Seit Anfang des Monats ist ein neuer Angriff auf das TLS-Protokoll bekannt, der dem Client sogar das echte SSL-Zertifikat präsentiert. ZDNet zeigt, wie die Attacke funktioniert und was zu tun ist, um HTTPS-Verbindungen wieder abzusichern.
Anfang des Monats wurde bekannt[1], dass es eine neue Methode zur Manipulation von SSL/TLS-Verbindungen[2] gibt. Bereits im August entdeckten Marsh Ray und Steve Dispensa ein Angriffsszenario, das sie nun veröffentlicht[3] haben. Dabei handelt es sich nicht um eine rein theoretische Möglichkeit, sondern um eine konkrete Gefahr.
Das Haupteinsatzgebiet von TLS-Verbindungen ist das sichere Webbrowsing mittels HTTPS[4]. Es wird jedoch bei auch bei anderen Übertragungsarten eingesetzt. Dazu gehören unter anderem die Verschlüsselung der E-Mail-Protokolle SMTP[5], POP3[6] und IMAP[7] sowie in abgewandelter Form die Verschlüsselung von VoIP-Gesprächen, etwa mit dem Protokoll SRTP[8].
Die neue Angriffsmethode kann in Form von Man-in-the-Middle-Attacken[9] ausgeführt werden. Dabei schützen auch die SSL-Serverzertifikate nicht mehr, die bisher solche Angriffe entlarven konnten, wenn man sich die Mühe gemacht hatte, tatsächlich bei jedem Besuch einer Homebanking-Site einen Blick auf das Zertifikat zu werfen.
Um zu verstehen, wie man Zertifikate richtig nutzt, muss man einige Grundlagen zu SSL/TLS kennen: Bei einer TLS-Verbindung kommen immer zwei Verschlüsselungsmethoden zum Einsatz - eine symmetrische[10] und eine asymmetrische[11]. Zunächst nutzen Client und Server ein asymmetrisches Verfahren wie RSA[12]. Dabei sendet der Server seinen öffentlichen Schlüssel, der zum Verschlüsseln einer Nachricht dient. Mit dem privaten Schlüssel, den er geheim halten muss, kann er die Nachricht entschlüsseln.
Da asymmetrische Verfahren relativ viel Rechenleistung brauchen, wird mittels der asymmetrischen Verschlüsselung nur ein symmetrisches Verschlüsselungsverfahren, beispielsweise AES[13], RC4[14] oder Camellia[15] ausgehandelt und ein zufällig generierter Schlüssel ausgetauscht. Die eigentliche Nutzdatenverbindung wird mittels des symmetrischen Verfahrens verschlüsselt.
Man-in-the-Middle-Angriffe sind eine generelle Schwachstelle bei diesem Verfahren. Sie erfordern, dass sich jemand auf dem Übertragungsweg in die Verbindung einklinkt. Wenn man sich per HTTPS an seine Bank verbindet, kann der Wohnungsnachbar keine Man-in-the-Middle-Attacke ausführen - ganz einfach deswegen, weil die Daten der HTTPS-Verbindung nicht über seine Leitung übertragen werden.
Das gleiche gilt beispielsweise für den Bürokollegen, dessen Rechner am selben Ethernetswitch hängt. Nur bei intelligenten Switches kann ein Administrator das sogenannte Portmirroring veranlassen, das bewirkt, dass alle Daten für einen Port an einen zweiten gesendet wird.
Ein Angreifer muss also die Möglichkeit haben, sich in den Datenverkehr einzuklinken, indem er beispielsweise beim Provider, bei einem Carrier oder bei einem Internetaustauschknoten wie dem DE-CIX[16] sitzt. Ein solches Szenario ist durchaus realistisch. Man vermutet, dass die großen Sammlungen von FTP-Passwörtern, die immer wieder auf einschlägigen Servern im Internet gefunden[17] werden, von illoyalen Mitarbeitern bei Providern und Carriern stammen, die sich durch Schnüffeleien ein Nebeneinkommen verschaffen.
Während es für das Ausspionieren von FTP-Kennwörtern ausreicht, einen Sniffer zu installieren, muss ein Angreifer für eine Man-in-the-Middle-Attacke einen größeren Aufwand betreiben: Es ist notwendig, zumindest einen Teil des Datenverkehrs an einem Router auf einen physischen Port umzuleiten, an dem ein Rechner mit der Software für den Angriff installiert ist. Die Gefahr, entdeckt zu werden, ist für den Angreifer um ein Vielfaches höher als beim Abhören.
Bei einem Man-in-the-Middle-Angriff gibt der Angreifer vor, selbst der Server zu sein, den der Anwender zu erreichen versucht, etwa durch IP-Spoofing[18]. Er handelt mit dem Client eine TLS-Session aus und führt gleichzeitig eine TLS-Verbindung mit dem echten Server, etwa dem einer Bank.
Dabei kann der Angreifer zwischen dem echten Server und dem Client rein vermittelnd tätig werden. Das heißt, er nutzt seinen Angriff nur, um den Datenverkehr auszuspionieren, etwa um die PIN oder das Passwort für den Homebanking-Zugang des Benutzers herauszufinden. Er kann aber auch eigene Aktionen auf dem Server der Bank ausführen. Wenn Transaktionen mit einer TAN geschützt sind, kann er nur Informationen abgreifen, beispielsweise Kontostand und Kontobewegungen. Bei Bezahlsystemen wie PayPal oder Click & Buy, die keine TAN verlangen, kann er jedoch auch Geld transferieren.
Um diese einfache Möglichkeit des Man-in-the-Middle-Angriff zu verhindern, verwenden TLS-Verbindungen Zertifikate. Über das Serverzertifikat kann der Client sicherstellen, dass er tatsächlich mit dem echten Server kommuniziert und nicht mit dem des Angreifers. Die gängigen Browser nutzen eine Vertrauensliste, in der anerkannte Zertifikataussteller wie Verisign[19] bereits vorinstalliert sind. Besitzt der Server ein solches Zertifikat, dann gibt der Browser keine Warnung aus.
Viele Websites stellen sich für HTTPS-Verbindungen das Zertifikat aus Kostengründen selbst aus, beispielweise mit OpenSSL[20]. In diesem Fall warnt der Browser, dass die Site nicht überprüft werden konnte. Der Benutzer muss eine Ausnahme zulassen. Diese Ausnahme kann er temporär oder dauerhaft einrichten.
Wenn der Browser bei einer Verbindung zur Bank nicht warnt, dann bedeutet das jedoch nicht, dass sich niemand in die Verbindung eingeklinkt hat. Schließlich kann jedermann ein "gültiges" SSL-Zertifikat erwerben, das heißt ein Zertifikat, das der Browser nicht moniert.
RapidSSL[21] wirbt etwa mit dem Slogan "issued in minutes, installed in seconds". Der Identitätsnachweis geschieht ausschließlich über die Kreditkarte. RapidSSL vertraut dabei darauf, dass der Aussteller der Kreditkarte die Identität überprüft hat. Wer im Besitz von gestohlenen Kreditkartendaten ist, bekommt auch ein SSL-Zertifikat mit falschem Namen.
Es ist daher wichtig, bei jeder Verbindung zu einer Bank das Zertifikat anzusehen. Wenn man beispielsweise auf die Homebankingsite der Hypovereinsbank surft und feststellt, dass das Zertifikat auf einen anderen Namen ausgestellt ist, dann ist man Opfer eines Man-in-the-Middle-Angriffs. Ebenso ist darauf zu achten, dass das Zertifikat nicht auf eine Abkürzung wie "HVB" ausgestellt ist - einen Firmennamen, den jeder anmelden kann.
Bei der neuen Attacke, die Ray und Dispensa entwickelt haben, hilft auch eine Überprüfung des Zertifikats nicht. Sie nutzt eine geschickte Kombination mehrerer Umstände aus. Der zentrale Faktor ist dabei die sogenannte TLS-Renegotiation. Unter bestimmten Bedingungen handeln Client und Server die TLS-Sitzung neu aus. Die TLS-Renegotiation kann vom Client oder vom Server aus initiiert werden.
Obwohl die Neuaushandlung der Verschlüsselung unter dem Schutz der alten Verschlüsselung geschieht, gibt es eine Authentifizierungslücke, die dann auftritt, wenn Client und Server sich nicht auf "Session Resumption" verständigen. In diesem Fall kann ein Angreifer einen Client-Request auslesen und modifizieren.
Ray und Dispensa nutzten dazu HTTP-1.1-Pipelining[22] und eine Injection-Attacke. Sie sandten am Ende ihrer Anfrage einen Kommentar (X-Ignore), der nicht mit einem Zeilenumbruch (CRLF) endete. So nutzten sie beispielsweise folgenden Request:
GET: /transfermoney.php?Konto=4711&Betrag=1000<cr><lf> Host: example.com<cr><lf> X-Ignore:
Zu beachten ist, dass nach "X-Ignore: kein <cr><lf> erfolgt. Der ahnungslose Client schickt anschließend folgenden Request:
GET: kontostand.php<cr><lf> Cookie: 8F617A53BC83792C6D4<cr><lf>
Das führt dazu, dass der Server folgendes sieht:
GET: /transfermoney.php?Konto=4711&Betrag=1000<cr><lf> Host: example.com<cr><lf> X-Ignore: GET: kontostand.php<cr><lf> Cookie: 8F617A53BC83792C6D4<cr><lf>
Damit hat sich der Angreifer mit dem richtigen Cookie authentifiziert und schickt einen Betrag von 1000 Euro an das Konto 4711. Der ursprüngliche Request des Clients, den Kontostand anzuzeigen, ist auskommentiert.
Die Forscher stellten fest, dass keine der getesteten Kombinationen von Webserver und Browsern eine "Session Resumption" durchführte. So konnten sie auf dem Man-in-the-Middle-Rechner eine zweite HTTPS-Session aufbauen, die unter dem Sicherheitskontext des ausspionierten Benutzers lief.
Die ersten Versuche liefen darauf hinaus, dass eine Authentifizierung per Client-Zertifikat erfolgreich war. Das hat praktische Relevanz, wenn man von der Bank eine Smartcard erhalten hat, die zum Homebanking erforderlich ist. Ray und Dispensa konnten sich eine HTTPS-Sitzung mit dem Client-Zertifikat aus einer Smartcard eines Benutzers verschaffen.
Eine andere Möglichkeit, dem Server eine TLS-Renegotiation zu entlocken, besteht darin, in verschiedenen Verzeichnissen des Servers unterschiedliche Verschlüsselungsalgorithmen zu konfigurieren. Das hat allerdings praktisch keine Bedeutung, da eine Bank in der Regel für den gesamten Server dieselbe Konfiguration der erlaubten Verschlüsselungsmethoden vornimmt.
Schließlich gelang es den Forschern beim Verbindungsaufbau der TLS-Sitzung einen Client-Request so zu modifizieren, dass unmittelbar eine TLS-Renegotiation stattfindet. Diese Form des Angriffs ist für Hacker sehr attraktiv, da keine speziellen Voraussetzungen auf dem Server erforderlich sind. Diese Methode funktioniert mit Homebanking-Sites, die keine Smartcard verlangen. Sowohl Apache als auch Microsoft IIS ließen sich auf diese Weise austricksen.
Für Apache und OpenSSL sind bereits Patches verfügbar, die allerdings darauf hinauslaufen, dass keine TLS-Renegotiation mehr stattfindet. Microsoft hat bisher nicht reagiert. Für GNUtls ist ein Patch angekündigt. Die Patches sind allerdings nur Workarounds, da das Abschalten der Verschlüsselungsneuaushandlung in einigen Szenarien zu Problemen führt. Langfristig wird es erforderlich sein, die nächste Version des TLS-Protokolls so abzuändern, dass die Daten einer Finished-Message im Renegotiation-Handshake client hello beziehungsweise server hello erneut übertragen werden müssen.
Als Nutzer von Homebanking und anderen Diensten, die über diese neue Angriffsmethode verwundbar sind, kann man wenig tun, um solche Angriffe zu verhindern. Anwender müssen darauf vertrauen, dass die Homebanking-Anbieter möglichst schnell ihre Webserver patchen und so konfigurieren, dass TLS-Renegotiations nicht erlaubt sind.
Ferner müssen die Anbieter sicherstellen, dass es für den Host nicht erforderlich ist, TLS-Renegotiations durchzuführen. Wenn für verschiedene Verzeichnisse unterschiedliche Verschlüsselungssysteme vorgeschrieben sind, muss der Server die Verschlüsselung neu aushandeln. Sollte das per Konfiguration verboten sein, kommt keine Verbindung zustande.
Die von Marsh Ray und Steve Dispensa entwickelte Angriffsmethode auf SSL/TLS-Verbindungen stellt eine reale Gefahr dar, Man-in-the-Middle-Angriffe so auszuführen, dass auch ein SSL-Serverzertifikat nicht mehr schützen kann. Auch Smartcards mit Client-Zertifikaten bieten keinen Schutz vor diesem Angriff.
Um einen solchen einen Angriff auszuführen, muss sich ein Angreifer jedoch in den physikalischen Übertragungsweg einklinken, etwa beim Provider. Die Wahrscheinlichkeit, dabei entdeckt zu werden, ist sehr hoch, wenn der Provider geeignete Überwachungsmethoden einsetzt.
Um solche Angriffe zu verhindern, sind die Anbieter von sicherheitsempfindlichen Diensten wie Homebanking gefordert. Am Webbrowser des Clients kann nichts getan werden, da der Angreifer einen Browser simulieren kann, der TLS-Renegotiations zulässt. Für alle Anbieter ist es wichtig, ihren Webserver zu patchen und sicherzustellen, dass TLS-Renegotiations einerseits nicht notwendig sind und anderseits abgelehnt werden.
Praktisch lassen sich Man-in-the-Middle-Angriffe auch mit einem gegen den Ray-Dispensa-Angriff gesicherten Server erfolgreich durchführen, da davon auszugehen ist, dass Benutzer einem SSL-Zertifikat vertrauen, welches der Browser nicht als potenziell unsicher moniert. So ein Zertifikat kann sich jedermann besorgen. Schützen kann man sich nur, wenn man jedes Mal einen Blick auf das Zertifikat wirft und überprüft, ob es tatsächlich auf die Bank ausgestellt ist.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/