Muraena und NecroBrowser hacken Zwei-Faktor-Authentifizierung

Ein „Fehler beim Mobilfunkanbieter“, erklärt Twitter Ende August, sei schuld daran, dass Hacker den Account des Twitter-CEOs Jack Dorsey trotz aktiver Zwei-Faktor-Authentifizierung (2FA) übernehmen konnten. Vermutlich war es einem Angreifer schlicht gelungen, seine Mobilfunk-SIM als die von Dorsey auszugeben. Dorsey war aber nicht der erste Promi, dem derlei widerfuhr: Bereits mehrfach musste Facebook ähnliche Vorfälle rund um Mark Zuckerbergs Account einräumen – ein Hacker drohte gar, „Zucks“ Account ganz zu löschen.

Auch wenn damals viele Medien sogleich unkten: „Facebook zerstört das Vertrauen in 2FA“, zeigten sich Sicherheitsexperten wenig überrascht. Dass gerade Smartphones oder Handys ein allzu leichtes Angriffsziel ausmachen und daher nicht für 2FA-Verfahren wie SMS-TAN Verwendung finden sollten, hat schon vor bald zehn Jahren eine vom Online-Banking und -Brokerage-Spezialisten Cortal Consors organisierte Roadshow exemplarisch vorgeführt.

Signifikante Zahl von Angriffen

Damals erklärten die Banker, die Gefahr sei gering, weil die Anzahl derartiger Angriffe überschaubar sei. Das hat sich geändert: Dieser Artikel zeigt, wie zwei spezialisierte, automatisierte Tools (Muraena und NecroBrowser) die meisten gängigen 2FA-Verfahren aushebeln und warum nur U2F/FIDO dagegen gefeit ist. Das Photon Research Team von Digital Shadows hat deshalb für die iX beide Tools einem ­Praxistest unterzogen. 

Phishing zählt nach wie vor zu den am weitesten verbreitenden Cyberbedrohungen. Kriminelle schaffen es immer wieder, über die einfache, aber effektive Technik an sensible Informationen wie Benutzernamen und Passwörter zu kommen. Traditionelle Phishingangriffe nutzen gefälschte Anmeldeseiten auf vom Angreifer gesteuerten Webservern mit benutzerdefinierten Fake-Domains, die den echten Webseiten zum Verwechseln ähnlich sehen. Einmal erbeutete Anmelde­informa­tionen lassen sich für weitere Angriffe nutzen oder gewinnbringend weiterverkaufen.

Zwei-Faktor-Authentifizierung ist kein Allheilmittel

Lange Zeit konnten sich Nutzer mithilfe der Zwei-Faktor-Authentifizierung vor dieser Art von Angriff weitgehend schützen. 2FA nahm dazu einfach einen weiteren Faktor in den Authentifizierungs­prozess mit auf – entweder eine Besitz­komponente („etwas, das du hast“, zum Beispiel einen USB-Stick oder eine Speicherkarte mit einem geheimen Token), eine Wissenskomponente („etwas, das du weißt“, wie eine TAN) oder eine in­härente Komponente („etwas, das du bist“, zum Beispiel ein biometrisches Kennzeichen wie einen Fingerabdruck). Die im Folgenden genauer betrachteten Besitzkomponenten, auf die sich Muraena und Necro­Browser spezialisiert haben, sind:

• Smartcards oder ICC-Karten (Integrated Circuit Chip),
• SMS-Token via Mobiltelefon,
• zeitbasierte Einmalpasswörter (Time-­based One-time Password, TOTP) via Software, beispielsweise Google Authenticator,
• zeitbasierte Einmalpasswörter (TOTP) via Hardwaretoken, etwa bei RSA SecurID,
• Universal Second Factor (U2F) Hardware Tokens, als Beispiel die Yubico Yubi­Keys.

Um zu zeigen, warum der zuletzt genannte U2F-Industriefaktor am wirkungsvollsten gegen automatisiertes Phishing schützt, stellt dieser Artikel kurz die Unterschiede zwischen den Technologien vor und erklärt anschließend, wie Muraena und NecroBrowser vorgehen.

Smartcards oder ICC-Karten 

ICC-Karten sind eine Form von 2FA, die typischerweise in hochsicheren Windows-­Umgebungen zum Einsatz kommt. Sie werden eigentlich nur für den Zugriff auf interne Ressourcen verwendet, nicht für externe Ressourcen wie Websites oder Cloud-Services. Die Smartcard speichert ein X509-Zertifikat, das der eindeutigen Identifizierung des Benutzers dient. Das Zertifikat ist verschlüsselt und muss mit einer PIN freigeschaltet werden. Während die Verwendung eines hardware­gestützten Zertifikats starke Sicherheits­eigenschaften aufweist, stellt die Verwaltung der PKI-­Infrastruktur, die für die unternehmensweite Bereitstellung von Smartcards erforderlich ist, für viele Unternehmen eine große Herausforderung dar.

SMS-Token via Mobiltelefon

SMS-Token, die von einem Mobiltelefon empfangen werden, gehören zu den am weitesten verbreiteten 2FA-Verfahren. Das Prinzip ist relativ simpel: Versucht ein Benutzer sich bei einer Ressource anzu­melden, wird ein Zufallscode generiert und an das vorab registrierte Mobiltelefon gesendet. Nach Eingabe dieses Codes in die sekundäre Anmeldeaufforderung folgt bei erfolgreicher Authentifizierung an der Ressource die Anmeldung.

SMS-Token sind allerdings angreifbar. Über einen SIM-Swap-Angriff lassen sich Token abfangen, wenn Angreifer beispielsweise den Mobilfunkanbieter davon überzeugen können, die Nummer auf eine von ihnen kontrollierte SIM-Karte zu portieren. Ähnliches soll Twitter-Chef Dorsey widerfahren sein.

