Search the Community

Fühlt euch gegrüßt, der aktuelle Revolut-Vorfall ist m.M.n ein ziemlich interessantes Beispiel dafür, dass man für einen erfolgreichen Angriff nicht unbedingt einen 0-Day oder irgendeinen RCE auf der Plattform braucht. Was bisher bekannt ist: Revolut wurde offenbar über eine legitime Government-Mail-Infrastruktur mit gefälschten Datenanfragen kontaktiert. Die Requests sahen entsprechend nach offiziellen Behördenanfragen aus und wurden von Revolut als legitim eingestuft. Dadurch wurden Kundendaten an den Angreifer herausgegeben. Wie genau so eine Goverment Mail Anfrage aussehen könnte findet ihr unten im Anhang. Revolut hat den Vorfall inzwischen bestätigt und betont, dass die eigenen Systeme und Kundengelder nicht kompromittiert wurden. Genau das finde ich an dem Fall interessant. Betroffen sein konnten laut den bisherigen Informationen unter anderem: Name und Geburtsdatum Adresse E-Mail-Adresse und Telefonnummer KYC-/Identitätsdokumente Verifikations-Selfies Account- und Finanzinformationen IBAN bzw. Kontodaten teilweise Transaktionsinformationen (Auf X kursieren aktuell schon geleakte Daten, somit ist eigentlich eindeutig bestätigt das die oben genannten Informationen betroffen sind. Siehe Anhang 1 ) Die genaue Zahl der betroffenen Kunden wurde bisher nicht öffentlich genannt. Auch bei den Informationen, die aktuell auf Social Media und in diversen Foren kursieren, würde ich vorsichtig sein. Nicht alles davon ist bisher unabhängig bestätigt. Was hier aus Security-Sicht interessant ist: Eine authentifizierte E-Mail bedeutet nicht automatisch, dass die Anfrage legitim ist. SPF, DKIM und DMARC können dir beispielsweise sagen, ob eine Mail tatsächlich von der entsprechenden Domain kommt bzw. ob sie entsprechend autorisiert und signiert wurde. Sie sagen dir aber nicht das die Person, welche Zugriff auf die Domain hat berechtigt ist die Daten anzufordern. Und genau dort scheint das eigentliche Problem zu sein. Wenn ein Angreifer Zugriff auf eine legitime Government Mail bekommt oder eine entsprechende Infrastruktur missbrauchen kann, sieht der Request auf den ersten Blick komplett anders aus als eine normale Phishing-Mail. Für einen automatisierten oder schlecht abgesicherten Verification-Prozess ist das natürlich eine ganz andere Ausgangslage. Vereinfacht könnte der Attack Path ungefähr so ausgesehen haben: Compromised Government Account ↓ Authenticated Request von legitime Government Domain ↓ interne Verifikation bei Revolut ↓ Request wird als legitim eingestuft ↓ Kundendaten werden herausgegeben Das Interessante daran ist, dass der Angreifer dafür unter Umständen überhaupt keinen Zugriff auf Revolut selbst benötigt. Keine Credentials eines Revolut-Mitarbeiters. Kein Exploit gegen einen Revolut-Server. Kein RCE. Kein 0-Day. Stattdessen wird einfach das bestehende Vertrauen zwischen Revolut und Behörde ausgenutzt. Und genau solche Relationships sind meiner Meinung nach langfristig ein ziemlich großes Problem, vorallem bei KYC Daten. Noch interessanter wird es bei Krypto-Daten. Wenn ein Angreifer weiß, welche Person hinter bestimmten Accounts bzw. Transaktionen steckt, kann er diese Informationen mit öffentlich verfügbaren On-Chain-Daten korrelieren. Aus: "Crypto Wallet XYZ hält 2 BTC" wird dann eventuell: "Person X besitzt & kontrolliert diese Adresse und wohnt an Adresse Y." Das ist für gezieltes Social Engineering und Real-Life Crime natürlich wertvoller als ein normaler Leak von E-Mail-Adressen. Man kann damit beispielsweise sehr glaubwürdige Spear-Phishing Campaigns bauen. Aus: "Dear customer, your account has been suspended. Click here." Wird: "Wir haben eine ungewöhnliche BTC-Transaktion über 48.000 EUR festgestellt. Bitte bestätigen Sie Ihre Identität..." Wenn der Angreifer bereits echte Informationen über die Person besitzt, wirkt so ein Angriff gleich deutlich glaubwürdiger. Und genau deshalb würde ich den Fall nicht nur unter "Data Breach" einstufen. Das ist gleichzeitig ein Beispiel für Identity Abuse, Social Engineering und dolles Vertrauen in eine Goverment Mail. Deshalb würde mich Interessieren: Welche interne Verifikation hat den Government-Request als authentifiziert eingestuft? Und: War das ein Social-Engineering-Problem oder gab es zusätzlich eine Compromise auf Systeme der betreffenden Behörde? Was ist eure Meinung zu dem Fall? --- Full KYC Breach vom gamdom.com CEO "Felix Romer" - Telegram -Beispiel einer Anfrage. -Toka