Ausgefischt Serverseitige Phishing-Erkennung ergänzt Client-Maßnahmen

Ordnungsmerkmale

erschienen in: <kes> 2006^#6, Seite 26

Rubrik: Management und Wissen

Schlagwort: Betrugsabwehr

Schlagwort-2: Phishing

Zusammenfassung: Phishing-Angriffe zielen im Kern auf die Wahrnehmung(sschwächen) von Technik durch den Benutzer. Deshalb setzen die meisten Anti-Phishing-Maßnahmen auf der Nutzer-Seite an. Aber auch Betreibern "echter" Websites stehen effiziente Mittel zur Verfügung, um Phishing-Attacken frühzeitig zu erkennen und den damit verbundenen Schaden zu minimieren.

Autor: Von René Reutter, Darmstadt

Phishing ist letztlich eine moderne Form des Trickbetrugs: Ein Betrüger lockt meist im ersten Schritt einen arglosen Anwender per E-Mail auf eine gefälschte Web-Seite (Angriffsinitialisierung), erst danach folgt der eigentliche Angriff (Betrugsphase), beispielsweise in Form unrechtmäßiger Überweisungen vom Konto des Opfers.

Das Phishing-Problem ist im Kern ein Authentifizierungsproblem des legitimen Webservers gegenüber dem Benutzer: Der Besucher denkt vornehmlich aufgrund seines "visuellen Erfahrungsschatzes" im realen Leben, er kommuniziere direkt mit dem Server seiner Bank oder seines Online-Händlers. Leicht schickt er dann seine Eingaben an den täuschend echt nachgemachten Server eines Angreifers, da für ihn die dargestellte Web-Seite optisch nicht von der Original-Seite zu unterscheiden ist.

Angreifer täuschen dabei vielfach nur vor, man befinde sich in einer SSL-Sicherheitsumgebung (Visual Spoofing). Darüber hinaus nutzen sie oftmals aus, dass Endanwender Web-Server-Zertifikate kaum prüfen. Nur so könnten diese aber wirklich sicherstellen, dass sie mit dem "richtigen" Webserver kommunizieren (eine technisch korrekte Implementierung der SSL-Kommunikation vorausgesetzt).

Selbstverständlich war und ist auf der Seite des Clients die erste Linie der Verteidigung das "Auge des Benutzers": Es muss geschult und so gut wie möglich unterstützt werden. Leider überfordert die korrekte Überprüfung des SSL-Zertifikates aber viele Benutzer.

Auch wenn die Browserhersteller hier noch mehr tun könnten – das Problem wird man an dieser Stelle nicht endgültig lösen, da der Webbrowser ein universelles Programm für viele Anwendungen bleiben soll. Damit ist die Vertrauens-Entscheidung auf den Endanwender abgewälzt, der diese in aller Regel nicht fällen kann. Weitere Ansätze auf der Nutzerseite wurden diskutiert und vielfach auch schon umgesetzt:

Das Home Banking Computer Interface (HBCI) prüft in einem speziellen Protokoll für das E-Banking die Authentizität der Gegenstelle. Im Gegensatz zum Browser wird hier die Trust-Entscheidung an die (spezialisierte) Software übertragen und der Endanwender entlastet. HBCI ist aber im Wesentlichen nur im deutschen Markt verbreitet und hat sich selbst dort nicht flächendeckend durchgesetzt.
Sichere webbasierte Verfahren mit gegenseitiger Authentifizierung setzen den Besitz von Zusatzgeräten wie Smartcard plus Reader beziehungsweise USB-Token mit Kryptofunktionen voraus und werden von Privatkunden aufgrund der Kosten derzeit (noch) nicht im ausreichenden Maße akzeptiert.
Anti-Phishing-Tools in Browsern sind für den Benutzer leicht verständlich, basieren derzeit aber meist auf Blacklists – die Phishing-Site muss also schon erkannt und an die entsprechende Datenbank weitergeleitet worden sein, damit die Toolbars wirken.
Das inzwischen von allen Banken eingesetzte iTAN Verfahren (indizierte Transaktions-Nummer) erschwert – richtig implementiert – einen Angriff, da man mit einer abgefangenen TAN nicht mehr sofort eine Transaktion ausführen kann. Ein Angreifer könnte jedoch warten, bis er nach der "richtigen" (abgefangenen) iTAN gefragt wird.
Einmalpasswörter oder Challenge-Response-Verfahren sind der (technisch gesehen) nächste logische Schritt; hierbei kann eine einmal abgefangene Autorisierung später nicht mehr verwendet werden. Token-basierte Lösungen verursachten bislang größere zusätzliche Kosten und haben sich daher noch nicht im Massenmarkt durchgesetzt. Zudem helfen auch diese Lösungen nicht immer gegen Man-in-the-Middle-Angriffe, bei denen ein Angreifer "online" in die Kommunikation eingreift. Dennoch dürften sich moderne Zugangsschutzsysteme mit sicherer dezentraler Generierung von Einmalpassworten verbreiten, sobald für den Massenmarkt geeignete kostengünstige Verfahren zur Verfügung stehen. Der hohe Verbreitungsgrad von Handys bietet hierzu beispielsweise Möglichkeiten auf Basis von SIM-Karten.
Beim mTAN-Verfahren werden Transaktionsdaten wie Kontonummer und Betrag zusammen mit der nur für diese Transaktion gültigen (eigens generierten) TAN nochmal auf einem unabhängigen, sicheren Kanal (per SMS) zum Kunden geschickt; dieser muss dann die so erhaltene Autorisierung (TAN) im Webbrowser eingeben. Dieses Verfahren setzt jedoch den Besitz eines SMS-fähigen Endgeräts voraus.

