mTAN-Betrugsfälle: Erst der Anfang

Betrugsfälle bei mTAN häufen sich inzwischen genauso, wie sich die Medienberichte darüber häufen. Dass das mTAN-Verfahren nichts taugt, war seit Jahren klar und ich habe bereits Anfang 2011 darüber berichtet.

Die aktuelle Betrugswelle setzt scheinbar auf gezielte Angriffe, bei denen der Mobilfunkanbieter des Opfers getäuscht wird, und schließlich den Betrügern eine Zweit-SIM-Karte mit der Nummer des Opfers überlässt. Im Gegensatz zu den Phishing-Angriffen, die versuchen mit möglichst wenig Aufwand möglichst viele Opfer zu erwischen, geht es hier also um gezielte und relativ aufwändige Angriffe.

Somit ist es nur eine Frage der Zeit, bis auch Angriffe über das Mobilfunknetz stattfinden. Die Sicherheit von GSM (klassischen Mobilfunknetzen) ist inzwischen vorne und hinten zerlegt worden. Mitlesen von SMS ist mit einem normalen Computer, 2 TB an Festplatten/SSDs/USB-Sticks, frei erhältlicher Software und einem einfachen DVB-T-Stick, der bei Amazon rund 20 EUR kostet, möglich. Alternativ gibt es auch aktive Attacken, welche die SMS frei Haus an einen beliebigen Ort in der gleichen Location Area liefern und praktischerweise auch gleich verhindern, dass der rechtmäßige Empfänger die SMS bekommt. Auch die Verschlüsselung von UMTS ist inzwischen zumindest stark angeknackst. Alle diese Sachen sind öffentlich bekannt, und zwar seit Jahren. Das Bestellen von Zweit-SIM-Karten hatte ich bereits in meinem Artikel von 2011 als einen möglichen Angriffsweg von vielen genannt. Ich weiß nicht, ob es schon damals praktiziert wurde und öffentlich bekannt war, oder einfach nur so offensichtlich, dass ich von selbst drauf gekommen bin. Ich tippe auf letzteres, denn zunächst waren Handy-Trojaner das Mittel der Wahl, um an mTANs zu kommen.

Bisher war den Betrügern das Abfangen der SMS im Mobilfunknetz scheinbar zu aufwändig, aber das wird sich ändern, sobald die Mobilfunkbetreiber es schaffen, den betrügerischen Zweitsimkarten-Bestellungen einen Riegel vorzuschieben. Von diesem Angriff wird der Kunde dann erst einmal nichts mitbekommen.

Statt das vermurkste mTAN-Verfahren abzuschaffen und z. B. ChipTAN einzusetzen, was bei korrekter Umsetzung nahezu perfekte Sicherheit bieten würde, verteidigen Banken die mTAN, versuchen einzelne Varianten des mTAN-Betrugs mit kleineren Änderungen abzustellen, und schieben zum Teil die Schuld ihren Kunden in die Schuhe, indem sie immer wieder die Sicherheit des Verfahrens betonen und auf die „Sorgfaltspflicht“ des Kunden hinweisen (Virenscanner etc.). In den oben verlinkten Berichten wird immer wieder erwähnt, dass Kunden zum Teil noch nicht wissen, ob sie ihr Geld zurückbekommen, denn das sei eine Einzelfallentscheidung…

Der Bankenverband geht laut Pressestelle davon aus, dass die Angriffe nicht auf die Praxis übertragbar seien und sich deswegen nicht auf das Onlinebanking auswirken. Beispielsweise sei physischer Zugriff auf die SIM nötig (andere Meinung), physische Nähe zum Mitschneiden (5-35 km laut Folie 13/PDF-Seite 14 dieser Präsentation), die Daten müssen offline und damit verzögert entschlüsselt werden (hier wird der Aufwand bei Verwendung von SSDs auf die Größenordnung von 10 Sekunden geschätzt), die TMSI-Übermittlung sei nötig und nur bei manchen Providern unterstützt (d.h. wenn das tatsächlich ein Hindernis ist, dann nur für manche Netze), und eine stille SMS könne nur der Provider schicken (diese und diese Android-App behaupten es auf gerooteten Geräten zu können, aber evtl. filtern die Provider; nicht getestet – andere Methoden wie kurze Anrufe wurden aber genannt).

Zudem sei die mTAN nur ein Faktor von mehreren (d.h. zusätzlich braucht der Angreifer die PIN). Dieses Argument ist allerdings Humbug, denn das mTAN-Verfahren dient ja gerade dazu, das System auch bei bekannter PIN sicher zu halten – sonst könnte man einfach iTAN weiternutzen oder gar ganz auf TANs verzichten.

Meine Meinung nach ist das wieder mal ein klarer Fall von „Kopf so lange in den Sand stecken, bis die Angriffe so oft passieren, dass man das Problem nicht mehr wegreden kann“, wie damals bei den EC-Karten und seitdem zig anderen Verfahren. Es wird sicher nicht einfach sein, diese Angriffe durchzuführen, was Kriminelle eine gewisse Zeit lang davon abhalten wird. Aber früher oder später wird es passieren – und der Kunde kann nichts tun, um das Abfangen der mTAN zu verhindern, er kann lediglich seine PIN schützen wie schon bei iTAN. Wenn jemand fahrlässig handelt, dann sind es die Banken, die ihre mTANs über unsichere Kanäle verschicken, deren Unsicherheit seit Jahren bekannt ist – und trotzdem immer wieder behaupten, das Verfahren sei sicher. Kurz, ich bleib bei ChipTAN bzw. iTAN und stocke meine strategischen Popcornreserven auf.

