Zurückgephisht
Wie wir einem unachtsamen Phisher auf die Schliche kamen
Phishing und Spamming sind eigene kriminelle Industriezweige, die Hand in Hand arbeiten. Weil sich ein Phisher einen dummen Fehler leistete, konnten wir mehr über ihn erfahren, als ihm lieb sein konnte.
Eine verdächtige Mail mit einer noch verdächtigeren URL landete in einem Spam-Filter, den einer unserer Leser betreut. Beruflich kümmert er sich um IT-Sicherheit und so war ihm sofort klar, dass es sich bei der vermeintlichen Aufforderung des Mailanbieters, sich aus Sicherheitsgründen sofort an der Webmail-Oberfläche anzumelden, um einen Phishing-Versuch handeln musste. Der Link in der Mail zeigte zu einer Subdomain von web.core.windows.net und enthielt am Ende als Query-Parameter die Mailadresse. Neugierig schaute sich der Leser die Seite an und fand ein anschauliches Beispiel für eine Phishing-Attacke – und eine Sicherheitslücke zu Ungunsten des Phishers.
In einer virtuellen Maschine probierten wir den Link aus und tauschten die Mailadresse im Link durch eine Beispiel-Adresse beim deutschen Mail-Hoster Web.de aus. In der Mitte erschien vor grauem Hintergrund ein stark deformiertes Login-Fenster, das nur entfernt an das Original von Web.de erinnerte. Wer dort sein Kennwort eingab, musste schon sehr naiv sein.
Ein Blick in die Entwicklerwerkzeuge des Browsers enthüllte, was sich der Phisher eigentlich überlegt hatte: Per Iframe sollte hinter dem Fenster die echte Web.de-Seite von https://web.de eingebettet werden, darüber sollte das selbstgebaute Login-Fenster schweben. Das hätte die Täuschung zumindest etwas besser gemacht und die Erfolgsquote sicher erhöht. Doch daraus wurde nichts: Weil die Betreiber von Web.de schon länger mit Phishing gegen ihre Nutzer zu tun haben, haben sie ihre Server so konfiguriert, dass sie folgenden Header mitschicken:
content-security-policy: frame-ancestors 'none'
Moderne Browser weigern sich dann, die Seite im Iframe darzustellen – es bleibt eine unattraktive graue Fläche. Eine kleine Einstellung im Server, die Phishing zumindest etwas erschwert. Wer selbst Login-Seiten betreibt, ist gut beraten, diesen Header zu aktivieren.
Die Phishing-Seite war so programmiert, dass sie dynamisch auf unterschiedliche Mailhoster reagierte: In der URL wurde die Mailadresse des Opfers übergeben, die Phishing-Links müssen also in einer Art Serienbrief personalisiert generiert und verschickt werden. Je nach Mailadresse versucht die Seite, unterschiedliche Mail-Anbieter per Iframe einzubinden und stellt das Favicon der Seite als Logo im Login-Fenster dar. Eine kleine Versuchsreihe zeigte aber, dass die gängigsten Mail-Provider Iframe-Einbindungen per Header unterbunden und die meisten Opfer wohl eine graue Fläche gesehen haben.
Passwortversand
Neben Iframe und gefälschtem Login-Fenster fanden wir JavaScript auf der Seite. Die Analyse hatten die Entwickler aber deutlich erschwert und den Code mit einem sogenannten Obfuskator etwas unkenntlich gemacht. Ein solches Werkzeug ersetzt möglichst viel aussagekräftigen Klartext (Strings, Funktions- und Variablennamen) durch andere Zeichen, in diesem Fall durch hexadezimale Zeichen. So wird es zwar nicht unmöglich, den Code zu verstehen, aber immerhin mühsam (als Gegenmittel gibt es wiederum De-Obfuskatoren).
Aber auch ohne JavaScript-Code im Klartext konnten wir beobachten, was beim vermeintlichen Anmelden geschah. Die Entwicklerwerkzeuge aller Browser haben einen Reiter „Netzwerk“, der HTTP-Aufrufe mit Anfrage- und Antwortdaten protokolliert und darstellt. Für gewöhnlich wird das Kennwort per HTTP an den Server geschickt und dort gespeichert. Doch dieser Fall war ungewöhnlich – und nicht gerade geschickt:
Sandte man das Formular ab, wurde eine Anfrage an den Endpunkt sendMessage von https://api.telegram.org/ geschickt, in den Formulardaten das Kennwort, das man ins Kennwortfeld getippt hatte:
##+nEw+lOg+## +------------------------+ max.muster@web.de+|+geheimes_passwort +------------------------+
Im Messenger Telegram kann jeder einen Bot anlegen und mit ihm eine Kommunikation starten. Bots sind klar als solche gekennzeichnet und ganz hilfreich, um sich zum Beispiel Statusmeldungen seiner Server oder des vernetzten Zuhauses schicken zu lassen. Dafür reicht ein API-Aufruf, wie wir ihn gefunden haben. Der Phisher nutzte dieses Verfahren, um alle Kennworteingaben von Opfern sofort aufs Handy zu bekommen.
Um das API zu nutzen, generiert Telegram ein Token, auf das man gut aufpassen muss – keinesfalls darf man das API direkt per JavaScript aus einer öffentlichen Seite heraus ansprechen: Die URL zum API enthält nämlich das Token, und wer das kennt, kann den Bot Nachrichten schicken lassen. Eigentlich legt man das Token daher auf einen Server und lässt ausschließlich diesen mit dem API sprechen, niemals den Browser.
Diese grundsätzliche Vorsichtsmaßnahme hatte der Phisher ignoriert und uns so das API-Token für seinen Bot präsentiert. Per API hätten wir ihn jetzt mit Nachrichten überhäufen können, doch damit nicht genug: In der HTTP-Antwort verrät das Telegram-API weitere Details: Vorname, Nachname und Telegram-Benutzername des Benutzers, dem der Bot eine Nachricht geschickt hat. So erfuhren wir, dass der Phisher offenbar Daniel heißt und hatten auch seinen Benutzernamen. Mithilfe des Werkzeugs TgScanRobot, das öffentliche Telegram-Gruppen systematisch durchsucht, fanden wir heraus, in welchen unsympathischen Kreisen er sich herumgetrieben hatte: Über 20 Gesprächs- und Handelsplattformen für Spamming, Hacking-Werkzeuge und Handel mit geklauten Kreditkarten. In einer dieser Gruppen hatte sich Daniel auch mal zu Wort gemeldet und wurde zurechtgewiesen, weil er sich nicht an die Regeln der Gruppe gehalten hatte.
