Disclaimer: Es handelt sich hierbei um echtes Phishing von echten Angreifern. Die in diesem Artikel beschriebenen Aktionen wurden mit bedacht in einer Sandboxumgebung durchgeführt. Öffnen Sie nicht die Phishing-Links aus dem Artikel. VERSUCHEN SIE DIES NICHT ZU HAUSE.
In der letzten Zeit (während der Black-Friday-Week) sah meine SMS-Nachrichteninbox so aus:
SMS-Phishing ("Smishing") Nachrichten.
Es ist natürlich erstmal komisch, dass die Deutsche Post so viele verschiedene Telefonnummern hat, aber schauen wir uns das Ganze trotzdem mal näher an. Die Fragen die wir heute beantworten wollen sind: Wer oder was ist dieses “Dienstpaket” und was will es von uns?
Normalerweise ist der Google Transparency Report (https://transparencyreport.google.com/safe-browsing/search) eine gute erste Anlaufstelle um zu schauen, ob eine Webseite Phishing sein könnte. Dort kann man Domains bzw. URLs eingeben und sich anschauen was Google Safebrowsing zu der URL sagt. Google Safebrowsing ist ein browserübergreifendes Feature, welches zum Beispiel bekannte Phishing-Seiten automatisch flagged und blockt.
Google Safebrowsing bescheinigt der Webseite keinen "unsafe content" zu enthalten.
No Unsafe Content Found? Das hört sich doch schonmal gut an! Dann muss es ja stimmen. Vielleicht habe ich im Black-Friday-Wahn einfach eines der vielen bestellten Pakete vergessen und es hängt jetzt beim Zoll fest.
Schauen wir also mal was sich hinter der URL aus der SMS verbirgt! Ein erster Besuch der URL macht allerdings erstmal nur wenig Hoffnung:
Der Webserver wirft einen "404 Not Found"-Fehler und der Browser zeigt nur eine leere Seite.
Oh man! Nur eine leere Seite. Ich habe mich doch schon auf mein Paket gefreut. Okay schade, dann packen wir unsere Sachen und gehen nach Hause… Danke für die Aufmerksamkeit und bis zum nächsten Mal!
Natürlich gibt man als Pentester nicht so schnell auf. Der Phishing-Link wurde per SMS ausgeliefert. Daher könnte der Phishing-Webserver unseren Desktop-Browser blocken und nur mobile Endgeräte auf die Phishing-Seite lassen. Als Angreifer muss man sich schließlich auch vor den Augen von Google’s Safebrowsing schützen.
Eine Möglichkeit auf mobile Endgeräte zu filtern ist den User-Agent des Browsers zu überprüfen. Der User-Agent ist quasi wie ein Fingerabdruck des Browsermodells. Den User-Agent können wir als Benutzer aber beliebig anpassen, zum Beispiel könnte man den folgenden iOS User-Agent verwenden:
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3
Dafür reicht es in unseren HTTP-Proxy der Wahl (in diesem Fall Burp Suite Community) eine Regel zu erstellen, die unseren alten Chromium User-Agent gegen den schicken neuen iOS User-Agent austauscht:
Mit einer Match-and-replace Regel kann der User-Agent automatisch ausgetauscht werden.
Und siehe da, wir sehen die eigentliche Phishing-Seite!
Ansicht der Phishing-Seite mit einem User-Agent eines mobilen Endgeräts (iOS).
Und wie praktisch, unsere 8-stellige(!) Paketnummer wurde schon vorausgefüllt. Na dann mal schnell weiter, unser Paket wartet!
Als nächstes braucht die “Post” natürlich unseren Namen, unsere E-Mail-Adresse, unsere Telefonnummer und natürlich unsere Anschrift, ist ja klar, das Paket soll ja auch schließlich ankommen 😉.
Die Phishing-Seite fragt uns nach unseren persönlichen Daten.
Neben dem Namen “Tony Stark” habe ich hier eine sogenannte 10-Minute-Mail erstellt und angegeben. Als Telefonnummer reicht die 1 und als Adresse ein a. Die Angreifer sollten definitiv mal an ihrer Eingabevalidierung arbeiten…
Sobald die Daten eingegeben wurden, gehts direkt zur Sache:
Eingabefeld für Kreditkartendaten.
Wir sollen die Zollgebühren von 1,99€ entrichten. Direkt per Kreditkarte versteht sich. Damit das Paket nicht ewig beim Zoll rumhängt, bezahlen wir es mal lieber schnell. Unsere Kreditkartennummer ist natürlich die 1:
Die Kreditkartennummer scheint validiert zu werden und unsere Nummer wird abgelehnt.
“Ungültige Kreditkartennummer”? Ach Mist! An dieser Stelle hat wohl jemand aufgepasst und validiert tatsächlich die Kreditkartennummer… Mindestens mal clientseitig.
Hier haben wir jetzt erstmal zwei Optionen (okay, eigentlich drei, aber meine echten Kreditkartendaten einzugeben habe ich jetzt mal großzügig ausgeschlossen):
- Testkreditkartennummern verwenden (zum Beispiel diese hier)
- Darauf hoffen, dass die Validierung nur clientseitig durchgeführt wird und umgangen werden kann
Wir versuchen erstmal letzteres und schauen uns an, ob die Validierung nur clientseitig, dass bedeutet im Browser selbst, durchgeführt wird. Hierfür geben wir eine der Testkreditkartennummern, zum Beispiel 4111111111111111 ein, klicken auf “Bezahlen” und fangen in unserem HTTP-Proxy die HTTP-Request ab:
Die Testkreditkartennummer 4111111111111111 wurde verwendet.
Der HTTP-Request, der beim Klick auf den "Bezahlen"-Button abgeschickt wird, wurde abgefangen.
“Leider” wird die Validierung nur auf der Clientseite durchgeführt. Daher können wir in dem HTTP-Request den Parameter number, welcher die Kreditkartennummer enthält, beliebig verändern, zum Beispiel auf 1.
Da haben unsere Angreifer wohl wirklich noch ein wenig Nachholbedarf in Sachen Websicherheit. Vor allem bei serverseitiger Eingabevalidierung. Wir helfen da natürlich gerne mit einem Pentest weiter! Angreifer, Hacker und Phisher erreichen uns unter der 110 😉
Der HTTP-Parameter "number", der die Kreditkartennummer enthält, wurde modifiziert.
Sobald wir den veränderten HTTP-Request abgeschickt haben, macht die Webseite scheinbar irgendwelche Sachen im Hintergrund. Zumindest sollen das die sich drehenden Zahnräder und die angezeigten IT-Sicherheits-Kalendersprüche wie Laden der Authentifizierung oder SMS-Authentifizierungsanfrage gesammelt wahrscheinlich suggerieren:
Die Webseite scheint irgendwelche wichtigen Dinge im Hintergrund zu machen.
Nach kurzer Zeit erscheint dann eine Authentifizierungsabfrage, in die wir einen Code eingeben sollen, den wir angeblich per SMS bekommen haben sollen:
Angebliche Authentifizierungsabfrage für einen SMS-Code.
Da wir vorher bei den persönlichen Daten als Telefonnummer die 1 angegeben haben, können wir natürlich keine SMS empfangen. Der Angreifer kann den Code aber natürlich nicht validieren, da er ihn nicht abgeschickt hat (sondern im Zweifelsfall unsere Bank). Daher können wir uns sehr wahrscheinlich einfach einen Code ausdenken. Leider hat der erste Versuch mit einer 1 nicht funktioniert. Dann versuchen wir es mal mit einem halbwegs sinnigen 2FA-Code: 123123
Und siehe da, wir haben es geschafft! Die Webseite akzeptiert unsere Eingabe und wir werden von der Phishing-Seite auf die echte Seite der Deutschen Post weitergeleitet, als wäre nie etwas passiert:
Weiterleitung von der Phishing-Seite auf die echte Webseite der Deutschen Post.
Fazit
Das Phishing von Kreditkartendaten ist trotz Sicherheitsvorkehrungen wie dem Mastercard® Identity Check™ oder Visa Secure weiterhin ein Problem. In diesem Fall hätten wir nicht nur unsere Kreditkartendaten, und damit potentiell auch Geld in Höhe unseres Kreditkartenlimits verloren, sondern dem Angreifer auch wertvolle persönliche Daten gegeben:
- Name
- Telefonnummer
- Anschrift
Wir haben natürlich direkt beim zuständigen Registar eine Abuse-Beschwerde abgegeben, sowie die Webseite bei Google Safebrowsing gemeldet. Dies geht bequem über die URL: https://safebrowsing.google.com/safebrowsing/report_phish/?hl=en.
Ansonsten bleiben Sie vorsichtig und bis zum nächsten Mal!