ePerso kann remote missbraucht werden

In meinem letzten Artikel zum ePerso (PIN-Diebstahl ohne Malware) stellte ich eine Möglichkeit vor, wie ein Angreifer an die PIN des ePerso gelangen kann, indem er eine falsche AusweisApp vortäuscht.

Wie ich erwartet hatte gab es daran viel Kritik: Einerseits sei das ja kein richtiger Angriff, weil „nur“ der Nutzer getäuscht wird, andererseits hätte der Angreifer ja „nur“ die PIN, mit der er nichts anfangen könne, weil er ja keinen Zugriff auf den Personalausweis selbst hätte.

Ersteres spielt für das Ergebnis keine Rolle: Der Angriff funktioniert gegen durchschnittliche Nutzer sehr gut, und der Angreifer hat am Ende die PIN. Damit wären wir beim zweiten Einwand: Die Authentifikation mit dem Ausweis ist eine sogenannte Zwei-Faktor-Authentifikation – man benötigt PIN und Ausweis. Mit der PIN alleine kann der Angreifer somit tatsächlich noch nicht direkt einen Angriff durchführen – aber er hat einen der beiden Faktoren überwunden. Das wird interessant, sobald ein Angriff den anderen Faktor überwindet. Alleine wäre auch dieser neue Angriff „wertlos“, verbunden mit der gestohlenen PIN ermöglicht er jedoch den Missbrauch des Ausweises.

Genau einen solchen zweiten Angriff habe ich nun gefunden. (Nachtrag: Wurde von Heise verifiziert.) Dadurch kann der Angreifer, wenn die im Folgenden erklärten Bedingungen zutreffen, sich mit dem Personalausweis des Opfers ausweisen. (Ich denke, jetzt sieht man auch, warum der PIN-Angriff sehr wohl ein Problem war!)

Weil das Missverständnis öfter aufkam: Der PIN-Diebstahl-Angriff ist kein simpler Phishing-Angriff. Bei einem Phishing-Angriff wird das Opfer auf die Seite des Angreifers gelockt, aber im Glauben gelassen, dass es z. B. die Seite seiner Bank besucht – denn nur dort dürfen die Bank-Zugangsdaten eingegeben werden. Auf den falschen Link reinzufallen ist ein vermeidbarer Fehler des Opfers. Hier jedoch kennt das Opfer die Identität der Seite. Ein legitimer Ausweisevorgang beginnt mit dem Besuch einer fremden Seite, wo dann die AusweisApp aufpoppt – genau wie beim Angriff. Dieser Angriff ist also deutlich schwerer erkennbar als Phishing – vor allem, weil Banken etc. dem Nutzer erklären, wie er sich schützen soll (Bank-Website manuell aufrufen), während auf die wenigen Warnzeichen für eine falsche AusweisApp nirgendwo hingewiesen wird.

Demo des Angriffs auf YouTube

Die von der ComputerBild als Beilage verteilten Starterkits bestehen aus einem Reiner SCT-Basislesegerät sowie einer LoginCard, mit der man sich Online einloggen können soll. Dazu muss eine Software (Browserplugin) von ReinerSCT installiert werden, die Websites Zugriff auf das Lesegerät gibt.

Über dieses sogenannte OWOK-Plugin kann eine Website (nach Bestätigung, siehe unten) frei mit der Karte kommunizieren. Die OWOK-Software habe ich als erstes untersucht, weil der Nutzer bei den Computerbild-Starterkits zur Installation aufgefordert wird, sie also bei vielen Ausweisinhabern vorhanden sein dürfte. Die Software nutzt dafür anscheinend das von den Sparkassen entwickelte SIZCHIP-Plugin – d.h. das gleiche Problem dürfte mit vielen anderen Plugins, z. B. mit dem Geldkarten-Plugin, bestehen.

Pro Website wird der Benutzer einmal gefragt, ob er diesen Zugriff zulassen soll. Diese Frage sollte eigentlich vor dem Angriff schützen, da der Nutzer ja darauf aufmerksam gemacht wird und zustimmen muss. Dabei gibt es jedoch mehrere Probleme:

1. Der Nutzer erwartet beim oben erwähnten PIN-Diebstahl-Angriff, dass der ePerso benutzt wird. Die Frage nach dem Zugriff auf dem Chipkartenleser dürfte den meisten Nutzern daher logisch vorkommen und meist bejaht werden. Nutzer mit gutem Hintergrundwissen über die Technik könnten an dieser Stelle aufmerksam werden – diese zählen jedoch zu einer kleinen Minderheit.
2. Sobald der Nutzer einmal die Entscheidung getroffen hat, scheint diese dauerhaft gespeichert zu werden. Indem der Angreifer das Plugin unter einem Vorwand einige Zeit vor dem Angriff das erste mal aktiviert, kann er verhindern, dass der Nutzer beim eigentlichen Angriff misstrauisch wird.
3. Die Anfrage besteht aus einem Dialogfenster, was an einer vorhersehbaren Position (Bildschirmmitte) auftaucht, sobald das Plugin geladen wird. Das kann sich der Angreifer zunutze machen, indem er den Nutzer animiert, wiederholt schnell auf die „richtige“ Stelle zu klicken (z. B. durch ein Spiel), und dann erst das Dialogfenster auslöst. Viele sicherheitskritische Dialogfenster in Browsern aktivieren die Schaltflächen inzwischen erst nach einer kurzen Verzögerung, um solche Angriffe zu verhindern.
4. Einige im Plugin vordefinierte Seiten können ohne diese Sicherheitsabfrage zugreifen. Gelingt es, in einer dieser Seiten z. B. eine XSS-Lücke zu finden, kann man die Sicherheitsabfrage umgehen, indem man den Angriff im Kontext der Seite durchführt. Eine solche Lücke habe ich gefunden – die Sicherheitsabfrage kann also umgangen werden.

