fkasler/cuddlephishBewaffneter Browser-in-the-Middle (BitM) für Penetrationstester
Einsatzbereites Multi-User Browser-in-the-Middle (BitM) für Penetrationstester. Dieser Angriff kann verwendet werden, um die Multi-Faktor-Authentifizierung auf vielen hochwertigen Webanwendungen zu umgehen. Er funktioniert sogar bei Anwendungen, die keine Sitzungstoken verwenden und daher mit traditionellen Token-Diebstahlangriffen nicht ausnutzbar wären. Dies ist ein Social-Engineering-Tool und nutzt keine technischen Schwachstellen im Zielservice aus.
Dieses Tool ist ein spezialisierter Webserver. Es ist für den Betrieb auf einem Debian 11 (Bullseye) Linux-Server ausgelegt und verlässt sich auf öffentliche IP-Informationen, um die Admin-Funktionalität zu schützen. Erwarten Sie nicht, dass Sie lokal testen können, ohne einige ernsthafte Hürden zu nehmen.
Warnung: Chromium wird auf ARM nicht unterstützt. Obwohl es technisch möglich ist, die Verwendung einer ARM-Chromium-Binärdatei zu erzwingen, verlieren Sie alle zusätzlichen Funktionen/Schutzmaßnahmen von puppeteer-extra.
Dieses Beispiel-Setup verwendet Caddy, um TLS, SNI zu handhaben und ein paar benutzerdefinierte Header wie 'X-Real-IP' zu jeder Anfrage hinzuzufügen. Sie müssen Caddy nicht mit Cuddlephish verwenden, da derselbe Reverse-Proxy mit Nginx, Apache usw. eingerichtet werden kann. Ich mag Caddy einfach, weil es einfach mit Docker zu installieren ist und Plugins zur Verwaltung von Letsencrypt-Zertifikaten für die meisten Domain-Registrare besitzt. Die beispielhafte Caddyfile zeigt, wie man es für Gandi einrichtet. Überprüfen Sie die Dokumentation für Ihren Registrar.
Installieren Sie Docker, Node, XVFB und einige andere Abhängigkeiten:
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh
Sie können dann Docker verwenden, um Caddy mit einem Wildcard-Zertifikats-Plugin für Ihren Registrar zu erstellen. Das Beispiel ist für Gandi. Überprüfen Sie die Dokumentation hier und die Liste der DNS-Provider-Module hier. Sie können die Dockerfile vor dem Bauen für Ihren Registrar anpassen:
sudo docker build -t caddy .
Ändern Sie nun die Caddyfile, um Ihre Domain und den Gandi (oder anderen Registrar) API-Key auszutauschen, und starten Sie Caddy. Ich empfehle, dies in einem screen- oder tmux-Fenster zu starten, damit Sie den Node-Server gleich in einem anderen Fenster ausführen können:
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest
Mit Caddy, das den Datenverkehr für uns auf den Ports 80 und 443 abfängt, können wir endlich das Tool ausführen!
Installieren Sie die Node-Abhängigkeiten:
npm install
Ein paar Konfigurationsanpassungen: KRITISCHER SCHRITT: Stellen Sie sicher, dass Sie die beispielhafte config.json anpassen, um Ihre genehmigte(n) öffentliche(n) IP(s) für den Admin-Zugriff hinzuzufügen. Diese Whitelist von IPs bestimmt den Zugriff auf das "/admin"-Webinterface. Sie sollten auch den Standardschlüssel für den Socket durch etwas Sichereres ersetzen.
Das Tool ist standardmäßig nicht auf Login-Seiten eingestellt, daher müssen Sie einige hinzufügen. Es gibt ein Skript 'add_target.js', das diesen Schritt einfach macht. Führen Sie einfach das Skript aus und fügen Sie die URL des Login-Portals, das Sie anvisieren möchten, ein, wenn Sie dazu aufgefordert werden:
node add_target.js
Dieses Skript holt den Dienstnamen, den Tab-Titel und das Favicon für Sie und fügt einen Eintrag in 'targets.json' hinzu. Sie können dieses Skript mehrmals ausführen, und es wird Ihre neuen Ziele hinzufügen. Das Skript benennt jeden Dienst basierend auf der Domain, ohne die Top-Level-Domain. Für 'https://www.example.com/login.php' würde der Dienst also nur 'example' sein, wenn Sie Ihr Ziel angeben, wenn Sie...
Führen Sie es aus!
node index.js example
Nach ein paar Sekunden sollten Sie eine Meldung in der Konsole sehen, wenn Ihre erste automatisierte Chrome-Instanz über Websockets eingecheckt wird. Jetzt sollten Besucher Ihrer Phishing-Seite das sehen, was wie die Ziel-Login-Seite aussieht, aber tatsächlich ein Video-Feed Ihrer automatisierten Browser-Instanz ist. Sie können auch mit Ihrer Browser-Instanz interagieren und sich für Sie einloggen.
Wenn Sie Ihre Admin-IP(s) korrekt in der config.json konfiguriert haben, sollten Sie in der Lage sein, ein spezielles '/admin'-Webinterface anzuzeigen, um Benutzer zu verfolgen, Tastenprotokolle anzuzeigen, die Kontrolle über eingeloggte Browser-Instanzen zu übernehmen, Cookies zu stehlen und unerwünschte Browser-Instanzen zu löschen.
Hinweis: Sie werden nichts auf der Admin-Seite sehen, bis Sie einige Opfer haben. Sobald Sie ein Opfer haben, sollte dessen Browser-Instanz auf der Admin-Benutzeroberfläche erscheinen.
Ich hatte mehrere Leute, die Issues über eine 'Blank White Page' eröffnet haben, was eher ein Symptom für viele mögliche Probleme ist, und kein Problem an sich. Bitte eröffnen Sie keine Issues unter vagen Symptomnamen. Versuchen Sie stattdessen, wenn Sie auf der Benutzerseite eine leere Seite haben, zunächst Folgendes zu überprüfen:
Auf hoher Ebene bedeutet eine leere Seite auf der Frontend-Seite, dass es eine Unterbrechung in der Datenflusskette gibt: 'Start WebRTC' > 'Wähle Tab zum Broadcasten' > 'ICE mit dem Browser des Opfers aushandeln' > 'Video streamen'. Die obigen Fehlerbehebungsschritte sollen Ihnen helfen, die Daten durch diesen Prozess zu verfolgen. Bei ordnungsgemäßem Betrieb sollten Sie einen Log-Stream auf dem Server sehen, der dem folgenden ähnelt:
Ich hoffe, das hilft bei Problemen, und wie immer sind ausreichende Informationen zur konsistenten Reproduktion eines Problems Voraussetzung für das Einreichen von Issues zur weiteren Untersuchung.
Lösen Sie manuell einen Payload aus, der über JavaScript auf das System des Opfers heruntergeladen wird. Jedes Ziel beginnt mit 'payload.txt' als Test-Payload. Tauschen Sie einfach den Dateipfad in targets.json aus, um einen benutzerdefinierten Payload zu senden.
Sendet eine window.location-Änderung an das Opfer, um es zum echten Login-Portal zu schicken. Es wird so aussehen, als müssten sie sich nur erneut authentifizieren, und verhindert, dass sie zusehen, wie Sie die Kontrolle übernehmen. Wenn Sie den Code anpassen, könnten Sie mit dieser allgemeinen Technik einige andere ausgefallene Dinge tun ;)
Ermöglicht es Ihnen, direkt vom Admin-Portal aus die Kontrolle über eine Browser-Instanz zu übernehmen. Um die Steuerung der Instanz zu beenden, drücken Sie die ESCAPE-Taste. Hinweis: Dies entzieht dem Phishing-Opfer die Kontrolle, und es wird Ihre Bewegungen sehen können, wenn Sie es nicht zuerst rauswerfen. Sie sind gewarnt.
Ermöglicht es Ihnen, dem Benutzer manuell die Kontrolle über die automatisierte Browser-Instanz zurückzugeben. Dies könnte in einigen Social-Engineering-Szenarien nützlich sein, wenn Sie die IT-Abteilung vorspielen. Sie können dem Benutzer sagen, dass Sie eine Hilfssitzung starten, die Kontrolle übernehmen und zum Zieldienst navigieren, die Kontrolle zurückgeben und ihn einloggen lassen, die Kontrolle wieder übernehmen usw.
Extrahiert alle Cookie- und Local-Storage-Elemente aus der Browser-Instanz und lädt sie als JSON-Datei herunter. Um dieses Anmeldeinformationsmaterial wieder in eine auf Ihrem lokalen System laufende Browser-Instanz einzuschleusen, gibt es ein Skript im Projekt namens 'stealer.js'. Es ist für die Ausführung auf Ihrem Rechner gedacht, nicht auf dem Server. Um es zu verwenden, müssen Sie auch die Node-Komponenten des Projekts auf Ihrem System installieren.
node stealer.js ~/Downloads/cuddle_asdf1234.json
Beendet eine Browser-Instanz, wenn Sie sie nicht mehr benötigen. Manchmal loggen Benutzer Sie nicht vollständig ein. Manchmal schlägt die WebRTC-Verbindung fehl. Manchmal läuft eine Sitzung ab, bevor Sie sie nutzen können. In diesen Fällen kann dieser Button Ihnen helfen, nutzlose Browser-Instanzen über das Admin-Portal zu bereinigen.
Jeder Browser wird mit einer eigenen zufälligen 'Browser-ID' und einem passenden Benutzerdatenverzeichnis im 'user_data'-Ordner des Projekts gestartet. In einigen Fällen, in denen 'stealer.js' nicht funktioniert, müssen Sie möglicherweise auch die Benutzerdaten für diese Instanz replizieren. Dies kann in Fällen nützlich sein, in denen Dienste mit einer 'Diesen Browser merken'-Funktion anvisiert werden, abhängig davon, wie diese Funktion implementiert ist.
Es gibt auch eine keylog.txt in jedem Benutzerdatenverzeichnis mit einem vollständigen Tastenprotokoll des Opfer-Benutzers. Das allgemeine Tastenprotokoll im Admin-Portal versucht, Dinge wie Rücktasten zu berücksichtigen, während diese keylog.txt alle aufgezeichneten Tastenanschläge enthält.
Beispiel pm.json:
{
"tacking_id": "id",
"logging_endpoint": "https://www.phishmongerserver.com/create_event",
"admin_cookie": "admin_cookie=s3cret",
"post_url_search": "ppsecure"
}
Dieses Tool funktioniert, indem es Besucher der Phishing-Seite mit einem automatisierten Chrome-Browser koppelt, der auf dem Phishing-Server läuft. Ein Videofeed der vom Angreifer kontrollierten Chrome-Instanz wird dann über WebRTC an das Phishing-Opfer gestreamt, und alle vom Benutzer bereitgestellten Mausbewegungen und Tastatureingaben werden vom Browser des Opfers an die zugehörige Chrome-Instanz weitergeleitet. Der Server verwendet Websockets, um Opfer zu verfolgen, sie mit Browsern zu paaren, WebRTC-Videostreams zu vermitteln und Benutzereingaben mitzulesen. Für jeden neuen Besucher erzeugt der Server eine neue Chrome-Instanz. Da wir das Chrome Devtools Protocol (CDP) verwenden, um jede Chrome-Instanz zu steuern, können wir APIs wie 'Storage.getCookie' nutzen, um Sitzungscookies für Zielseiten zu extrahieren, sobald sich der Benutzer für uns eingeloggt hat. Wir können auch jederzeit eingreifen und jede Chrome-Instanz direkt steuern, wobei wir dieselbe Methode verwenden, mit der wir Opfern überhaupt erst die Fernsteuerung ermöglichen.
Der Node-Server führt Folgendes aus:
Nach meinem Verständnis wurde diese Technik seit mehreren Jahren theoretisiert und sogar bewaffnet (siehe Danksagungen). Während Bedrohungsakteure diese Technik nutzen können und dies wahrscheinlich auch schon seit einiger Zeit tun, hatten offensive Sicherheitsexperten keine einfache Möglichkeit, diese Technik zu replizieren, und sind sich ihrer Existenz möglicherweise nicht einmal bewusst. Meine Absicht bei der Veröffentlichung des Tools ist es, Penetrationstestern und Red Teamern zu ermöglichen, BitM in Operationen einzusetzen, um seine potenziellen Auswirkungen zu demonstrieren und Netzwerkverteidigern zu helfen, sich auf echte Bedrohungen vorzubereiten.
Zunächst einmal verstehen Sie, dass dieser Angriff auf Social Engineering beruht, bei dem ein Benutzer dazu gebracht wird, eine bösartige Website zu besuchen. Domain-Whitelisting würde viel dazu beitragen, dies und andere Arten von Social Engineering zu verhindern. Wenn wir uns darauf verlassen, dass Benutzer 100 % der Anmeldedaten (Passwort, OTP, SMS, PhoneFactor, Push-Benachrichtigung usw.) für einen Webdienst verwalten, sind wir potenziell anfällig für diesen Angriff. Um diesen Angriff zu vereiteln, müssen wir daher Anmeldedaten nutzen, die Benutzer nicht verwalten. Beispielsweise können Client-TLS-Zertifikate an Client-Geräte ausgestellt werden und sind nur für den echten Webdienst gültig. Das Zertifikat wird vom Browser und Betriebssystem verwaltet, und es gibt keine Möglichkeit für den Server eines Angreifers, eine Kopie des TLS-Zertifikats des Opfers zu erhalten. Eine weitere Möglichkeit ist die Verwendung von U2F oder FIDO2 mit Hardware wie einem YubiKey, um einen Teil der erforderlichen Anmeldedaten zu verwalten. Es gibt keine Möglichkeit für die Website eines Hackers, mit einem YubiKey zu interagieren, der an den Computer eines Opfers angeschlossen ist.
Ich bin noch kein Docker-Experte. Wenn Sie ein einfaches Docker-Setup entwickeln können, würde ich mich über einen Pull-Request sehr freuen.
Es ist ein Wortspiel aus Cuttlefish (einem knallharten Meerestier, das sich seiner Umgebung anpassen kann), Phishing (weil es Social Engineering erfordert, um den Angriff durchzuführen) und absichtlich falsch geschrieben, um einzigartig, verspielt und albern zu sein. Es macht mich glücklich zu denken, dass dieser lustige Toolname in Pentest-Berichten neben kritischen Risikobewertungen erwähnt wird.
Obwohl ich diese Technik und Implementierung unabhängig entwickelt habe, habe ich inzwischen erfahren, dass ein paar andere Forscher mir bei der Entdeckung zuvorgekommen sind. Sie haben jeweils einen Ansatz mit webbasierten VNC-Clients verwendet, um ein ähnliches Ergebnis zu erzielen. Es ist ein intuitiver Ansatz und könnte auch für MitM-Angriffe gegen andere Software als Browser anwendbar sein (VPN-im-Browser vielleicht?). Auf jeden Fall einen Blick wert:
Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5
@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/
Auch:
Shoutout to Daniel Aaron @majordmg for helping with the early stages of WebRTC proof-of-concept.
Huge thanks to RJ Stallkamp @Z3rO-C00L for fixing and styling the admin interface, and the sweet new logo.