Defcon 20 CTF Prequals 2012 –
Grab Bag 200

Bei dieser Challenge (Grab Bag 200) wird uns eine Datei zur Verfügung gestellt und nicht mehr das Ziel “Get the key!” genannt. Die Festellung, dass es sich bei Datei um ein Zip-Archiv handelt, habe ich bereits voraus gegriffen und die Datei entsprechend umbenannt. ;-)

Beginnen wir also mit der ersten Untersuchung der Daten.

rup0rt@lambda:~/grab200$ unzip grab200-95a9797075e36edfe649a0141b7cf2b2.zip
Archive:  grab200-95a9797075e36edfe649a0141b7cf2b2.zip
  inflating: 115e0ba3c3d72647fcb9a53ae90e47a6.jpg  
   creating: __MACOSX/
  inflating: __MACOSX/._115e0ba3c3d72647fcb9a53ae90e47a6.jpg  

rup0rt@lambda:~/grab200$ file 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
115e0ba3c3d72647fcb9a53ae90e47a6.jpg: JPEG image data, JFIF standard 1.01

rup0rt@lambda:~/grab200$ file __MACOSX/._115e0ba3c3d72647fcb9a53ae90e47a6.jpg
__MACOSX/._115e0ba3c3d72647fcb9a53ae90e47a6.jpg: AppleDouble encoded Macintosh file

Das Archiv beinhaltet ein Bild im Jpeg-Format und eine versteckte Datei, die vom Namen her mit dem Bild assoziiert zu sein scheint. Vom bloßen Hinsehen scheinen wir bei diesem Spassbild die Lösung der Challenge jedenfalls nicht ablesen zu können.

Defcon 20 CTF 2012 - Grab Bag 200 - forensic image

Auch eine gezielte Suche nach dem Verzeichnis “__MACOSX” und dem Typ “AppelDouble encoded Macintosh file” bringt uns nur zu der Erkenntnis, dass es sich hierbei um einen sogenannten “resource fork” handelt, der bei Mac OS beim Packen von Archiven üblich ist. Sehen wir uns nun die beiden Dateien also etwas genauer an.

rup0rt@lambda:~/grab200$ ls -lh 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
-rw-r--r-- 1 rup0rt rup0rt 56K Jun  1 22:52 115e0ba3c3d72647fcb9a53ae90e47a6.jpg

rup0rt@lambda:~/grab200$ exiftags 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
exiftags: couldn't find Exif data

rup0rt@lambda:~/DC20/grab200$ strings __MACOSX/._115e0ba3c3d72647fcb9a53ae90e47a6.jpg
Mac OS X        
ATTR
)com.apple.metadata:kMDItemDownloadedDate
%com.apple.metadata:kMDItemWhereFroms
bplist00
bplist00
Ghttp://ircimages.com/ircimages/1/1/115e0ba3c3d72647fcb9a53ae90e47a6.jpg

Das Bild selbst beinhaltet keine EXIF-Daten und ist von der Größe her nicht sonderlich auffällig. Die Macintosh-Datei jedoch scheint den Link zu beinhalten, von dem die Datei herunter geladen wurde. Dies lässt mich vermuten, dass sich ein Vergleich der beiden Dateien zumindest lohnen könnte.

rup0rt@lambda:~/grab200$ wget -q http://ircimages.com/ircimages/1/1/115e0ba3c3d72647fcb9a53ae90e47a6.jpg -O original.jpg

rup0rt@lambda:~/DC20/grab200$ ls -lh original.jpg 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
-rw-r--r-- 1 rup0rt rup0rt 56K Jun  1 22:52 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
-rw-r--r-- 1 rup0rt rup0rt 56K May 25 08:31 original.jpg

rup0rt@lambda:~/grab200$ md5sum original.jpg 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
f746d011669c1a22c32ac8d478e2ef2f  original.jpg
5b1c17edb22fcd8884e00b0c8c8b898f  115e0ba3c3d72647fcb9a53ae90e47a6.jpg

