mercredi 19 juin 2013

Writeup for naga3 @ NoSuchCon CTF 2013

This is a writeup for the naga3 challenge that was part of the NoSuchCon 2013 CTF. I picked this challenge for the Montréhack session I was hosting this month as I found it quite interesting and a bit different than the challenges I did in the past. Montréhack is an informal group that gathers every month to practice CTF challenges and the solution is presented at the end; if you live in the Montreal area feel free to drop by, it's a lot of fun and a great way to learn. For the purpose of this article I will use the challenge environment I recreated for the event, the paths are different than on the CTF server but I used the original binary.

The challenges are accessible at OverTheWire so if you want to try it by yourself first you should stop reading now.

The original description of the challenge was "To monitor local system performance, a tool was developed to take some timing measurements by executing some commands." The first step was to find the binary. Searching for files owned by naga3 shows a program called rtv. rtv is SUID on user naga3. (To simplify things, I put the program and source code directly in /home/level2/ on my VM for Montréhack.)

naga2@naga:/$ find . -user naga3


We now have access to the binary and the source code of the program. As rtv.c is actually quite short, I reproduce it here.

Review of rtv.c

Let's examine the main() function first. We see that a pipe is created [1], then a child process is created with fork [2]. In the child process, the SETUID privileges are dropped [3] and then the process is made debuggable with ptrace via the call to prtcl(PR_SET_PTRACER) [4]. Finally, we see that the parent and child process execute functions that have to do with "measurements" and each uses one side of the pipe [5]. We can assume that information will be passed between both processes.

Figure 1 - main function of rtv

The call to prctl() with PR_SET_PTRACER has a big impact here. Ptrace allows us to read and modify memory of the process, set breakpoints and modify register values (including EIP). The end result is that the code of the child is now irrelevant, we can replace it with whatever we want. This is something we will put to use later on.

Systematic failure

We then inspect the functions that are called in the child process. The first one is make_measurements(). This function iterates over the entries defined in the Measurement table [1] (see Figure 3). This table contains measurement_t structures which contains commands. Those commands are executed via system() [2], the output is redirected to /dev/null. Finally the function the execution time of the commands in the runtime member of the structure in the Measurements table.

Figure 2 - vulnerable call to system() in make_measurements

Figure 3 - The Measurements table

As we can see, the commands that are called are defined with relative paths. This is classic vulnerability on UNIX systems. To exploit this, we simply need to modify the PATH environment variable to add a folder that we control at the beginning and create an executable file (a shell script works just fine) for one of the commands in it (for example env in this case). The result will be that our executable will be called instead of the intended one.

However, in this case this is not sufficient to read the flag. As the calls to system() are made by the child process, the SETUID privileges have already been dropped by then. It does however allow us to easily retrieve the pid of the child process as it is put in the PARENTPID variable when the commands are called. This will be of great importance in the next part. (Note : on the original CTF server, /proc/ was disabled, probably to avoid snooping between competitors. The PARENTPID variable was thus needed).

Let's talk

The last part of the program is where the child process returns the measurement data to the parent process which in turn prints it to the standard output  via print_measurements().

We see that report_measurements() iterates over the Measurement table with a for loop and writes 1) i, the index in the table and 2) runtime, the execution time of the executed command.

Figure 4 - report_measurements() in the child process
The same thing is done in read_measurements() in the parent process, however it is done slightly differently. The function enters in a while loop and reads the data provided in the pipe, if the size of the reads don't correspond to the expected size the program stops execution there [1]. The runtime information is then written in the Measurements table of the parent process, the loop ends when i is equal to the last index of the table (measurementCount - 1). 

Normally this would be fine if we expect the child to behave correctly. However, due to our ability to use ptrace on the child process and modify the data written in the pipe, we can cause  a write outside of the Measurements table [2]. We will also control 8 bytes at every write, since we control i we can make as many writes as we want.

Figure 5 - read_measurements() in the parent process

Arbitrary write? not quite

