PoliCTF 2012 – Bin-Pwn 100

Für die “Bin-Pwn 100” Challenge wird uns ein Archiv bereit gestellt sowie die recht simple Aufgabenbeschreibung:

Retrieve the key!

genannt.

Wir arbeiten uns also langsam vor, entpacken als erstes die Datei und sehen uns den Inhalt genauer an:

rup0rt@linux:~/PoliCTF2012$ tar xfvz umad.tar.gz 
jpeg/
jpeg/jconfig.h
jpeg/jpeglib.h
jpeg/jmorecfg.h
jpeg/jerror.h
libjpeg.a
Makefile
umad.cpp

Im Archiv befinden sich Header-Dateien der JPEG-Bibliothek, die statisch kompilierte JPEG-Bibliothek selbst (libjpeg.a) sowie eine C++-Quellcodedatei “umad.cpp” und deren Makefile. Wir kompilieren zunächst den Quellcode mit Hilfe der “Makefile” um so das Verhalten abzuschätzen.

rup0rt@linux:~/PoliCTF2012$ make
g++ -o umad umad.cpp -L. -ljpeg

rup0rt@linux:~/PoliCTF2012$ ./umad 
Done

rup0rt@linux:~/PoliCTF2012$ ls -lh
drwxr-xr-x 2 creeq creeq 4.0K May 26 00:23 jpeg
-rw-r--r-- 1 creeq creeq 1.4M Aug  8 16:11 libjpeg.a
-rw-r--r-- 1 creeq creeq   56 May 26 00:30 Makefile
-rw-r--r-- 1 creeq creeq  13K Nov 21 17:15 out.jpeg
-rwxr-xr-x 1 creeq creeq 422K Nov 21 17:15 umad
-rw-r--r-- 1 creeq creeq 3.3K May 26 10:51 umad.cpp

Anhand der Kompilierungszeile der Makefile erkennen wir, dass sowohl die JPEG-Header-Dateien (-l) als auch die statische JPEG-Library (-L) tatsächlich für die Kompilierung verwendet werden. Die Ausführung des erstellten Programmes “umad” liefert eine weitere Datei “out.jpeg”, die wir uns als nächstes ansehen.

PoliCTF 2012 - Bin-Pwn 100 - library image output

Bis auf die Frage “U MAD ?” ist an diesem Bild nichts besonderes erkennbar. Auch nach binärer Betrachtung scheint es sich um ein herkömmliches JPEG-Bild zu handeln. Das Betrachten des C++-Quellcodes sowie der Header-Dateien lässt uns ebenfalls keine besonderen Auffälligkeiten vorfinden.
Continue reading

PoliCTF 2012 – Forensics 100

This challenge (Forensics 100) was a little bit weird but solvable. It said:

Retrieve the key.

Remember to write it in capital letters.

Attachment:45141181944a722.tbz2.gpg (password: 310b44aab74809c6ec9dd026b9e8e59a5e401083 )

After unpacking the attachment we got a challenge.pcap file. Opening it using wireshark presented us the capture of a SSH session to a (probably) Juniper device. Some Juniper devices tend to use SSHv1 until told otherwise, so the first shot would be to somehow break the encryption and use the provided key as flag. There is a great tool for analyzing packet captures called Chaosreader, we use that to meet with the pcap file in private. Unfortunately, just submitting the extracted data did not work out, but half way through we got a perl script named session_0001.textSSH.replay. Here is what it looks like when we execute the script:

PoliCTF 2012 - Forensics 100 - timing

replaying captured packets (click me, i’m anim00ted!)

Looks like a pattern, doesn’t it? We take the 320 seconds it lasts to watch astonished and write down the pattern in a more simple way. Short transmissions become “.” and longer ones we write down as “-“. We now have:

….—.–..-.—–..-…-.-…..-..—.——-..-…—-.–…-.-.—..–

This must be morse code! Since morse code is one of the codes where timing is everything, we have to watch the replay again to get the transmission pauses right. This is essential for decoding. We lean back for 320 seconds once again and are rewarded with:

…. — .–. . -.– — ..- …- . -… . . -. .- –. — — -.. -… — -.– … -.-. — ..- –

