Dipl.-Inform. Carsten Eilers

Werfen wir zuerst noch einmal einen Blick auf die bisher bekannten Probleme von SSL. Der größte Schwachpunkt ist das verwendete Zertifizierungssystem. Es gibt einfach viel zu viele Zertifizierungsstellen (Certificate Authority, CA), und einige davon nehmen es mit der Sicherheit und der Kontrolle, was für Zertifikate sie ausstellen, nicht so genau. Das Ergebnis: Gehackte CAs und falsch ausgestellte Zertifikate. Das größte Problem dabei: Alternativen zum SSL-CA-Zertifizierungssystem sind rar.

Ein kleiner Überblick über die Entwicklung:

• Frühjahr 2011:
  Gefälschte Zertifikate für prominente Domainnamen wie login.live.com, mail.google.com, www.google.com und login.yahoo.com werden entdeckt. Eine Registrierungsstelle (Registration Authority, RA) der CA Comodo wurde erfolgreich kompromittiert und von dort aus gefälschte Zertifikatsanforderungen genehmigt. Angeblich von einem einzelnen Hacker.
• Sommer 2011: Nach einer Kompromittierung der niederländischen CA Diginotar wurden gefälschte Zertifikate für prominente Domainnamen ausgestellt, darunter wieder www.google.com. Diginotar versuchte anfangs, den Vorfall zu vertuschen und die Folgen des Angriffs herunter zu spielen. Mit dem Ergebnis, dass man einige Zeit darauf den Betrieb komplett einstellen musste.
• Herbst 2011: Die Electronic Frontier Foundation berichtet, dass seit Juni 2011 mindestens 4 CAs kompromittiert wurden.
• November 2011: Zwei weitere CAs fallen aus: Die CA der zum niederländischen Telekommunikationskonzern KPN gehörenden Tochter KPN Corporate Market wurde möglicherweise kompromittiert und stellt sicherheitshalber vorübergehende den Betrieb ein, der malayischen CA Digicert Sdn. Bhd. (nicht zu verwechseln mit und völlig unabhängig von der US-Amerikanischen DigiCert Inc.) wurde das verwendete Intermediate-Zertifikat der CA Entrust wegen Unzuverlässigkeit entzogen.
• Februar 2012: Die CA Trustwave ruft ein von ihr ausgestelltes "MitM-Zertifikat" zurück.

Die Gefahr, die von einem "MitM-Zertifikat" wie es Trustwave ausgestellt hat ausgeht, habe ich hier beschrieben. Der Angriff erfolgt genau nach dem gleichen Muster beim Einsatz eines gefälschten Zertifikats, nur dass damit nur Verbindungen zum jeweils angegebenen Server bzw. zur angegebenen Domain aufgebrochen werden können, während mit einem "MitM-Zertifikat" alle SSL-Verbindungen aufgebrochen werden können.

Ein weiteres Problem sind mögliche Angriffe auf die Verschlüsselung, wie sie im Sommer 2011 mit BEAST demonstriert wurden.

Und im März dieses Jahres stellen mehrere Forscher dann fest, dass die RSA-Schlüssel in vielen SSL-Zertifikaten nicht so sicher sind, wie sie eigentlich sein sollten. Allerdings scheinen zu einem großen Teil die von Embedded Devices generierten Schlüssel betroffen zu sein und keine von CAs ausgestellten Zertifikate.

Der neueste Schlag

Forscher von der University of Texas in Austin und von der Stanford University haben herausgefunden, dass Designfehler in APIs von SSL-Implementierungen dazu führen, das Zertifikate von Nicht-Browser-Software gar nicht oder unzureichend geprüft werden ("The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software", Paper als PDF).

Die Forscher untersuchten, wie verschiedene Nicht-Browser-Software auf falsche Zertifikate reagiert. Dabei wurden sowohl selbst-signierte Zertifikate auf den korrekten ebenso wie auf einen falschen Namen eingesetzt, und auch ein korrektes Zertifikat für die Domain AllYourSSLAreBelongTo.us kam zum Einsatz. In den meisten Fällen akzeptierten die Server diese gefälschten Zertifikate und bauten eine SSL-Verbindung auf. Dadurch werden Man-in-the-Middle-Angriffe möglich - also genau die Angriffe, die SSL eigentlich verhindern soll.

Die SSL-Libraries wie JSSE, OpenSSL, GnuTLS oder CryptoAPI selbst funktionieren völlig einwandfrei, sie werden von den Entwicklern jedoch falsch verwendet, so dass die Zertifikatsprüfung auf die eine oder andere Weise ausgeschaltet bzw. unbrauchbar gemacht wird. Eine Ursache ist die Komplexität der verfügbaren Optionen, die zu Fehlkonfigurationen geradezu einlädt. Hinzu kommt, dass die Libraries in manchen Fällen darauf angewiesen sind, dass die darüber liegenden Softwareebenen nötige Informationen liefern, was den Entwicklern dort aber mitunter gar nicht bewusst ist.

