Eine Geschichte über Forschung und Entwicklung in 3 Teilen. Teil 1 — Forschung.
Viele Buchstaben — noch mehr Nutzen.
Aufgabenstellung
Bei Penetrationstests und RedTeam-Kampagnen ist es nicht immer möglich, die Standardtools der Kunden wie VPN, RDP, Citrix usw. zur Verbindung mit dem internen Netzwerk zu nutzen. Manchmal funktioniert der standardmäßige VPN über MFA, wobei ein physischer Token als zweiter Faktor verwendet wird, manchmal wird er stark überwacht, und unser Zugang über VPN wird sofort sichtbar, wie man so sagt — mit allen Konsequenzen, und manchmal gibt es solche Tools einfach nicht.
In solchen Fällen müssen wir ständig sogenannte „Reverse Tunnels“ erstellen — Verbindungen vom internen Netzwerk zu externen Ressourcen oder zu einem von uns kontrollierten Server. Innerhalb eines solchen Tunnels können wir dann mit den internen Ressourcen der Kunden arbeiten.
Es gibt mehrere Arten solcher Reverse Tunnels. Der bekannteste ist natürlich Meterpreter. Auch SSH-Tunnel mit Port-Forwarding erfreuen sich in der Hackerszene großer Beliebtheit. Es gibt viele Möglichkeiten, Reverse-Tunneling durchzuführen, und viele davon sind gut erforscht und dokumentiert.
Natürlich stehen die Entwickler von Sicherheitslösungen nicht untätig daneben und erkennen solche Aktivitäten aktiv.
Zum Beispiel werden MSF-Sitzungen erfolgreich von modernen IPS-Systemen von Cisco oder Positive Tech erkannt, und ein umgekehrter SSH-Tunnel kann praktisch von jeder halbwegs normalen Firewall erkannt werden.
Daher müssen wir, um in einer guten RedTeam-Kampagne unentdeckt zu bleiben, Reverse-Tunnels mit unkonventionellen Mitteln bauen und uns so nah wie möglich an den realen Betriebsmodus des Netzwerks anpassen.
Lass uns versuchen, etwas Ähnliches zu finden oder zu erfinden.
Bevor wir etwas erfinden, müssen wir verstehen, welches Ergebnis wir erzielen wollen und welche Funktionen unsere Entwicklung erfüllen sollte. Welche Anforderungen werden an den Tunnel gestellt, damit wir im Modus maximaler Geheimhaltung arbeiten können?
Es ist klar, dass sich diese Anforderungen je nach Fall stark unterscheiden können, aber aus der Berufserfahrung lassen sich einige grundlegende herausfiltern:
- Betrieb auf Windows 7-10, da in den meisten Unternehmensnetzwerken genau Windows verwendet wird.
- Der Client verbindet sich über SSL mit dem Server, um das bloße Lauschen durch IPS zu vermeiden;
- Bei der Verbindung muss der Client die Funktionalität über einen Proxy-Server mit Authentifizierung unterstützen, da in vielen Unternehmen der Internetzugang über einen Proxy erfolgt. Tatsächlich kann es sein, dass die Client-Maschine davon nichts weiß und der Proxy im transparenten Modus verwendet wird. Aber diese Funktionalität müssen wir einbauen;
- Der Client-Teil sollte prägnant und portabel sein;
Es ist klar, dass für den Betrieb innerhalb des Netzwerks des Auftraggebers auf der Client-Maschine OpenVPN installiert werden kann, um einen vollwertigen Tunnel zu unserem Server aufzubauen (zumal OpenVPN-Clients auch über Proxys arbeiten können). Aber erstens wird das nicht immer möglich sein, da wir möglicherweise keine lokalen Admins sind, und zweitens wird dies so viel Lärm machen, dass ein ordentlicher SIEM oder HIPS sofort „Alarm schlägt“. Idealerweise sollte unser Client eine sogenannte Inline-Lösung sein, wie sie viele Bash-Shells implementieren, und über die Befehlszeile gestartet werden, zum Beispiel bei der Ausführung von Befehlen aus einem Word-Makro. - Unser Tunnel sollte mehrsträngig sein und mehrere Verbindungen gleichzeitig unterstützen;
- Die Verbindung zwischen Client und Server sollte eine Art Authentifizierung haben, damit der Tunnel nur für unseren Client eingerichtet wird und nicht für alle, die auf den angegebenen Server mit Adresse und Port zugreifen. Idealerweise sollte für „externe Benutzer“ eine Landing-Page mit Katzen oder professionell thematisierten Inhalten, die mit der ursprünglichen Domain verbunden sind, geöffnet werden.
Wenn beispielsweise der Auftraggeber eine medizinische Organisation ist, sollte für den Informationssicherheitsadministrator, der die Ressource überprüfen möchte, auf die ein Mitarbeiter der Klinik zugegriffen hat, eine Seite mit pharmazeutischen Waren, Wikipedia mit einer Beschreibung der Diagnose oder der Blog von Dr. Komarowski usw. geöffnet werden.
Analyse der bestehenden Werkzeuge
Bevor wir unser eigenes Fahrrad erfinden, ist es notwendig, eine Analyse der bestehenden Fahrräder durchzuführen und zu verstehen, ob wir tatsächlich Bedarf haben und wahrscheinlich nicht die Einzigen sind, die an einem solchen funktionalen Fahrrad gedacht haben.
Google-Suchen im Internet (wir goggle wohl ganz normal), sowie die Suche auf GitHub mit den Schlüsselwörtern „reverse socks“ haben nicht wirklich viele Ergebnisse geliefert. Im Wesentlichen geht es vor allem um den Aufbau von SSH-Tunneln mit rückwärts gerichteter Portweiterleitung und allem, was damit zusammenhängt. Neben SSH-Tunneln lassen sich einige Lösungen hervorheben:
Eine ältere Implementierung des Rücktunnel von den Jungs aus dem Kaspersky-Labor. Der Name macht klar, wofür dieses Skript gedacht ist. Implementiert in Python 2.7, funktioniert der Tunnel im Klartextmodus (wie man heutzutage gerne sagt – hallo RKN)
Eine weitere Implementierung in Python, ebenfalls im Klartext, aber mit größeren Möglichkeiten. Als Modul geschrieben und es gibt eine API zur Integration der Lösung in eigene Projekte.
Der erste Link – die ursprüngliche Version der Implementation von Reverse Socks in Golang (wird vom Entwickler nicht unterstützt).
Der zweite Link – unsere Überarbeitung mit zusätzlichen Funktionen, ebenfalls in Golang. In unserer Version haben wir SSL implementiert, die Arbeit über einen Proxy mit NTLM-Authentifizierung, die Client-Authentifizierung, eine Landing-Page bei falschem Passwort (genauer gesagt – Weiterleitung zur Landing-Page), einen Multithread-Modus (d.h. mehrere Personen können gleichzeitig mit dem Tunnel arbeiten), ein Ping-System des Clients, um zu überprüfen, ob er noch lebt oder nicht.
Die Implementierung von Reverse Socks von unseren „chinesischen Freunden“ in Python. Dort gibt es auch für die Faulen und „Unsterblichen“ bereits eine fertige Binärdatei (exe), die von den Chinesen kompiliert wurde und bereit zur Verwendung ist. Hier weiß nur der chinesische Gott, was in dieser Binärdatei noch sein kann, außer der Hauptfunktionalität, also nutzen Sie dies auf eigenes Risiko.
Ein ziemlich interessantes Projekt in C++ zur Implementierung von Reverse Socks und mehr. Neben dem Rücktunnel kann es Ports weiterleiten, eine Befehlszeile erstellen usw.
MSF meterpreter
Hier, wie man sagt, ohne Kommentare. Alle halbwegs gebildeten Hacker wissen gut über dieses Ding Bescheid und verstehen, wie leicht es von Schutzmaßnahmen entdeckt wird.
Alle oben beschriebenen Werkzeuge arbeiten nach einer ähnlichen Technologie: Auf dem Computer innerhalb des Netzwerks wird ein zuvor vorbereiteter ausführbarer Binärmodul gestartet, der eine Verbindung zu einem externen Server herstellt. Auf dem Server wird ein SOCKS4/5-Server gestartet, der Verbindungen akzeptiert und diese an den Client weiterleitet.
Der Nachteil aller oben genannten Werkzeuge ist, dass entweder Python oder Golang auf dem Client-Computer installiert sein muss (wie oft haben Sie zum Beispiel Python auf den Computern von Unternehmensdirektoren oder Büroangestellten gesehen?), oder dass man ein bereits kompiliertes Binary (tatsächlich Python und das Skript in einer Flasche) auf diesen Computer bringen und dieses Binary dort ausführen muss. Das Herunterladen einer exe-Datei und deren anschließendes Ausführen ist ein weiteres Signal für die lokale Antiviren-Software oder HIPS.
Im Allgemeinen ergibt sich die Schlussfolgerung von selbst – wir benötigen eine Lösung in PowerShell. Jetzt wird man uns mit Tomaten bewerfen – ist PowerShell nicht schon ausgelutscht, wird überwacht, blockiert usw. Tatsächlich ist das nicht überall der Fall. Wir behaupten das verantwortungsvoll. Übrigens gibt es unzählige Möglichkeiten, die Blockaden zu umgehen (hier kommt wieder die schicke Phrase über den Hallo RKNP 🙂), angefangen bei der einfachen Umbenennung von powershell.exe in cmdd.exe bis hin zu powerdll usw.
Wir fangen an zu erfinden.
Es ist klar, dass wir zuerst bei Google nachsehen werden und… genau nichts zu diesem Thema finden (wenn jemand etwas gefunden hat – postet Links in die Kommentare). Es gibt nur von Socks5 in PowerShell, aber das ist ein gewöhnlicher „direkter“ Sock, der eine Reihe von Nachteilen hat (darüber werden wir später sprechen). Natürlich kann man ihn mit einem einfachen Handgriff in einen umgekehrten verwandeln, aber das wird nur ein einsträngiger Sock, was für uns nicht ganz das Richtige ist.
Das heißt, wir haben nichts Fertiges gefunden, also müssen wir trotzdem unser eigenes Rad erfinden. Die Grundlage für unser Rad werden wir eines umgekehrten Socks in Golang nehmen und den Client dafür in PowerShell realisieren.
RSocksTun
Wie funktioniert also rsockstun?
Die Funktionsweise von RsocksTun (im Folgenden rs genannt) beruht auf zwei Software-Komponenten – Yamux und Socks5-Server. Der Socks5-Server ist ein gewöhnlicher lokaler Socks5, der auf dem Client gestartet wird. Die Multiplexierung der Verbindungen zu ihm (erinnern Sie sich an die Multithreadfähigkeit?) wird durch Yamux gewährleistet (). Dieses Schema ermöglicht das Starten mehrerer Client-Socks5-Server und die Verteilung externer Verbindungen zu ihnen, indem diese über eine einzige TCP-Verbindung (fast wie bei meterpreter) vom Client zum Server geleitet werden, wodurch ein Mehrbenutzermodus realisiert wird, ohne den wir in einem internen Netzwerk nicht einwandfrei arbeiten können.
Die Funktionsweise von yamux besteht darin, dass es eine zusätzliche Netzwerkschicht von 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 „Thread“, um den Leser nicht mit dem Software-Thread-Begriff zu verwirren — dieses Konzept werden wir ebenfalls in diesem Artikel verwenden). Im Header von yamux sind die Stream-Nummer, Flags zur Eröffnung/Beendigung des Streams, die Anzahl der übertragenen Bytes und die Größe des Übertragungsfensters enthalten.
Neben der Eröffnung/Beendigung von Streams implementiert yamux auch einen Keepalive-Mechanismus, der es ermöglicht, die Funktionsfähigkeit des etablierten Kommunikationskanals zu überwachen. Die Funktionsweise der Keepalive-Nachrichten wird beim Erstellen einer Yamux-Sitzung konfiguriert. Tatsächlich gibt es nur zwei Parameter: aktivieren/deaktivieren und die Häufigkeit der Paketsendungen in Sekunden. Keepalive-Nachrichten können sowohl vom yamux-Server als auch vom yamux-Client gesendet werden. Bei Erhalt einer Keepalive-Nachricht muss die entfernte Seite mit der genau gleichen Message-ID (tatsächlich einer Zahl) antworten, die sie empfangen hat. Im Allgemeinen ist Keepalive dasselbe wie ein Ping, nur für yamux.
Die Technik der Funktionsweise des Multiplexers: Packettypen, Flags zur Einrichtung und Beendigung von Verbindungen sowie der Mechanismus der Datenübertragung ist ausführlich beschrieben in yamux.
Abschluss des ersten Teils
In Teil 1 des Artikels haben wir uns mit einigen Werkzeugen zur Organisation von Reverse-Tunneln vertraut gemacht, ihre Vor- und Nachteile betrachtet, den Mechanismus der Funktionsweise des Yamux-Multiplexers untersucht und die grundlegenden Anforderungen an das neu zu erstellende PowerShell-Modul beschrieben. Im nächsten Teil werden wir mit der Entwicklung des Moduls praktisch von Grund auf beginnen. Fortsetzung folgt. Bleiben Sie dran 🙂
Quelle: habr.com
