Inhaltsübersicht

• Was ist ein Man-in-the-Middle?
• Man-in-the-Middle Techniken
• DHCP basierende Angriffe
• ARP Cache Vergiftung
• DNS basierende Angriffe
• Vorspiegelung eines WLAN Access Points
• Man-in-the-Browser
• Man-in-the-Mobile
• Human-Assisted Angriffe
• Schutzmöglichkeiten- 2 Kanäle sind nötig
• Stichwort: Paranoia-Level
• Weitere Informationen

 

 

Man-in-the-Middle Angriffe

Überarbeitet September 2011

Was ist ein Man-in-the-Middle?

Man-in-the-Middle-Angriffe sind Methoden, 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.

Klarstellung 2011: In 2006 hatte ich geschrieben, dass die damaligen Phishing Angriffe (noch) simpler sind als diese hier beschriebenen Angriffe. Das stimmt heute (2011) leider nicht mehr. Die technischen Man-in-the-Middle Angriffe die im ersten Teil beschrieben werden funktionieren immer noch (z.B. sehr leicht in WLAN-Umgebungen), sind aber ergänzt worden durch und Human Assisted, zum Teil verbunden mit Abfangen der SMS. Diese modernen Angriffsformen können besser mit SMS-TANs umgehen.

In 2011 gibt es immer noch Phisher, die das Look-and-Feel der Bank-Website auf ihrem eigenen Webserver imitieren und die Interaktion mit dem Kunden selbst durchführen. Aber Man-in-the-Browser Angreifer brauchen keine gefälschten Webserver mehr, sie reichen die Daten vom Kunden-Brwoser direkt zum Bankserver durch.

Und noch ein Punkt: Man-in-the-Middle kann nicht nur für finanziellen Gewinn eingesetzt werden. Wegen der zunehmenden Bedeutung des Internets auch für die Politik setzen es mehr und mehr auch Regierungen ein und bei ihren Bürgern mitzulesen. Die NYT berichtet im August 2011 dass der Iran offenbar Google-Web-Zertifikate gefälscht hat und daher den Datenverkehr zu gmail mitlesen kann. Aber nicht nur Google war von diesen Angriffen betroffen.

Angriffe müssen für den Angreifer skalierbar sein

Es sind ganz verschiedene Angriffsformen rund um das Man-in-the-Middle-Konzept denkbar. Wichtig ist für den Angreifer, dass "der Angriff skaliert". Damit ist gemeint, dass der Angriff automatisiert und wie am Fließband ausgeführt werden kann (Ausnahme: eine Regierung will 1 bestimmten Opositionellen überwachen). Ein Beispiel für Skalierung: 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: 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.

Bei der Bewertung von solchen Schutzmaßnahmen ist deshalb zu berücksichtigen, dass mit beliebig hohem Aufwand jede Schutzmaßnahme ausgehebelt werden kann (notfalls kann man jemanden bestechen), aber wenn die Schutzmaßnahme erreicht, dass der Angriff "nicht skaliert", dann ist das in der Regel im Bereich Internetbanking ausreichend.

April 2006: heise.de berichtet über eine Bande in Deutschland, die über Banken-Trojaner gearbeitet hat (d.h. Man-in-the-Middle auf dem Rechner des Kunden) und auf diese Weise PIN und TAN ausgespäht hat.

Juli 2006: der erste Angriff mittels Trojaner in Österreich. Details dazu auf ARGE Daten. Es ist noch unklar, wie der Trojaner auf den betroffenen Rechner kam, aber das Programm wartet darauf, dass der Benutzer sich mit Raiffeisen, Erste/Sparkassen oder Bawag/PSK verbindet. Dann tauscht er einzelne Teile der angezeigten Websites aus (Frames), lässt den Rahmen aber intakt. D.h. der Benutzer sieht weiterhin das geschlossene Vorhängeschloss und das Zertifikat ist auch das echte. Der Kunde kann den Angriff daran merken, dass er unvermittelt aufgefordert wird, 4 TANs einzugeben. (Wenn eine Website Frames einsetzt, kann auch über Zertifikat nicht sicher gestellt werden, dass alle Teile der Website echt sind).

