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:

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

Leave a reply

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

Leave a reply

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.

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:

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

Leave a reply

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

Leave a reply

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 ;-).

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

Leave a reply

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:

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

Leave a reply

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:

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 →

Hack.Lu CTF 2012 – Spambot

Leave a reply

Die Spambot – Challenge berichtet von einer Kontroll-Oberfläche, die verwendet wird um automatisiert (SPAM-)Nachrichten in Gästebücher oder andere Online-Plattformen einzubringen. Ziel soll es daher sein, die Spambots “aufzuhalten”.

Zuerst verschaffen wir uns wie gewohnt einen Überblick, indem wir die bereit gestellte Oberfläche ausgiebig erkunden und damit experimentieren. Sie stellt sich folgendermaßen dar:

Es handelt sich um ein einziges Formular, dem eine URL übergeben werden kann. Zusätzlich wird die Webseite “/guestbook/” genannt, die verwendet werden kann, um das Senden der SPAM-Nachrichten zu testen. Diese Webseite sehen wir uns auch einmal kurz an.
Continue reading →

Hack.Lu CTF 2012 – TUX-BOMB!

Leave a reply

Diese Challenge (TUX-BOMB) stellt eine EXE-Datei bereit und beauftragt uns, den Zugang zu erlangen, der bisher auf Grund fehlendem Benutzernamen und Schlüssel nicht möglich ist.

Nachdem mit dem Tool “file “festgestellt wurde, dass es sich um ein 32bit-Binary handelt, starte ich die entsprechende virtuelle Maschine und führe die EXE-Datei aus, um einen ersten Eindruck von deren Funktionsweise zu erlangen.

Dem ersten Eindruck nach scheint das Programm aus dem übergebenen Benutzernamen (“User 1”) eine “UserID” zu generieren, die hier 529 ist, im optimalen Fall aber wohl 666 (“AdminID”) sein sollte. Darüber hinaus wird der Benutzer als “unbekannt” eingestuft und der Produktschlüssel als “falsch” angesehen.

Da man so nicht weiter kommen wird, bleibt nur die Untersuchung im Debugger. Ich verwende hier den Immunity Debugger.
Continue reading →

Hack.Lu CTF 2012 –
Zombie AV Part 2

Leave a reply

Im weiteren Verlauf des Capture the Flags wurde die Challenge “Zombie AV” abgeändert, wohlmöglich um sie schwerer oder leichter zu machen. Die vorher vorgestelte Lösung funktioniert ab diesem Zeitpunkt nicht mehr.

Grund dafür ist eine Änderung im Quellcode der Datei “elfparsing.php”, die sich folgerndermaßen darstellt:

function getEntryPoint($contents) { 
  global $readelfpath; 
  global $objdumppath;     

  $output=shell_exec($readelfpath.' -h '.$contents);  

  $data = preg_match( '/0x[a-fA-F0-9]{5,8}/', $output,$matches); 
  //$retValue=(hexdec($matches[0]) & 4294967288); 
  $retValue=hexdec($matches[0]); 
  return ($retValue ); 
}

Zeile 8 wurde auskommentiert(!!), was dazu führt, dass der Entry point und der Beginn der “Zombie-Opcodes” vom Scanner nun einheitlich betrachtet werden. Wir müssen also eine andere Lösung finden.

Die Schwachstelle ist jedoch immernoch die obige “getEntryPoint”-Funktion, da weiterhin einfach nur die erstbeste hexadezimale Speicheradresse der Ausgabe des Tools “readelf -h” per regulärem Ausdruck zur Überprüfung der Opcodes herangezogen wird (Zeile 7).

Wenn wir es also schaffen, eine weitere Speicheradresse vor den Entry Point in die Ausgabe von “readelf” zu schleusen, wird der “Zombie-Opcode” an dieser Adresse vom Scanner gesucht werden. Wir sehen uns dazu die Ausgabe von “readelf -h” etwas genauer an:

rup0rt@lambda:~$ readelf -h virus2
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048062
  Start of program headers:          52 (bytes into file)
  Start of section headers:          144 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 2

Da die Adresse oberhalb des eigentlichen Entry Points liegen muss, scheint auf den ersten Blick nur das Feld “Version” zur Manipulation geeignet, da die anderen Felder Einfluss auf die Interpretation als 32bit ELF-Binary, und so wohlmöglich auf deren Ausführung, zu haben scheinen.
Continue reading →

f00ls bl0g

the blog for f00ls only

PoliCTF 2012 – Forensics 100

PoliCTF 2012 – GrabBag 100

CScamp 2012 Quals – Misc 200

CScamp 2012 Quals – Crypt 300

CScamp 2012 Quals – Web 300

Hack.Lu CTF 2012 –
Secure Safehouse

Hack.Lu CTF 2012 – Safehouse

Hack.Lu CTF 2012 – Spambot

Hack.Lu CTF 2012 – TUX-BOMB!

Hack.Lu CTF 2012 –
Zombie AV Part 2