Home      Themenübersicht / Sitemap      Notizen      Webmaster      

 

Ein verwandtes Thema ist Phishing, d.h. elektronische Angriffe gegen Bankkunden und gegen alle Arten von Internet-Accounts.

Der Artikel "Die Phishing Misere" 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.

Man-in-the-Middle Angriffe

Autor: Philipp Schaumann - Letzte Änderungen: Jan. 2016

Ergänzt 2012 in Bezug auf Man-in-the-Mobile und 2013 bzgl. Man-in-the-Middle bei HTTPS-Verbindungen und 2013/2014 die NSA Angriffe.)

Was ist ein Man-in-the-Middle?

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.

Newsletter Abo

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.

    Klarstellung 2011:
    In 2006 hatte ich geschrieben, dass die damaligen Phishing Angriffe (noch) simpler sind als diese hier beschriebenen Angriffe. Das stimmt seit 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 auch sehr gut mit SMS-TANs umgehen.
Link-Konventionen:
Fette Links öffnen ein fremde Seite in einem neuen Fenster
Blau hinterlegte Links bleiben auf der sicherheitskultur.at

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.

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

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

    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 Angriffe bei HTTPS Verbindungen

    Im folgenden Text 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.

     

     

     

    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.

    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 (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.

    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.

    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 basierende 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, 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 falschen 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 (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.

     

     

     

    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.

     

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

     

     

     

    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.

     

    April 2015: The Great Cannon of China
    Jetzt gibt es Man-on-the-Side Angriffe aus China auf GitHub. Und zwar werden diese für Denial of Service genutzt. D.h. die Angreifer hängen sich in den legitimen Verkehr von Nutzern hinein. Dies fällt den chinesischen Behörden sehr leicht, denn durch den Great Firewall of China oder "GFW" hängt die Regierung quasi eh in jeder Auslandsverbindung drin.

     

     

     

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

     

    Angriff mit Fernsteuerung - Neverquest

    Es gibt noch weitere Variationen solcher Angriffe. Der Trojaner Neverquest installiert eine Fernwartungssoftware auf dem PC des Opfers und kann daher nicht nur die Zugangsdaten das Benutzers abgreifen, sondern sich gleich auf diesen Rechner verbinden und von diesem Rechner aus die betrügerischen Überweisungen durchführen. Das hat für den Betrüger den großen Vorteil, dass für die Betrugserkennungssysteme der Banken der Angreifer vom richtigen PC kommt, die gleiche IP-Adresse hat wie immer und dass es keine Hinweise gibt, dass irgendwas nicht stimmt.

    Hier noch mehr technische Details zu Neverquest.

     

     

     

    Man-in-the-Mobile Angriffe

    Und wenn der Angreifer auch noch auf dem Handy sitzt

    Aktualisierung März 2012:
    Sehr clever gemacht: Der Angreifer sitzt überhaupt NUR auf dem Mobile und die Banken haben eigentlich wenig Möglichkeit, in ihrem Bereich dagegen was zu tun. So läuft es:

    Die Angreifer stellen in geeignete App-Stores Software, die behauptet ein "Token-Generator" (was auch immer das sein soll) für die jeweilige Bank zu sein. Wenn die App dann installiert ist, so fragt sie nach Verfüger und Passwort und berechnet dann irgendeine Zufallszahl. Dann wartet sie, bis auf dem Handy eine SMS-TAN eingeht (sie kennt die Absendernummer) und leitet alle diese zukünftigen SMS von der Bank an den Programmierer der App weiter. Und der kann in aller Ruhe das Konto abräumen.

     

    heise.de berichtete 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:

    • 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
    • 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.
    • Der Benutzer muss an seinem Handy auf diesen Link klicken und die Software aktiv installieren.
    • Jetzt ist der Angreifer bereit. Er kann bei der nächsten Netbanking-Sitzung des Opfers bei einer Überweisung Betrag und Empfängerkonto verändern.
    • 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.
    • 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.

     

    Aktualisierung Juli 2012:
    Aktuelle kombinierte Angriffe 2012 gegen PCs und Android Smartphones: Android Trojan attacks SMS smartphone bank security, mit vielen Screenshots und Details von den Angriffen. Die Angriffe laufen in Deutschland, Niederlande, Portugal und Spanien.

     

     

     

    Schutzmöglichkeiten gegen elektronischen Bankraub - 2 Kanäle sind nötig

    Dez. 2015:
    Die Presse berichtet über das neue Push-TAN Verfahren das eine ganze Reihe von deutschen Banken einsetzen. Dabei sind 2 Apps auf dem Smartphone, die eine macht wie bisher die Überweisung, die andere empfängt die TAN und reicht sie an den Überweisungs-App weiter.

    Dass das keine gute Idee ist berichtet die Presse und zeigt ein junger Forscher auf dem 32. Chaos Computer Club Event: (Un)Sicherheit von App-basierten TAN-Verfahren im Onlinebanking. Auch wenn es etwas unbequem sein sollte: Nur bei der Nutzung von 2 getrennten Geräten ist die Überweisung sicher (z.B. PC und Smartphone oder Handy, PC oder Smartphone und separater TAN-Generator). Auch die Finanzaufsicht (bis zum Europäischen Zentralbank) schreiben getrennte Geräte vor.

    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.

    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.

     

    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

    Allerdings liese sich mittels einer Smartcard sehr wohl eine auch gegen Man-in-the-Middle sichere Implementierung bauen: Wichtig ist, dass die Transaktion selbst mit einer digitalen Signatur versehen wird und zwar muss diese Signatur so erstellt werden, dass auch ein Trojaner auf dem PC des Benutzers in diesen Prozess nicht eingreifen kann.

    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:

    Um auch bei infizierten PCs geschützt zu sein muss die Bank in dem SMS nicht nur den TAN-Code senden, sondern auch die Kontonummer des Zielkonto. Ansonsten kann der Angreifer auf dem infizierten PC die Zielkontonummer ändern und die Überweisung durch den Kunden bestätigen lassen.

    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.

    Social Engineering Angriffe

    Dez. 2013: Bei aller technischen Absicherung sind immer Social Engineering Angriffe möglich. In 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.

     

     

     

    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:

    Hier das Beispiel einer 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.

     

    Weitere Informationen

    Hier gibt es mehr über die Internetkriminalität hinter den Phishing Angriffen und hier zu Internetkriminialität.

     


     

    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. Creative Commons License
    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.