Ein verwandtes Thema ist Phishing, d.h. elektronische Angriffe gegen Bankkunden und gegen alle Arten von Internet-Accounts.
Mein Artikel "Sicheres Internet-Banking" stellt die Angriffe ausführlich dar und gibt Tipps, wie Internet-Banking und andere Web-Accounts sicher genutzt werden können.
An anderen Stellen beschreibe ich die grundsätzlichen Schwächen im HTTPS-Ökosystem.
Und dieses Video zeigt eine ganz andere Form von Man-in-the-Middle Angriff: beim Stehlen eines Fahrzeugs muss nicht mal in den Datenverkehr eingegriffen werden, oft reicht es aus, über entsprechendes Weiterleiten von Signalen des korrekten Autoschlüssels das Fahrzeug zu öffnen (Relay-Angriff). Im Video ist zu sehen wie die Angreifer mit passender Elektronik die Schlüsselsignale verstärken und innerhalb von Minuten mit dem Auto weg sind. Auch die Tatsache, dass sie dabei gefilmt wurden, hilft niemandem weiter, die Täter sind nicht gefasst worden.
Man-in-the-Middle-Angriffe sind Methoden (die seit ca. 1995 diskutiert werden), bei denen sich der Angreifer in eine Kommunikationsverbindung einklinkt, er sitzt dann in der Mitte zwischen den beiden Kommunikationsendpunkten. Früher, als Datenkommunikation noch über Standleitungen ablief setzte dies voraus, dass der Angreifer die Leitung unterbricht, sich dazwischen hängt und damit in der Lage ist, alle übertragenen Daten zu sehen und auch zu verändern.
Heute ist das einfacher. Mit der Vernetzung im Internet und auf Grund der Philosophie hinter dem Internet, dass nämlich die Daten selbst ihren Weg zur Gegenstelle finden, ist diese physische Platzierung zwischen den beiden Kommunikationsendpunkten nicht mehr notwendig. Der Angreifer braucht nur die Wegweiser umzustellen, mit deren Hilfe die Datenpakete ihren Weg finden, d.h. er sorgt dafür, dass die Datenpakete erst mal zu ihm kommen, nachdem er sie angeschaut oder auch verändert hat, leitet er sie an die Endstelle weiter. Dies ist die Grundlage aller modernen Man-in-the-Middle-Angriffe.
Dieser Artikel kombiniert mehrere Themen, nämlich die technischen Hintergründe zu Man-in-the-Middle Angriffen und die Zwecke, zu denen diese dann verwendet werden. Diese Zwecke reichen von Abhör-Aktivitäten der Geheimdienste, über das Abfangen von Zugangsdaten bei Nutzern von öffentlichen WLANs bis zu dem großen Bereich des elektronischen Bankraubs, das früher reinen Phshing-Angriffen bestand, aber seit SMS-TAN sehr weitgehend eingesetzt wurden, sich zu Variationen von Man-in-the-Middle Angriffen gewandelt hat, z.B. Man-in-the-Browser.
Angriffe durch ISPs, meist auf Wunsch von Regierungen
Man-in-the-Middle werden nicht nur für finanziellen Betrug eingesetzt. Auch Regierungen klinken sich gern mal ein und wollen bei ihren Bürgern mitzulesen - dies wäre aber in Europa, wenn überhaupt, nur mit Richterentscheid möglich. Die NYT berichtet im August 2011 dass der Iran offenbar Google-Web-Zertifikate gefälscht hat und daher den Datenverkehr zu gmail mitlesen kann. An den Mühen mit den Zertifikaten sieht man, dass es seit den Enthüllungen von Snowden (und der darauf folgenden Welle von Verschlüsselungen fast aller Websites) für die Regierungen nicht mehr so leicht ist, diesen Datenverkehr mitzuschneiden ohne dass die Benutzer eine Warnung bekommen.
Die einfachste Stelle für eine Regierung für einen solchen Man-in-the-Middle Angriffe ist der ISP des Nutzers, mit dem der sich ins Internet verbindet. 2018 wird berichtet, dass Türk Telekom und Telecom Egypt die Datenpakete seiner Kunden analysiert und dann, vermutlich auf Wunsch der Regierungen, Schadsoftware auf den Rechnern der Kunden platziert. Typischerweise sind das Staatstrojaner, in Ägypten wares es zum Teil auch Kryptotrojaner, die die Finanzen des ISPs aufbessern sollten. Für diese Installation wurde gar keine Schwachstelle im PC des Nutzers benötigt, die ISPs haben Programme wie VLC, Skype oder Opera mit einer zusätzlichen Schadsoftware infiziert. Dies funktioniert, weil diese Anbieter ihre Software ohne HTTPS-Verschlüsselung verteilen, was ein Fehler ist der so was ermöglicht.
Quelle: www.documentcloud.org. Man-in-the-Middle der NSA gegen ausgewählte Google-Nutzer
Ein gutes Beispiel für einen politischen Man-in-the-Middle Angriff ist in einer Studie zum Einbruch bei Diginotar 2011 dokumentiert. Dort wurden gefälsche SSL-Zertifikate und ein "Verbiegen" der DNS-Auflösung für einen Angriff gegen iranische Internet-Surfer genutzt. Bei 300 000 Verbindungen kann nachgewiesen werden, dass sie über den Man-in-the-Middle Zugang surften. Die iranische Regierung bekam auf diese Weise Zugriff zu allen Email-Konten der Nutzer von Gmail und anderen Webmailern.
Link-Konventionen: Fette Links öffnen ein fremde Seite in einem neuen Fenster Blau hinterlegte Links bleiben auf der sicherheitskultur.at
Und nicht nur die iranische Regierung: Dokumente von Snowden zum NSA-Thema zeigen, wie die NSA genau das gleiche durchführt (bzw. die Diginotar Probleme selbst ausgenutzt hat): NSA Mimics Google to Monitor "Target" Web Users. Dafür werden wohl gefälschte SSL-Zertifikate eingesetzt (siehe auch Darstellung rechts). Weitere Details finden sich im 2. Teil des brasilianischen Videos NSA Documents Show United States Spied Brazilian Oil Giant in dem Bilder aus den NSA-Powerpoints gezeigt werden.
Angriffe aus finanziellen Gründen müssen für die Angreifer skalierbar sein
Es sind ganz verschiedene Angriffsformen rund um das Man-in-the-Middle-Konzept denkbar. Wichtig ist für Angreifer, die die Angriffe aus finanziellen Gründen nutzen (und nicht um z.B. Staatstrojaner zu platzieren), dass "der Angriff skaliert". Damit ist gemeint, dass der Angriff automatisiert und wie am Fließband ausgeführt werden kann. Diese Anforderung fällt natürlich weg, wenn eine Regierung einen oder wenige Opositionellen überwachen will. Dann können auch sehr gezielte Angriffe eingesetzt werden.
Ein Beispiel für Skalierungsproblematik: Es ist nicht sehr schwierig, mittels Social Engineering-Techniken das Geburtsdatum eines bestimmten Menschen herauszufinden. Ein solcher Angriff "skaliert" aber nicht, er kann nicht massenhaft und automatisiert eingesetzt werden.
Noch ein Beispiel für die Problematik der Skalierung: In 2006 hatte ich geschrieben, dass Handys zwar mit einigem Aufwand abgehört werden können. Aber das geht immer nur in der Nähe des Handynutzers, nicht flächendeckend (anders ist es, wenn die Behörden beim Mobilfunkanbieter die Leitungen anzapfen, das skaliert natürlich sehr gut). Diese Herausforderung hat die Technologie mittlerweile obsolet gemacht. Immer mehr Bankkunden haben Smartphones und das infizieren eines Smartphones, speziell wenn es auf Android basiert und der Kunde eifrig Apps installiert, ist in 2011 überhaupt kein Problem mehr. Damit lassen sich SMS-TANs sehr schön abfangen und bei Bedarf auch der Aufenthaltsort und alle anderen Daten auf dem Gerät auslesen. Damit "skaliert" so ein Angriff auf ein Handy nun und kann mittels Phishing-Emails auch großflächig eingesetzt werden.
Bei der Bewertung von Schutzmaßnahmen ist deshalb immer zu berücksichtigen, vor welchem Typ von Angreifer ich mich schützen will und muss. Für die meisten Bürger reicht der Schutz gegen Kriminelle, denn die werden sich immer auf die "niedrigen Früchte" konzentrieren. Für Regierungen gilt aber, dass mit beliebig hohem Aufwand jede Schutzmaßnahme ausgehebelt werden kann (notfalls kann man jemanden bestechen). Die nächste Zeichnung zeigt einen Man-in-the-Middle Angriff der nicht skaliert, da er eine räumliche Nähe zum Opfer voraussetzt.
Ein "klassicher" Man-in-the-Middle Angriff, z.B. in einem öffentlichen WLAN
Solch ein Man-in-the-Middle Angriff wie links gezeigt ist für die Bank und für den Benutzer nicht erkennbar. Der Kunde sieht (fast) die gleichen Bildschirminhalte wie immer, denn er ist ja mit der korrekten Website verbunden - wenn er aufmerksam ist wird er jedoch sehen, dass das Zertifikat der Website nicht stimmt, denn das kann der Angreifer nicht so leicht imitieren. Der Angreifer kann ganz gezielt in die Interaktion des Kunden mit der Website eingreifen und ganz gezielt Daten ändern, z.B. Betrag und Kontonummer einer Überweisung.
Solch ein Angriff ist schwer zu vereiteln, denn was immer die Bank an den Kunden als Prüfungsfrage (Autorisierung) weiterleitet, der Angreifer holt sich die korrekte Antwort vom Kunden und leitet sie einfach weiter. Beispiel: Die Bank fragt nach dem Passwort, der Man-in-the-Middle leitet die Frage an den Benutzer weiter, dieser gibt das Passwort ein und der Man-in-the-Middle (d.h. sein Programm) nimmt es zur Kenntnis und sendet es weiter. Das geht auch mit komplizierten Authentifizierungen, z.B. One-Time Passworten, die sich ständig ändern (z.B. über sog. Tokens).
Das klappt auch über sog. sichere SSL-Verbindungen. Denn bei SSL, so wie es heute in der Regel verwendet wird, authentifiziert sich nur 1 Stelle, nämlich der Server mit seinem Zertifikat. Weil es die theoretisch möglichen Client-Zertifikate praktisch nicht gibt, ist dem Server egal, wer die Gegenstelle ist. Der Angreifer spielt bei einer SSL-Verbindung dem Webserver ganz einfach den Benutzer vor und dem Benutzer spielt er den Webserver vor. Das ist, was man i.d.R. als Proxy-Funktion bezeichnet. D.h. der Angreifer baut von seinem Rechner eine verschlüsselte SSL-Verbindung zum Webserver auf und eine weitere verschlüsselte Verbindung von sich zum Benutzer. Dem Benutzer spielt er dabei ein falsches SSL-Zertifikat vor. Dazwischen hat der Man-in-the-Middle die Informationen im Klartext. Solche falschen Zertifikate kann jeder Angreifer leicht selbst erstellen, aber dann sind diese "self-signed", d.h. niemand verbürgt sich für die Korrektheit. Oder er lässt sich das Zertifikat von einem der Zertifizierungsstellen (Certification Agency, CA) ausstellen, die dafür keinerlei Belege verlangen, außer dass der Kunde eine geringe Gebühr zahlt.
Der Ablauf eines solchen Man-in-the-Middle (MITM) Angriffs wenn die Überweisung durch Handy-TAN abgesichert ist
der Kunde verbindet sich zur Bank, wird jedoch über den MITM-Rechner umgeleitet, der den gesamten SSL-Datenverkehr entschlüsselt, bei Bedarf leicht modifziert und dann wieder verschlüsselt an die Bank weiterleitet. Ebenso werden alle Antworten von der Bank wieder entschlüsselt, bei Bedarf leicht verändert und dann wieder verschlüsselt dem Kunden weitergeleitet. Die Authentisierung über One-Time Passwort gelang ohne Probleme, dafür musste nicht mal eine Veränderung der Daten durchgeführt werden.
der Kunde stößt nun eine Überweisung an, gibt Betrag, BLZ und Kontonummer ein. Der Angriffe in der Mitte verändert den Betrag und die Konto-Informationen und leitet diese so modifzierte Überweisung an die Bank weiter
setzt die Bank ein sehr modernes Verfahren ein, so die Bank generiert eine Zufallszahl und leitet diese an das Handy des Kunden weiter (Handy-TAN oder mTAN).
der Angreifer kann zwar die Handy-TAN nicht abfangen, aber er kann die Konto-Informationen für den Bildschirm abfangen und wieder auf die ursprünglichen Werte des Kunden zurücksetzen. D.h. der Kunde sieht von der Bank ein Bestätigungsfenster mit den Informationen, die er eingegeben hat, die aber nicht die Informationen sind, die die Bank bekommen hat.
der Kunde sieht, dass das Bestätigungsfenster korrekt ist und gibt die Handy-TAN ein, die der Angreifer weiterleitet, aber erst nachdem er wieder die Konto-Informationen auf den falschen Wert zurückgesetzt hat
Aber auch hier ist ein sicherer Schutz möglich wenn die Bank die Überweisungsdaten, d.h. die Konten-Informationen des Empfängerkontos an den Kunden zur Bestätigung mittels der Handy-TAN zurück ("out-of-band Übertragung") mitsendet und der Kunde diese anschaut - der Kunde sieht den falschen Betrag und die Kontonummer des Geldkuriers und bricht die Interaktion mit der Bank ab.
Der Benutzer kann diesen Angriff entdecken, denn der Angreifer ist nicht in der Lage, das korrekte Zertifikat zu präsentieren. Das Risiko geht der Angreifer ein, weil die Chance, dass der Benutzer das Zertifikat anschaut, leider gering ist (welcher Internetnutzer weiß überhaupt, wie man ein Zertifikat überprüft?). Hinter diesem Link finden sich auch Beispiele, wie Phisher es recht leicht geschafft haben, sich gültige Zertifikate von mehr oder weniger renomierten Anbietern erstellen zu lassen.
Evtl. klingt das jetzt so, als wäre so ein Angriff nur schwer durchzuführen. Es gibt aber bereits fertige Phishing-Kits, mit deren Hilfe sich eine Weiterleitung einer e-Banking-Sitzung recht leicht gestalten lässt (z.B. Rock Phish. Hier ein Beispiel für eine dieser Angriffstechniken im Detail: Citibank Phish Spoofs 2-Factor Authentication und das bereits im Juli 2006.
Auch viele der Phishing Angriffe über E-Mails, die zu gefälschten Websites weiterleiten, sind Man-in-the-Middle Angriffe, nämlich wenn sie nach Eingabe der falschen Informationen auf die korrekte Website weiterleiten.
Eine andere Phishing-Attacke läuft über Google. Dort finden sich heute Reiseportale, die gar keine sind. Sie bieten extrem billige Flüge an, aber letztlich geht es um den Moment, wo der Kunde die Kreditkartennummer und möglicherweise andere sensible Informationen eingibt. Eine solche gefälschte Website kann ohne großen Aufwand sogar über Suchmasken aktuelle Flüge anzeigen, der Betreiber der gefälschten Website muss einfach nur 1:1 die Anfragen an ein wirkliches Reiseportal weiterleiten und dann die Antworten die von dort kommen weiterleiten. Nachdem der Kunde dann die Kreditkarte eingegeben hat kann einfach eine Fehlermeldung ausgegeben werden und damit der Dialog abgebrochen werden. Ich habe aber auch von einem Angriff gehört, bei dem sogar ein Ticket per Post ankam, und zwar von einem legitimen Anbieter, aber mit einer zusätzlichen Rechnung.
Um mich logisch zwischen einen Webbrowser und einen Webserver zu hängen, gibt es viele Techniken. Die im folgenden geschilderten techischen Angriffe beschreiben, wie ein Mittelsmann sich in dem Kommunikationskanal einschaltet. Eine andere Technik wird weiter unten beschrieben, dabei sitzt der Mittelsmann auf dem PC des Kunden.
Man-in-the-Middle Angriffe bei HTTPS Verbindungen
In den folgenden Kapiteln beschreibe ich, wie der Angreifer es schafft, sich in die Internetverbindung "logisch" reinzuhängen. Das ist aber nur der halbe Angriff - danach muss der Angreifer damit rechnen, dass er es mit einer verschlüsselten HTTPS-Verbindung zu tun hat. In diesem Fall kann er gegenüber dem Webserver als Client auftreten und gegenüber dem Webbrowser als Webserver. Die Herausforderung bei HTTPS-Verbindungen ist aber, dass der Browser überprüft, ob das Zertifakat das der Angreifer gegenüber dem Browser präsentiert, in der Liste der vertrauenswürdigen Certification Authorities (CAs) enthalten ist. Falls ja, so gibt es keine Warnung. Falls es ein vom Angreifer selbst ausgestelltes Zertifkat ist ("self-signed"), so bekommt der Benutzer eine Warnung dass die Website unsicher wäre. An dieser Stelle brechen nach Studien ca. die Hälfte der Benutzer ab, die andere Hälfte geht trotzdem auf die Website.
Angreifer lösen diese Herausforderung manchmal, indem sie einen CA hacken, so wie das seit 2011 immer wieder mal passiert ist. So konnte sich ein Angreifer nach einem solchen Angriff Zertifikate im Namen von Google, Microsoft und Facebook selbst ausstellen und die iranischen Regierungsbehörden waren in der Lage, den Datenverkehr von vermutlich mehr als 1 Mio. Bürgern mitzulesen, die Passworte zu speichern und auf deren Emails zuzugreifen.
Eine einfachere Methode ist SSL-Stripping. Dabei macht sich der Angreifer nicht die Mühe, dem Benutzer eine HTTPS-Verbindung vorzugaukeln, er leitet den Datenverkehr einfach über HTTP weiter und vertraut darauf, dass die Benutzer nicht merken, dass die URL-Zeile nicht so aussieht wie gewohnt. Dieser Angriff kann vereitelt werden, wenn die Website mittels HSTS dem Browser mitteilt, dass ihre Inhalte nie über http kommen werden, dies ist heute aber noch extrem selten.
An anderer Stelle beschreibe ich die grundsätzlichen Schwächen im HTTPS-Ökosystem und auch mehr Details zu solchen Angriffen und Verteidigungsmöglichkeiten.
Vorspiegelung eines falschen WLAN-Access Points
Bevor ich etwas weiter unten zu den technisch komplizierteren Angriffen komme, hier jetzt erst mal was ganz simples: ein Angriff über öffentliches WLAN. Dies setzt natürlich typischerweise voraus, dass Angreifer und Opfer räumlich nahe sein müssen. D.h. dieser Angriff "skaliert" nicht weltweit. Er ist z.B. geeignet, um jemanden anzugreifen, der im selben Restaurant sitzt und dort das WLAN nutzt.
Dies ist ein Man-in-the-Middle Angriff auf der Luftschnittstelle von WLAN, üblicherweise in einem öffentlichen WLAN. Der Angreifer simuliert einen zusätzlichen Access Point mit einer missverständlichen SSID (bzw. siehe weiter unten) und einer möglicherweise besseren Signalqualität. Er wartet darauf, dass die Kunden des WLANs sich bei ihm und nicht bei dem echten Access Point anmelden. Er kann dann den Verkehr an den echten Access Point weiterleiten, so dass für die Opfer der Eindruck einer normalen Verbindung entsteht. Wenn der echte Access Point eine Authentifizierung verlangt, so erfährt der Angreifer auf diesem Weg auch die Benutzernamen und Passworte. Der Angreifer kann auf diese Weise den gesamten Verkehr abhören, bzw. andere Angriffe, wie Phishing, durchführen. Die Nutzung von Verschlüsselung des WLAN-Verkehrs in diesem Netz würde nicht automatisch einen Schutz darstellen, denn wenn der Angreifer ebenfalls Kunde ist oder auch in dem Hotel wohnt, so kennt er den Schlüssel den der korrekte Access Point verwendet und kann den gleichen verwenden).
Software für solche Angriffe ist heute sehr leicht verfügbar, hier ist eine Anleitung für ein kleines Gerät namens Pineapple. Aus diesem Artikel habe ich gelernt, dass WLAN-fähige Geräte, z.B. Smartphones, ständig alle SSID ihrer früheren Connection "proben". Der Pineapple simuliert dann genau diese SSID und das Gerät des Opfers verbindet sich automatisch.
Natürlich kann ein Administrator des WLAN-Anbieters sich soweie in die Verbindungen aller Kunden reinhängen. Ob er damit aber an die Daten kommt, das hängt davon ab, ob der Kunde verschlüsselt "unterwegs" ist und falls ja, ob der Kunde auf die Browserzeile achtet. Mehr dazu unter dem Stichwort HTTPS Herausforderungen.
Ablauf beim Man-in-the-Browser Angriff
Man-in-the-Browser gegen Internet-Banking
Dies ist eine spezielle Variante, die immer wichtiger wird und die anderen Methoden schon fast verdrängt hat {weil sie so einfach durchzuführen ist, einen nicht vollständig aktualisierten Rechner zu infizieren ist leider sehr einfach :-( . In diesem Fall wird die Kommunikation bereits im PC, entweder in der Kommunikations-Software oder eben im Web-Browser abgefangen und verändert. Möglich sind diese Angriffe, wenn der PC durch Schadsoftware infiziert wurde (was für eine sehr große Zahl von Heim-PCs leider zutrifft, Schätzungen gehen bis zu 30% - an anderer Stelle steht, wie diese Infektion des PCs durchgeführt wird).
In diesem Fällen greifen die herkömmlichen Schutzmethoden (siehe nächstes Kapitel) wie Verschlüsselung mit SSL nicht, denn das Abhören und die Veränderungen werden bereits durchgeführt, bevor die Verschlüsselungssoftware überhaupt aktiv wird. Gegen diese Form von Angriff hilft nur, dass man durch geeignete Maßnahmen die Infektion verhindert. Außerdem gelten die weiter unten beschriebenen Schutzmaßnahmen.
"Human-assisted" Angriff Dropzone bezeichnet den Server, auf dem die vom Rechner des Opfers gestohlenen Daten abgelegt werden. Quelle: OWASP EU09 Poland The Bank in the Browser (pdf, mit vielen Graphiken, speziell ab Slide 50)
Human-Assisted Phishing Angriffe
Eine Methode, die ab 2009 immer häufiger bei Phishing-Angriffen zu beobachten ist erfordert einen Angreifer, der gleichzeitig wie der Kunde aktiv ist. Es findet ein "konventioneller" MITM-Angriff, Man-in-the-Browser oder auch nur Phishing-Angriff statt, aber im Augenblick wenn der Kunde sich mit der Bank verbindet (oder im Fall von Phishing: Glaub sich zu verbinden), wird ein Alarm an den Angreifer gesendet. Der sitzt an seinem eigenen Rechner und bekommt die Authentisierungsinformationen (z.B. Passwort) in Real-time übermittelt. Diese Angriffe sind keine Theorie, sie finden aktiv und erfolgreich statt.
Bei dem ersten Typ wird ausgenutzt, dass die Kontinuität einer Bankensitzung oft über einen Cookie mit einer "session-ID" hergestellt wird. Dieser Cookie kann vom angegriffenen Rechner auf den Rechner des Angreifers übertragen werden, dann unterbricht der Angreifer die Sitzung des Opfers, das loggt sich neu ein, der Angreifer führt die ursprüngliche Sitzung weiter.
Das Opfer kann über simulierte TAN-Abfragen dazu gebracht werden, reichlich TANs einzugeben, die sofort an den Angreifer übertragen wird, der damit dann Überweisungen durchführt.
Auf diese Weise lässt sich das Konto viel effektiver leer räumen, als durch einen automatisierten Angriff. Und diese "Human-Assistance" ist oft in Billiglohn-Länder ausgelagert.
Phishing-Angriff gegen SMS-TAN (Klick gibt großes Bild)
Bei dem Angriff links bekommt das Opfer ein Email und wird auf eine gefälschte Banken-Website gelockt. Dort gibt er Benutzername und Passwort ein und wird dann durch weitere Eingaben beschäftigt, z.B. Geburtsdatum und Email-Adresse. Benutzername und Passwort waren gleichzeitig an den Angreifer übermittelt worden, der loggt sich statt des Opfers bei der Bank ein und schaut, ob auf dem Konto was zu holen ist. Falls ja, so macht er eine Überweisung fertig und fordert eine SMS-TAN an.
Das Opfer ist mittlerweile vorgewarnt worden dass er gleich eine SMS-TAN erhalten würde, die er zur Bestätigung eintippen müsste. Jetzt hängt alles davon ab, ob das Opfer sich die SMS durchliest. Denn da steht drin, dass er Geld auf irgendein Konto überweisen würde. Wenn das Opfer dies nicht merkt, die SMS eintippt, so bekommt der Angreifer diese übermittelt und kann seine eigene Überweisung damit bestätigen.
Schutzmöglichkeiten gegen elektronischen Bankraub - 2 Kanäle sind nötig: PSD2 Richtlinie
2 Kanäle sind ab 2019 Vorschrift
Hier die gute Nachricht: Ab Mitte 2019 wurden durch die Zahlungsdiensterichtlinie der EU (engl. PSD2) solche 2 Kanäle zur Vorschrift. Dies hat die Latte für die Angreifer die an Bankkonten wollen deutlich höher gelegt.
Leider haben die Angriffe aber nicht aufgehört sondern die Laien-Angreifer sind jetzt professionalisiert worden. Die Angriffe sind mit höherem Automatisierungsaufwand immer noch möglich, aber die abgefangenen Passworte müssen sofort dazu genutzt werden, um die dann erfolgende Verifizierung des Kunden durch die Bank sofort zu triggern und dann den Code den der Kunde auf dem 2. Kanal bekommen hat, auch noch abzufragen. Dies funktioniert sowohl bei der Verwendung von Code die auf Handys gesendet werden wie auch bei den meisten Implementierungen von Autorisierungs-Apps.
Natürlich sind auch hier Gegenmaßnahmen möglich, die sind jedoch für den Kunden etwas umständlicher, z.B. das Abfotografieren eines QR-Codes.
Verhindern kann man die eher traditionelle Art von Man-in-the-Middle Angriffen bei dem ein Angreifer den Datenverkehr über seinen eigenen Rechner leitet durch die gegenseitige Authentifizierung der Endpunkte, d.h. die beiden Endpunkte "kennen" sich bereits und wissen, wem sie vertrauen können. Dieses "Kennen" ist z.B. gegeben, wenn beide Partner im Datenverkehr Zertifikate nutzen oder wenn, sie im Fall von SSL (HTTPS) der Kunde am Browser das Zertifikat überprüft.
Eine SSL-Verbindung mit gegenseitiger Authentisierung wenn der Kunde dafür auch ein Zertifikat nutzen würde, z.B. über ein Zertifikat wie auf der Bürgerkarte. Einige Banken bieten dies in Österreich an. Dabei muss ich in einem ersten Schritt meine Karte bei der Bank registrieren lassen (ebenfalls online). Ab dann weiß die Bank, mit wem sie es zu tun hat.
Technischer Einschub: [Die Sicherheit entsteht bei der Nutzung eines Public Key Verfahrens dadurch, dass während der Authentifizierung nicht das Zertifikat mit dem öffentlichen Schlüssel ausgetauscht wird, sondern eine Zufallsfolge wird mittels des eigenen privaten Schlüssels signiert und dem Kommunikationspartner gesendet. Dieser nutzt den ihm bekannten öffentlichen Schlüssel um die Signatur zu überprüfen und stellt damit den Zusammenhang zwischen dem öffentlichen Schlüssel (im Zertifikat) und dem privaten Schlüssel des Kommunikationspartners fest. Wenn der Empfänger der signierten Datenfolge nicht vorher bereits über eine andere Quelle den öffentlichen Schlüssel erhalten hatte (out of band), sondern in der gleichen Sitzung, so muss der Empfänger durch Überprüfung des Ausstellers des Zertifikats sicherstellen, dass ihm nicht durch einen Man-in-the-Middle ein gefälschtes Zertifikat untergeschoben wird.]
Technisch könnten wir im Internet so arbeiten dass sich wohl der Browser wie auch der Server identifiziert und das wäre deutlich sicherer. Aber es wäre auch ein Stück umständlicher. Statt einfach bei amazon.com einkaufen zu können, müsste ich vorher auf einem anderen Wege mein Zertifikat (das sich jeder leicht mittels geeigneter Software selbst erstellen kann) an amazon senden, so dass diese mich als authentisierten Kunden einspeichern können. Wenn dann jemand meine Identität vorgeben will, so würde amazon das merken und den Geschäftsvorgang abbrechen. Es gab ein solches Konzept für Internetzahlungen mittels Kreditkarten vor vielen Jahren, SET genannt und von den Kreditkartenfirmen stark propagiert. Jeder Kunde hätte sich dafür bei seiner Kreditkartenfirma ein sog. Wallet holen müssen (eine Software mit einem persönlichen digitalen Zertifikat). Das ist nicht von den Kunden angenommen worden, ansonsten hätten wir heute die gesamte Phishing-Misere überhaupt nicht.
Bruce Schneier geht davon aus, dass wir auch dann keine 100% Sicherheit bei der Authentisierung des Logins erreichen können und schlägt als Lösung vor, dass nicht nur die Authentifizierung sicherer gemacht wird, sondern auch der Transaktionsvorgang abgesichert wird. Dies ist der Weg der von eigentlich allen Banken beschritten wird. D.h. die Sicherheit des Internet-Bankings besteht nicht so sehr aus der Sicherheit meines Logins, sondern darain, dass jede Überweisung separat bestätigt wird. Damit ist das Problem erst mal nur verlagert worden, denn auch diese Autorisierung der Transaktion muss sicher gestaltet werden und das ist nicht einfach.
Es gibt eine andere Technik, die meine Bank in Singapur verwendet und die ich sehr sicher finde. Die Bank in Singapur erlaubt mir nur Überweisung auf Grund von Vorlagen, die ich nicht ändern kann, ohne einen Code auf das Handy zu senden. D.h. ein Angreifer kann sich nicht selbst etwas auf sein Konto überweisen. Die Vorlage enthält auch ein Limit bzgl. der maximalen Beträge. Das Erstellen oder Ändern von Vorlagen geht nur über einen Code, den mir die Bank aufs Handy schickt. Die Überweisung selbst erfordert dann nicht mal eine TAN, aber ich halte das trotzdem für sehr sicher.
Mehr Sicherheit durch 2 unabhängige(!) Daten-Kanäle
Wenn ein sehr clever Angreifer bereits auf dem Rechner des Kunden sitzt, d.h. wenn sein Rechner mit einem Trojaner infiziert ist der mit dem E-Banking seiner Bank umgehen kann so ist ein Schutz sehr schwierig. Ein Angriff funktioniert sogar für die eigentlich sehr sichere Smartcard:
Kunde authentifiziert sich über die Smartcard und startet Überweisung der Stromrechnung an Wien Energie
dafür werden bei einer sehr sicheren Implementierung die Überweisungsdaten an den Kartenleser und damit an die Smartcard gesendet
der Angreifer hat aber bereits die Überweisungsdaten durch eine Überweisung an den Geldkurier ersetzt
der Kunde gibt nun seine PIN ein, weil er nicht weiß, dass er damit die falsche Überweisung signiert
der Angreifer sendet die signierte falsche Überweisung an die Bank, täuscht dem Kunden jedoch eine Fehlermeldung und einen Abbruch vor
wenn der Kunde sich wieder anmeldet, kann der Angreifer ihm wieder einen falschen Kontostand vorgaukeln
Social Engineering Angriffe
Dez. 2013, aber immer weiter aktiv, auch in 2020: Bei aller technischen Absicherung sind immer Social Engineering Angriffe möglich. Seit 2013 gibt es vermehrt Fälle, bei denen die Angreifer, um an die TAN zu kommen, bei den Opfern der Phishing-Angriffe anrufen und verlangen, dass die SMS-TAN oder die iTAN vorgelesen wird. Sie geben sich dann entweder als Kundenbetreuer, das Call-Center oder sogar als die Sicherheitsabteilung aus. Natürlich gibt es immer wieder Menschen, die dann die TAN weitergeben. Da die Angreifer nachdem das Konto leer ist üblicherweise noch 3x ein falsches Passwort eingeben, kommen die Opfer nicht mehr auf ihr Konto und sehen den Schaden oft erst, nachdem sie sich ein neues Passwort haben geben lassen.
Wie kommt der Angreifer IN die Verbindung?
Um verstehen zu können wie der Angreifer IN die Verbindung, d.h. zwischen den Webbrowser und den Webserver kommt, muss man wissen wie ein Webbrowser den Webserver eigentlich findet. Nehmen wir ein konkretes Beispiel: Jemand ist mittels Kabel-Modem oder xDSL/ADSL über einen Internet-Provider (ISP) mit dem Internet verbunden. Wenn der Benutzer am Webbrowser eine Adresse eingibt, z.B. www.orf.at, so schaut der Webbrowser nach, unter welcher numerischen IP-Adresse dieser Webserver zu finden ist. Um das zu tun, befragt er einen DNS-Server. Wo der DNS-Server zu finden ist, hat ihm vorher der DHCP-Server des Providers gesagt. [Der DHCP-Server gibt dem PC des Benutzers bei der Anmeldung mehrere Informationen: Er gibt ihm eine (evt. nur temporäre) IP-Adresse für diese Sitzung, er teilt dem Rechner mit, unter welcher anderen IP-Adresse der Zugang zum Internet zu finden ist (Gateway-Adresse) und unter welcher Adresse der DNS-Server steht].
Der DNS-Server ist es dann, der "www.orf.at" in eine numerische IP-Adresse übersetzen kann. D.h. hier haben wir schon eine ganze Reihe von Angriffspunkten, denn alle diese Wegweiser können verstellt werden.
Einen sehr guten technischen Überblick über Man-in-the-Middle Angriffe gibt es auch bei heise.de.
DHCP basierende Angriffe
Eine erste Methode ist es, DHCP-Server zu spielen, was in einem Kabelnetz sehr leicht ist (z.B. in einem Hotel-LAN - WLAN). Der Rechner des Kunden fragt im lokalen Netz über einen sog. Broadcast, ob ihm irgendjemand eine IP-Adresse geben könnte. Der DHCP-Server, der am schnellsten antwortet, wird vom Rechner akzeptiert. D.h. wenn der falsche DHCP-Server einen falschen Weg ins Internet (Gateway-Adresse) angibt, so schickt der Rechner des Kunden alle Internet-Anfragen an diese falsche Adresse. Der Rechner, der dort steht, kann die Daten dann lesen, verändern und weitersenden. Oder der Angreifer lügt bei der DHCP-Antwort, wenn es um den DNS-Server geht. Der Angreifer gibt dem Kunden einen DNS-Server, den er selbst kontrolliert. Dann kann er dem Webbrowser falsche IP-Adressen liefern. Alle diese Angriffe setzen voraus, dass ich im gleichen lokalen Netz wie das Opfer bin, was bei Kabelnetzen, Hotel-LANs und auch öffentlichen WLAN-Hotspots gegeben ist.
Statt einen falschen DNS-Server vorzuspielen, kann ein Angreifer auch die "hosts" Datei auf einem Rechner austauschen. Dafür muss er in den Rechner eindringen, entweder über eine Schwachstelle oder über ein Virus-E-Mail. Der Rechner des Internetbenutzers prüft nämlich, bevor er einen DNS-Server befragt, erst mal diese hosts-Datei und auch da kann bereits eine Umlenkung passieren.
Ein Beispiel für die Ausführung dieses Angriffs ist das sog. Drive-By Pharming, für das fertige Software vorliegt. Der Angreifer lockt das Opfer auf eine Website, auf der ein Javascript vorliegt, das versucht, auf den Wireless Access Point, Router oder Switch für dieses Heim-Netz zuzugreifen. Das Programm kennt die Default Passworte für Linksys, D-Link und NETGEAR und verändert dort den DNS-Eintrag. D.h. der Angreifer kann von nun an den Internet-Datenverkehr des Opfers auf seine eigenen Server umleiten. Das Paper dazu: Drive-By Pharming. Die Antwort ist natürlich ganz leicht: Passworte natürlich sofort bei der Installation abändern.
ARP Cache Vergiftung
Dies ist ein Man-in-the-Middle Angriff, der seit 2001 bekannt ist. Der Angriff benutzt das Address Resolution Protocol (ARP) und funktioniert, indem der Angreifer den anderen Geräten im Netz auf Layer 2 vorspielt, er selbst wäre der WLAN Access Point oder das Gateway zum Internet (im Fall von Kabelnetzen). Zu diesem Zweck sendet der Angreifer geeignete ARP-Pakete an Geräte im lokalen Netz (sog. Gratuitous ARP). Betroffene Geräte glauben dann, der Weg ins Internet führe über den Angreifer. Dieser leitet dann den Verkehr an den echten Gateway weiter, so dass die normale Funktionalität erhalten bleibt. Wie beim vorigen Angriff kann wiederum der gesamte Datenfluss mitgelesen und auch verändert werden. Programme für diesen Angriff sind im Internet verfügbar.
In 2012 wird das ganze noch viel einfacher: Mit der Spionage-Software "WhatsApp Sniffer" können Unbefugte den
gesamten WhatsApp-gebundenen Datenverkehr einsehen: versendete und
eingehende Textnachrichten, Bilder und Videos. Dies sei besonders einfach
möglich, wenn Anwender über öffentlich zugängliche WLANs kommunizieren,
etwa an Bahnhöfen, Flughäfen oder in Cafés. "WhatsApp Sniffer" auf Android leitet den gesamten Netzwerkverkehr im lokalen Netz mittels
ARP-Spoofing durch das Smartphone und analysiert diesen im Hinblick auf WhatsAppWhatsApp-Nachrichten. Das ist ähnlich zu der App "DroidSheep", mit der man Sitzungen von Facebook und anderen Webdiensten kapern kann.
DNS basierte Angriffe
Ein ähnlicher Angriff findet im Laufe 2013 auf ungeklärte Weise regelmäßig statt: Datenverkehr-Umleitungen auf den Hauptwegen des Internets, durchgeführt über falsche BGP (Border Gateway Protocol) Announcements. Inner-amerikanischer Datenverkehr wurde über Weißrussland oder Island geführt und die unverschlüsselten Anteile konnten dort analyisiert werden. Die Hintergründe sind unklar, hier weitere Links.
Ein Angriff basiert auf DNS Cache Poisoning. Dabei werden auf Grund von Verwundbarkeiten von DNS-Servern Zugriffe zu einzelnen Websites und manchmal sogar ganze top-level-domains wie .com auf einen falschen Server umgeleitet. Dieser leitet dann den Verkehr an die korrekten Webserver weiter, der Kunde merkt außer einer Verzögerung nichts. Derzeit wird der Angriff hauptsächlich dafür verwendet, dass der Rechner des Kunden auf Pay-per-Click Websites weitergeleitet wird, z.B. Google Adwords. Aber damit lassen sich auch Verbindungen zu Internetbanken umleiten und ausnutzen. Der Kunde hat keine wirkliche Möglichkeit, sich dagegen zu schützen und auch der angewählte Webserver kann sich nicht verteidigen, der Angriff findet in der Infrastruktur des Internets statt. Die Angriffe ließen sich verhindern, wenn alle Betreiber von DNS-Servern diese auf den letzten Stand bringen würden.
2015 wird bekannt, dass die NSA nicht die einzigen sind, die "packet-injection" oder man-on-the-side Angriffe verwenden. Bruce Schneier schreibt darüber unter Democratization of Cyberattack - jede etwas fortgeschrittene Regierung kann das, und für die anderen bietet z.B. Hacking Team so was auch zum Kauf an.
Er erwähnt da auch, dass auch die SS7 Abhörtechnologie weltweit zum Kauf angeboten wird. Jeder Diktator kann so seine Bürger überwachen oder der Mafioso seine Konkurrenten. Bruce Schneiers Punkt: Schwachstellen die auf Wunsch der NSA irgendwo eingebaut werden, werden dann von anderen Angreifern auch ausgenutzt, wir werden alle unsicherer.
China muss so etwas nicht zukaufen, sie haben die Great Cannon of China entwickelt. Sie steht netztechnisch nahe beim Great Firewall of China und "sieht" den gesamten Datenverkehr nach China rein und von China raus will. Im Gegensatz zur Firewall wird hier nicht blockiert, sondern wie bei QUANTUM der NSA, werden Daten eingefügt. Eingesetzt wurde das Tool im März 2015 als Denial of Service Tool gegen Websites in den USA (siehe Man-on-the-Side Angriffe aus China auf GitHub), aber genauso lassen sich auf diese Weise auch sehr leicht PCs infizieren. Die Details hier.
Die Man-on-the-Side Angriffe (der NSA und von anderen)
Man-on-the-Side ist eine spezielle Variante von Angriffen die von der NSA im Rahmen ihrer QUANTUM-Aktivitäten benutzt werden - genutzt für Fälle, in denen sie sich nicht direkt als Man-in-the-Middle in den Datenverkehr einschleusen wollen. Diese Variante hat den Vorteil, dass der Benutzer keine Verzögerungen im Datenverkehr sieht, denn der wird gar nicht unterbrochen, sondern nur "ergänzt". Das geht mittels Packet Injection.
Nachdem die NSA in der Lage ist, mehr oder weniger beliebig die Knotenpunkte im Internet anzuzapfen haben sie an diesen Knotenpunkten Rechner aufgestellt, die zum sog. QUANTUM Programm gehören. Das Programm ist recht clever und eignet sich nicht nur für Abhören, sondern auch für die Übernahme der Zielrechner.
Der sog. QUANTUM-Rechner der NSA steht "neben" dem Datenstrom, d.h. er unterbricht ihn nicht wie bei einem Man-in-the-Middle Angriff, er fügt in den Datenstrom von der legitimen Website zum Browser des Opfers zusätzliche Datenpakete ein. Dies kann z.B. zusätzlicher HTML-Code sein, der den Browser auf andere Websites lenkt.
Die weiteren Details finden sich auf meiner Seite zum Thema Abhören und NSA.
Mein Vorschlag: einstellbarer Paranoia-Level für jeden Bankkunden
Der derzeitige (2020) Stand bei der Absicherung des Internetbankings ist, dass zentrale Vorschriften erlassen werden, welches Sicherheitsniveau ALLE Banken implementieren müssen. Es gibt aber Menschen wie ich, die gern ein etwas höheres Niveau hätten und die dafür auch kleine Unbequemlichkeiten in Kauf nehmen würden.
Am liebsten wäre es mir, wenn ich meinen "Paranoia-Level" einstellen könnte. D.h. wenn die Bank mir die Option anbieten würde, dass ich sagen kann, unter welchen Bedingungen (z.B. Betragshöhe oder Konto auf das von meinem Konto noch nie überwiesen wurde) ich z.B. eine Verzögerung um 24 Std. und eine Benachrichtigung per E-Mail und/oder SMS mit Stornierungsmöglichkeit wünsche. Die Seite auf der der Benutzer seine Wünsche einstellen kann könnte dann z.B. so aussehen:
Hier das Beispiel solcher Funktionalität wie sie bei der DBS-Bank in Singapur wirklich verwendet wird
Ein verwandtes Thema ist Phishing, d.h. elektronische Angriffe gegen Bankkunden. Der Artikel "Die Phishing Misere" stellt ausführlich dar, wie die Angreifer heute auch mit SMS-TANs umgehen können - vorausgesetzt der Kunde ist ein wenig unaufmerksam. Ebenfalls sehr relevant sind die Überlegungen zu Haftungsfragen.
Copyright-Hinweis:
Das Copyright des Materials auf diesen Webseiten liegt, falls kein anderer Autor genannt wird, bei Philipp Schaumann. Diese Texte sind lizensiert unter der Create Commons Attribution-Noncommercial-Share Alike 2.0 Austria Lizenz. Natürlich gelten auch die Regeln des Fair Use und über Ausnahmen bzgl. der Lizenz kann jederzeit mit den Autoren gesprochen werden.