After translating the morse code to characters we fiinally got our flag:

HOPEYOUVEBEENAGOODBOYSCOUT

Yes, we were good boy scouts, the flag is ours!

Note: This challenge was downgraded to 75 points after a while.

PoliCTF 2012 – GrabBag 100

GrabBag 100 was this CTF’s loss leader and an easy  one if you are familiar with the legendary Hackers movie from 1995 starring Jonny Lee Miller, Angelina Jolie and Jesse Bradford. The assignment read:

We need your help to hack the planet!!! Somehow we have lost a little chunck of the garbage file. We just need 4 byte starting from address 0x000020. Please help us!!!

(Hint: in hex, lowercase,without leading 0x)

To solve the challenge just grab your old copy of Hackers you’re still hiding somewhere, power up the VHS recorder and forward to the scene were Cereal Killer opens Plague’s garbage file. The file gets hexdumped for a blink of an eye, here’s a shot:

PoliCTF 2012 - GrabBag 100 - Hackers movie garbage file

hexdumping the garbage file

Starting from 0x20 we read four bytes as advised: 3dc6032c was the flag.

Never send a boy to do a woman’s job. (Kate)

CScamp 2012 Quals – Misc 200

CScamp CTF 2012 - Misc 200 - task description

Neben dieser Aufgabenstellung zur Challenge “Misc 200” – “Bilder laden um Türen zu öffnen” – wird uns eine ZIP-Datei übergeben. Diese entpacken wir zunächst einmal und sehen uns an, womit wir es bei dieser Challenge genau zu tun haben.

CScamp CTF 2012 - Misc 200 - binary layout and file drop

Das Archiv beinhaltet viele Dateien von denen die Datei “drop.exe” als das Hauptprogramm der Challenge ins Auge fällt. Der Aufruf dieses Binarys lässt ein Fenster erscheinen, das über einen großen Button “Load” Bilder annimmt und an dessen Unterkante sich zehn Radiobuttons befinden, die vom Benutzer durch Klicken verändert werden können.

Das testweise Laden beliebiger Bilder führt zunächst zu keinem sichtbaren Ergebnis. Man erkennt jedoch, dass das Programm arbeitet – nicht zuletzt, da im Verzeichnis kurzzeitig temporäre Dateien erscheinen. Eine genauere Überprüfung des Verhaltens mit dem Werkzeug “procmon” aus der Sysinternals Suite liefert:

CScamp CTF 2012 - Misc 200 - procmon output

Demnach wird nach dem Laden des Bildes das Programm “dontdelete.exe” mit den Parametern “temp.bmp temp” ausgeführt sowie im weiteren Verlauf auf die Datei “temp.txt” zugegriffen. Es wird Zeit, sich die anderen Dateien des Archives – hier insbesondere die Datei “dontdelete.exe” – genauer anzusehen.
Continue reading

CScamp 2012 Quals – Crypt 300

CScamp CTF 2012 - Crypt 300 - task description

Bei dieser Challenge (Crypt 300) sollen wir den originalen Schlüssel zu einem Schlüsseltext bestimmen. Wir erhalten dazu das Verschlüsselungsprogramm, ein Linux 64bit Binary, die Information, dass der Schlüssel alphanumerisch sowie 11 Zeichen lang ist, den Schlüsseltext “7f e7 ff ce 0 98 15 dd 88 fb 6e” und die CRC-XMODEM Prüfsumme 0x8124 des Originalschlüssels.

Zunächst einmal sehen wir uns die Binary genauer an um die Aufgabe etwas besser fassen und das Ziel näher bestimmen zu können:

rup0rt@linux64:~$ ./crypt 111
your encrypted key is : ff ff ff 0 0 0 0 0 0 0 0 
rup0rt@linux64:~$ ./crypt 123456
your encrypted key is : ff 86 89 d3 89 27 0 0 0 0 0 
rup0rt@linux64:~$ ./crypt A A A 
your encrypted key is : 8f 0 0 0 0 0 0 0 0 0 0

