Hackover CTF 2015 – easy-math

This writeup describes the solution for the easy-math challenge in Hackover CTF 2015 held by Chaos Computer Club Hamburg.

The task describes some basic arithmetics to warm up:

Hackover CTF 2015 - easy-math - task description

This file was published: easy-math.tar.gz. It is a 32bit ELF executable. Running the file shows this output:

ruport@zentaur:~/hackover2015$ ./easy_math
Warmup: sh0w m3 h0w 1337 y0u 4r3> rup0rt

It reads some data and does stuff with it. I gonna try GDB to have a detailed look in the operations.
So lets set a breakpoint after the read() functions and single step (si).

(gdb) b *0x0804855d
Breakpoint 1 at 0x804855d
(gdb) display /i $eip
(gdb) run
Starting program: /home/ruport/hackover2015/easy_math 
Warmup: sh0w m3 h0w 1337 y0u 4r3> AAAABBBBCCCC

(gdb) CC
Undefined command: "CC". Try "help".
1: x/i $eip
=> 0x804855d <main+153>:	add    esp,0x10

We already recognize that the binary only takes 10 bytes of input because, 2 bytes of our input (CC) is already passed back to GDB. Then the program does some compares. One of them is very interesting because it checks our input data:
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

Boston Key Party CTF 2013 – randy

Boston Key Party CTF 2013 - randy - task description

Bei der Challenge “randy” wird uns eine Binärdatei bereit gestellt und auf “Zufälligkeit” hingeweisen. Nach dem Download starten wir das Programm direkt um dessen Funktionalität zu beobachten.

