_______________________________________________________________________

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/^://'`
************

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).

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 a
program 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:

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:

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.

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.