ARGE Daten berichtet, dass die Angreifer professionell vorgegangen sind: Seit Ende Juni wird Österreich massiv mit Mails überschwemmt, in denen leichte Tätigkeit und hoher Gewinn für einfache Finanzmanagertätigkeit versprochen wurde. Dabei geht es darum, dass die Phisher zuerst sicher stellen wollen, dass sie genügend "Dumme" für die Geldwäsche gefunden haben, die für sie bluten müssen (und notfalls in Gefängnis gehen).

Ein "klassicher" Man-in-the-Middle Angriff, z.B. in einem öffentlichen WLAN

Solch ein Angriff wie links gezeigt ist für die Bank und für den Benutzer transparent. 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 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 (wer weiß überhaupt, wie man ein Zertifikat überprüft). Dort finden sich auch Beispiele, wie Phisher es recht leicht geschafft haben, sich gültige Zertifikate von mehr oder weniger renomierten Anbietern erstellen zu lassen.

Jan.2007: 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.

Okt. 2007: Die Schweizer Melde- und Analysestelle Informationssicherung (Melani) berichtet: "klassische“ Phishing-Angriffe per E-Mail mit der Aufforderung Passwörter einzugeben, haben in der Schweiz stark abgenommen. Zudem waren alle erfolglos. Dafür haben erfolgreiche Angriffe mit Malware zugenommen. Zwei-Faktor-Authentisierungssysteme (z.B. Streichlisten, SecurID, usw) bieten keinen Schutz gegen solche Angriffe und müssen als unsicher betrachtet werden, sobald der PC des Kunden mit Malware verseucht worden ist".

Sie berichten von Vorfällen, in denen sich ein solches Schadprogramm im Browser einnistet und dort vor der verschlüsselten Übertragung der Überweisungsdaten Namen und Kontonummer des Empfängers und auch den Betrag manipuliert. Selbst die Bestätigung der Bank wird abgefangen und falsch angezeigt. Sie berichten dass die Infektion sehr einfach ist: "Als Infektionsweg stark zugenommen haben Webseiten, bei deren Besuch Malware ohne Dazutun des Benutzers auf dem Rechner installiert wird (Drive-by-Infektion). Dabei werden Sicherheitslücken im Betriebssystem, im Browser oder in einer anderen Applikation ausgenützt. Längst geschieht dies nicht mehr nur auf dubiosen, sondern auch auf (kompromittierten) seriösen und bekannten Seiten. Die Erkennungsrate der Malware durch Antiviren-Software bleibt tief."

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 - technische Angriffe im Netz

Um andere Techniken verstehen zu können, muss man wissen wie ein Webbrowser den Webserver eigentlich findet. Nehmen wir ein konkretes Beispiel: Jemand ist mittels Telefon-Modem, 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. Wenn der Benutzer sich übers Telefon einwählt, so kann ihm jemand die Telefonnummer geändert haben. Dies passiert relativ oft, das sind nämlich Dialer-Angriffe. Die werden aber bisher fast immer dazu genutzt, um über die Telefongebühren der dabei untergeschobenen Mehrwertnummern Geld zu verdienen. Aber sie sind auch als klassische Man-in-the-Middle Angriffe möglich.

Einen sehr guten technischen Überblick über Man-in-the-Middle Angriffe gibt es auch bei heise.de.

DHCP basierende Angriffe

Die nächste Methode wäre, DHCP-Server zu spielen, was in einem Kabelnetz sehr leicht ist. 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.

Hier finden sich übrigens die Passworte für die Netzwerkgeräte:

http://www.phenoelit.de/dpl/dpl.html
http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
http://www.virus.org/default-password/

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.

DNS basierende Angriffe