root@linux64:~# ./randy
Password: rup0rt
:(

Das Binary verlangt nach der Eingabe eines Passwortes. Bei Eingabe einer beliebigen (falschen) Zeichenfolge erhalten wir nur ein trauriges Smiley. Um zu erfahren, wie das Programm das Passwort verarbeitet und die Korrektheit bestimmt, nutzen wir objdump um den Assembler-Code zu erzeugen.

Darin fingen wir unter anderem folgende Abschnitte:

0000000000400884 <main>:
[...]
  400958:  e8 c3 fc ff ff  call   400620 <strlen@plt>
  40095d:  48 83 f8 1c     cmp    rax,0x1c
[...]
  400983:  b8 00 00 00 00  mov    eax,0x0
  400988:  e8 97 fe ff ff  call   400824 <wrong>

Zunächst wird die Funktion strlen() aufgerufen um die Länge des von uns eingegebenen Passwortes zu bestimmen. Anschließend wird das Ergebnis mit 0x1c (28) verglichen und bei Misserfolg, das Programm mit der <wrong> Funktion beendet. Wir wissen also, dass das Passwort 28 Zeichen lang sein muss.
Continue reading

ATAST CTF Quals 2012 –
Crack It!

Zu dieser Challenge gibt es keine weitere Aufgabenstellung, da der Name bereits selbsterklärend ist – “Crack It!”. Alles was wir erhalten, ist eine ZIP-Datei mit einem Binary.

rup0rt@lambda:~/ATAST2012$ file crackit
crackit: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x1eb85f9048b1d8dddfbc3898826aaddfe63a55ab, not stripped

… einem Linux-32bit-Programm um genau zu sein. Dieses führen wir, wie gewohnt, erst einmal aus um deren Funktionsweise überblicken zu können.

rup0rt@linux:~/ATAST2012$ ./crackit
Usage : ./crackit <password>

rup0rt@linux:~/ATAST2012$ ./crackit 12345
hahaha wrong password :p

Wie bei der vorherigen Challenge auch wird also ebenso ein Passwort benötigt um die Abfrage des Programmes passieren und somit die Lösung zur Aufgabe (Crackt It!) erhalten zu können. Erneut beginnen wir mit einer Betrachtung des Assembler-Codes durch Verwendung von “objdump”, wobei folgender Abschnitt direkt auffällt:

8048620: c7 44 24 0c 00 00 00  mov DWORD PTR [esp+0xc],0x0
8048628: c7 44 24 08 00 00 00  mov DWORD PTR [esp+0x8],0x0
8048630: c7 44 24 04 00 00 00  mov DWORD PTR [esp+0x4],0x0
8048638: c7 04 24 00 00 00 00  mov DWORD PTR [esp],0x0
804863f: e8 c4 fd ff ff        call 8048408 <ptrace@plt>
8048644: 85 c0                 test eax,eax
8048646: 79 16                 jns 804865e <main+0x6d>

Das Programm ruft die Funktion “ptrace()” auf (Zeile 5), prüft anschließend deren Rückgabewert (Zeile 6) und springt, davon abhängig, weiter in den Quellcode (Zeile 7). Mit “ptrace()” können Prozesse debuggt und gesteuert werden. Dies Funktioniert jedoch nur für einen Prozess. Sollten wir also bei Programmstart selbst einen Debugger verwenden, wird “ptrace()” fehlschlagen und das Programm beendet.

Hierbei handelt es sich hierbei also um eine Anti-Debugging-Methode, die verhindern soll, dass wir mit Programmen wie “strace” oder dem GDB das Programm bei der Ausführung beobachten. Um diesen Schutz zu umgehen verändern wir einfach den bedingten Sprung (Zeile 7) in einen unbedingten Sprung unter Verwendung eines Hex-Editors.
Continue reading

ATAST CTF Quals 2012 –
Chall2_200pts (crack1)

Wie so oft werden wir auch bei dieser Challenge (crack1) einfach nur mit den Worten

“get the password”

begrüßt. Dieses Passwort sollen wir aus einer Binärdatei extrahieren.

Sehen wir uns also als Erstes den Typ des Binarys an:

rup0rt@lambda:~$ file crack1
crack1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x4579db2a2ebe3b4e83948f7a650dc3fced1d812d, not stripped

Es handelt sich um ein einfaches Linux-32bit-Programm.

Wir führen das Programm zunächst einmal aus um uns einen Überblick über dessen Funktionsweise zu verschaffen:

creeq@linux:~/ATAST2012$ ./crack1 
Password Required : 12345 
Wrong !!!! better luck next time :D

Es wird eine Passwortabfrage durchgeführt, die uns anschließend, bei Eingabe von “12345”, mit “falsch” beantwortet wird. Unser Ziel ist es daher, den Programmcode zu untersuchen um festzustellen, wie genau das Passwort überprüft wird und so an die korrekte Lösung zu gelangen.

Dafür nutzen wir “objdump” um an den Assembler-Code des Binarys zu gelangen. Dabei fallen folgende Inhalte in der <main>-Funktion auf:

804865f:     mov    eax,DWORD PTR [esp+0x2c]
8048663:     mov    edx,DWORD PTR [esp+0x2c]
8048667:     movzx  edx,BYTE PTR [esp+edx*1+0x32]
804866c:     xor    edx,0x21

804866f:     mov    BYTE PTR [esp+eax*1+0x68],dl
8048673:     mov    eax,DWORD PTR [esp+0x2c]
8048677:     mov    DWORD PTR [esp+0x8],eax
804867b:     lea    eax,[esp+0x68]
804867f:     mov    DWORD PTR [esp+0x4],eax
8048683:     lea    eax,[esp+0x54]
8048687:     mov    DWORD PTR [esp],eax
804868a:     call   80484d0 <strncmp@plt>

804868f:     test   eax,eax
8048691:     jne    804869a <main+0x106>
8048693:     add    DWORD PTR [esp+0x2c],0x1
8048698:     jmp    80486ad <main+0x119>

In Zeile 4 wird eine XOR-Operation auf einen statischen Byte-Wert angewendet. Dies ist für gewöhnlich nur dann der Fall, wenn Daten im Programm versteckt wurden. Anschließend (Zeile 13) wird die “strcmp”-Funktion ausgeführt um den mit XOR erhaltenen Wert, mit den von uns eingegebenen Passwort-Buchstaben zu vergleichen. Zuletzt (Zeile 15) wird geprüft, ob die Zeichen überein stimmen und bei Erfolg der Buchstaben-Zähler (Zeile 17) erhöht.
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 – 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

CSAW CTF Qualifiers 2012 –
Reversing 400

Bei dieser Challenge (Reversing 400) wird uns wiederholt nur “wortlos” eine Datei übergeben. Wir sind also wieder völlig auf uns gestellt, herauszufinden, wie und wo in diesem Binary der Schlüssel zur Aufgabe versteckt ist.

Wie gewohnt beginnen wir mit einer Untersuchung des Dateityps mit dem Tool “find”:

rup0rt@lambda:~/CSAW2012$ file csaw2012reversing
csaw2012reversing: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x012c3cf67d5aa15a9985ea064958921dc600c367, not stripped

Dieses Mal handelt es sich also um ein Linux-Binary, das für ein 64bit-System kompiliert wurde. Es wird daher Zeit, die entsprechende Virtuelle Machine zu starten (hier ein Debian GNU Linux 6.0) um die Datei näher zu betrachten.

Wie gewöhnlich lässt uns die Neugier nicht im Stich und wir führen die Datei zu aller Erst ohne Nachzudenken einfach aus! Als Antwort erhalten wir:

CSAW CTF 2012 - Reversing 400 - normal execution

Das Programm scheint uns hier den verschlüsselten Key zum Lösen der Challenge auszugeben, der uns jedoch in dieser Form überhaupt nichts nützt. Um zu prüfen, ob es sich wirklich um verschiedene Zeichen handelt – denn die Ausgabe wirkt durch die Fragezeichen recht merkwürdig – nutzen wir das Werkzeug “xxd”.

CSAW CTF 2012 - Reversing 400 - encrypted key

Es handelt sich also tatsächlich um einen 16 Byte langen, verschlüsselten String. Demnach muss nun ein Weg gefunden werden, diesen Key zu entschlüsseln!

Continue reading