WOWHacker CTF – Challenge 2 and Challenge 9
August 26, 2009 by thaidn · Leave a Comment
Challenge 2
Challenge 2 is simple yet interesting. The initial target is a Python 2.2 byte-compiled file, so the first job is to decompile it to get the source code. Fortunately, decompyle just works:
$ decompyle newbie.pyc
Thu Aug 27 02:13:25 2009
# emacs-mode: -*- python-*-
import urllib
def some_cryption(arg):
pass
a = 'http://'
dummy = 'http://korea'
b = 'uxcpb.xe'
b = b.encode('rot13')
c = 'co.kr'
cs = '.com'
d = '/vfrp/uxuxux'
dt = '/hackers'
d = d.encode('rot13')
dx = 'coolguys'
ff = urllib.urlopen(((a + b) + d))
f_data = ff.read()
file = open('hkhkhk', 'w')
file.write(f_data)
some_cryption(f_data)
file.close()
You can see that the purpose of this script is to download some data from a fixed URL, and save them to a file named hkhkhk. We ran the script, and it indeed downloaded this file. As the script suggests, the content of hkhkhk is encrypted by some cipher.
Opening hkhkhk in a hex editor, one could see that it contains quite a lot of 0×77 characters. A friend of us, Julianor from Netifera, thought that hkhkhk is an executable file, and because excutable file contains a lot of null bytes so 0×77 may be the null byte in the original file. He suggested xoring the content of hkhkhk against 0×77. We did as he suggested, and it worked :-D. hkhkhk turns out to be an ELF executable file:
$ file hkhkhk hkhkhk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped $ ./hkhkhk ./hkhkhk [server] [port] --------------------------- server> 221.143.48.88 port> 1111, 2222, ..., 9999 ---------------------------
Disassembling hkhkhk reveals that this binary is just a simple client that connects to a remote server to get two integers, and send the sum of them back to that server. If the result is correct (which is always), the server will return a congratulation message like below:
$ ./hkhkhk 221.143.48.88 1111 [(867925) + (9792)] = ? answer is 877717 it's correct. great!, :-)
At first, we thought we should try to exploit the server to force it to return an error or something, but that didn’t work. Then we thought there’s something hidden inside hkhkhk, so superkhung and I spent 1 hour to inspect every single instruction of the binary, but we saw nothing weird.
At this point, a friend suggested us running the binary inside a debugger. He thought that there may be something hidden in the communication between the server and hkhkhk.
The communication? I fired up wireshark, and to my surprise, I saw the answer right away: Pandas likes hkpco XD. It turns out that the congratulation message is something like:
it's correct. great!, :-)<b>\x00</b>Password is "Pandas likes hkpco XD"
This message is passed to a printf call, and since printf expects a null-terminated string, one could never see the characters after the null byte if he doesn’t run the binary inside a debugger, or sniff the communication like us.
Challenge 9
Challenge 9 (IP: 221.143.48.88; port :4600) is a remote stack-based buffer overflow exploitation. It’s interesting because WOWHacker doesn’t release the binary as other usual exploitation challenges.
While I was banging my head against challenge 8, gamma95 told me that he could crash challenge 9 with 293 bytes. He thought that this challenge is very obvious, and wondered why none was working on it.
Actually we were very short on manpower in the first day of the premilinary round. So we chose to work only on those challenges that we were interested in or had a larger chance of solving them.
When I first saw challenge 9, I thought this challenge should be hard. Blind remote exploitation is supposed to be hard you know. This wrong assumption plus the fact that I haven’t practiced software exploitation in the last several months made me decide to leave this challenge for other teamates who might join us in the second day.
But it turns out this challenge is an easy one.
In order to exploit a stack-based buffer overflow vulnerability, one must know which address to return to. Fortunately, WOWHacker gives us a very helpful hint:
Mr.Her give you something "call me~ call me~" : bfbfeaf2
So 0xbfbfeaf2 is the return address. Normally this address should point to the beginning of our input buffer which in turn should have this structure:
<SHELLCODE><NOP SLED><\xf2\xea\xbf\xbf>
The next problem is to determine how many bytes we need to control the EIP. The trick is to use \xeb\xfe as the shellcode, and increase the message one byte a time until we see the service hang after it processes our input. If our theory of the structure of the input buffer is correct, this process will succeed eventually because \xeb\xfe means “loop forever”:
$ echo -ne '\xeb\xfe' | ndisasm - 00000000 EBFE jmp short 0x0
Using this technique, we can see that we need totally 302 bytes to control the EIP:
$ (python -c 'print "\xeb\xfe" * 149 + "\xf2\xea\xbf\xbf"'; cat) | nc 221.143.48.88 4600
We use Metasploit to generate a BSD reverse-shell shellcode, and we got the answer: WOWHACKER without beist.
Actually this wasn’t as easy as we write here. We made two stupid mistakes: first off, we assumed that this challenge ran on a Linux box; secondly, our connect back box was behind a firewall :-(. Thanks Tora and biest for giving us a hand in resolving them.
WOWHacker CTF – Web Hacking Challenge
August 25, 2009 by thaidn · Leave a Comment
Challenge 8 (not accessible atm) is the only web hacking challenge in WOWHacker’s CTF. In hindsight it’s not very difficult, but in fact it took us almost 1 day to solve it.
This is a classic PHP local file inclusion attack. If you set the parameter ty and the cookie 71860c77c6745379b0d44304d66b6a13 to the same file name, the vulnerable PHP script in challenge 8 would try to include that file. Here’s what the code looks like:
$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
{
echo "Error!";
}
else
{
if (include($ty) != 'OK')
{
echo "Can't find that page!";
}
}
Update: gamma95 has just noticed me this challenge may not be a PHP local file inclusion attack. Maybe it’s just a vulnerable readfile call like this:
$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
{
echo "Error!";
}
else
{
if (file_exists($ty))
{
readfile($ty);
}
else
{
echo "Can't find that page!";
}
}
For vulnerable scripts like this, the trick is to include files in known location which may contain important information, i.e. Apache httpd’s error_log or access_log. As we knew this is a Windows machine, we tried to test our theory by including C:\Windows\system32\drivers\etc\hosts which worked as expected. At this point, we thought we were just moments away from the solution of this challenge, but in fact we were totally stuck for the next several hours.
We went on to guess the location of Apache httpd’s log files. We sent hundreds of requests, but none worked. I even downloaded and installed a copy of Apache httpd to understand its directory structure but still no luck. Why it didn’t work???
Like challenge 1, it wasn’t until we almost gave up on this challenge, we realized the simple fact: we always thought that the web server was Apache httpd while it was IIS actually! Years of abandoning Windows has brainwashed us! What a shame!
The next steps are simple. The default IIS installation would store log files in C:\WINDOWS\system32\LogFiles\W3SVC1\exYYMMDD.log. As the premilinary round started on 2009.08.14, we guess we should include C:\WINDOWS\system32\LogFiles\W3SVC1\ex090814.log which in turn reveals this secret script:
/tmxhffjsqkdlxmwhaWkddlsemt/answpsorltlagkrpglaemfdjttmqslek/rmfoehrufrnrdpsvntutspdy.php
This script asks for a username and password which gamma95 had bypassed it using a trivial SQL injection attack even before I figured out what I should do next. After bypassing the authentication, we obtained the flag which is: Do you know StolenByte???
No we don’t know him, but thanks for a nice challenge!
WOWHacker CTF – Crypto Challenges
August 25, 2009 by thaidn · Leave a Comment
Challenge 1
Challenge 1 is…crazy hahaha. Only one or two teams could solve it until the author (hello hinehong :-D) gave out a list of 7 hints. I have designed some web-related crypto challenges (which you will see soon ^^) so I think the difficulty of challenge 1 relies on how fast people can guess the meaning of the cookie. It would be easier for the teams if the author sets the cookie as cookie = cipher + “|” + key. BTW, here’s my solution.
When you access the link above, you’ll see a bunch of javascripts. After decoding those javascripts (which I leave as exercise for readers), you’ll see a form whose target is http://221.143.48.96:8080/you_are_the_man_but_try_again.jsp. This form accepts a parameter named “hong” which is either true or false. If you set hong=true, the server sends back a cookie like below:
id=<code>pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e</code>
This looks like a base64 encoded string, but it’s not. In fact you need to modify it a little bit before you can base64 decode it. This is, as I said previously, why this challenge is hard.
One trick I learn from this challenge is to guess the boundary between key and cipher text, one should try to truncate one character a time and base64 decode the string until he gets an output whose length in bytes is a multiple of 8 or 16, which are common block cipher’s block length.
The cookie can be either “cipher + key” or “key + cipher”, so one should try the above process in both cases. If you can’t find any such output, then you know your theory is wrong, i.e. the cookie is in some other form. Fortunately, my theory is right in this case.
It turns out that the first 32 bytes of the cookie is the cipher text, and the rest 8 bytes is the key. It’s a 8-bytes key, so this cookie should be encrypted by DES which is a popular 8-bytes key block cipher. I wrote a small python script to decrypt the it:
>>>from Crypto.Cipher import DES >>>cookie = 'pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e' >>> key = cookie[32:] >>> data = base64.b64decode(cookie[0:32]) >>> des = DES.new(key, DES.MODE_CBC) >>> des.decrypt(data) 'wowhacke\xd6\xe0\xbc*e\xe7\n\xc7\x1a\xf92w6H\xfd\xe5'
Hmm. I remembered I tried to submit ‘wowhacke’ to the scoring server, but, of course, it’s not the correct answer. Then I wasted the next hour to test various stupid theories to understand what the last 16 bytes of the output are.
It was not until I nearly gave up on this challenge, I realized the obvious: this is mode ECB stupid!!! Why on earth I always thought it’s CBC? I changed the mode, and the result is:
>>> des = DES.new(key) >>> des.decrypt(data) 'wowhacker@!hine@ipsec\x03\x03\x03'
Remember those ‘\x03\x03\x03′. You’ll see them again in my crypto challenges ;-).
Challenge 10
Challenge 10 is cool. In summary, the author sets a RSA private key as a property of a Java object, then he gives out the serialization stream of that object, and asks teams to recover the private key to decrypt a ciphertext.
So the first thing we must do is to understand how Java does serialization. I was never a fan of Java, so this is something completely new to me. But that’s why I really enjoy playing capture the flag games. It forces me to learn new thing fast in a very short time.
I spent nearly 1 hour reading the spec, mostly on the object serialization stream protocol. Then I spent one and a half hour starring at my hex editor screen and acting as a binary parser which was, I don’t know why I feel that, really fun (later on Tora of SexyPwndas fame showed me a much less painful way to recover the object. Thanks Tora!)
I recovered the RSA private key eventually. How to use it to decrypt the ciphertext in key.txt? While de-serializing the object, you would see that there’s a field named tripleDesKey containing a 24-bit string which you can get by base64-decoding the last 32 bytes of the serialized object.
At first I thought I should use the RSA key to decrypt this 24-bit string to get the real tripleDesKey, and uses that key in turn to decrypt key.txt. This hybrid approach is the standard way to do encryption using public key cryptosystem. But you shouldn’t expect anything standard in CTF, rite?
It turns out all that tripleDes key and ciphertext are just there to distract me. I have to admit that I don’t like challenges giving false trails. You can either give good trails or no trail at all. Giving false trail is a sin :-P.
Anyway, if you look at key.txt, you’ll see that its content is a 128-bytes string. 128-bytes = 1024-bit = the size of the modulus in the recovered RSA private key. So this string should be the ciphertext encrypted directly using the RSA private key. Indeed it is!
>>> from M2Crypto.RSA import *
>>> rsa = load_key('my_rsa_key')
>>> data = open('key.bin').read()
>>> rsa.private_decrypt(data, 3)
'\x00\x02#padding#x00isec@#$wowhacker!!'
There’s a small minor issue that I intentionally left out. Can you find out what it is and resolve it yourself?
I hope you enjoy reading this. Happy hacking!