Ein Angriff, der seit Mitte März bis heute immer noch läuft (Mitte April) 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.

Hier die Dokumentation von Man-in-the-Middle Angriffen im Anonymisierungsnetzwerk TOR (vor dessen Nutzung daher eher abgeraten wird, Experten empfehlen lieber JAP und AN.ON. Der Autor hat die Angriffe mit einem cleveren Trick entdeckt, er hat seinen eigenen SSL-Webserver angesurft und dann geschaut, welches SSL-Zertifikat der Webbrowser anzeigt. Und das war in einem von 10 untersuchten Fällen nicht sein eigenes. D.h. jemand, der einen TOR Exitknoten betreibt, hat dort einen SSL-Proxy installiert und dabei entsteht dann wieder ein neues Zertifikat. Entdecken kann man daher solche Angriffe, genau wie hier beschrieben, durch Prüfung des SSL-Zertifikats (wie das geht, steht weiter oben. Und mehr über TOR und Onion-Routing schreibt Bruce Schneier.

Vorspiegelung eines WLAN-Access Points

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 und 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 Kunden 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.

Ablauf beim Man-in-the-Browser Angriff

Man-in-the-Browser

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.

Diese Angriffe können, wie ich in dem Einschub weiter oben aufgezeigt habe, auch SMS-TANs austricksen.

"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 Angriffe

Eine Methode, die ab 2009 immer häufiger zu beobachten ist erfordert einen Angreifer, der gleichzeitig wie der Kunde aktiv ist. Es findet ein "konventioneller" MITM-Angriff nach einer der oben beschriebenen Methoden statt, aber im Augenblick wenn der Kunde sich mit der Bank verbindet, 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.

Man-in-the-Mobile Angriffe

Und wenn der Angreifer auch noch auf dem Handy sitzt

heise.de berichtet Ende 2010 vom ersten Auftreten einer Zeus-Bankentrojaner-Version, die auch mit SMS-Tan umgehen kann. Zum Glück erfordert dieser Angriff noch eine recht aktive Mitarbeit des Opfers und funktioniert auch nur für Smartphones mit Symbian und Android. Hier ein Artikel im Register zum gleichen Angriff: ZeuS attacks mobiles in bank SMS bypass scam.

Der Ablauf des Angriffs auf die SMS-TAN wird in einer ausführlichen Analyse von s21sec.com dargestellt:

1. Der Angreifer infiziert den Rechner des Opfers, setzt sich in den Browser (z.B. als browser-helper-object) und hat damit Zugang zu Benutzername und Passwort des Benutzers

2. Die Software fordert den Benutzer auf, bei seinem Rechner seine Handynummer einzugeben (angebliche Verifizierung durch die Bank). Einige Zeit später sendet der Angreifer eine MMS an das Handy und behauptet, die Firmware des Handys müsste aktualisiert werden. In der MMS ist ein Link zu der Infektionssoftware für das jeweilige Handy.

3. Der Benutzer muss an seinem Handy auf diesen Link klicken und die Software aktiv installieren.

4. Jetzt ist der Angreifer bereit. Er kann bei der nächsten Netbanking-Sitzung des Opfers bei einer Überweisung Betrag und Empfängerkonto verändern.

5. Dann warten das Opfer und der Angreifer auf die SMS-TAN. Das infizierte Handy zeigt die TAN nicht an, sondern leitet sie weiter an den Angreifer, der damit die gefälschte Zahlung bestätigt.

6. Das Opfer wartet weiter auf die SMS, die aber nicht kommt. Er bricht vermutlich diese Transkation ab und versucht es noch einmal. Moderne Bankentrojaner sind in der Lage den Kontostand der jetzt eigentlich die Betrugs-Transaktion zeigen sollte, so zu verändern, dass es für das Opfer so aussieht, als ob die Transaktion gar nicht stattgefunden hätte. D.h. der Kontostand ist genau wie vor dieser Transaktion und der Benutzer schöpft keinen Verdacht. Auch die Überweisung selbst wird im Browser des Benutzers nicht angezeigt.

Im Februar 2011 wird ein Trojaner für Windows Mobile entdeckt: Hier eine Analyse eines Angriffs gegen die polnischen Kunden der ING-DIBA: ZeuS in the Mobile is back (mit Code-Analyse)

Der Screen den der Benutzer nach der Installation des angeblichen Zertifikats sieht - Quelle und ausführliche Analyse: www.f-secure.com/

Aktualisierung April 2011:

Jetzt gibt es erste deutsch-sprachige Versionen von solchen Angriffen: Angriffe auf deutsche mTAN-Banking-User.

Der Angriff läuft so ab (und funktioniert in dieser exakten Form nur für Nokias mit Symbian OS): Zuerst muss der PC des Kunden infiziert werden, dies ist erheblich einfacher als ein Handy zu infizieren. Wenn der Kunde auf das Netbanking (dieser deutschen Bank) geht erscheint ein zusätzliches Fenster, das die Handynummer und die IMEI, d.h. die interne Kennung des Handys abfragt. Dann wird angekündigt, dass die Bank ein Zertifikat für das Handy installieren muss.

Nun lässt sich der Angreifer auf einer chinesischen Website ein Zertifikat für Symbian erstellen. Damit dieses Zertifikat keine Fehlermeldung erzeugt muss in diesem Zertifikat die IMEI des Handys eingetragen werden, daher die ungewöhnliche Abfrage. Wenn das Zertifikat fertig ist, wird damit die Schadsoftware signiert, die dann auf dem jeweiligen Handy installiert werden kann. Kurze Zeit später erhält der Kunde eine Nachricht mit dem angeblichen Installer für das Zertifikat (der aber in Wirklichkeit die Schadsoftware ist die das SMS abfängt). Startet er diesen Installer, erscheint die deutschsprachige Nachricht: "Die Seriennummer des Zertifikats: 88689-1299F"

Die gute Nachricht ist, dass bei allen bisherigen Angriffen (Stand Mitte 2011) der Kunde aktiv mithelfen muss, d.h. der Angreifer muss den Kunden reinlegen und zur Mithilfe bringen. Andererseits befürchte ich, dass dies durchaus in vielen Fällen gelingen wird. Ein weiterer Aspekt ist, dass diese Angriffe nicht gut "skalieren". D.h. sie sind bisher nicht flächendeckend möglich. Der Angreifer muss einen PC infizieren dessen Kunde zufällig ein Handy mit passendem Betriebssystem hat. Aber dies sind ja auch erst die ersten Versuche auf diesem Gebiet.

Ein Artikel Herbst 2011 zu SpyEye attackers turn to Android phones to steal SMS messages zeigt den aktuellen Stand des Phishings auf. Hintergrund dieses Artikels ist, dass Android jetzt Symbian als beliebtestes Ziel von solchen Angriffen ablöst. Der Grund ist, dass es extrem einfach ist, beliebte Apps für Android zu analysieren, Schadcode einzubauen und auf einen der vielen Androids-Markets hochzuladen. McAfee berichtet von sie täglich 55000 neue Formen von Malware für Android finden, fast alles Variationen von beliebten Apps. Die schlechte Nachricht ist, dass in diesem Fällen der Kunde selbst aktiv mithilft, die Schadsoftware zu installieren. Dagegen ist nur wenig Schutz möglich.

Schutzmöglichkeiten - 2 Kanäle sind nötig

(überarbeitet Herbst 2011)

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.

[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 und das wäre deutlich sicherer. Statt einfach bei amazon.com einkaufen zu können, müsste ich vorher auf einem anderen Wege mein Zertifikat 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.

Ein anderes Konzept das z.B. in der Schweiz zum Teil eingesetzt wird hier dargestellt: Breaking out of the browser to defend against phishing attacks . Es ist das Konzept eines speziellen Browsers, der gar keine Adresszeile mehr hat und automatisch und sicher auf die gewünschte Website findet. Wenn entsprechende Zertifikate fest eingebaut sind, so kann auf diese Weise auch sichergestellt werden, dass kein Man-in-the-Middle sich einmischt. Dieser spezielle Browser müsste auf einem read-only Speicher, z.B. einer CD verteilt werden und akzeptiert keine Plug-ins, d.h. auch keine Man-in-the-Browser.

Ein Angriff mittels Trojaner setzt einen infizierten PC voraus (davon gibt es aber reichlich) und ist von der Programmierung her etwas aufwendiger. Die Angreifer konnten 2006 noch beliebig viel Geld mit den simplen Angriffen verdienen. Der Bericht der Melde- und Analysestelle Informationssicherung (MELANI) in der Schweiz berichtet jedoch bereits im Halbjahresbericht II/2006 über einen Trend zum Man-in-the-Middle Angriff, entweder über client-seitige Malware, über eine logische Umleitung z.B. über DNS-Angriff oder auch durch sofortige Weiterleitung aller Benutzereingaben von der gefälschten Website zur korrekten Website (der Client des Anwenders baut eine SSL-Verbindung zur falschen Website auf und diese wiederum eine SSL-Verbindung zur richtigen. heise.de berichtete 2006, dass der Engpass die Geldkuriere sind.

Die Banken haben dann mTAN (SMS-TAN) eingeführt und stark beworben und die arbeitet damit, dass es 2 getrennte Kanäle gibt, die der Angreifer nur schwer gemeinsam kontrollieren kann:

• 1. Kanal: der PC hat eine Verbindung über das Internet, entweder über Modem, Kabel oder xDSL

• 2. Kanal: das Handy kommuniziert über das Mobilfunknetz in Form eines SMS

Leider ist auch dieses Konzept nicht 100% sicher, denn wie ich oben im Kapitel Human-Assisted gezeigt habe setzt das Sicherheitskonzept voraus, dass der Kunde das SMS liest, versteht und entsprechend reagiert, d.h. bei einer falschen Kontonummer den Vorgang abbricht.

Das nächste Problem mit diesem Schutzkonzept liegt darin, dass viele Kunden heute ihre Bankgeschäfte mittels Smartphone erledigen und damit bricht das 2-Kanäle-Konzept zusammen. Ein infiziertes Smartphone bietet nur noch 1 Kanal, denn das SMS kann heute von entsprechender Banken-Malware leicht abgefangen werden und an den Angreifer weitergeleitet werden (siehe voriges Kapitel). Der Kunde sieht nur noch, dass das erwartete SMS mit dem mTAN nicht ankommt. Jetzt müsste er sehr schnell den Helpdesk der Bank anrufen und die Überweisung stoppen.

D.h. E-Banking auf einem Smartphone bei dem Apps (oder andere Software) von unbekannten Quellen installiert wurde kann nicht wirklich sicher gemacht werden. Es fehlt die Unabhägigkeit der Datenkanäle.

Dez. 2009:
Im Secorvo Newsletter Nov.09 wird auf eine formale Analyse mit einem Vergleich von 2 Transaktionsauthentisierungsverfahren für eBanking hingewiesen: Formale Sicherheitsanalyse von Online-Banking-Protokollen (pdf.). (Nur für Leser, die keine Angst vor Gleichungen der formalen Logik haben.) Und 2009 waren die Smartphones noch nicht die große Bedrohung für das sichere E-Banking.

Stichwort: Paranoia-Level

Ein englischer Artikel, der dahin zielt, dass die Transaktion der eigentlich kritische Schritt ist und nicht so sehr das Login des Kunden und der in die Hier der Link zu einem interessanten Artikel, der m.E. in die richtige Richtung geht, indem er von der Bank erwartet, dass sie in ihrem Back-End Plausibilitätsmaßnahmen einführt: Gone Phishing...

" . . . . When something goes wrong, the bank will tell you that you "authorised" the transaction, where in fact the party who ultimately "authorised" it is the bank, based on the information they chose to take as evidence that this transaction is the genuine desire of a legitimate customer. The problem is, right now the only information they are basing this decision on is a username and password. What they apparently don't realise is that they have access to a huge amount of other information that can help to determine whether this is _really_ what the customer wants. Some of this information is immediately available with each transaction, and some can be readily inferred from historical context. The bank has access to all of it, and the more you use the system, the _harder_ it should be for a thief to take your money. ...." - D.h. Plausibilitätsprüfungen, wie es bei den Kreditkartenfirmen bereits seit langer Zeit üblich ist.

Und die Banken haben viel genauere Informationen, z.B. die IP-Adresse(n) von denen der Kunde normalerweise arbeitet. Wenn der Kunde jetzt von einer neuen IP-Adresse kommt, so kann sie über whois prüfen, in welchem Land die registriert ist. Sie weiß auch, ob der Kunde bisher bereits Überweisungen ins Ausland getätigt hat. Und es sollte ihr auffallen, wenn auf einmal ganz viele unterschiedliche Kunden von der gleichen (neuen) IP-Adresse (irgendwo im Ausland) zugegreifen und diese Kunden alle auf das gleiche Konto überweisen wollen (evt. sogar ein Konto im Ausland, aber das muss nicht sein).

Wenn mehrere solche ungewöhnliche Fakten zusammentreffen, so hätten wohl die meisten Kunden Verständnis, wenn die Überweisung nicht sofort ausgeführt würde, sondern die Bank über Telefon, E-Mail oder auf anderem Weg eine Klärung herbeiführt. Er macht noch einen Vorschlag, eine Technik, die bei Amazon.com üblich ist. Die schicken die Bücher nicht sofort, sondern mit einer Verzögerung. Sie schicken aber sofort eine Bestätigung per E-Mail. Und ich habe bis zum Versand noch Zeit, den Auftrag zu stornieren. Genauso könnte eine Bank als Option anbieten, dass Überweisungen erst nach 24 Stunden rausgehen. Das gibt dem vorsichtigen Kunden 24 Stunden zum Stornieren von falschen Überweisungen. Das braucht nicht mal für alle Überweisungen zu sein, ich würde z.B. die Überweisungen in meinen Vorlagen davon ausnehmen. Aber wenn ich eine neue Vorlage erzeuge oder keine Vorlage verwende, so entsteht eine 24 Std. Verzögerung mit E-Mail-Benachrichtigung und Stornierungsmöglichkeit.

Ergänzung 27.10.2006: Ein interessanter Artikel aus den USA berichtet, dass die Banken bis zum Ende 2006 eine Verbesserung der Internet-Transaktionen implementieren müssen. Naheliegend ist für viele Banken die Einführung von Sicherheitstokens (entweder Smartcards oder One-Time-Passwort (OTP)-Geräten), aber in dem Artikel wird ebenso diskutiert, dass ein gezieltes Absichern im Fall eines ungewöhnlichen Verhaltens des Kunden aufscheint (verglichen mit wie er sich sonst online verhält, neues Schlagwort dazu: "risk-based authentication"). Dies ist ebenfalls mein Vorschlag.

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 ich 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:

Und hier ein Beispiel, das die DBS-Bank in Singapur wirklich verwendet:

Weitere Informationen zu Phishing

Hier gibt es mehr über die Internetkriminalität hinter den Phishing Angriffen. Ebenfalls sehr relevant sind die Überlegungen zu Haftungsfragen.

Eine ganze Reihe von Vorschlägen, wie Phishing erheblich erschwert werden könnte, finden sich am Ende der Glosse zur Problematik, wer eigentlich Schuld an der Phishing-Misere ist.

Philipp Schaumann, http://sicherheitskultur.at/

Home

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.