Eine Geschichte über Forschung und Entwicklung in drei Teilen. Teil 1 – die Forschung.
Es gibt viele Buchungen – und noch mehr Nutzen.
Problemstellung
Bei der Durchführung von Penetrationstests und Red-Teaming-Kampagnen ist es nicht immer möglich, die Standard-Tools der Kunden wie VPN, RDP, Citrix usw. zu nutzen, um auf das interne Netzwerk zuzugreifen. Manchmal arbeitet das Standard-VPN mit MFA und verwendet einen Hardware-Token als zweiten Faktor, manchmal wird es stark überwacht, sodass unser Zugang über VPN sofort sichtbar wird – mit allen Folgen. In anderen Fällen gibt es solche Tools einfach nicht.
In solchen Fällen müssen wir ständig sogenannte "Reverse Tunnels" einrichten – Verbindungen vom internen Netzwerk zu externen Ressourcen oder Servern, die wir kontrollieren. Innerhalb eines solchen Tunnels können wir dann mit den internen Ressourcen der Kunden arbeiten.
Es gibt verschiedene Arten solcher Rücktunnel. Am bekanntesten ist natürlich Meterpreter. Auch SSH-Tunnel mit Port-Forwarding sind in den Hacker-Kreisen sehr gefragt. Es gibt viele Möglichkeiten, um Rücktunneling durchzuführen, von denen viele gut untersucht und dokumentiert sind.
Natürlich stehen die Entwickler von Sicherheitslösungen nicht still und erkennen solche Aktivitäten aktiv.
Zum Beispiel werden MSF-Sitzungen erfolgreich von modernen IPS-Systemen wie denen von Cisco oder Positive Tech erkannt, und ein umgekehrter SSH-Tunnel kann fast von jeder halbwegs anständigen Firewall erkannt werden.
Daher ist es wichtig, in einer guten RedTeam-Kampagne unauffällig zu bleiben — wir müssen also Rücktunnel mit unkonventionellen Mitteln aufbauen und uns so nah wie möglich an den realen Netzwerkbetrieb anpassen.
Lassen Sie uns versuchen, etwas Ähnliches zu finden oder zu erfinden.
Bevor wir etwas entwickeln, müssen wir verstehen, welches Ergebnis wir erreichen möchten und welche Funktionen unsere Lösung erfüllen soll. Welche Anforderungen muss der Tunnel erfüllen, damit wir maximal anonym arbeiten können?
Klar ist, dass solche Anforderungen je nach Anwendungsfall stark variieren können, aber aus Erfahrung lassen sich folgende Grundanforderungen ableiten:
- Betrieb auf Windows 7–10, da in den meisten Unternehmensnetzwerken Windows verwendet wird;
- Der Client verbindet sich über SSL mit dem Server, um ein Abhören durch IPS zu verhindern;
- Bei der Verbindung muss der Client die Nutzung eines Proxy-Servers mit Authentifizierung unterstützen, da in vielen Unternehmen der Internetzugang über Proxy erfolgt. In der Tat könnte die Clientmaschine davon nichts wissen, während der Proxy im transparenten Modus verwendet wird. Diese Funktionalität müssen wir jedoch implementieren;
- Die Client-Seite sollte übersichtlich und portabel sein;
Es ist klar, dass für die Arbeit im Netzwerk des Kunden OpenVPN auf dem Client-Rechner installiert werden kann, um einen vollständigen Tunnel zu unserem Server aufzubauen (zum Glück können OpenVPN-Clients über Proxys arbeiten). Doch erstens gelingt das nicht immer, da wir möglicherweise nicht die lokalen Administratoren sind, und zweitens erzeugt es so viel Lärm, dass ein zuverlässiges SIEM oder HIPS sofort an die entsprechenden Stellen berichten wird. Idealerweise sollte unser Client als sogenannte Inline-Lösung funktionieren, ähnlich wie viele Bash-Shells, und über die Eingabeaufforderung gestartet werden, beispielsweise beim Ausführen von Befehlen aus einem Word-Makro. - unser Tunnel sollte multithreaded sein und Unterstützung für mehrere gleichzeitige Verbindungen bieten;
- die Client-Server-Verbindung sollte über eine Art Authentifizierung verfügen, damit der Tunnel nur für unseren Client eingerichtet wird und nicht für alle, die zu uns auf den angegebenen Server und Port kommen. Idealerweise sollte für "außerstehende Benutzer" eine Landingpage mit Katzen oder professionellen Themen, die mit der ursprünglichen Domain verbunden sind, geöffnet werden.
Wenn der Auftraggeber eine medizinische Einrichtung ist, sollte für den Informationssicherheitsadministrator, der die Website überprüfen möchte, eine Seite mit pharmazeutischen Produkten, eine Wikipedia-Seite über die Diagnose oder einen Blog von Dr. Komarovsky angezeigt werden, usw.
Analyse der bestehenden Tools
Bevor wir unser eigenes Fahrrad erfinden, sollten wir die vorhandenen Fahrräder analysieren und verstehen, ob wir tatsächlich eines brauchen und ob nicht auch andere über die Notwendigkeit einer solchen funktionalen Lösung nachgedacht haben.
Eine Internetrecherche (das Googeln scheint uns gut zu gelingen) sowie eine Suche auf GitHub nach den Schlagwörtern "reverse socks" haben nicht besonders viele Ergebnisse gebracht. Im Wesentlichen dreht sich alles um den Aufbau von SSH-Tunneln mit umgekehrtem Port-Forwarding und alles, was damit verbunden ist. Abgesehen von SSH-Tunneln gibt es einige Lösungen:
Eine langjährige Umsetzung des Reverse-Tunnels von den Jungs aus dem Kaspersky-Labor. Der Name macht klar, wofür dieses Skript gedacht ist. Implementiert in Python 2.7, der Tunnel funktioniert im Cleartext-Modus (wie man heute so schön sagt – Hallo RKN).
Eine weitere Umsetzung in Python, ebenfalls im Cleartext, aber mit mehr Möglichkeiten. Geschrieben als Modul und bietet eine API zur Integration der Lösung in eigene Projekte.
Der erste Link ist die ursprüngliche Version der Reverse-Sock-Implementierung in Go (wird vom Entwickler nicht mehr unterstützt).
Der zweite Link ist bereits unser Update mit zusätzlichen Funktionen, ebenfalls in Go. In unserer Version haben wir SSL, den Betrieb über einen Proxy mit NTLM-Authentifizierung, Client-Authentifizierung, eine Landing-Page bei falschem Passwort (besser gesagt – Redirect zur Landing-Page), sowie einen Mehrbenutzer-Modus (d.h. mehrere Personen können gleichzeitig mit dem Tunnel arbeiten) und ein Ping-System für den Client umgesetzt, um zu überprüfen, ob er aktiv ist oder nicht.
Die Implementierung eines Reverse SOCKS von unseren "chinesischen Freunden" in Python. Für die Faulen und "unsterblichen" gibt es auch bereits eine fertige Binary (exe), die von Chinesen zusammengestellt und einsatzbereit ist. Nur ein chinesischer Gott weiß, was in dieser Binary sonst noch enthalten sein könnte, neben der Hauptfunktionalität, also verwenden Sie sie auf eigenes Risiko.
Ein ziemlich interessantes Projekt in C++ zur Implementierung von Reverse SOCKS und mehr. Neben dem umgekehrten Tunnel kann es auch Portweiterleitung und das Erstellen einer Befehlszeile durchführen usw.
MSF Meterpreter
Hier gibt es, wie gesagt, nichts hinzuzufügen. Alle halbwegs gebildeten Hacker sind mit diesem Teil bestens vertraut und wissen, wie leicht ihn Schutzmaßnahmen erkennen können.
Alle oben beschriebenen Werkzeuge funktionieren nach einem ähnlichen Prinzip: Auf einem Gerät im Netz wird ein zuvor vorbereiteter ausführbarer Binary-Modul gestartet, der eine Verbindung zu einem externen Server herstellt. Auf dem Server wird ein SOCKS4/5-Server gestartet, der Verbindungen annimmt und diese an den Client weiterleitet.
Ein Nachteil all dieser Werkzeuge ist, dass entweder Python oder Golang auf dem Client-Maschine installiert sein muss (wie oft haben Sie eigentlich Python auf den Maschinen von Geschäftsführern oder Büromitarbeitern gesehen?), oder man muss ein vorab kompilierter Binary (tatsächlich Python und das Skript in einem) auf diese Maschine bringen und dort ausführen. Und das Herunterladen einer exe-Datei und deren Ausführung ist ein echtes Signal für lokale Antivirenprogramme oder HIPS.
Im Grunde zieht sich die Logik von selbst — wir brauchen eine Lösung in PowerShell. Jetzt werden wir Tomaten entgegenfliegen — die Behauptung, dass PowerShell bereits abgedroschen ist, dass es überwacht, blockiert wird usw. usf. In Wirklichkeit ist das nicht überall der Fall. Das stellen wir mit Verantwortung fest. Übrigens gibt es eine Menge Möglichkeiten, diese Blockaden zu umgehen (hier ist wieder der beliebte Ausdruck über die Grüße an den RKН 🙂 ), angefangen bei der simplen Umbenennung von powershell.exe in cmdd.exe und bis hin zu powerdll usw.
Wir fangen an zu erfinden
Es ist klar, dass wir zuerst in Google schauen und… absolut nichts zu diesem Thema finden werden (wenn jemand etwas gefunden hat — bitte Links in die Kommentare). Es gibt nur Socks5 unter PowerShell ist im Wesentlichen ein klassischer "direkter" Sockett, der einige Nachteile hat (darüber sprechen wir später). Man kann ihn zwar mit wenigen Handgriffen in einen umgekehrten Sockett verwandeln, aber das wird nur ein einkanaliger Sockett sein, was für uns nicht wirklich ideal ist.
Also haben wir nichts Fertiges gefunden, weshalb wir tatsächlich unser eigenes Rad erfinden müssen. Als Grundlage für unser Rad verwenden wir eines umgekehrten Sockets in Go, und der Client wird in PowerShell implementiert.
RSocksTun
Wie funktioniert also RsocksTun?
Das Funktionieren von RsocksTun (im Folgenden als rs bezeichnet) basiert auf zwei Softwarekomponenten – Yamux und dem Socks5-Server. Der Socks5-Server ist ein klassischer lokaler Socks5, der auf dem Client gestartet wird. Und die Multiplexierung der Verbindungen zu ihm (denken Sie an die Multithread-Funktionalität?) erfolgt mithilfe von Yamux (). Dieses Schema ermöglicht den Betrieb mehrerer Client-Socks5-Server und verteilt externe Verbindungen zu ihnen, indem sie durch eine einzige TCP-Verbindung (fast wie in Meterpreter) vom Client zum Server geleitet werden. Damit implementieren wir einen Multithread-Betrieb, ohne den wir einfach nicht effektiv im internen Netzwerk arbeiten können.
Die Funktionsweise von yamux besteht darin, dass es eine zusätzliche Netzwerkebene für Streams einführt, die in Form eines 12-Byte-Headers für jedes Paket realisiert wird. (Hier verwenden wir absichtlich das Wort 'Stream' und nicht 'Fluss', um den Leser nicht mit dem Software-Thread-Begriff zu verwirren – dieses Konzept werden wir ebenfalls in diesem Artikel verwenden). Innerhalb des yamux-Headers befinden sich die Stream-Nummer, Flags für das Einrichten/Beenden des Streams, die Anzahl der übertragenen Bytes und die Fenstergröße.
Neben dem Einrichten/Beenden des Streams implementiert yamux einen Mechanismus für Keepalives, der es ermöglicht, die Funktionsfähigkeit des etablierten Datenkanals zu überwachen. Die Funktionsweise der Keepalive-Nachrichten wird bei der Erstellung der Yamux-Sitzung konfiguriert. Tatsächlich gibt es dort nur zwei Parameter: aktivieren/deaktivieren und die Häufigkeit des Versendens von Paketen in Sekunden. Sowohl der yamux-Server als auch der yamux-Client können Keepalive-Nachrichten senden. Bei Erhalt einer Keepalive-Nachricht ist die entfernte Seite verpflichtet, mit einer Nachricht mit genau derselben Identifikationsnummer (tatsächlich einer Zahl) zu antworten, die sie empfangen hat. Zusammenfassend ist Keepalive dasselbe wie ein Ping, allerdings für yamux.
Detaillierte Funktionsweise des Multiplexers: Pakettypen, Flags zur Einrichtung und Beendigung von Verbindungen sowie der Datenübertragungsmechanismus sind in yamux beschrieben.
Fazit zu Teil eins
In diesem ersten Teil des Artikels haben wir einige Werkzeuge zur Einrichtung von Reverse-Tunneln kennengelernt, ihre Vor- und Nachteile betrachtet, den Funktionsmechanismus des Yamux-Multiplexers untersucht und die wichtigsten Anforderungen an das neu zu erstellende PowerShell-Modul beschrieben. Im nächsten Teil beschäftigen wir uns mit der Entwicklung des Moduls, praktisch von Grund auf. Fortsetzung folgt. Bleiben Sie dran 🙂
Quelle: habr.com