We now know that we can cause memory overwrites in the address space of the parent memory. But where exactly can we write? Figure 6 shows the assembly code from IDA corresponding to the Measurements[i].runtime = t; statement in read_measurements(). 0x0804100 is the address of the first runtime entry in the Measurements table. Then i is multiplied by 0x88 which is the size of the measurement_t structure (128 bytes for cmd + 8 bytes for runtime).

Figure 6 - Memory overwrites in read_measurements()
The multiplication is somewhat obscured as it optimized with shift-left instructions, each shift multiplies by 2.

shl eax,   3; eax = i * 8
mov ebx, eax; ebx = i * 8 
shl ebx,   4; ebx = i * 8 * 16 = i * 128
add eax, ebx; eax = i * 8 + i * 128 = i * 136 (136 equals 0x88)

The write address can be determined with the following formula :

       writeAddr = 0x804A100 + i * 0x88

If you are lucky enough to have a license for it, Hexrays Decompiler actually provides the formula directly.

Figure 7 - writeAddr formula in Hexrays Decompiler

We now need to find one or may memory address(es) to overwrite to hijack the control flow of the program. The GOT (Global Offset Table) is usually a good candidate. It can be dumped with the command objdump -R rtv.

level2@montrehack:~$ objdump -R rtv

rtv:     file format elf32-i386

OFFSET   TYPE              VALUE
08049ffc R_386_GLOB_DAT    __gmon_start__
0804a32c R_386_COPY        stderr
0804a00c R_386_JUMP_SLOT   setresuid
0804a010 R_386_JUMP_SLOT   read
0804a014 R_386_JUMP_SLOT   printf
0804a018 R_386_JUMP_SLOT   gettimeofday
0804a01c R_386_JUMP_SLOT   __stack_chk_fail
0804a020 R_386_JUMP_SLOT   getuid
0804a024 R_386_JUMP_SLOT   perror
0804a028 R_386_JUMP_SLOT   fwrite
0804a02c R_386_JUMP_SLOT   getpid
0804a030 R_386_JUMP_SLOT   puts
0804a034 R_386_JUMP_SLOT   system
0804a038 R_386_JUMP_SLOT   __gmon_start__
0804a03c R_386_JUMP_SLOT   exit
0804a040 R_386_JUMP_SLOT   __libc_start_main
0804a044 R_386_JUMP_SLOT   write
0804a048 R_386_JUMP_SLOT   getgid
0804a04c R_386_JUMP_SLOT   prctl
0804a050 R_386_JUMP_SLOT   pipe
0804a054 R_386_JUMP_SLOT   fork
0804a058 R_386_JUMP_SLOT   sprintf
0804a05c R_386_JUMP_SLOT   setresgid

Inspecting the code of the program reveals the functions read, printf and exit might be called after memory corruption, being able to overwrite the entry of one those should allow us to redirect execution.

A naive approach would be to calculate the write addresses for each value of i. This can be done with the following script :

While this approach will find a result, it is very slow. A better approach is to take into account the fact that the value of writeAddr grows by 0x88 each time i is increased. We can bring back writeAddr around the area of the address we are targeting by increasing i so that it cycles over the 32 bit address space. To obtain this value, we divide 0xFFFFFFFF by 0x88 which gives us 31 580 641. Then it's just a matter of adjusting i upward or downward until we are between 0x88 bytes of our target address. We have now saved 31 580 640 useless computations, that's  a nice optimization :-)

The script actually executes instantly, provided that our target address is near the base address 0x0804A100 which is the case for the GOT. Here is a part of the output for read.

