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.
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
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.
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!