Folgende Probleme wurden erkannt:

1. Falsche Benutzung von SSL-APIs
   • Amazon Flexible Payments Service (FPS) (PHP-Version)
     Die PHP-Version des FPS SDK nutzt libcurl, ruft cURL aber falsch auf, so dass Zertifikate mit beliebigen Common Name akzeptiert werden.
   • PayPal Payments Standard und PayPal Invoicing (PHP)
     Auch hier wird cURL genutzt und ebenfalls falsch aufgerufen.
   • PayPal IPN in ZenCart
     Durch das falsche Setzen von cURL-Parametern wird die Zertifikatsprüfung komplett ausgeschaltet.
   • Lynx mit GnuTLS
     Durch eine Fehlkonfiguration wird die Chain-of-Trust-Prüfung ausgeschaltet.
   • Apache HttpClient
     Version 3.x akzeptiert jedes Zertifikat mit korrekter Chain-of-Trust, unabhängig vom angegebenen Namen. Dieser Fehler wurde in Version 4.0-alpha1 behoben, dafür enthält Version 4.2.1 einen Fehler, durch den unter Umständen korrekte Zertifikate abgelehnt werden.
   • Trillian
     Der Instant Messaging Client nutzt OpenSSL, aber leider falsch, so dass beliebige Zertifikate akzeptiert werden.
   • Rackspace App for iOS
     Durch einen Programmierfehler in der App zur Verwaltung von Rackspace-Clouddiensten ist die Zertifikatsprüfung ausgeschaltet.
   • TextSecure
     Die Android-App zur Verschlüsselung von SMS- und MMS-Nachrichten enthält Code zur Nutzung von SSL, der aber nicht aktiviert ist. Da SSL nicht genutzt wird, ist auch kein Angriff darüber bzw. darauf möglich.
2. Unsichere Middleware
   • Apache Axis, Axis 2, Codehaus XFire
     Schwachstellen in der Middleware beeinträchtigen zum Beispiel Amazon-Libraries wie die Amazon EC2 API Tools und Amazon Flexible Payments Service (Java), PayPal Payments Pro (Direct Payment), PayPal Transactional Information und PayPal Mass Pay sowie Apache ActiveMQ.
   • Pusher (WebSocket-API)
     Die Pusher Android-Libraries nutzen eine unsichere Version von Weberknecht.
   • Apache CXF
     In der Default-Einstellung ist die Zertifikatsprüfung aktiviert, in Beispiel-Code wird sie jedoch ausgeschaltet.
3. Nutzung unsicherer SSL-Bibliotheken
   • PHPs fsockopen führt keine Zertifikatsprüfungen durch
     fsockopen wird in PayPals IPN genutzt. Der Code wird in PayPals Modulen für ZenCart und PrestaShop verwendet, vergleichbare Schwachstellen gibt es in Open Source Classifieds.
   • Pythons URL-Libraries prüfen keine Zertifikate
     Die Libraries werden beispielsweise von Tweepy und Zamboni genutzt.
4. Unfähige Entwickler
   Das Ausschalten der Zertifikatsprüfung scheint die bevorzugte Problemlösung für Entwickler zu sein, die Probleme mit SSL-Bibliotheken haben.

Folgende Schwachstellen wurden speziell genannt:

• Die Onlinebanking-App für Android der Chase Bank enthält Code, der die Zertifikatsprüfung komplett ausschaltet.
• Die Python-Library Apache Libcloud verwendet einen falschen regulären Ausdruck zum Prüfen des Hostnames.
• Amazon Elastic Load Balancing API Tools prüft keine Hostnamen.
• Die Webshops osCommerce, ZenCart, Ubercart und PrestaShop nutzen cURL zur Kommunikation mit Zahlungs-Gateways. Ist cURL nicht vorhanden, wird das unsichere fsockopen als Fallback verwendet. Die Module für verschiedene Zahlungsanbieter enthalten meist Fehler, die die Zertifikatsprüfung ausschalten. Die einzigen Ausnahmen sind Googles Module für PrestaShop und osCommerce.
• AdMob enthält Beispielcode, der cURL nutzt, aber die Zertifikatsprüfung ausschaltet.
• Die Android-Apps Groupon Redemptions, Breezy und ACRA enthalten verschiedene Fehler.
• AIM für Windows akzeptiert Zertifikate von nicht vertrauenswürdigen CAs und prüft keinen Hostnamen.
• FilesAnywhere zeigt ein interessantes Verhalten: Wird ihm bei der Verbindung mit einem Nicht-Google-Server ein Google-Zertifikat präsentiert, gibt es eine Warnung. Bei jedem anderen falschen Zertifikat wird das Zertifikat ohne Warnung akzeptiert.

