Category Archives: Writeups

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

Hack.Lu CTF 2012 – Spambot

Hack.Lu CTF 2012 - Spambot - task description

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:

Hack.Lu CTF 2012 - Spambot - bot control website

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!

Hack.Lu CTF 2012 - TUX-BOMB - task description

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.

Hack.Lu CTF 2012 - TUX-BOMB - normal execution

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

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

Hack.Lu CTF 2012 – Zombie AV

Hack.Lu CTF 2012 - Zombie AV - task description

Diese Challenge (Zombie AV) liefert uns einige PHP-Dateien und nennt das Ziel, den Inhalt der Datei “config.php” auf einer bestimmten Webseite auszulesen. Ohne die PHP-Quellcodes vorher zu betrachten rufen wir zunächst die Webseite auf um uns einen Überblick über die vor uns liegende Aufgabe zu verschaffen.

Hack.Lu CTF 2012 - Zombie AV - virus upload

Es scheint sich um einen online AntiVirus (AV) Scanner zu handeln, dem Dateien übergeben werden können um auf das Vorhandensein von Viren zu prüfen. Wir testen das System probeweise mit einer beliebigen 32bit Binärdatei mit folgendem Ergebnis:

Hack.Lu CTF 2012 - Zombie AV - virus scan

Dem Anschein nach prüft das System den Beginn (ELF Header) des Binarys auf eine bestimmte (Viren-) Signatur. Welche Opcodes hier genau erwartet werden und was für eine Reaktion bei Fund erfolgt, können wir nur erahnen und müssen uns daher nun den PHP-Quellcodes widmen.

Continue reading

CSAW CTF Qualifiers 2012 –
Networking 200

“Some dude I know is planning a party at some bar in New York! I really want to go but he’s really strict about who gets let in to the party. I managed to find this packet capture of when the dude registered the party but I don’t know what else to do. Do you think there’s any way you can find out the secret password to get into the party for me? By the way, my favorite hockey player ever is mario lemieux.”

Zusätzlich zu diesem Text, wird uns bei der “Networking 200” – Challenge auch eine PCAP-Datei bereit gestellt. Das Ziel ist, mit Hilfe dieser Netzwerkdaten, herauszufinden, wie das “geheime Passwort” lautet, das erforderlich ist, um Zugang zur Party zu erhalten.

Wir öffnen als Erstes die Datei mit Wireshark um uns einen Überblick zu verschaffen. Die Datei selbst ist über 64 Megabytes groß, was ein manuelles Durchsuchen nach auffälligen Inhalten fast unmöglich macht. Daher betrachten wir zunächst die “Protocol Hierarchy”-Statistiken in Wireshark.

CSAW CTF 2012 - Networking 200 - Protocol hierarchy

Hieraus erkennen wir, dass die Datei insgesamt über 73000 Pakete umfasst, die größtenteils TCP-Daten darstellen. Die einzigen Daten, die von Wireshark einem Protokoll zugeordnet werden konnten und von uns sinnvoll interpretiert werden können, sind HTTP-Daten.

Continue reading

CSAW CTF Qualifiers 2012 –
Web 300

http://128.238.66.217/
“This is a website belonging to a horse-fighting gang. Even with an account, it’s not clear what they’re up to. Your task is to get administrator access and see if you can figure anything out. Your account is csaw_challenger/letmein123.”

Bei der Challenge Web 300 handelt es sich um ein Board, in der diverse Informationen präsentiert werden. Dies umfasst im wesentlichen jeweils eine Seite mit News, bzw. Benutzerinformationen oder jegliche Informationen zu Pferden (Name, Beschreibung etc pp).

CSAW CTF 2012 - Web 300 - website

Die Seiten selbst werden per GET Request weiter verarbeitet. Ausserdem stellt man recht schnell fest, dass ein Session Cookie des aktuell angemeldeten Benutzers gesetzt wird. Somit muss man wohl irgendwie versuchen die Session des Administrators zu übernehmen. Bei näherer Untersuchung fällt auf, dass jegliche Informationen mittels URI (id=XXX) ausgewertet werden. Das lässt vermuten, dass bei dieser Challenge eine SQL Injection Schwachstelle ausgenutzt werden muss. Das wird auf den Seiten “user.php” und “horse.php” überprüft.

http://128.238.66.217/user.php?id=1′ or ‘1’=’1      => keine Schwachstelle
http://128.238.66.217/horse.php?id=1′ or ‘1’=’1    => Schwachstelle !!!

CSAW CTF 2012 - Web 300 - SQL injection error message

Continue reading