Auf den ersten Blick sieht es so aus, dass das crypt-Tool einen Parameter übernimmt, diesen zeichenweise auswertet, dabei das entsprechende Zeichen verschlüsselt und den verschlüsselten Key ausgibt. Wir müssen es demnach schaffen, den originalen Schlüssel (Übergabeparameter) zu finden bzw. so zu wählen, dass der von der Aufgabe geforderte Cipher “7f e7 ff ce 0 98 15 dd 88 fb 6e” entsteht.

Um dies zu erreichen Schreiben wir ein (hier zugegeben sehr unsauberes) Python-Skript, dass den Schlüssel per Brute Force bestimmt:

#!/usr/bin/python

import commands
import re

chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"

for c1 in chars:
 if re.match(".* : 7f.*", commands.getoutput("./crypt " + c1)):
  for c2 in chars:
   if re.match(".* : 7f e7.*", commands.getoutput("./crypt " + c1 + c2)):
    for c3 in chars:
     if re.match(".* : 7f e7 ff.*", commands.getoutput("./crypt " + c1 + c2 + c3)):
      for c4 in chars:
       if re.match(".* : 7f e7 ff ce.*", commands.getoutput("./crypt " +c1+c2+c3+c4)):
        for c5 in chars:
         if re.match(".* : 7f e7 ff ce 0.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5)):
          for c6 in chars:
           if re.match(".* : 7f e7 ff ce 0 98.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6)):
            for c7 in chars:
             if re.match(".* : 7f e7 ff ce 0 98 15.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6+c7)):
              for c8 in chars:
               if re.match(".* : 7f e7 ff ce 0 98 15 dd.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6+c7+c8)):
                for c9 in chars:
                 if re.match(".* : 7f e7 ff ce 0 98 15 dd 88.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6+c7+c8+c9)):
                  for c10 in chars:
                   if re.match(".* : 7f e7 ff ce 0 98 15 dd 88 fb.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6+c7+c8+c9+c10)):
                    for c11 in chars:
                     if re.match(".* : 7f e7 ff ce 0 98 15 dd 88 fb 6e.*", commands.getoutput("./crypt " +c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+c11)):
                      print c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+c11

Continue reading

CScamp 2012 Quals – Web 300

CScamp CTF 2012 - Web 300 - puzzle image website

Bei dieser Challenge (Web 300) ist das eigentliche Ziel sehr schnell klar. Es existiert ein Bild, deren Teile verwürfelt sind, und die von uns innerhalb von zwei Sekunden in die richtige Reihenfolge gebracht werden müssen. Da es sehr schwer werden wird, das Bild innerhalb von zwei Sekunden per Hand zu sortieren und das Ergebnis einzugeben, bleibt uns nur der Weg, eine automatisierte Lösung per Skript zu entwickeln.

Dabei wird es erforderlich sein, jedes der zwölf Quadrate eindeutig zu identifizieren. Zur Umsetzung habe ich mir daher überlegt, aus jedem Quadrat die Farben (Rot – Grün – Blau) von vier Pixeln aus den Eckbereichen zu entnehmen und darüber eine Art “Fingerabdruck” jedes Quadrates zu erhalten – hier vereinfacht dargestellt ;-).

CScamp CTF 2012 - Web 300 - identifying puzzle pieces by pixel

Bei der Umsetzung hat sich jedoch das Problem ergeben, dass – wohlmöglich durch die jeweils erneute JPEG-Umwandlung – die Farben der Pixel sich immer (minimal) unterscheiden. Als Umweg werden wir daher nur festhalten, ob sich viel oder wenig Rot-/Grün-/Blau-Töne in den Pixeln befinden und so eine eindeute Zuordnung der Quadrate realisieren.

Um den Server nicht unnötig mit Anfragen zu beschäftigen, nutzen wir hier zwei Skripte. Ein Bash-Skript zur Kommunikation mit dem Server sowie ein Python-Skript zur Sortierung des Bildes. Somit kann die Sortierung an ein- und demselben Bild wiederholt durchgeführt werden um die korrekte Funktion des Sortieralgorithmus zu testen.
Continue reading

Hack.Lu CTF 2012 –
Secure Safehouse

Hack.Lu CTF 2012 - Secure Safehouse - task description

Diese Challenge (Secure Safehouse) ist sehr ähnlich zu Safehouse. Es werden uns neben der oben genannten Aufgabenstellung wieder SSH-Zugangsdaten genannt. Nach dem Login und einem Listing des Verzeichnisinhaltes sehen wir folgendes:

Hack.Lu CTF 2012 - Secure Safehouse - setuid file view

Wieder gibt es eine Datei mit SUID-Bit namens “secure-safehouse” sowie eine “FLAG”-Datei, deren Auslesen wohl das Ziel dieser Challenge darstellt. Aus den Erfahrungen der vorherigen Challenge prüfen wir an dieser Stelle auch schon, welche UID der Benutzer “secure_safehouse” besitzt, hier: 1005.

Anschließend erstellen wir, wie vorher auch, zunächst einen Objekt-Dump. Die Instruktionen sind größtenteils mit denen der Challenge Safehouse identisch. Ich verzichte daher auf ein Ansprechen aller Einzelheiten und werde nur die Besonderheiten und Unterschiede zur vorherigen Challenge hervorheben.

4009cd:  ff 55 d8           call  QWORD PTR [rbp-0x28]
4009d0:  8b 5d 8c           mov   ebx,DWORD PTR [rbp-0x74]
4009d3:  ff cb              dec   ebx
4009d5:  39 c3              cmp   ebx,eax
4009d7:  0f 85 87 fe ff ff  jne   400864 <sig>

Zunächst einmal existiert keine Routine “again” mehr, das heißt der von uns übergebene Opcode wird nicht mehr alle vier Bytes per CALL angesprungen, sondern nur noch einmal (Zeile 1). Da aber immernoch alle vier Bytes ein 0xc3 (RET) geschrieben wird, müssen wir uns diesmal etwas anderes überlegen, wenn wir mehr als nur 3 Bytes für unseren Opcode verwenden wollen.

Außerdem wird, nachdem unser unser Opcode angesprungen wurde (Zeile 1) nicht wie in der vorherigen Challenge direkt die Shell geöffnet, sondern vorher noch ein Vergleich durchgeführt. Im Detail wird die Variable “ARGC” (RBP-0x74, Zeile 2) um Eins verringert (Zeile 3), was die genaue Anzahl der Übergabeparameter ergibt, und anschließend mit dem Register EAX verglichen (Zeile 4). Wenn die Register nicht überein stimmen, wird ein Fehlersignal ausgelöst (Zeile 5).
Continue reading

Hack.Lu CTF 2012 – Safehouse

Hack.Lu CTF 2012 - Safehouse - task description

Neben dieser Aufgabenstellung werden uns die SSH-Zugangsdaten zu einem Server genannt, zu dem wir uns auch direkt verbinden um das Ziel dieser Challenge (Safehouse) besser fassen zu können.

Nach Login und Ausführung eines Dateilistings erhalten wir folgende Ausgabe:

Hack.Lu CTF 2012 - Safehouse - setuid file view

Zunächst einmal erkennen wir den coolen ASCII-Art-Zombie, der uns freundlich begrüßt ;-). Darüber hinaus ist eine Binärdatei “safehouse” im Verzeichnis hinterlegt sowie eine Datei namens “FLAG”. Ziel wird es also sein, den Inhalt der Datei “FLAG” auszulesen um an das Lösungswort der Challenge zu gelangen.

Da wir selbst jedoch der Benutzer “ctf” sind, können wir die Datei “FLAG”, die nur für den Benutzer “safehouse” lesbar ist, nicht ohne weiteres betrachten. Die Binärdatei “safehouse” jedoch gehört dem Benutzer “safehouse” und ist mit dem SUID-Bit versehen, dass heißt, sie wird bei Ausführung mit den Rechten dieses Benutzers gestartet.

Damit ist der Weg zum Ziel erkennbar: Wir werden die Binärdatei “safehouse” zum Beispiel durch einen Exploit derart ausnutzen müssen, dass wir eine Shell erhalten (oder zumindest das Tool “cat” benutzen) um dadurch die Datei “FLAG” ausgeben zu können.
Continue reading