Dieser Angriff setzt also voraus:

• Das Opfer hat z. B. das von der ComputerBild verteilte Starterset nach Anleitung installiert
• Das Opfer fällt auf den PIN-Diebstahl-Angriff mit einer falschen AusweisApp herein
• Das Opfer bestätigt dabei (oder irgendwann vorher!) die Sicherheitsabfrage „Darf von (Seitenname) auf Chipkartenleser zugegriffen werden?“ oder der Angreifer umgeht die Sicherheitsabfrage über eine XSS-Lücke (siehe oben)
• Der Ausweis liegt auf dem Lesegerät (folgt bereits aus dem Hereinfallen auf den PIN-Diebstahl-Angriff)

Sobald diese Voraussetzungen erfüllt sind, hat der Angreifer über das Plugin Zugriff auf den Kartenleser und den darauf liegenden Ausweis, und befindet sich im Besitz der PIN. Damit gilt:

• Der Angreifer kann mit der Identität des Ausweisinhabers Aktionen durchführen, und diese mit dem fremden Ausweis bestätigen.
• Der Angreifer kann sich auch in Benutzerkonten des Ausweisinhabers, die Login via Ausweis zulassen, einloggen, und dort z. B. Daten ausspähen oder weitere Aktionen durchführen.

Der Angreifer braucht also insbesondere weder Malware auf dem Rechner des Nutzers, noch muss er man-in-the-middle-Attacken fahren. Er muss lediglich Besucher auf seine Seite locken und dort mit der falschen AusweisApp täuschen!

Folgen

Der Angreifer kann den Ausweis und somit die bestätigte Identität des Opfers missbrauchen. Das Opfer bekommt dies nicht mit, da ihm z. B. eine erfolgreiche Altersverifikation vorgetäuscht wird. Da die Identitätsbestätigung über den Ausweis einen sehr starken Anscheinsbeweis liefert, wird das Opfer nur sehr schwer belegen können, dass eine Aktion von einem Angreifer und nicht vom Opfer selbst durchgeführt wurde.

Dabei wäre beispielsweise ein Szenario denkbar, bei dem ein Onlineshop Lieferung auf Rechnung anbietet, wenn der Käufer sich per Ausweis identifiziert – soweit ich weiß eines der öfter genannten Beispiele für eine mögliche Anwendung des ePersos. Würde ein Angreifer mit der Identität des Opfers eine Bestellung tätigen, würde der Händler sein Geld beim Opfer einfordern – und hätte vor Gericht dank der Ausweisprüfung gute Chancen, dies auch durchzusetzen. Auch wäre denkbar, dass der Angreifer ein Konto im Namen des Kunden eröffnet und für Betrügereien missbraucht – mit der Folge, dass das Opfer für diese Taten verantwortlich gemacht wird.

Totalversagen

Zum Glück gibt es eh kaum Dienste, die wirklich mit dem ePerso genutzt werden können. SCHUFA und die Flensburg-Punkteauskunft schicken die Zugangsdaten bzw. Infos separat per Post, sodass der Ausweis hauptsächlich als Formularausfüllhilfe dient, und ansonsten kann man damit Onlinepetitionen unterschreiben und kommt vielleicht bei ein paar Versicherungen ins Kundenmenü. Kurz: Unabhängig von den Sicherheitsproblemen hat das Projekt versagt.

Wie in diesem Beitrag erklärt, bin ich der Meinung, dass der ePerso vor allem als Instrument zur Zerstörung der Freiheit und Anonymität im Netz taugt und früher oder später auch dafür verwendet werden wird. Entsprechende Forderungen hat der Bundesinnenminister Friedrich erst gestern wieder gebracht. Wie das aussehen wird, sobald die Mehrheit der Bevölkerung einen ePerso besitzt, ist also absehbar. Wenn Kritik nicht mehr Anonym geäußert werden darf, leidet die Meinungsfreiheit massiv, da viele sich aus Angst vor möglichen Folgen nicht trauen, ihre Meinung zu sagen.

Davon abgesehen ist der ePerso eine sinnlose Wirtschaftsförderungsmaßnahme auf Steuerzahlerkosten. Neben den subventionierten Starterkits sieht man das am Besten daran, dass die Bürger ihre Signaturzertifikate von privaten Unternehmen kaufen müssen (für rund 20 Euro pro Jahr), statt sie zusammen mit dem Personalausweis direkt zu erhalten.

Die Entwicklung und Einführung des Ausweises sollen „nur“ rund 50 Millionen gekostet haben. Gegenüber dem alten Ausweis müssen die Bürger für den ePerso rund 20 Euro mehr zahlen. Bei 6,5 Millionen neuen Ausweisen pro Jahr kommen auf die Bürger jährliche Mehrkosten von 130 Millionen zu. Es ist also nie zu spät, das Projekt noch einzustampfen!

Apropos Signatur: Die geht mit dem Ausweis immer noch nicht, weil die entsprechende Version der AusweisApp auf sich warten lässt. Genauso übrigens, wie eine auf MacOS lauffähige Version.

Gegenmaßnahmen

Folgende Dinge können getan werden, um den Angriff zu erschweren bzw. zu verhindern:

Nutzer können:

• Den neuen Ausweis nicht im Internet nutzen, niemals an Lesegeräte halten und ggf. in einer abschirmenden Hülle transportieren
• Wenn sie den Ausweis im Netz nutzen wollen, ausschließlich Lesegeräte der höheren Sicherheitsstufen (eigenes PIN-Pad) einsetzen und die PIN ausschließlich auf dem Lesegerät eingeben. Weiterhin muss das eigene System sicher und virenfrei gehalten werden!
• Ihren alten Ausweis solange es geht behalten
• Plugins, die Chipkartenzugriffe erlauben, deinstallieren.

Reiner SCT (bzw. die für den Kern des Plugins verantwortliche Firma) kann:

• Die Sicherheitsabfrage vor jedem Zugriff auf das Lesegerät stellen (sollte nur bei Loginvorgängen nötig sein) und sie deutlicher formulieren
• Die APIs des Plugins einschränken, sodass Websites nur noch vordefinierte Funktionen der Karten auslösen können

Das hilft aber nur, wenn alle Hersteller vergleichbarer Plugins das auch tun.

Die Projektverantwortlichen können:

• Die unsicheren Basislesegeräte endlich abschaffen (nicht mehr für die Nutzung mit dem ePerso zulassen). Das ist die einzige Möglichkeit, die das Problem wirklich löst. Allerdings sind die besseren Geräte teuer und somit nicht gerade gut für die Akzeptanz.
• Das Projekt begraben und nicht noch mehr Geld verschwenden
• Die AusweisApp so umbauen, dass sie exklusiven Zugriff auf den Leser nimmt und ihn so für andere Anwendungen sperrt. Das würde Angriffe erschweren oder verhindern, allerdings nur, solange die AusweisApp auch läuft.

Aufgrund der Reaktion des BMI auf meinen ersten Angriff (falsche Behauptung, ich hätte den Angriff länger gekannt und absichtlich zurückgehalten) musste ich leider mit Versuchen rechnen, diese Angriffsmöglichkeit zu vertuschen. Daher habe ich mich entschieden, die Hersteller vor der Veröffentlichung nicht zu benachrichtigen (außer im Fall der XSS-Lücke). Am Besten vor dem Angriff schützen kann sich immer noch der Nutzer allein (durch Deinstallation der Browserplugins), sodass möglichst schnelle öffentliche Aufklärung über diese Gefahr meiner Meinung nach sinnvoll ist.

Die Schuld an dieser Lücke sehe ich übrigens weniger bei den Pluginentwicklern, auch wenn es keine gute Idee und ziemlich unnötig ist, Websites uneingeschränkten Low-Level-Zugriff auf Chipkarten zu geben. Das Hauptproblem ist die bescheuerte Idee, für eine derart sicherheitsrelevante Anwendung unsichere Lesegeräte (Basisleser/Klasse-1-Leser) nicht nur zu verwenden, sondern auch noch aus Steuergeldern zu fördern.

Technische Details

Das OWOK/SIZCHIP-Plugin erlaubt es der Website, per JavaScript einen Kanal zur Chipkarte zu öffnen und darüber beliebige Befehle (APDUs) zu schicken (und die Antworten zu lesen). Ein Angreifer würde diese Befehle von einem Server abholen, auf welchem eine AusweisApp (oder eine äquvivalente Software) läuft. Statt an ein echtes Lesegerät würden die APDUs, die die AusweisApp an die Karte schicken will, über AJAX zum JavaScript im Browser des Opfers geschickt. Dort würden sie über das Plugin an den Ausweis gesendet, und die Antwort würde auf dem umgekehrten Weg wieder zur AusweisApp kommen.

Ich habe hierzu zwei Proof-of-concepts erstellt. Für beide muss ein Lesegerät, das OWOK-Plugin sowie eine kompatible Karte (nicht unbedingt ein Ausweis) vorhanden sein.

Einer (attackwebsite) basiert auf der falschen AusweisApp (die bereits im „FSK18-Bereich“ der Piratenpartei zu sehen war). Er demonstriert, wie ein kompletter Angriff ablaufen würde. An den Ausweis (bzw. die Karte) wird hier nur der Befehl zum Auswählen der ePass-Anwendung geschickt, sodass man die unterschiedlichen Antworten von Ausweisen im Vergleich zu anderen Karten sehen kann.

Der zweite PoC (shellserver) implementiert das Abholen der Befehle über AJAX. Es kann entweder zum einfachen Testen ein fest im Server eingetragener Befehl an das Opfer geschickt werden, oder aber die Karte auf dem Lesegerät des Opfers wird an eine modifizierte cyberflex-shell angeschlossen, von wo dann beliebige Anfragen gestellt werden können.

Die PoCs kann man hier herunterladen, den ersten davon gibt es auch live unter https://fsk21.piratenpartei.de.

Den XSS-Angriff habe ich an Heise mit Bitte um Verifikation und anschließende Weiterleitung an den Seitenbetreiber gemeldet. Die Redaktion konnte ihn nachvollziehen.

Wie Sofortüberweisung.de funktioniert

Scheinbar wissen viele nicht, wie der Dienst „Sofortüberweisung.de“ funktioniert – denn ich glaube kaum, dass so viele ihn sonst nutzen würden. Der Dienst verspricht, wie der Name schon sagt, sofortige Überweisungen, was beim Online-Shopping dem Händler die (vermeintliche – siehe unten) Garantie gibt, dass die Ware direkt bezahlt ist, und dem Kunden so unter Umständen zu einer kürzeren Lieferzeit verhilft. Im Gegensatz zum Lastschriftverfahren ist eine Überweisung auch nicht (zumindest nicht so leicht und nur innerhalb kurzer Zeit) zurückrufbar.