Ein SIM-Token kann zudem wiederverwendet werden (Replay-Angriff), wenn es im Rahmen einer Social-Engineering-­Kampagne an einen bösartigen Server gesendet wird. Es ist sogar möglich, dass ein SMS-Token durch SS7-Hijacking abgefangen wird, ein Signalsystem von Netzbetreibern, das über keine grundlegenden Schutzmaßnahmen verfügt und jedes Kommando verarbeitet, egal aus welcher Quelle es kommt.

TOTP via Software 

TOTP-Passwörter sind kryptografisch generiert und nur für eine einmalige Verwendung vorgesehen. Spezielle TOTP-­Software erzeugt sie, meist über eine App auf einem mobilen Gerät. Bei deren Initialisierung synchronisieren Server und App ein gemeinsames kryptografisches Geheimnis. Mit diesem Secret als Seed erzeugt die App beispielsweise jede Minute eine neue Zufallszahl, die vom Server als zweiter Faktor verwendet wird, um den Anmeldevorgang abzuschließen. Dieser Prozess erfordert, dass die Uhren der App und des Servers synchronisiert sind, beispielsweise durch NTP. Nur so lässt sich das Wiederverwenden alter Zufallszahlen verhindern.

Nach der Einrichtung ist keine Kommunikation zwischen der App und dem Server mehr notwendig, das heißt, der Code kann nicht wie im SMS-Token-Fall abgefangen werden. Es gibt jedoch keine Authentifizierung der Serverkomponente, sodass beispielsweise Opfer eines Social-­Engineering-Angriffs Gefahr laufen, Kriminellen unbeabsichtigt einen echten Code preiszugeben.

TOTP via Hardwaretoken

Auf dem Markt verfügbar sind auch viele Hardwaregeräte, die 2FA bereitstellen, allen voran RSA SecurID oder SafeNet eToken. Auch wenn sich die Produkte in manchen Punkten deutlich unterscheiden, bleibt die Hauptfunktion sehr ähnlich. Wie bei den Softwaretoken generieren sie kryptografisch eine Zufallszahl, die als zweiter Faktor für einen Login-Prozess verwendet wird, nur eben auf vermutlich sicherer Hardware. Wie Software-TOTP-­Token, die über eine App auf mobilen Geräten instanziiert werden, können auch Hardwaretoken verloren gehen. In dem Fall – oder wenn die Hardware beschädigt oder vernichtet wurde – muss die PKI ein neues Hardwaretoken bereitstellen und registrieren.

Phishing 2.0

Seit es 2FA gibt, existieren Techniken, die zweistufige Verifizierung zu umgehen. Entsprechende Toolkits sind mittlerweile auch in die gängigen Phishing-Frameworks implementiert. Der Klassiker beim Überlisten von 2FA ist es nach wie vor, Phishingwebseiten als Proxys aufzusetzen, Anfragen im Namen der Opfer an die legitimen Webseiten weiterzuleiten und Antworten in Echtzeit zu liefern. Auf diese Weise gelangen Angreifer nicht nur an Benutzernamen und Passwörter, sondern auch an aktive Session-Token (Session-­Cookies). Die echten Webseiten weisen diese den angemeldeten Accounts zu – und durch das Platzieren dieser Session-Cookies in einem Browser kann ein Angreifer direkt auf die zugehörigen Konten zugreifen, ohne dass er sich authentifizieren muss.

Auch wenn die Proxy-basierte Vorgehensweise nicht neu ist, erfordert sie dennoch technisches Fachwissen inklusive Konfiguration mehrerer voneinander unabhängiger Tools, beispielsweise den nginx-­Webserver als Reverse-Proxy. Außerdem muss der Angreifer die gestohlenen Session-Cookies manuell benutzen, ehe sie ablaufen. Einige Webseiten setzen zudem Technologien wie Subresource Integrity (SRI) und Content Security Policy (CSP) ein, um Proxying zu verhindern. Das ermöglicht es den Betreibern, manche automatisierten Browser zu blockieren, die auf Headern basieren. Mit aktiviertem CSP wird der Webserver als Antwort einen HTTP-­Security-Header versenden und so den Browser zwingen, eine Reihe von Sicherheitsvorkehrungen zu aktivieren oder zu deaktivieren. Die darin enthaltenen Metadaten liefern beispielsweise Informationen zu Größe und Art des Inhalts, Cache-Einstellungen oder Serverdaten. Manche automatisierten Angriffsvarianten lassen sich so erfolgreich blockieren.

Muraena und NecroBrowser

Im Mai 2019 veröffentlichten Sicherheitsexperten mit Muraena und Necro­Browser zwei Tools, die die oben genannten Schutzmaßnahmen nicht nur umgehen, sondern Angriffe auf 2FA automatisieren. Damit sind nun auch groß angelegte Phishing­angriffe auf 2FA möglich.

Muraena und NecroBrowser wurden erstmals auf der „Hack in the Box“-Konferenz in Amsterdam vorgestellt und standen schon nach wenigen Tagen bei GitHub bereit. Muraena fungiert dabei als transparenter Reverse-Proxy, der Anmeldeinformationen und Session-Cookies erfasst. Diese gültigen Sitzungen übergibt es an den NecroBrowser, der die gesammelten Sitzungen verwendet, um das Opfer zu imitieren. NecroBrowser nutzt dazu eine Reihe von Docker-Images mit laufenden Chrome-Browsern, um die gestohlenen Sitzungen am Leben zu erhalten, die Extraktion von Daten zu automatisieren und andere Aktionen im Namen des Angegriffenen durchzuführen.