ekse@montrehack:~/level2$ python
i = -0000001 writeaddr =  0804a078 diff = 104
i = 01e1e1e1 writeaddr =  0804a088 diff = 120
i = 03c3c3c2 writeaddr =  0804a010 diff = 0
i = 05a5a5a3 writeaddr =  08049f98 diff = 120
i = 07878785 writeaddr =  08049fa8 diff = 104
i = 09696967 writeaddr =  08049fb8 diff = 88
i = 0b4b4b49 writeaddr =  08049fc8 diff = 72
i = 0d2d2d2b writeaddr =  08049fd8 diff = 56
i = 0f0f0f0d writeaddr =  08049fe8 diff = 40
i = 10f0f0ef writeaddr =  08049ff8 diff = 24
i = 12d2d2d1 writeaddr =  0804a008 diff = 8
i = 14b4b4b2 writeaddr =  08049f90 diff = 128
i = 16969694 writeaddr =  08049fa0 diff = 112
i = 18787876 writeaddr =  08049fb0 diff = 96
i = 1a5a5a58 writeaddr =  08049fc0 diff = 80
i = 1c3c3c3a writeaddr =  08049fd0 diff = 64
i = 1e1e1e1c writeaddr =  08049fe0 diff = 48
i = 1ffffffe writeaddr =  08049ff0 diff = 32
i = 21e1e1e0 writeaddr =  0804a000 diff = 16
i = 23c3c3c1 writeaddr =  08049f88 diff = 136
i = 25a5a5a3 writeaddr =  08049f98 diff = 120
i = 27878785 writeaddr =  08049fa8 diff = 104
i = 29696967 writeaddr =  08049fb8 diff = 88
i = 2b4b4b49 writeaddr =  08049fc8 diff = 72
i = 2d2d2d2b writeaddr =  08049fd8 diff = 56
i = 2f0f0f0d writeaddr =  08049fe8 diff = 40
i = 30f0f0ef writeaddr =  08049ff8 diff = 24

We can see that by using an i value of 03c3c3c2 we are able to overwrite read directly. - ptrace to my heart

I wrote a script using python-ptrace to modify the values of i and runtime that are sent in the pipe by the child process. To go faster, I actually used the Gdb implementation provided with the library which allows to easily create breakpoints and modify memory and registry values.

The code is actually quite simple. It sets 2 breakpoints, one before the write of i in the pipe and the second before the write of runtime. In each case eax points to the data that will be written, we simply  point it to another address with our own supplied data. Note that in this debugger, breakpoint are removed after being hit so they will be executed only for the first command. To test that it works, we overwrite the address of read in the GOT with 0x41424344.

The setup of our exploit will be as follow :

  1. Create an env script that writes PARENTPID to a file  named "pid"
  2. run PATH=.:$PATH rtv
  3. run and attach to the child process

Here is the output of when executed.

ekse@montrehack:~/level2/$ ./
Waiting for pid...
Switch to
[!] attached to 1188
New breakpoint:
New breakpoint:
PID: 1188
Child process 1191 exited normally
Signal sent by user 1000
interrupted by SIGCHLD
EIP: 0xb775d424L
PID: 1188
Child process 1199 exited normally
Signal sent by user 1000
interrupted by SIGCHLD
EIP: 0xb775d424L
PID: 1188
Child process 1201 exited normally
Signal sent by user 1000
interrupted by SIGCHLD
EIP: 0xb775d424L
PID: 1188
Child process 1203 exited normally
Signal sent by user 1000
interrupted by SIGCHLD
EIP: 0xb775d424L
Stopped at
EIP: 0x80487d6L
Current id loc: 0xbff5295cL value : (0,)
Changing data location for write of id...
Stopped at
EIP: 0x8048802L
Process 1188 exited normally
Unhandled exception : None

And sure enough, when running rtv in GDB execution ends up at 0x44434241.

ekse@montrehack:~/level2/exploit_1$ ./

(gdb) run
Starting program: /home/level2/rtv
Command runtime verification tool v1.0
Please wait while command runtimes are being verified...

Program received signal SIGSEGV, Segmentation fault.
0x44434241 in ?? ()

(gdb) bt
#0  0x44434241 in ?? ()
#1  0x080489d5 in read_measurements ()
#2  0x08048bdc in main ()

Where do we put our shellcode?

We now have control of the execution of the parent process. The last thing we need to do is to figure where to put our shellcode and jump to it. A technique is often use when doing this kind of challenge is to put the shellcode in an environment variable, prepend a large nopsled in front of it and jump somewhere in it. However this approach does not work as the stack is defined as non-executable, which we can confirm with execstack.