Wie aber schafft es der Dienst, Überweisungen durchzuführen? Ganz einfach – man gibt ihm seine Onlinebanking-Zugangsdaten. Nein, man loggt sich nicht bei seiner eigenen Bank ein und überweist, man gibt diesem Dienst seine Zugangsdaten für den Onlinebankingzugang. Damit loggt er sich dann bei der Bank ein und führt die Transaktionen durch. Mit Benutzername/Kontonummer und PIN hat der Dienst schonmal weitreichenden Lesezugriff aufs Konto – und wurde vor kurzem dabei erwischt, wie er diesen missbraucht, um die Umsätze der letzten 30 Tage, den Dispokredit, Vorhandensein und Kontostände anderer Konten bei der gleichen Bank und/oder vorgemerkte und ausgeführte Auslandsüberweisungen abzufragen. Das soll nur der Absicherung der Überweisung dienen, was aber nichts daran ändert, dass Sofortüberweisung.de die entsprechenden Informationen abfragt. Mit der eingegebenen TAN wird dann die Überweisung durchgeführt. Technisch läuft die Kommunikation mit der Bank über das HBCI-Protokoll, worüber auch Onlinebanking-Software wie Hibiscus, WISO etc. mit der Bank kommuniziert.

Rein technisch gesehen ist das ganze Verfahren exakt das gleiche, was die ganzen Phishingseiten machen – es werden Zugangsdaten des Nutzers abgefragt und dann verwendet, um eine Transaktion durchzuführen. Bei iTAN wird die Transaktion eben der Bank gegenüber eingeleitet, die Bank sagt, welche iTAN sie möchte, und dann wird diese iTAN abgefragt. Der Nutzer muss darauf vertrauen, dass Sofortüberweisung.de mit der TAN keinen Missbrauch anstellt. Das soll durch ein TÜV-Zertifikat bestätigt werden – es gab allerdings schon zahlreiche Fälle (hier ein anderer TÜV-Verein), wo TÜV-geprüfte Webseiten völliger Murks waren. Diese Zertifikate sind also meiner Meinung nach nicht die Bytes wert, die die PDF-Dateien belegen.

Wenn ein Händler also nur eine Zahlung über Sofortüberweisung anbietet, oder bei anderen Zahlungsmethoden miese Konditionen bietet, kaufe ich eben woanders. Sofortüberweisung ist genauso (un)sicher wie Vorkasse per Überweisung, bietet aus Kundensicht in dem Punkt also keinen Vorteil. Wenn ein Händler Lastschrift anbietet, bevorzuge ich das – kaum Arbeit, sollte es große Probleme mit dem Händler geben (was mir bisher nie passiert ist) kann die Lastschrift zurückgebucht werden und die Missbrauchsgefahr ist nahe Null. Klar kann unberechtigt abgebucht werden, dann wird es eben zurückgebucht – dazu ist die eigene Bank grundsätzlich verpflichtet, egal ob sie sich das Geld vom Händler zurückholen kann oder nicht!

Bei mTAN und chipTAN dürfte das Verfahren ähnlich laufen – die Überweisung wird eingeleitet, bei der chipTAN leitet Sofortüberweisung.de die Challenge weiter, der Nutzer gibt die TAN vom Handy/Generator an Sofortüberweisung. Hier ist wenigstens sichergestellt, dass keine falsche Überweisung aufgegeben werden kann – die PIN kann allerdings immer noch benutzt werden, um – wie im oben genannten Fall geschehen – das Konto auszuspähen!

Diese Funktionsweise hängt Sofortüberweisung natürlich nicht an die große Glocke (natürlich steht das alles irgendwo – aber irgendwo wo es keiner liest), und setzt darauf, dass Nutzer sich schon nicht so recht informieren oder es ihnen egal ist. Die Weitergabe von Logindaten an fremde Webseiten verstößt in der Regel gegen Banken-AGB. Diesen Punkt hat das Kartellamt übrigens in einer grandiosen Fehlentscheidung bemängelt, denn viele Banken bieten einen ähnlichen Dienst selbst unter dem Namen GiroPay an. Dieser hat höhere Transaktionsgebühren, wird jedoch von den Banken selbst betrieben und unterscheidet sich in einem „klitzekleinen“ Detail: Der Kunde loggt sich bei seiner eigenen Bank in sein Onlinebanking ein, und die Bank bestätigt dann die Überweisung. Die Logindaten gehen also nicht an eine dritte Partei, in deren Hände sie nicht gehören.

