Dipl.-Inform. Carsten Eilers

Nach dem dritten Schritt des Triple Handshake Angriffs geht der Client C davon aus, dass er mit dem Server des Angreifers, A, verbunden ist. Tatsächlich kommuniziert er aber über eine mit seinem Client-Zertifikat authentifizierten Verbindung mit dem Server S. Dadurch sind einige Angriffe möglich, zum Beispiel weil A von C an S gesendete sensitive Daten ausspähen oder Nachrichten manipulieren kann.

Auf ins Web!

Bei einem Web-basierten Angriff ist C ein Webbrowser, A und S sind Webserver. Dann sind folgende Angriffe möglich:

• A sendet vor dem dritten Schritt einen partiellen POST-Request an S, der dann während der Renegotiation durch das Client-Zertifikat von C authentifiziert wird - S geht dann davon aus, dass der Request von C stammt.
• A schleust vor dem dritten Schritt in den Webbrowser C JavaScript-Code ein. Der Code wird dann nach der Renegotiation in der authentifizierten Session ausgeführt.
• A kann nach der Client-Authentifizierung eine Seite von S in einem Frame im Webbrowser C laden und aus einer von A geladenen Seite in einem anderen Frame auf deren Inhalt zugreifen. Ermöglicht wird das indirekt durch die Same Origin Policy, die solche Zugriffe ja eigentlich verhindern soll: A darf nur auf ebenfalls von A geladene Ressourcen zugreifen. Da es für C aber so aussieht, als stamme die von S geladene Seite von A ist die SOP erfüllt und der Zugriff möglich.

Die Entdecker des Triple Handshake Angriffs haben einen Webbasierten Angriff in einem Video demonstriert. Beteiligt sind die folgenden Server:

• Angegriffen wird der Server victim.ht.vc, der anonyme Zugriff erlaubt, bis der Benutzer /login aufruft. Daraufhin sendet der Server einen Renegotiation-Request an den Client, der eine Client-Authentifizierung erfordert. Erst nach der Authentifizierung ist der Zugriff auf sensitive Informationen möglich.
• Der Server des Angreifers ist secure-resumption.com. Ruft ein Benutzer diese Website auf, führt sie einen Triple Handshake Angriff durch, um den Client mit dessen Client-Zertifikat beim Server victim.ht.vc zu authentifizieren.

Im Browser des Benutzers läuft dann in einem Frame JavaScript-Code, der vom Server des Angreifers geladen wurde. Dieser Code kann die Daten im Client-Authentifizierten Frame mit den sensitiven Informationen von victim.ht.vc lesen, da es für den Browser so aussieht, als wären beide Frames vom gleichen Server geladen worden.

Im Gegensatz zu Phishing- und ähnlichen Angriffen gibt sich die Website des Angreifers nicht als der angegriffene Server aus. Stattdessen ist ihre Identität sogar eindeutig erkennbar: Sie nutzt ihr eigenes Zertifikat und der Webbrowser zeigt die URL des Angreifer-Servers an.

Ein mögliches Angriffsziel könnte das Onlinebanking auf einer Banken-Website sein: Die Website selbst ist für jeden zugänglich, das Onlinebanking aber nur Kunden nach deren erfolgreichen Authentifizierung.

Ein Angriff mit Haken

Dieser Angriff hat zwei Haken:

1. Der Benutzer muss sein Client-Zertifikat für victim.ht.vc auf der Website secure-resumption.com des Angreifers verwenden - warum sollte er das tun?
2. Der Webbrowser muss während der Renegotiation einen Wechsel des Server-Zertifikats erlauben, ohne den Benutzer darüber zu informieren. Aber das tun viele Browser und auch andere TLS-Clients.

Ein aufmerksamer Benutzer sollte sich weigern, sein Client-Zertifikat für eine völlig fremde Website zu verwenden. Aber mit etwas Social Engineering werden sich sicher genug Benutzer dazu überreden lassen, das Zertifikat eben doch zu verwenden. Und dann würde auch eine Warnung vor dem Wechsel des Server-Zertifikats sie nicht davon abhalten. Zum einen kann das beim Social Engineering bereits berücksichtigt werden, zum anderen zeigt das ja gerade, dass der Angreifer-Server nichts Böses in Schilde führt. Der Angreifer kann einfach behaupten: "Wenn Sie ihr Client-Zertifikat frei geben, werden Sie auf den Server Ihrer Bank weitergeleitet. Das erkennen Sie daran, dass die Bank sich mit ihrem Zertifikat ausweist!" - Wer würde dann noch einen Angriff vermuten? Das Client-Zertifikat der Bank wird an den Server der Bank geschickt, also ist alles genau so, wie es sein soll.

