Hackover CTF 2015 – easy-shell

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

Hackover CTF 2015 - easy-shell - Task description

Lets first check what the binary does when executing.

ruport@zentaur:~/hackover2015$ ./easy_shell

        .-"; ! ;"-.
      .'!  : | :  !`.
     /\  ! : ! : !  /\
    /\ |  ! :|: !  | /\
   (  \ \ ; :!: ; / /  )
  ( `. \ | !:|:! | / .' )
  (`. \ \ \!:|:!/ / / .')
   \ `.`.\ |!|! |/,'.' /
    `._`.\\\!!!// .'_.'
       `.`.\\|//.'.'
        |`._`n'_.'| 
        "----^----">>

nom nom, shell> rup0rt

Some nice ascii art and data reading without output. Because this is a pwn challenge lets send much data in GDB and check the result.

nom nom, shell> AAAAAAAAAAA [300 * "A"]

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

Wow, we already got EIP control – that will literally be an easy-shell :-). Lets check where to direct the EIP into a controlled code segment.
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

CSAW CTF Qualifiers 2012 –
Exploitation 200

Diese Challenge (Exploitation 200) stellt ein Binary bereit und verlangt von uns:

“Read the key out of ./key in the current working directory.”

Zusätzlich wird der Server “128.238.66.218” mit dem Port “54321” genannt.

Es geht also darum, die bereitgestellte ausführbare Datei, die auch auf dem genannten Server an Port 54321 betrieben wird, so durch das Senden von Daten auszunutzen, dass wir an den Inhalt der “key”-Datei gelangen, die auf dem Server abgelegt ist.

Wir sehen uns das Binary wie üblicherweise mit dem Tool “file” genauer an, um die zum Bearbeiten erforderliche Virtuelle Machine bestimmen zu können.

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

Es handelt sich um ein normales 32-bit Linux-Programm. Ich starte daher eine entsprechende Machine, hier ein Debian GNU Linux 6.0 über VirtualBox.

Auf der Virtuellen Machine legen wir zunächst eine “key”-Datei mit beliebigem Inhalt an. Diese soll die Datei auf dem Server nachstellen und beim späteren Testen des Exploits unterstützen, den Erfolg des Auslesens feststellen zu können. Danach starten wir die Datei machen uns mit der Funktionsweise des Binarys vertraut.

user@linux:~$ ./exploitation1-release 
Got a connection from 127.0.0.1 on port 50047

user@linux:~$ nc localhost 54321
Wecome to my first CS project.
Please type your name:  rup0rt
user@linux:~$

Genau wie auf dem Zielserver lauscht das Binary auf Port 54321. Nach dem Verbindungsaufbau mit “netcat” werden wir begrüßt und zur Eingabe unseres Namens aufgefordert. Nachdem dieser Abgesendet wurde, passiert nichts weiter.

Dem Anschein nach wird die Lösung dieser Challenge also darin bestehen, eine geeignete Zeichenkette zu wählen, so dass die interne Bearbeitung des Namens zu einem (ungewollten) Programmverhalten führt, durch das wir an den Inhalt der “key”-Datei gelangen können.

Continue reading