Wechselseitige Authentifizierung
Wenn der Server den Ausweis zückt
Phishing-Attacken ist allein mit einer starken Authentifizierung des Anwenders am Dienst oder Server nicht beizukommen. Auch dem Server droht Ausweispflicht - und zwar nicht gegenüber dem Client, sondern direkt gegenüber dem Anwender.
Auf der rein technischen Ebene eines Protokolls wie IPSec ist wechselseitige Authentifizierung
kein Problem: Zwei kommunizierende Rechner weisen sich dabei als gleichberechtigt voreinander aus.
Auf der Anwendungsebene allerdings, beispielsweise beim Online-Banking, kommen ganz andere Probleme
ins Spiel: Der Anwender nutzt selten immer denselben Client, um Transaktionen durchzuführen. Er
ruft von einem beliebigen Internetzugang aus eine ihm vertraute Seite auf und weist sich selber
dort mit Name und Kennwort und gegebenenfalls mit zusätzlichen Faktoren wie Smartcard oder Token
aus. Eine gleichwertige Authentifizierung in der anderen Richtung entfällt – der User muss in den
meisten Fällen darauf vertrauen, mit dem richtigen Server zu kommunizieren. Phishing-Attacken
nutzen diese Sicherheitslücke aus: Im einfachsten Fall locken sie Opfer mit einem Link in einer
Mail auf eine möglichst exakt gefälschte Website und nehmen dort die persönlichen Anmeldedaten des
Anwenders entgegen, oder sie manipulieren das Zielnetz selbst und lenken die korrekte URL auf
eigene Serverfarmen um. Zusätzliche Sicherheit ist hier nur dadurch zu gewinnen, dass sich der
Server nicht beim Client des Anwenders, sondern bei der Person zu erkennen gibt.
Serverzertifikate genügen nicht
Eine Möglichkeit, die Integrität einer bestehenden Onlineverbindung zu prüfen, ist die Kontrolle
des Serverzertifikats bei SSL-Verbindungen. Die Erfahrung hat allerdings gezeigt, dass nur wenige
Anwender in der Lage sind, typische Zertifikate immer wieder mit der gleichen Aufmerksamkeit auf
Plausibilität zu überprüfen. Ein vom Betrüger selbst ausgestelltes Zertifikat für die "Sporkasse"
statt Sparkasse von "Vorisign" statt Verisign fällt also nicht unbedingt auf, und Fehlermeldungen
werden von unerfahrenen Benutzern oft einfach weggeklickt, wenn nur die Optik der Website der
gewohnten Bankumgebung entspricht.
Dieses Verhalten resultiert aus der Lebenserfahrung in der realen Welt: Dort sind es in vielen
Fällen der Ort und bestimmte Umgebungsmerkmale, die einem Kunden die Sicherheit geben, mit der
richtigen Institution in Kontakt zu treten. Eine Bankfiliale etwa, eine Arztpraxis oder die
Geschäftsstelle einer Versicherung lässt sich in der vertrauten kulturellen Umgebung nur mit so
viel Aufwand komplett fälschen, dass das entsprechende Risiko getrost vernachlässigt werden darf.
Ebenso wenig ist zu erwarten, dass in der gewohnten Bankfiliale unbemerkt ein falscher Kassierer
agieren oder gar eine Nebenkasse aufbauen kann. Den Phishing-Tricks vergleichbar sind in der
Alltagswelt höchstens geschickte Manipulationen an Geldautomaten.
Die Optik personalisieren
Eine erste von immer mehr Lösungen adaptierte Methode, wechselseitige Authentifizierung für
Server einzuführen, nimmt deshalb direkt Bezug auf Identifizierungstechniken der Lebenswelt.
Anwendern wird in diesem Fall angeboten, mit dem Server entweder ein "Geheimnis" zu vereinbaren,
das dieser auf Wunsch anzeigen soll, oder der personalisierten Anmeldeseite mit Bildern oder Texten
eine persönliche Note zu geben. Typische Verfahren sind:
die Auswahl eines Bildes aus einer vorgegebenen Liste,
das Ablegen eines selbst geschriebenen Textes oder
das Hochladen einer persönlichen Bilddatei.
Vorausgesetzt, die entsprechenden Einstellungen werden selbst während einer nicht
kompromittierten Sitzung vorgenommen, vermag nach der entsprechenden Konfiguration nur der legitime
Server dem Anwender die ausgehandelten Texte oder Bilder anzuzeigen. Die Tatsache, dass die
vertrauten Merkmale fehlen oder nicht stimmen, fällt dem Anwender im Fall eines Angriffs deutlich
schneller auf als unscheinbare Abweichungen in einer ohnehin recht kryptisch wirkenden
Zertifikatsanzeige.
Ein Angreifer wiederum müsste entweder Zugang zum echten Server und dort zum Speicherbereich des
Zielkunden erhalten, um die personalisierte Optik nachgestalten zu können, oder in der Lage sein,
eine Sitzung aus der Sicht des Anwenders mitzuverfolgen – beides ist mit immerhin so viel Aufwand
verbunden, dass es den Großteil der kommerziell interessierten Angreifer abschrecken dürfte.
Allerdings sind auch Phishing-Angriffe bekannt, bei denen Betrüger über eine Lock-E-Mail das
Opfer sehr wohl mit der richtigen Zielseite verbinden, diese allerdings mit einem eigenen
Pop-up-Fenster überlagern. Hier sieht der Betrogene möglicherweise im Hintergrund die vertrauten
Bilder und Texte und lässt sich gerade deshalb verleiten, beispielsweise Transaktionsnummern im
Zusatzfenster anzugeben, wenn der Angreifer einen plausiblen Grund dafür erfindet. Aus diesen
Gründen reicht das Bild- oder Text-Replay als Serverauthentifizierung nicht für jede Transaktion
und jeden Security-Level aus.
Bezug auf das Authentifizierungs-Device
Bei Zwei-Faktor-Authentifizierung verringert sich die Gefahr, die von gefälschten Websites
ausgeht, bestenfalls graduell – festgestellt hat dies schon im März 2005 der
US-Sicherheitsspezialist Bruce Schneier
(www.schneier.com/blog/archives/2005/03/the_failure_of.html).
Ganz nutzlos sind die kleinen Sicherheitsvorteile allerdings nicht. Bei zeitsynchronen
Token-Modellen etwa bleibt dem Angreifer immerhin nur ein knapp bemessenes Zeitfenster, um mit
gestohlenen Daten etwas anfangen zu können, und bei Grid-Karten wie denen von Grid Data Security
oder Entrust kann er zumindest nur das Kennwort für eine einzelne Transaktion abfangen, da der
Server die bei der nächsten Transaktion abgefragten Koordinaten nach dem Zufallsprinzip bestimmt.
Ähnliches gilt für E-TAN-Listen, bei denen die Transaktionsnummern nach dem Zufallsprinzip gezielt
abgefragt werden. Noch sicherer ist es, wenn bei der Transaktion ein Hardware-Token wie eine
Smartcard fest mit dem Client verbunden sein muss oder die Hardware eines bestimmten PCs selbst als
Ausweis herangezogen wird, wie es etwa bei der Device-Authentifizierung von Phoenix geschieht.
Völlig ausgeräumt ist das Risiko der Kommunikation mit einem gefälschten Server allerdings nie.
Im Rahmen starker Authentifizierung kann sich ein Server aber auch dadurch ausweisen, dass er
dem Anwender seine Kenntnis des persönlichen Authentifizierungs-Devices demonstriert, das er ja
ausgestellt haben muss. Im einfachsten Fall nennen Server die Seriennummer des Tokens oder der
verwendeten Karte. Hier wird allerdings nicht der Sicherheits-Level erreicht, das Einmalkennwörter
bieten: Sollte es dem Angreifer gelingen, die Nummer des Devices im Besitz eines bestimmten
Anwenders herauszufinden, kann er sich bei gezielten Angriffen auf dieses Opfers so oft
legitimieren, bis das Device ausgewechselt wird.
Out-of-Band reicht nicht immer aus
Eine interessante Variante ist die Übermittlung eines Einmalkennworts per SMS an ein für den User registriertes Telefon - wobei zu bedenken ist, dass Angreifer derartige Nummern durchaus außerhalb des Onlinesystems ermitteln und die Devices damit in ihre Fälschungsstrategien einbauen können.
Bei Grid-Karten, auf denen für jeden User individuell gefüllte Zahlentabellen aufgedruckt sind, lässt sich die wechselseitige Authentifizierung sehr elegant lösen. Hier gibt dieser zunächst selbst Zahlen an, die in der Tabelle des Anwenders an bestimmten Koordinaten stehen. Zur Transaktionsfreigabe verlangt er vom User dann wiederum die Eingabe von anderen Ziffern an anderen Koordinaten. Die schiere Zahl der möglichen Kombinationen verhindert hier, dass ein Man-in-the-Middle-Angreifer genug Inhalte einer bestimmten Anwender-Grid-Karte mitschneiden kann, um die gewonnenen Zelleninhalte praktisch einsetzen zu können. Zeitsynchrone Tokens haben in diesem Zusammenhang den Nachteil, dass sie zu einem gegebenen Zeitpunkt immer nur eine Zufallszahl zeigen - würde der Server dem Anwender die aktuell angezeigte Zahl nennen, müsste dieser wahrscheinlich kurz darauf die gleiche Zahl für die eigene Authentifizierung benutzen.
Vom 29. April bis 2. Mai 2006 findet in Hamburg die Jahreskonferenz der European Expert Group
für IT-Security (Eicar) statt. Das europäische Event kommt damit nach langer Zeit wieder einmal
nach Deutschland.
Thema ist "Security in the Mobile and Networked World". Das technisch und wissenschaftlich
anerkannt fundierte Event mit Student-Workshops und Präsentationen neuer Erkenntnisse
internationaler Forscher sowie Ergebnissen aus den Eicar-Task-Forces zu Sicherheitsthemen wie
Content Security und RFID öffnet sich zum ersten Mal mit einem Management-Track auch IT-Anwendern.
EICAR versucht so, einen Beitrag zu einem besseren Wissenstransfer zwischen Forschung und Anwendung
im Bereich Sicherheit zu leisten. Zur Sprache kommen auch Themen aus den Bereichen Organisation und
Compliance. Details zur Teilnahme finden Sie unter conference.eicar.org/2006/index.htm.
Besonders hervorzuheben ist die Gründung der Awareness-Task-Force am 3. Mai im Anschluss an die
Hauptkonferenz. Der Konradin IT-Verlag als Medienpartner des Events übernimmt hierbei eine aktive
Rolle. LANline und COMPUTER ZEITUNG wollen einen eigenen Beitrag dazu leisten, der menschlichen
Seite der IT-Sicherheit neue Impulse zu geben, ohne die Techniker ins Abseits zu stellen. Die
Initiative wird vom Bundesinnenministerium und dem Bundesbeauftragten für den Datenschutz
unterstützt.
Darüber verleiht Eicar während der Konferenz den EICAR Award for Data Protection. Die
Auszeichnung honoriert IT-Implementierungen, die in hervorragender Weise den Grundsätzen des
Datenschutzes entsprechen.
Lesen Sie mehr zum Thema