Varianten des Triple Handshake Angriff

Die Entdecker des Angriffs haben weitere Varianten entwickelt:

Der Triple Handshake Angriff funktioniert so wie beschrieben nur, wenn Client und Server den RSA-Schlüsselaustausch verwenden. Er lässt sich aber auch an den Diffie-Hellman-Schlüsselaustausch anpassen, sofern der Client eine unbekannte Diffie-Hellman-Gruppe vom Angreifer akzeptiert.

TLS Channel Bindings (RFC 5929), dienen unter anderem dazu, die Authentifizierung auf der Anwendungsschicht an eine TLS-Verbindung zu binden. Beim Triple Handshake Angriff lässt sich diese Bindung unterlaufen, da der Man-in-the-Middle dafür sorgen kann, dass das verwendete tls-unique-Bindung für zwei verschiedene Verbindungen identisch ist.

Die sich noch in der Entwicklung befindende Channel ID (Draft) soll unter anderem Zugangsdaten auf der Anwendungsebene (zum Beispiel Cookies) an einen auf dem Client gespeicherte Public Key binden, um die Verwendung einer Session auf einen anderen Client zu verhindern. Auch dieser Schutz lässt sich durch den Triple Handshake Angriff umgehen.

Getunnelte Authentifizierungsprotokolle wie PEAP und EAP-TTLS bauen zuerst eine TLS-Verbindung auf, um dann im Tunnel eine EAP-Authentifizierung durchzuführen. Um Man-in-the-Middle-Angriffe zu verhindern werden die von den inneren und äußeren Protokollen verwendeten Schlüssel kryptographisch aneinander gebunden. EAP-Client und -Server müssen sich gegenseitig beweisen, dass sie auch das gleiche TLS-Master-Secret und die gleichen Client- bzw. Server-Zufallswerte verwenden. Dieser Schutz funktioniert nur, wenn das TLS-Master-Secret nicht für zwei verschiedene Verbindungen identisch sein kann. Das ist beim Triple Handshake Angriff nicht mehr gegeben, da die beiden Verbindungen C<->A und A<->S schon nach dem ersten Handshake das gleiche Master Secret verwenden. Dadurch sind MitM-Angriffe auf EAP wieder möglich.

Wie gefährlich sind Triple Handshake Angriffe?

Wie gefährlich Triple Handshake Angriffe in der Praxis sind bleibt abzuwarten. Zumindest der Webbasierte Angriff dürfte, etwas Social Engineering vorausgesetzt, möglich sein. Aber wie sieht es mit möglichen Angreifern aus? Interessieren sich Cyberkriminelle oder "staatlich gesponserte Angreifer" überhaupt für solche Angriffe? Die Cyberkriminellen scheinen zumindest noch mit ihren Onlinebanking-Schädlingen recht erfolgreich zu sein, so dass ein Triple Handshake Angriff eher nicht zu erwarten ist. Wie es bei den Geheimdiensten etc. aussieht wage ich nicht zu beurteilen. Zumindest die NSA gehört ja eindeutig zu den "Jägern und Sammlern", sowohl was die möglichen Angriffe als auch die Daten ihrer Opfer betrifft. Die werden sicher auch auf Triple Handshake Angriffe zurückgreifen, wenn sie damit Daten abgreifen können.

Die spannendere Frage ist eigentlich, ob es überhaupt mögliche Opfer gibt. Wie viele Clients nutzen denn Client-Zertifikate, vor allem im Web? Wie wahrscheinlich ist es, diese Benutzer mit einem Social-Engineering-Angriff zur Preisgabe ihres Client-Zertifikats zu bewegen? Client-Zertifikate sind doch eher selten im Einsatz, und ihre Benutzer dürften im Allgemeinen sicherheitsbewusster als normale Benutzer sein. Fallen die auf Social Engineering ein? Ich habe keine Ahnung. Man sollte erwarten, dass solche Benutzer sich nicht so einfach täuschen lassen. Andererseits geht es hier eher um gezielte Angriffe auf bestimmte Benutzer, und mit gut gemachten Social Engineering lässt sich einiges erreichen. Ob das auch einen Triple Handshake Angriff einschließt? Warten wir es ab.

Hiermit ist der Einschub zu den Triple Handshake Angriffen abgeschlossen. In der nächsten Folge geht es wieder um neue Entwicklungen beim Clickjacking.

Carsten Eilers