Nebula is the first VM of exploit-exercises.com and I highly recommend it to those who want to challenge themselves to discover vulnerabilities, practice privilege escalation, exploit development, debugging, reverse engineering and other cyber security issues.
It consists of 20 different levels. Let’s take a look at level 01.
To Download It!
Nebula – level 01
The first thing you need to do is downloading the VM, run it and log in using user: level01 and password level01 if you didn’t do it yet.
Read carefully the description of the exercise. The goal is to capture the flag.
The description tells us that the vulnerable program is located at /home/flag01.
Now it’s time to focus on the source code that is kindly provided. It looks like a small C program. If you don’t know what gid and uid are you can just google them. I also recommend you to read about level00 still on my blog.
The functions setresgid() and setresuid() set the gid and uid of the process to the effective gid and uid. Do you remember the difference between real, effective and saved gid and uid? If not, study about it.
Then we see the last important statement that is a system() function call. Even if you don’t know C, it simply executes a command. It behaves the same way as if you open a terminal window and type the command yourself and press enter. The argument inside the system() function seems to be unique but actually it can be decomposed into 3 parts:
- /usr/bin/env – a path
- echo – a linux command
- and now what? – this looks like a normal string.
The best way to learn more about it is just to run it and see what happens. After that, you may need to find a way to pass some arguments (maybe) or do something else to alter the program flow (maybe) and get the flag. These are just hypotheses. See, I also wrote “maybe”, I don’t want to spoil the solution yet.
This should be enough to give you the necessary knowledge for solving the challenge. I recommend you to try by yourself first and if you don’t find the way to solve it soon don’t worry. Chances are it is the first challenge you do, so that’s alright. Try harder! If you really got stuck and you want to see the solution, check the paragraph below.
Solution – Walkthrough
Read the description of the exercise again. You need to get the flag.
Okay, the description says that the program is located in /home/flag01. Let’s check to confirm.
Good. Now let’s run it to see what happens.
The text “and now what?” is printed on the screen as expected.
We can try to supply some arguments to the program and see if they get executed, but it seems we’ve got no luck with this approach. Nothing happens, we just get the annoying and challenging text. We have to do something about that. We want to capture the flag.
Hmm the system() function looks interesting anyway. Let’s look at it again.
Did you check /usr/bin/env as I suggested you before?
Yup, that’s a program itself. If you run it you can see a long output on your screen, in particular you can see the PATH variable. That is a system environment variable that defines the location where to look for executables when they are invoked by their name. It isn’t just one, but chances are you can see several ones like /usr/bin , usr/local/bin and so on. The interesting thing is that order matters. The executable is searched in the first path in the list, if not found it is then searched in the second location and so on. The PATH variable isn’t something immutable, but can be changed as we please.
Let’s keep that in mind. It can prove useful to know.
Then the echo command. This is a common program located in usr/bin and we can see that by using the command which echo.
In order to solve the challenge we should be able to run the getflag program located in /bin/ . How can we do that?
It would be great if when the program echo is called, getflag is executed instead.
Magic? Almost, but pretty doable in this case.
Hmm every file has a name just like every person has. Just as we can give a nickname to someone we can also create an alias for a command or a symbolic link. A symbolic link contains a reference to a file or a directory in the form of an absolute or relative path and that affects pathname resolution.
A handy path we could choose is the /tmp/ path, because it usually has read, write and execution permissions.
Let’s try to add the the /tmp/ path to the system paths:
Now let’s try to create a symbolic link between the echo program and the getflag program that we want to execute
ln -s /bin/getflag /tmp/echo
We can check the new path associated to the echo command by issuing the command which echo:
As you can see, the path of echo changed from /bin/echo to /tmp/echo. Great! That’s what we wanted.
Now let’s cd into /home/flag01 and run the vulnerable program flag01
And we finally get the flag:
You have successfully executed getflag on a target account.
That’s what we wanted to hear 🙂
This is the end of the challenge, but if you wanted to do more, you could try to execute also other commands..maybe inject /bin/bash and get a shell 🙂 Remember that whatever command you run, the command isn’t executed by the account level01, but by the account that owns flag01 that may run with higher privileges and thus, it may lead to privilege escalation.
Author: Fabio Baroni Date: 2016-10-02 13:56:40