Die Banken hätten also einerseits ein wirtschaftliches Interesse, Sofortüberweisung zu behindern, riskieren dabei allerdings juristische Probleme – weswegen z. B. die Postbank den Laden auch nicht technisch aussperrt. Wäre ich zuständiger für die Online-Sicherheit einer Bank und hätte das unabhängig von den wirtschaftlichen/rechtlichen Sachen zu entscheiden, würde ich die IPs von Sofortüberweisung regelmäßig in die Firewalls stopfen, und die bis zur Erkennung als IP von Sofortüberweisung eingereichten, aber noch nicht durchgeführten Überweisungsaufträge stornieren (mit Benachrichtigung des Kunden, aber ohne Benachrichtigung von Sofortüberweisung) – der Laden müsste dann zusehen, wie er sein Geld vom Kunden bekommt, vor allem, nachdem dieser einen bösen Brief von seiner Bank erhalten hat. Es wäre natürlich auch denkbar, dem Kunden einfach den Onlinezugang wegen Missbrauch zu sperren. Ehrlich gesagt überrascht es mich massiv, dass das nicht durch irgendwelche automatischen Systeme, denen das hohe Transaktionsvolumen auffällt, geschehen ist. Die vereinzelten Posts in Foren, wo behauptet wird, dass Leuten wegen der Nutzung von Sofortüberweisung.de (d.h. unberechtigter Weitergabe von Zugangsdaten) die Onlinebankingzugänge oder gar Konten gekündigt werden, sind bisher (leider, muss man sagen) vermutlich eher Falschmeldungen, das kann sich aber natürlich noch ändern. In Foren als Möglichkeit erwähnt und durchaus denkbar ist es, dass die Banken protokollieren, wer derart gegen AGB verstößt, und im Falle eines Schadens (z. B. durch Phishing) das Verhalten des Kunden als Argument benutzen, um den Schaden nicht auszugleichen. Sofortüberweisung.de „empfiehlt“ den Shopbetreibern, um Abmahnungen durch Verbraucherzentralen zu vermeiden, zu Erklärungen von Sofortüberweisung einen Text hinzuzufügen, in dem zwischen viel wiederholendem Geschwurbel steht:

Vorsorglich weisen wir dennoch darauf hin, dass es in Deutschland Banken und Sparkassen gibt, die davon ausgehen, dass die Nutzung von sofortüberweisung.de wegen der Verwendung von PIN und TAN außerhalb der eigenen Online-Banking-Systeme bei etwaigen Missbrauchsfällen zu einer Haftungsverlagerung führen kann. Dies kann bedeuten, dass im Missbrauchsfall die Bank sich weigert, den Schaden für den Endkunden zu übernehmen und der Endverbraucher den Schaden zu tragen hat.

Für Händler hat das Verfahren neben der Abmahngefahr außerdem noch das Problem, dass die Überweisung keineswegs so garantiert ist wie angedeutet wird – Sofortüberweisung bestätigt nur, dass die Überweisung abgeschickt wurde. Wenn der Kunde die Überweisung direkt danach bei der Bank widerruft, oder die Bank sich einfach entscheidet, die Überweisungen zu stornieren, dürfte der Händler seinem Geld wohl hinterherlaufen.

Giropay hat übrigens auch ein Problem, ist nämlich bei unvorsichtigen Nutzern besonders anfällig gegen Phishing. Der Nutzer wird von einer Drittwebsite (Onlineshop) auf sein Onlinebanking umgeleitet und soll sich dort einloggen. Der Onlineshop könnte den Nutzer nun auf eine Phishingseite umleiten. Wenn der Nutzer weiß, wie Giropay zu funktionieren hat (d.h. Login erfolgt auf der eigenen Bankwebsite) und er (z. B. über das SSL-Zertifikat) prüft, dass er sich auf der richtigen Website befindet, würde er so etwas natürlich erkennen. Ich weiß das, weiß wie ich das prüfen kann, und tue es auch konsequent – ich bezweifle jedoch, dass das auf Otto Normalnutzer auch zutrifft. Das ließe sich mit ein wenig Aufklärung aber wahrscheinlich korrigieren, denn die Nutzer sind inzwischen für Sicherheitsthemen gerade beim Onlinebanking sensibilisiert. Das gleiche Problem (mit der gleichen Lösung) gibt es übrigens auch beim Verified-by-Visa-Programm für Kreditkarten (bei Online-Kreditkartenzahlungen muss man sich bei Visa einloggen, somit sind Zahlungen nur mit den Infos die der Händler klauen kann nicht mehr mögich) sowie beim Authentifizierungsverfahren OpenID – und natürlich bei Sofortüberweisung, wo ein „Phishing-Angriff“ sogar mehr oder weniger Teil des Verfahrens ist.

Und nein, ich bekomme für diesen Artikel weder Geld noch habe ich irgendwas mit Giropay oder sonstigen Online-Zahlungssystemen zu tun. Es regt mich „nur“ tierisch auf, wenn das Verletzen grundlegener Sicherheitskonzepte zum Geschäftsmodell gemacht wird. Wenn man sich die Kommentare im Heiseforum zur Entscheidung des Kartellamts anschaut, bin ich offensichtlich nicht der einzige.

Zusammenfassung:

Probleme für Kunden

• Kontoumsätze wurden und werden abgefragt
• Missbrauch möglich
• Keine Rückbuchung bei Problemen mit Händler (wie bei normaler Vorkasse auch)
• AGB-Verstoß gegen Bank-AGB
  • Bank könnte Haftung bei Missbrauch (auch in unabhängigen Fällen!) verweigern
  • Onlinebanking-Sperrung denkbar

Probleme für Händler

• Verlust von Kunden die wissen wie das Verfahren funktioniert und es daher nicht nutzen wollen oder es gar als unseriös ansehen
• Abmahngefahr durch Verbraucherzentralen
• Zahlungen sind keineswegs garantiert!

ePerso: PIN-Diebstahl ohne Malware

Der CCC hatte im September 2010 einen Angriff gegen den ePerso präsentiert: Ein Trojaner auf dem PC des Nutzers kann die PIN abfangen, wenn der Nutzer sie über die Tastatur eingibt. Das ist für jeden, der sich ein wenig auskennt, keine Überraschung – aber durchaus ein großes Problem für den realen Einsatz des Personalausweises.