ekse@montrehack:~/level2/exploit_1$ execstack /home/level2/rtv
- /home/level2/rtv

If we look at the output of the script, we see that we can have multiple consecutive writes of 8 bytes so we should probably be able to write a short shellcode somewhere. The problem we are facing is that none of the memory section of rtv is both writeable and executable.

Figure 8 - Permissions of the memory segments of rtv

Another approach would be to use a ROP payload to set the memory region where we put our shellcode executable, but that is somewhat complicated and I'm lazy so I kept looking for an easier way. I reviewed what could be overwritten in the memory and thought about the commands in the Measurements table. We could probably overwrite one of the commands and have it execute what we want, but that doesn't work either as it's the commands in the child address space that are executed... and then it all became clear.

All we need to do is to redirect execution to make_measurements() so that it is executed in the parent process. This way we can use another command that is called by system() (I used md5sum) to copy the flag. The final setup of our exploit is like this :

  1. env is a script that writes PARENTPID to the file "pid"
  2. md5sum is a script that copies the flag to the file "flag"
  3. run PATH=.:$PATH rtv
  4. attach to the child process with
  5. Overwrite the address of the read() function in the GOT with the address of make_measurements()
  6. md5sum is called by the parent process, we win.

You can find the code of the exploit and the scripts I presented on my github repository. The slides I made for Montréhack are also available.


This challenge required the use of 3 different vulnerabilities of the program. Each of those taken separately was not sufficient to exploit the program. This is something that is often needed today to bypass modern protection mechanisms, for example one of the winners of Pwn2Own last year used 6 vulnerabilities to exploit Google Chrome.

As I write these lines, I just learned about a new vulnerability in FreeBSD that was disclosed today and that involves ptrace and mmap. While the context is completely different, it's funny to see that the exploit code is actually simpler than what we had to do =) 

If you have questions or would like something to be clarified in the post, feel free to email me at Happy hacking!

vendredi 3 mai 2013

Unpacking exploit kits with Fiddler

Most exploit kits use javascript packing to avoid the code appearing in plain text. Figure 1 shows an example of such a packed script. Multiple techniques and tools exist to help in the task of unpacking and analyzing these kits, for example Kahu Security has many articles on his blog about this. This post presents a quick and dirty method I have been using a lot recently; it uses Fiddler and its AutoResponder feature. The idea is to modify the Javascript code and then replay the HTTP traffic in the browser. If you want to try this technique, here is the Fiddler HTTP archive I used as an example (archive password is "infected").

Figure 1 Packed Blackhole Exploit kit
The first step involves capturing the kit with Fiddler. Then activate the AutoResponder feature as shown in Figure 2. Next drag the sessions corresponding the kit traffic in the AutoResponder panel. In this example  this is the first session.

Figure 2 Enabling AutoResponder
Next edit the session, you can use the context menu or just press Enter.

Figure 3 Editing the response

Now I want to modify the script to be able to see the unpacked code so I open the Syntax View tab. This part is different from one pack to another and you might need multiple attempts to figure out the best way to do it. In this example the pack is Blackhole, there is an eval statement at the end very end that executes the script after it is unpacked.I use console.log to get the content, so I replace w(c) by console.log(c) and hit Save.

Figure 4 Deciding what to modify

Next I open Google Chrome (make sure it is configured to use Fiddle as a proxy), open the Developer Console with F12 and click on the Console tab. I then browse to the pack URL, in this example (you can use Ctrl+U to copy the URL from a session). If all went well the unpacked code should appear in the logs.

Figure 5 unpacked script in the logs
Another neat feature of Fiddler is the code beautifier. I copy the script from the log, replace the original script in the SyntaxView and click on Format Script/JSON. The code is now well formatted and ready for analysis.You can find the unpacked code here. Note that this is an old version of Blackhole v1 from February 2012 but the technique still works today.

Figure 6 Format Javascript code

Figure 7 Formatted Blackhole code

This is a quick and dirty technique and could easily be defeated but it works with many packs. If you have any question leave a comment or email me at