Die unterschiedlichen Prüfsummen der beiden Dateien zeigen deutlich, dass etwas an dem entpackten Bild anders sein muss. Das können wir jetzt entweder mit einem Hex-Editor manuell prüfen oder bequem das Werkzeug stegdetect verwenden.

rup0rt@lambda:~/grab200$ stegdetect 115e0ba3c3d72647fcb9a53ae90e47a6.jpg
115e0ba3c3d72647fcb9a53ae90e47a6.jpg : appended(84)<[nonrandom][data][..H....PV.....E.]>

Aha! Es wurden scheinbar 84 Bytes Daten an das Bild angehangen. Extrahieren wir diese Bytes zunächst mit dem Werkzeug “tail” und sehen sie uns dann genauer an.

rup0rt@lambda:~/grab200$ tail -c 84 115e0ba3c3d72647fcb9a53ae90e47a6.jpg > data

Defcon 20 CTF 2012 - Grab Bag 200 - pcap inside jpeg image

Die extrahierte Zeichenkette “13.12.11.10.in-addr.arpa” lässt sehr stark auf eine DNS-Anfrage schließen und damit auf ein mögliches Netzwerk-Paket, das an das Bild angehangen wurde. Um dieses besser lesbar zu machen, können wir es in das Pcap-Format überführen. Dazu fügen wir 16 beliebige Bytes (einen Pseudo Pcap Packet Header) an die Datei an und versuchen sie mit dem Werkzeug pcapfix zu reparieren.

rup0rt@lambda:~/grab200$ perl -e "print 'A'x16" | cat - data > data.pcap

rup0rt@lambda:~/grab200$ pcapfix data.pcap
pcapfix 0.6 (c) 2012 Robert Krause

[*] Reading from file: data.pcap
[*] Writing to file: fixed_data.pcap
[*] Analyzing global header...
[-] The global pcap header seems to be missing ==> CORRECTED!
[*] Analyzing packets...
[*] End of file reached. Aligning last packet.
[+] CORRECTED LAST Packet #1 at position 0 (0 | 0 | 84 | 84).
[+] Success!

Your pcap file has been successfully repaired (1 corrupted packet(s)).
Wrote 1 packets to file fixed_data.pcap.

Nachdem die Reparatur erfolgt ist, sehen wir uns die Daten, die nun im pcap-Format vorliegen, mit Wireshark an.

Defcon 20 CTF 2012 - Grab Bag 200 - extracted pcap data

Auch Wireshark teilt uns nun mit, dass es sich um ein DNS-Paket handelt. Darüber hinaus erfahren wir, dass es mit einer PTR-Anfrage nach “13.12.11.10.in-addr.arpa” vom Quellport 31337 an die IP-Adresse 140.197.217.85 gesendet wurde. Diese Anfrage stellen wir nun mit dem Werkzeug “dig” nach.

rup0rt@lambda:~/grab200$ dig @140.197.217.85 -b "0.0.0.0#31337" 13.12.11.10.in-addr.arpa PTR

; <<>> DiG 9.7.3 <<>> @140.197.217.85 -b 0.0.0.0#31337 13.12.11.10.in-addr.arpa PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48543
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;13.12.11.10.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
13.12.11.10.in-addr.arpa. 86400 IN      PTR     dan.kaminsky.kung.fu.

;; Query time: 169 msec
;; SERVER: 140.197.217.85#53(140.197.217.85)
;; WHEN: Sun Jun  3 17:23:30 2012
;; MSG SIZE  rcvd: 76

Der Server antwortet uns tatsächlich auf unsere Anfrage nach einer eigentlich lokalen IP-Adresse mit dem Host-Namen “dan.kaminsky.kung.fu.“. Dieser stellt zeitlich die korrekte Antwort zu dieser Challenge dar!

Leave a Reply

Your email address will not be published. Required fields are marked *