Ich habe nun einen Angriff entwickelt, der in der Lage ist, die PIN des Nutzers zu stehlen, ohne Malware auf dem Rechner des Nutzers zu installieren. Wer sich das mal anschauen möchte, kann ja die Altersverifizierung für den (fiktiven) FSK18-Bereich der Piratenpartei-Website durchführen. (Die PIN wird bei der Demo natürlich nicht an den Server gesendet.) Wer den Angriff testen will, sollte das jetzt erstmal tun und nicht weiterlesen.

v

v

v

Man kann den Angriff auch ohne Ausweis, Lesegerät und AusweisApp testen: Einfach eine sechsstellige PIN ausdenken und so tun als sei die AusweisApp installiert, das Lesegerät angeschlossen und der Ausweis aufgelegt.

v

v

v

Der Angriff funktioniert ganz einfach: Mit JavaScript, HTML und Screenshots (also Bildern) wird eine AusweisApp im Browser simuliert. Der Nutzer denkt, er würde die echte AusweisApp sehen, und gibt seine PIN ein. In diesem Fall wird nach der PIN-Eingabe eine Auflösung angezeigt, bei einem echten Angriff bekäme der Nutzer eine Fehlermeldung zu sehen, damit er keinen Verdacht schöpft, und seine PIN würde an den Server geschickt. Die Fehlermeldung wäre auch nichts besonderes – bei den meisten Seiten funktioniert die Ausweisfunktion eh nicht. (Und auch sonst funktioniert an dem ganzen Projekt ziemlich wenig: Die Änderungs-Terminals spinnen, Sonderzeichen machen Probleme, und so weiter.

Bei dieser Simulation ist es nicht möglich, die PIN über die eingebaute Bildschirmtastatur einzugeben, die entsprechende Schaltfläche fehlt. Das hat allerdings nichts damit zu tun, dass das prinzipiell nicht möglich wäre, sondern dass ich faul bin und keine Lust hatte, noch ein Dialogfeld detailgetreu nachzubauen. Sollte also jemand als „wirksame“ Gegenmaßnahme vorschlagen wollen, die Bildschrimtastatur zu nutzen, kann ich das gerne noch nachreichen. Die Bildschirmtastatur schützt lediglich vor sehr einfachen Keyloggern, und vermittelt ansonsten nur ein falsches Gefühl der Sicherheit. Wer Ausweise missbrauchen will, wird sich beim Trojanerschreiben die Mühe machen, auch Eingaben über die Bildschirmtastatur zu erkennen – das ist keine Kunst, sondern Fleißarbeit.

Dieser Angriff nutzt keine Sicherheitslücke im Ausweis oder der AusweisApp aus, sondern die Tatsache, dass Nutzer nicht in der Lage sind, echt aussehende von echten Fenstern zu unterscheiden. Das könnte zwar zu der Behauptung führen, dass dieser Angriff -in der Theorie- gar kein richtiger Angriff sei – das Ergebnis ändert das aber nicht: Der Angreifer hat am Ende die PIN des Nutzers.

Diese Funktionsweise macht es umso schwieriger, den Angriff zu verhindern: Die letzte Sicherheitslücke in der AusweisApp, die ich gefunden hatte, ließ sich mit ein paar Zeilen Code und einem Update lösen. Dieses Problem hingegen lässt sich nur lösen, indem man den Nutzern beibringt, worauf sie zu achten haben – und sie dazu erzieht, auch tatsächlich daran zu denken, jedes mal auf diese Merkmale zu achten. Das ist allerdings sehr schwierig.

Bei unvorsichtigen Nutzern könnte dieser Angriff selbst dann funktionieren, wenn der Nutzer ein Lesegerät der höheren Sicherheitsstufe hat, bei denen man die PIN normalerweise über das Lesegerät eingibt. Eigentlich sollte es dem Nutzer auffallen, wenn er die PIN plötzlich am Rechner eingeben soll – aber wie viele Nutzer, die von den Sicherheitskonzepten keine Ahnung haben, werden die PIN trotzdem über die Computertastatur eingeben, wenn der Computer sie dazu auffordert und die Eingabe über das Lesegerät nicht akzeptiert?

Um sich gegen diesen Angriff zu schützen, muss man lernen, falsche von echten Fenstern zu unterscheiden. Im Browser wird die Website in einem bestimmten Bereich angezeigt. Lässt sich ein Fenster aus diesem Bereich heraus verschieben, dann handelt es sich zumindest um ein richtiges Fenster. Allerdings können Webseiten auch Popup-Fenster öffnen, die sich dann frei verschieben lassen. Bei allen gängigen Browsern kann die Website dabei zwar viele Teile des Browserfensters ausblenden, aber die Adressleiste (bzw. bei Opera eine dünne Leiste mit der Website-Adresse) bleibt immer stehen, eben um zu verhindern, dass ein Popup für ein echtes Fenster gehalten wird. Der „Verschiebetest“ zusammen mit einem kritischen Blick auf das Fenster ist also ein guter allgemeiner Anhaltspunkt.

Darüber hinaus hat die AusweisApp (bei angeschlossenem Lesegerät) ein Chip-Symbol in der Taskleiste neben der Uhr, welches bei aufgelegter Karte grün wird. Ist die AusweisApp aktiv, wechselt es die Farbe zu Blau. Das ist ein weiteres Sicherheitsmerkmal, auf das man achten sollte. Da ich nicht ausschließen möchte, dass es möglich ist, die AusweisApp zu aktivieren und dann irgendwie zu überlagern, würde ich den Verschiebetest zusätzlich empfehlen. Seltsam aussehende Schrift im AusweisApp-Fenster ist übrigens kein Hinweis auf eine Fälschung: Die Schriften sehen auch in der echten AusweisApp seltsam aus.

Man kann falsche Fenster also durchaus unterscheiden – aber die Hinweise, wie man es macht und dass man es machen solte, fehlen in den Hochglanzbroschüren zum Ausweis. Von sich aus kommen selbst Fachleute selten auf die Idee, diese Prüfungen zu machen, solange nicht irgendetwas Verdacht erregt. Eine gute Fälschung tut das aber nicht.

Ist der Angreifer im Besitz der PIN, reicht dies allein zwar noch nicht, um die Identität des Ausweisinhabers zu missbrauchen – die PIN existiert aber nicht ohne Grund und sollte nicht nur zum Spaß geheimgehalten werden. Ein Beispiel für einen Angriff, für den eine gestohlene PIN nützlich wäre, wurde auf dem 27C3 präsentiert.

Warum ich den Ausweis auch unabhängig von der Lücke ablehne, steht in diesem Beitrag. Auf weitere grundsätzliche Probleme wie die Beweislastumkehr, die für Ausweisnutzer ein ziemlicher Nachteil ist, werde ich in weiteren Beiträgen eingehen wenn/falls ich dafür Zeit finde. Ich kann nur davon abraten sich so einen Ausweis zu holen, bzw. wenn man schon einen hat, ihn zu nutzen. Auch wenn Alufolie immer an Verschwörungstheoretiker mit Aluhüten erinnert – ein paar Lagen davon, um den Ausweis gewickelt und an den Seiten umgefaltet, verhindern das Auslesen sowohl beim Ausweis als auch bei anderen RFID-Karten zuverlässig.

Noch ein kleiner Hinweis für die Presse: Ich bin immer noch kein CCC-Mitglied, obwohl ich letztes Mal nach den Falschmeldungen eingeladen wurde ;-)