Es gibt also bereits etliche Ansätze den Sicherheitslevel beim Internet Business – bei gleichzeitig hoher Usability – kontinuierlich zu steigern. Von der verbesserten Darstellung (Warnhinweise) wenig vertrauenswürdiger Seiten im Browser bis hin zu verschiedenen Authentifizierungs-Systemen. Zusätzlich werden bereits heute – quasi im Hintergrund – neue Verfahren eingesetzt, um Angriffe auch auf der Serverseite frühzeitig zu erkennen und Gegenmaßnahmen einleiten zu können.

Erkennung am Original-Server

Rasches Erkennen von Phishing-Attacken ist auch anhand "untypischer Interaktionen" auf und mit der Original-Website möglich. Um diese Methode zu verstehen, muss man zunächst die Motivation und das Vorgehen des Angreifers analysieren: Er möchte im Kern mit möglichst wenig Aufwand möglichst hohen wirtschaftlichen Erfolg erzielen – dazu muss er möglichst lange mit einer möglichst hohen "Trefferquote" arbeiten. Konkret bedeutet dies:

viele Phishing-Mails mit vergleichsweise kleiner Erfolgsquote oder sehr gezielte Aktionen mit möglichst genauen Zielgruppen, also potenziell hoher Erfolgsquote,
möglichst optimale Übereinstimmung der Phishing-Site mit der Ziel-Website,
möglichst kurze Verweildauer des Opfers auf der Phishing-Site nach dem erfolgreichen Angriff, um die Gefahr der Entdeckung zu minimieren.

Um die genannten Ziele effektiv zu erreichen, finden in der Regel Interaktionen zwischen der Phishing-Site und der Original-Website statt, die aus der Perspektive der Original-Website "untypisch" sind. Um diese Abwehrmöglichkeit nicht zu schwächen, können hier zwar nur einige bereits bekannt gewordene Beispiele für solche untypischen Interaktionen beschrieben werden; diese geben aber dennoch einen guten Überblick über das Prinzip.

Leistungsfähiges Security Information and Event Management mit Anomalierkennung kann für Anbieter von Online-Diensten wichtige Frühwarninfos gegen Phishing und andere Angriffe liefern.

Verlinkte Bilder von der Original-Site

Webbrowser schicken beim Anfordern einer Webseite oder eines Bildes meist den so genannten Referer (HTTP-Header) an den Server, der die Adresse (URL) der Webseite enthält, die den Link auf das aktuell angeforderte Objekt enthält. Im Falle einer Phishing-Site, die Bilder von der Original-Site lädt, kann der Original-Server anhand dieses Headers erkennen, dass ein Phishing-Angriff (oder zumindest eine "untypische Interaktion") vorliegt und Alarm schlagen. Der Betreiber kann daraufhin die mutmaßliche Phishing-Site manuell überprüfen und gegebenenfalls Gegenmaßnahmen einleiten. Es ist hierzu beispielsweise möglich, speziell aufbereitete Bilder mit Warnhinweisen auszuliefern, welche die verlinkende Phishing-Site auch einem unbedarften Webanwender gegenüber klar als Fälschung kennzeichnen.

Backlinking

Wenn Phishing-Seiten dazu übergehen, Bilder von Original-Sites zu kopieren, lassen die untypischen Interaktionen nach. Das oberste Ziel der Phisher muss aber sein, den Benutzer keinen Verdacht schöpfen zu lassen. Viele Phishing-Seiten verweisen deswegen nach erfolgreichem Abgriff der Daten wieder auf die Originalseite der Bank (oder eines anderen nachgeahmten Anbieters). Hier kann der Betreiber wie im vorgenannten Beispiel erneut den vom Browser mitgeschickten Referer auswerten und den Benutzer gegebenenfalls warnen, dass er entweder von einer bereits bekannten Phishing-Seite kommt oder zumindest von einer Webseite, die nicht der Bank gehört. Dadurch ist der Nutzer gewarnt und kann telefonisch seinen Anbieter kontaktieren und beispielsweise eine soeben abgegebene TAN sperren lassen.

