Einführung
Beim Penetration Testing und Red Teaming kommt es häufig vor, dass Sie einen öffentlich zugänglichen Server kompromittieren und feststellen, dass dieser Zugriff auf ein internes Netzwerk hat, das von Ihrer Angriffsmaschine aus nicht direkt erreichbar ist. Um diese internen Systeme anzugreifen, benötigen Sie eine Möglichkeit, Ihren Datenverkehr über den kompromittierten Server zu leiten. Diese Technik wird als "Pivoting" bezeichnet.
Beim Pivoting geht es im Wesentlichen darum, den eigenen Standpunkt zu verlagern. Sie testen nicht mehr nur von der Netzwerkposition Ihrer ursprünglichen Maschine aus, sondern nutzen einen kompromittierten Host als neuen Beobachtungs- und Zugriffspunkt.
Eine der leistungsfähigsten und gebräuchlichsten Pivoting-Techniken ist die Verwendung von SSH-Dynamischer Portweiterleitung zur Erstellung eines SOCKS-Proxys in Kombination mit einem Tool namens proxychains. Diese Kombination ermöglicht es Ihnen, nahezu jedes externe Netzwerk-Tool (wie Nmap, Nikto oder Metasploit) nahtlos über den kompromittierten Host zu leiten.
In diesem Lab simulieren wir ein Szenario, in dem Sie SSH-Zugriff auf einen dedizierten Pivot-Host haben, der in einem Docker-Container läuft. Ein zweiter Container im selben privaten Docker-Netzwerk hostet einen versteckten internen Webdienst. Da dieser Dienst nicht direkt für die LabEx-VM zugänglich ist, müssen Sie ihn über den SSH-Pivot-Host erreichen. Sie lernen, wie Sie eine SSH-Dynamische Portweiterleitung einrichten, proxychains konfigurieren und damit auf den versteckten Dienst zugreifen.
SSH-Dynamische Portweiterleitung (-D) einrichten
In diesem Schritt bauen Sie eine SSH-Verbindung zum containerisierten Pivot-Host auf und erstellen einen lokalen SOCKS-Proxy.
Die dynamische Portweiterleitung ermöglicht es Ihnen, einen lokalen Port auf Ihrer Angriffsmaschine festzulegen. Der SSH-Client lauscht an diesem Port, und sobald eine Anwendung eine Verbindung herstellt, wird diese über den sicheren SSH-Kanal an den SSH-Server weitergeleitet. Der SSH-Server fungiert dann als Proxy und leitet den Datenverkehr an sein endgültiges Ziel weiter.
Dies ist flexibler als eine einfache Portweiterleitung, da der SOCKS-Proxy über einen einzigen Tunnel eine Vielzahl unterschiedlicher Zielanfragen verarbeiten kann.
Um dies einzurichten, verwenden wir das Flag -D in unserem SSH-Befehl. Wir nutzen zudem einige weitere Flags, damit die Verbindung reibungslos im Hintergrund läuft.
Das Setup hat für Sie einen privaten Schlüssel unter ~/project/pivot_key erstellt und den SSH-Dienst des Pivot-Hosts auf dem lokalen Port 2222 bereitgestellt. Führen Sie den folgenden Befehl in Ihrem Terminal aus, um einen SOCKS-Proxy auf dem lokalen Port 9050 zu erstellen:
ssh -f -D 9050 -q -C -N \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i ~/project/pivot_key -p 2222 pivot@127.0.0.1
Lassen Sie uns die in diesem Befehl verwendeten Flags aufschlüsseln. Das Flag -D 9050 spezifiziert die dynamische Portweiterleitung und setzt den lokalen Port auf 9050. Das Flag -q steht für den "Quiet Mode", der Warn- und Diagnosemeldungen unterdrückt. Das Flag -C fordert die Komprimierung aller Daten an, was die Verbindung beschleunigen kann. Das Flag -N weist SSH an, keinen Remote-Befehl auszuführen, was nützlich ist, wenn Sie nur Ports weiterleiten. Das Flag -f versetzt den SSH-Client nach der Authentifizierung in den Hintergrund, sodass Sie die Terminalsitzung weiter nutzen können. Die Optionen -o StrictHostKeyChecking=no und -o UserKnownHostsFile=/dev/null verhindern, dass Abfragen zum Host-Key bei der ersten Verbindung den Arbeitsablauf im Lab unterbrechen. Das Flag -i gibt an, welcher private Schlüssel verwendet werden soll, und -p 2222 weist SSH an, sich mit dem Pivot-Host-Container anstelle des Standard-SSH-Dienstes der LabEx-VM zu verbinden.
Nachdem Sie den Befehl ausgeführt haben, können Sie überprüfen, ob der Port offen ist und Verbindungen annimmt, indem Sie den Befehl ss verwenden, der Socket-Statistiken ausgibt.
ss -tuln | grep 9050
Sie sollten eine Ausgabe ähnlich der folgenden sehen, die anzeigt, dass Ihre Maschine nun auf Port 9050 lauscht:
tcp LISTEN 0 128 127.0.0.1:9050 0.0.0.0:*
tcp LISTEN 0 128 [::1]:9050 [::]:*
Proxychains konfigurieren (/etc/proxychains.conf)
In diesem Schritt überprüfen Sie die Konfiguration für proxychains.
Obwohl Sie nun einen SOCKS-Proxy auf Port 9050 laufen haben, wissen die meisten Befehlszeilen-Tools (wie Nmap) von sich aus nicht, wie sie ihren Datenverkehr über einen SOCKS-Proxy leiten sollen. Hier kommt proxychains ins Spiel. Es ist ein Tool, das jede TCP-Verbindung, die von einer bestimmten Anwendung initiiert wird, dazu zwingt, über einen Proxy zu laufen.
In der Praxis ist proxychains das Werkzeug, das den Tunnel von einem manuellen Test in einen wiederverwendbaren Workflow für viele verschiedene Tools erweitert.
Die Konfigurationsdatei für proxychains befindet sich unter /etc/proxychains4.conf. Für dieses Lab sollte der Proxy-Eintrag auf einen SOCKS5-Proxy unter 127.0.0.1 auf Port 9050 zeigen, was der soeben erstellten SSH-Dynamischen Portweiterleitung entspricht.
Lassen Sie uns das Ende der Konfigurationsdatei betrachten, um diese Einstellung zu bestätigen. Verwenden Sie den Befehl tail, um die letzten 10 Zeilen der Datei anzuzeigen:
tail -n 10 /etc/proxychains4.conf
Sie sollten eine Ausgabe ähnlich der folgenden sehen:
[ProxyList]
## add proxy here ...
## meanwile
## defaults set to "tor"
socks5 127.0.0.1 9050
Der Abschnitt [ProxyList] ist der Ort, an dem Proxys definiert werden. Die Zeile socks5 127.0.0.1 9050 weist proxychains an, den Datenverkehr über den lokalen Port 9050 zu leiten. Da unser SSH-Befehl mit -D genau auf diesem Port einen Proxy erstellt hat, ist nach der Aktualisierung des Protokolltyps keine weitere Konfiguration erforderlich.
Falls Sie jemals einen anderen Port oder einen anderen Proxy-Typ verwenden müssen, können Sie diese Datei mit einem Texteditor wie nano bearbeiten.
Den SOCKS-Proxy testen
In diesem Schritt testen Sie, ob Ihr Proxy-Setup korrekt funktioniert, indem Sie auf den versteckten internen Webdienst zugreifen.
Denken Sie daran, dass auf einem versteckten internen Container unter 172.30.0.20:80 ein Webdienst läuft. In einem realen Szenario entspricht dies einer internen Intranet-Seite, auf die vom öffentlichen Internet aus nicht direkt zugegriffen werden kann.
Um proxychains zu verwenden, stellen Sie dem Befehl, den Sie ausführen möchten, einfach proxychains4 voran. Lassen Sie uns curl verwenden, um die Webseite abzurufen.
Führen Sie den folgenden Befehl aus:
proxychains4 curl http://172.30.0.20
Wenn Sie dies ausführen, fängt proxychains die Netzwerkanfrage von curl ab und tunnelt sie durch den SSH-SOCKS-Proxy auf Port 9050. Der Pivot-Host stellt dann die Anfrage an 172.30.0.20:80 im internen Docker-Netzwerk und gibt das Ergebnis zurück.
Sie sollten eine Ausgabe ähnlich der folgenden sehen:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Secret Internal Data: You have successfully pivoted
Die Meldung OK zeigt an, dass die Proxy-Verbindung erfolgreich war, und die letzte Zeile zeigt die geheimen Daten des internen Webservers an.
Externe Tools über den Pivot-Host ausführen
In diesem letzten Schritt verwenden Sie ein fortgeschritteneres externes Tool, Nmap, um das interne Netzwerk über Ihren eingerichteten Pivot-Host zu scannen.
Bei der Verwendung von proxychains mit Nmap gibt es wichtige technische Einschränkungen zu beachten. SOCKS-Proxys unterstützen nur vollständige TCP-Verbindungen. Sie unterstützen kein ICMP (Ping) oder halb-offene SYN-Scans (die Nmap standardmäßig verwendet, wenn es mit sudo ausgeführt wird).
Daher müssen Sie Nmap bei der Ausführung über proxychains zwingen, einen vollständigen TCP-Connect-Scan zu verwenden und die Ping-Erkennung zu deaktivieren.
Führen Sie den folgenden Nmap-Befehl aus, um den internen Webdienst auf Port 80 zu scannen:
proxychains4 nmap -sT -Pn -p 80 172.30.0.20
Lassen Sie uns die hier verwendeten Nmap-Flags aufschlüsseln. Das Flag -sT erzwingt einen TCP-Connect-Scan, was zwingend erforderlich ist, da SOCKS-Proxys keine rohen Pakete oder SYN-Scans verarbeiten können. Das Flag -Pn deaktiviert die Host-Erkennung (Ping); da SOCKS-Proxys keine ICMP-Echo-Anfragen routen können, würde Nmap fälschlicherweise annehmen, dass der Host offline ist, wenn dieses Flag weggelassen würde. Schließlich gibt das Flag -p 80 den exakt zu scannenden Port an.
Sie werden sehen, wie proxychains die Verbindungsversuche protokolliert, gefolgt von den Nmap-Scanergebnissen:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Starting Nmap 7.91 ( https://nmap.org ) at 2024-01-01 12:00 UTC
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Nmap scan report for 172.30.0.20
Host is up (0.0020s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
Dies bestätigt, dass Sie komplexe Sicherheitstools erfolgreich über einen kompromittierten Host leiten können, um mit internen Netzwerksegmenten zu interagieren.
Zusammenfassung
Herzlichen Glückwunsch! Sie haben das Lab zur dynamischen Portweiterleitung mit Proxychains erfolgreich abgeschlossen.
In diesem Lab haben Sie gelernt, wie man einen lokalen SOCKS-Proxy mithilfe von SSH-Dynamischer Portweiterleitung (-D) erstellt. Sie haben zudem gelernt, wie man die Konfiguration von proxychains versteht und überprüft. Darüber hinaus haben Sie erfolgreich grundlegende HTTP-Anfragen über den Proxy geleitet, um auf versteckte interne Dienste zuzugreifen. Schließlich haben Sie fortgeschrittene Scan-Tools wie Nmap für die Arbeit über einen SOCKS-Proxy angepasst, indem Sie TCP-Connect-Scans (-sT) verwendet und die Ping-Erkennung (-Pn) deaktiviert haben.
Diese Pivoting-Techniken sind grundlegende Fähigkeiten, um sich bei Penetration Tests und Sicherheitsüberprüfungen in komplexen Netzwerkumgebungen zurechtzufinden.