Fragen die öffentlich beantwortet werden sollen/können, bitte über die Kommentarfunktion. Sonstige (An)fragen bitte über Jabber (XMPP, Google Talk) an janschejbal at jabber.ccc.de (das ist keine Mailadresse!) oder Mail an janhomepage [at] gmx punkt net. Telefon ist ungünstig, ggf. bitte Festnetznummer per Mail schicken.

Citibank Telefon-Phishing

Vor einigen Tagen habe ich etwas Interessantes mitbekommen:

Jemand erhielt einen Anruf, bei dem die Anruferin behauptete, von der Citibank zu sein, und irgendwelche Kontoangaben überprüfen wollte. So fragte die Dame aus dem Callcenter nach dem Geburtsdatum, welches bei der Citibank auch Teil der Kontonummer ist. Da die angerufene Person jedoch wusste, dass Betrüger gerne solche Informationen herausfinden wollen, bekam die Anruferin keine Antwort, sondern nur die Gegenfrage, worum es den ginge. Dies wollte sie jedoch nicht sagen, nannte aber ihren Namen und bejahte die Frage, ob sie aus der Filiale xyz anrufe, woraufhin die angerufene Person das Gespräch mit dem Hinweis, man werde dort anrufen, beendete.

Ein Anruf bei der erwähnten Filiale ergab die Antwort, dass dort keiner mit diesem Namen arbeitet, besonders gewillt, dem möglichen Betrug nachzugehen, war die Filiale jedoch nicht.

So weit, so gut, möchte man meinen, ein erfolgloser Telefon-Phishingversuch, selten, aber nicht unbekannt. Eine Nachfrage bei der zuständigen Stelle der Polizei ergab, dass der Beamtin solche Anrufe bekannt waren – aber keineswegs als Betrugsmasche, sondern als echte Anrufe von einer Bank, die wohl eine Versicherung verkaufen wollte.

Auf eine erneute Nachfrage bei der Citibank wurde dies dann für möglich gehalten.

Entweder es hat sich also um einen Betrugsversuch gehandelt, der aber der Bank ziemlich egal war, oder der Anruf war wirklich von der Bank.

Den zweiten Fall fände ich persönlich bedenklicher: Statt den Kunden beizubringen, sorgsam mit persönlichen Daten umzugehen, werden sie darauf trainiert, diese Daten über das Telefon an irgendwelche Anrufer, die behaupten, von der Bank zu sein, herauszugeben.

Dies gilt auch für den Fall, dass der Anruf nicht von der Citibank kam, denn der betroffenen Person wurde gesagt, dass solche Anrufe durchaus vorkommen können.

Als nächstes könnte die Citibank ja gleich auch noch anfangen, E-Mails verschicken, mit der Bitte, Name, Adresse, Kontonummer, Online-PIN und 10 TANs einzugeben, um die Kontodaten zu prüfen.

Egal welcher der Fälle zutrifft, die Citibank hat sich nicht gerade mit Ruhm beckleckert und wird wohl in Zukunft mindestens einen Kunden weniger haben.

Auch für mich steht nach dieser verantwortungslosen Aktion eine weitere Bank fest, bei der ich wohl kein Konto haben werde, zumal die Citibank bereits dafür bekannt geworden ist, dass sie ziemlich unsichere TAN-Listen erzeugt hat, und das, was man so im Internet findet, ist auch nicht gerade Vertrauen erweckend. UPDATE: Und noch ne Runde, diesmal hat sich die Citibank USA die PINs klauen lassen. Da ist es ja schon grob fahrlässig, bei denen ein Konto zu haben.