Überprüfung von Entry-Points

Ein typischer Nutzer erreicht ein Online-Angebot zu Beginn einer Session meist über die Leitseite (Homepage) seines Anbieters oder über spezielle Unterseiten (z. B. Bookmark der Login-Seite). Erfolgt der "Erstkontakt" eines Nutzers über eine "tiefer liegende" Seite, so ist diese Interaktion zumindest auffällig und sollte genauer beobachtet werden.

Abfrage verschiedener Kunden-Accounts

Bei Man-In-The-Middle-Attacken gegen einschlägige Bezahldienste wird heutzutage bereits oft sofort automatisch geprüft, ob die entsprechenden Opfer-Daten auch tatsächlich als Accounts existieren – gegebenenfalls ändert ein Phisher auch gleich das zugehörige Passwort. Auffällig sind hierbei ungewöhnlich häufige Anfragen bezüglich verschiedener Kunden-Accounts, die in der Regel von einer oder wenigen IP-Adressen (Angreifer) stammen. Dies kann zwar auch durch verschiedene Benutzer eines Internetanbieters geschehen, die dessen Proxy-Server benutzen; da die Proxies der großen Anbieter jedoch bekannt sind und sich selten ändern, kann eine entsprechende Unterscheidung gegenüber vermutlichen Phishing-Sites automatisch erfolgen.

Das übergeordnete Prinzip der serverseitigen Phishing-Erkennung ist die Analyse des Webdatenverkehrs auf dem Original-Server. Mithilfe von Schwellenwert-Prinzipien kann der Betreiber dabei definieren, unter welchen Voraussetzungen er untypischen Traffic auch als gefährlich einstuft. Hierbei können Web-Application-Security-Services die Umsetzung entsprechender Richtlinien deutlich erleichtern. Moderne Datamining-Verfahren im Bereich eines leistungsfähigen Security Information and Event Management (SIEM) kommen hierbei verstärkt zum Einsatz (vgl. Abb.).

Transaktions-Screening

Im "Alarmfall" können Betreiber von Online-Angeboten ihre Nutzer wie skizziert durch leicht verständliche Hinweise von der Eingabe persönlicher Daten abhalten oder zumindest nachträglich über verdächtige Wege zur Website informieren. Dies ist jedoch nicht immer im Sinne des Betreibers, denn gerade Banken möchten keinen Image-Schaden riskieren, der oft mit aufgedeckten Phishing-Attacken einhergeht.

Ein vielversprechender Ansatz ist dann nach frühzeitiger serverseitiger Erkennung von Anomalien im Netzwerkverkehr die Ergänzung durch ein leistungsfähiges Data-Mining im Backend. So werden beispielsweise Banktransaktionen zur Risikominimierung erst dann ausgeführt, wenn die Korrektheit und Berechtigung zur Transaktion zweifelsfrei nachgewiesen ist. Zudem helfen derartige Vorgehensweisen auch gegen nachgelagerte Versuche der Geldwäsche aus Phishing-Attacken. Reaktionen wie die Weitergabe der notwendigen Informationen zur juristischen Verfolgung von Angreifern und zur Schließung der Phishing-Websites können unter Umständen gleich vom ausführenden Dienstleister angestoßen werden.

Fazit

Das Hauptaugenmerk der Phishing-Abwehr geht weg vom Trägermedium E-Mail hin zu den gefälschten Web-Seiten. Dort können auch weitere technische Angriffsmethoden wie Cross-Site-Scripting oder Frame-Spoofing besser erkannt werden, die man ebenfalls zur Klasse der Phishing-Attacken zählen kann, die sich aber mit rein browserbasierten Verteidigungsansätzen nur schwer bekämpfen lassen. Damit gewinnen die Schutzmaßnahmen auf Seiten der Website-Betreiber in Zukunft stärker an Bedeutung.

Die Phishing-Plage kann aber letztlich nur durch ein optimales Zusammenspiel aller beteiligten Instanzen eingedämmt werden: Dem Nutzer müssen die bestmöglichen Mittel an die Hand gegeben werden, die Authentizität von Original-Sites möglichst einfach zu überprüfen sowie sich für wichtige Geschäfte mit handhabbarem Aufwand sicher authentifizieren zu können. Web-Site-Betreiber müssen – in ihrem eigenen Interesse – den Netzwerkverkehr auf ihren Servern bedarfsgerecht kontrollieren und steuern sowie ihre Anwendungen möglichst auch gegen neuartige Angriffsmethoden absichern.

Dipl.-Ing. René Reutter ist Leiter Security Architektur & Portfolio bei der T-Systems, Darmstadt.