Die Auswirkung der Fehler

Die Client-Seite

Betrachten wir zuerst die Client-Seite. Hier fallen besonders die Client-Anwendungen wie die Onlinebanking-App für Android der Chase Bank, Trillian und AIM für Windows auf: Denen kann ein Man-in-the-Middle durch die Fehler sehr einfach vortäuschen, er sei ein zuverlässiger Server. Das macht MitM-Angriffe deutlich einfacher als im Fall von Webbrowsern, die die Zertifikate korrekt prüfen.

Während die betroffenen Programme das Zertifikat des MitM ohne Warnung oder Ähnliches akzeptieren, muss im Fall der Webbrowser entweder der Webbrowser mit einem von einer CA erbeuteten "falschen" Zertifikat getäuscht oder der Benutzer per Social Engineering trotz entsprechender Warnung des Webbrowsers zum Akzeptieren des falschen Zertifikats gebracht werden.

Die Server-Seite, Möglichkeit 1: Webbrowser kommuniziert mit Server

Betrachten wir nun die Server-Seite, zuerst die Kombination "Webbrowser kommuniziert mit Server". In diesem Fall ist ein MitM gar nicht darauf angewiesen, gegenüber dem Server ein gefälschtes Zertifikat zu verwenden. Wie ich hier bereits beschrieben habe, läuft so ein MitM-Angriff normalerweise so ab, dass der Angreifer sich gegenüber dem Webbrowser seines Opfers durch ein gefälschtes Zertifikat als vertrauenswürdiger Server ausgibt, während er zum Server ganz normal eine SSL-Verbindung aufbaut und sich dort als der entsprechende Benutzer ausgibt. Da dafür das Original-Zertifikat des Servers verwendet werden kann, besteht gar kein Grund, dem Server ein gefälschtes Zertifikat unter zu schieben.

Das von den Forschern beschriebene Problem wird in diesem Fall erst dann interessant, wenn der Benutzer sich selbst auch durch ein SSL-Zertifikat ausweist (was von SSL als Option vorgesehen ist, im Allgemeinen aber nicht gemacht wird). Die entscheidende Frage also, ob die Server gefälschte Client-Zertifikate akzeptieren würden, wurde von den Forschern aber gar nicht untersucht: "SSL also supports client authentication, but we do not analyze it in this paper." Allerdings ist es wohl ziemlich unwahrscheinlich, dass die Prüfung der Client-Zertifikate besser als die der Server-Zertifikate ausfallen würde.

Die Server-Seite, Möglichkeit 2: Server kommuniziert mit Server

Sehr gefährlich sind die Fehler im zweiten möglichen Fall, der Kommunikation von Servern untereinander. Ein Angreifer, der sich als MitM beispielsweise in die Kommunikation eines Webshops mit seinem Zahlungsdienstleister einschalten kann, kann natürlich einigen Schaden anrichten. Und solche Angriffe sind durch die fehlerhafte Zertifikatsprüfung sehr einfach möglich. Das gleiche gilt natürlich entsprechend bei allen anderen Fällen, in denen Server untereinander kommunizieren. Einer der Server agiert dabei i.A. als "Client" und kann dann vom MitM dazu gebracht werden, ihn als den vertrauenswürdigen anderen Server zu akzeptieren. Da man SSL ja einsetzt, um MitM-Angriffe zu verhindern, dürften die Folgen i.A. fatal sein.

Fazit

Ist dies der nächste Nagel im Sarg von SSL? Nun, zumindest wurde da ein Loch vorgebohrt, in das dann jemand den Nagel schlagen kann. Im Grunde dürfen beispielsweise Webshops jetzt nicht mehr darauf vertrauen, dass sie wirklich mit ihrem Zahlungsdienstleister kommunizieren und dass eine bestätigte Zahlung ihnen wirklich gut geschrieben wurde. eCommerce wird damit ziemlich schwierig. Allerdings wird das auch für entsprechenden Druck auf die betroffenen Entwickler sorgen, und da die SSL-Bibliotheken selbst ja keine Fehler enthalten, müssen die Entwickler sie nun "nur" richtig einsetzen, und die Gefahr ist gebannt.

Und dann sollten sich die Entwickler der SSL-Bibliotheken und APIs vielleicht mal Gedanken darüber machen, wie sie die Nutzung ihres Code vereinfachen können. Denn allem Anschein nach ist das zur Zeit so schwierig, dass nicht nur DAE, die Dümmsten Anzunehmenden Entwickler, daran scheitern, sondern auch alle (oder zumindest fast alle) anderen. Sichere Sicherheits-Bibliotheken zu entwickeln, die dann aufgrund verwirrender Optionen nicht sicher genutzt werden, ist für die betroffenen Entwickler sicher kein Ruhmesblatt.

Carsten Eilers