Thanks to David, Kai, and Kevin for help with various phases of this challenge.
This is a writeup on solving a particular CTF challenge, as well as a meta-writeup on practical applications of using Burp Suite to beat HTML forms into submission when manual entry is becoming tiresome.
We start out with a sad story about employees exfiltrating data and are given a zip file containing “evidence.001”. We can run file on the file to figure out what it is:
$ file evidence.001
evidence.001: x86 boot sector; partition 1: ID=0x7, starthead 2, startsector 128,
198656 sectors, code offset 0xc0, OEM-ID " м", Bytes/sector 190,
sectors/cluster 124, reserved sectors 191, FATs 6, root entries 185,
sectors 64514 (volumes <=32 MB) , Media descriptor 0xf3, sectors/FAT 20644,
heads 6, hidden sectors 309755, sectors 2147991229 (volumes > 32 MB) ,
physical drive 0x7e, dos < 4.0 BootSector (0x0)
It appears to be a disk image. We ran parted to get a more intelligible printout of what the partitions are:
$ parted evidence.001
WARNING: You are not superuser. Watch out for permissions.
GNU Parted 2.3
Using /home/rmd/codegate/evidence.001
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit? [compact]? b
(parted) print
Model: (file)
Disk /home/rmd/codegate/evidence.001: 104857600B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 65536B 101777407B 101711872B primary ntfs
Now we can mount this on our system using the following command:
sudo mount -o loop,ro,offset=65536 evidence.001 /mnt/codegate/forensics
After a bit of poking around, this appears to be from an Iphone. Directory 5BB3AF5D-01CC-45D9-947D-977DB30DD439/ contains Dropbox.app, and Dropbox seems the likely suspect for exfiltrating documents, so I focused my attention there.
The files of interest that we found were 5BB3AF5D-01CC-45D9-947D-977DB30DD439/tmp/run.log, 5BB3AF5D-01CC-45D9-947D-977DB30DD439/Documents/Dropbox.sqlite, and 5BB3AF5D-01CC-45D9-947D-977DB30DD439/Library/Caches/cache.db
Looking through run.log, we found a few references to docx and txt files, but in the interest of not leading this story in circles, here are the ones that are specific to the file that was eventually the correct one:
2012-12-27 17:59:03.133 Dropbox[352:907] [INFO] DocumentWebViewController -
(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
navigationType:(UIWebViewNavigationType)navigationType 5 url = dbcache://dropbox//tim_folder/S-Companysecurity.pdf
2012-12-27 17:58:53.927 Dropbox[352:907] [INFO] FileViewController -
(id)initWithDirectoryEntry:, path = '/tim_folder/S-Companysecurity.pdf'
Browsing through Dropbox.sqlite, we found references to the same file “/tim_folder/S-Companysecurity.pdf”. This seems like a file that Tim should not be sending outside of the company, so it sounds like a winner. Along with this there are two date timestamps, ZMODIFIEDDATE: “378291232”, and ZLASTVIEWEDDATE: “378291543.163915”, and a size: “2249192”
These dont look like any date format I recognize, so we tried converting them using date -d "@378291232" -u, we got “Sun Dec 27 08:53:52 UTC 1981”. Adding 9 hours to convert to UTC+9, we get Sun Dec 27 17:53:52 UTC+9 1981. This date being in 1981 seems off, but the fact that the time and date are so close to the dates found in run.log is not likely a coincidence. The key here is to realize that Mac OS X dates are exactly 31 years after Unix epoch (Jan 1 1970). This means that this date is actually in 2012. Bingo.
Finally, with sqlitebrowser, In cache.db, there was an entry for tim_folder, and what looked like a base64 encoded block of data. Converting this to its original form with base64 -d -ifor100.base64.plist > for100.plist, we get an Apple binary property list. As this file is not very readable in binary form, we converted it to xml to get something more useful:CATURDAY.plist. Inside we found a few more dates related to S-Companysecurity.pdf:
378291354 - Sun, 27 Dec 2012 17:55:54 UTC+9
357554798 - Fri, 01 May 2012 17:46:38 UTC+9
At this point, we have everything needed to solve the problem, but the answers we submit don’t seem to be working. The format they specify is this:
Upload date&time(UTC+9:00)_Modified date&time(UTC+9:00)_Filename.extention_Filesize(logicalfilesize)
2013-03-01 21:00:00_2013-04-03 10:00:50_sample.docx_100MB
How many significant figures do they want on the file size? Is the upload date in run.log, or Dropbox.sqlite, or cache.db? After quite a while of trying permutations of these parameters, we are getting lazy, so it is time to start using a little brute force. Here is the python code to generate input strings:
dates = ("2012-12-27 17:53:52","2012-12-27 17:58:49","2012-12-27 17:55:54","2012-05-01 17:46:38","2012-12-27 17:59:03","2012-12-27 17:58:53")
sizes = ("2.14MB", "2.1MB", "2MB")
for d1 in dates:
for d2 in dates:
for s in sizes:
print d1+"_"+d2+"_S-Companysecurity.pdf_"+sThis gives us a list of all the possible permutations of dates and sizes, now it is time to feed them to the submission website using Burp Suite. We loaded up Burp Suite, set proxy to 127.0.0.1:8080 in browser settings, and disabled intercept under Proxy -> Intercept.
After loading up the CTF submission page, and sending in a key to test, there is now a POST under Proxy -> History containing the test key. We forward this to Intruder by right clicking on the post. Under Intruder -> Positions, we clear all the fields besides the key string that we are going to be iterating through. Under Intruder -> Payloads, we load the list of strings generated by the python script above. Now we launch intruder from the top drop-down menu, and wait for profit. At the end of the day, the winning string was:
2012-12-27 17:55:54_2012-05-01 17:46:38_S-Companysecurity.pdf_2.1MB