Hack.Lu CTF 2014 – ImageUpload

Hack.Lu CTF 2014 - ImageUpload - Task description

Diese Challenge (ImageUpload) erzählt uns von einer Website, auf der man Bilder hochladen kann um dem Scheriff bei der Verbrechenjagd zu unterstützen. Als erstes sehen wir uns diese Webseite etwas genauer an.

Hack.Lu CTF 2014 - ImageUpload - Website

Die Seite ist sehr klein und übersichtlich. Es gibt eine Möglichkeit sich anzumelden, mit der wir – wegen Abfrage von Benutzernamen und Password – zunächst nichts anfangen können. Des Weiteren lassen sich offensichtlich Bilder hochladen. Diese Möglichkeit nutzen wir für ein Testbild.

Hack.Lu CTF 2014 - ImageUpload - Picture upload

Nach dem Hochladen sehen wir das Bild auf der Webseite. Zusätzlich wurden am unteren Ende des Bildes Daten angefügt. Bei diesen Daten handelt es sich vermutlich um Exchangeable Image File Format (EXIF) Daten, die aus dem Bild selbst ausgelesen wurden. Da mein Bild keine Daten enthielt, sind die Felder leer.

Continue reading

Hack.Lu CTF 2013 – FluxArchiv (1)

Hack.lU 2013 CTF - FluxArchiv (Part 1) - Task Description

Die Challenge “FluxArchiv (Part 1)” befasst sich mit einer Archivierungssoftware. Damit können Archive erstellt und mit Passwörtern versehen werden. Außerdem erhalten wir die Information, dass ein Archiv mit einem sechsstelligen Passwort versehen wurde, dass nur Großbuchstaben und Zahlen beinhaltet. Zusätzlich zur Beschreibung erhalten wir diese Dateien.

Dabei handelt es sich um ein 64bit Linux-Binary (die Archivierungssoftware) und ein damit verschlüsseltes Archiv. Die Software führen wir direkt einmal aus.

ruport@lambda:~$ ./archiv 

################################################################################

FluxArchiv - solved security since 2007!
Written by sqall - leading expert in social-kernel-web-reverse-engineering.

################################################################################

Unknown or invalid command.

Usage: ./archiv <command> <archiv> <password> <file>
commands:
-l <archiv> <password> - lists all files in the archiv.
-a <archiv> <password> <file> - adds a file to the archiv (when archiv does not exist create a new archiv).
-x <archiv> <password> <filename> - extracts the given filename from the archiv.
-d <archiv> <password> <filename> - delete the given filename from the archiv.

Es können mehrere Operationen durchgeführt werden. Wir probieren testweise das Anzeigen der beinhalteten Dateien des Archives.

rup0rt@lambda:~$ ./archiv -l FluxArchiv.arc rup0rt

################################################################################

FluxArchiv - solved security since 2007!
Written by sqall - leading expert in social-kernel-web-reverse-engineering.

################################################################################

Given password is not correct.

Continue reading

Hack.Lu CTF 2013 – RoboAuth

Hack.Lu 2013 CTF - RoboAuth - Task Description

Die “RoboAuth”-Challenge erzählt von einem Authentisierungssystem und übergibt uns ein Binary, das wir analysieren sollen um zwei Passwörter als Flagge zu erhalten. In guter Manier starten wir das fremde Programm natürlich erstmal als Administrator 😉

Hack.Lu 2013 CTF - RoboAuth - First run

Wir werden zur Eingabe des ersten Passwortes aufgefordert. Jeder fehlerhafte Versuch führt direkt zum Abbruch der Programmausführung. Nutzen wir also den Immunity Debugger um das Programm zu untersuchen.

Dazu starten wir das Programm im Debugger und Pausieren sobald die Passwort abfrage erscheint. Nun geben wir das Passwort ein lassen das Binary so lange weiter arbeiten (continue until return) bis wir in das Code Segment des Programmes zurück kehren. Im Ergebnis landen wir direkt an der Position, wo das Passwort auf Korrektheit überprüft wird:

Hack.Lu 2013 CTF - RoboAuth - First compare for password
Continue reading

Hack.Lu CTF 2013 – Packed

Hack.Lu CTF 2013 - Packed - Task Description

Die Challenge “Packed” beschreibt den Fund verwürfelter Daten, in denen sich irgendwo noch etwas Nützliches befinden soll. Zur Bearbeitung erhalten wir nur eine Datei, die wir zunächst etwas genauer untersuchen:

Hack.Lu CTF 2013 - Packed - File Content

Neben vielen Bytes, die sich nicht wirklich zuordnen lassen, sind doch drei Dinge relatisch schnell erkennbar. Im oberen Bereich befindet sich ein PDF, das im Magick zu erkennen ist (nicht abgebildet). Darunter befindet sich ein Text aus ASCII-Zeichen, der jedoch unverständlich ist. Zusammen mit dem Wort “rot”, das in der Datei vorhanden ist, könnte es sich jedoch um einen ROT13-Cipher handeln.

Im unteren Bereich befindet sich ein langer Abschnitt aus Base64-kodierten Daten. Wenn wir die Abschnitte nun einzeln untersuchen, stellen wir Folgendes fest. Die PDF-Datei kann direkt ausgeschnitten und dann geöffnet werden. Als Ergebnis erhalten wir diese Ausgabe:

Hack.Lu CTF 2013 - Packed - PDF File Part

Sowohl optisch als auch forensisch sind keine weiteren Informationen aus dieser Datei zu entnehmen.

Continue reading

Hack.Lu CTF 2013 – Pay TV

Hack.Lu CTF 2013 - Pay TV - task description

Diese Challenge verlangt von uns, Zugriff auf eine Pay TV Plattform mit Nachrichten über das “Oktoberfest” zu erlangen. Dazu erhalten wir nichts weiter als die Webseite selbst genannt, die wir uns als Erstes ansehen.

Hack.Lu CTF 2013 - Pay TV - Website

Auf der Webseite befindet sich nur ein Bild sowie die Eingabemaske für ein Passwort. Sehen wir uns also als Nächstes des HTML-Quellcode genauer an.

<!DOCTYPE html>
<title>Skynet Pay TV</title>
<link rel="stylesheet" href="/static/style.css">
<div id="container">
    <div id="news">
        <div id="newstext">
        </div>
    </div>
    <img src="/static/noise.gif" id="noise">
    <form action="/gimmetv" method="post">
        <input type="text" id="key" name="key" focus><br />
        <input type="submit" value=" ">
        <div id="error"></div>
    </form>
</div>
<script src="/static/key.js"></script>

In Zeile 10 erkennen wir, dass die Formulardaten an das Ziel “/gimmetv” gesendet werden. Außerdem wird ein in Zeile 16 ein zusätzliches JavaScript eingebunden, dass sich in “/static/key.js” befindet. Auch diese Datei laden wir herunter und betrachten sie.
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