Ursprünglich für Browser entwickelt, wurde das SSL / TLS-Protokoll später zum De-facto-Standard für die gesamte sichere Internetkommunikation. Jetzt wird es für die Remoteverwaltung der in der Cloud bereitgestellten virtuellen Infrastruktur verwendet, um Zahlungsdetails von Kunden von E-Commerce-Servern an Zahlungsprozessoren wie PayPal und Amazon zu übertragen, lokale Daten an den Cloud-Speicher zu senden, Korrespondenz in Instant Messenger zu speichern und Serverauthentifizierung in mobilen Anwendungen iOS und Android.

Die Liste der Situationen, in denen der Austausch hochsensibler Informationen maximale Sicherheit erfordert, ist beeindruckend. In diesem Artikel werden wir untersuchen, wie die Sicherheit dieser Kommunikation in der Praxis gewährleistet ist.

- SSL / TLS-Protokoll: Sie wollten das Beste ...
- ... aber es stellte sich wie immer heraus: Beispiele für fehlgeschlagene SSL / TLS-Zertifikatsüberprüfung
- Logische Schwachstellen des SSL / TLS-Protokolls
- Andere häufig auftretende Sicherheitslücken bei der Implementierung des SSL / TLS-Protokolls
- Die Hauptursache für Sicherheitslücken im SSL / TLS-Protokoll
- Ein Löffel Honig in einem Fass Teer

SSL / TLS-Protokoll: Wir wollten das Beste ...

Theoretisch sollte eine sichere SSL / TLS-Protokollverbindung die Vertraulichkeit, Zuverlässigkeit und Integrität der Client- und Server-Softwarekommunikation sicherstellen, selbst wenn ein aktiver fortgeschrittener Angreifer aus dem Netzwerk anwesend ist: Wenn das Netzwerk vollständig vom Feind übernommen wird, wird DNS vergiftet und Access Points und Router wechseln und WiFi werden von einem Angreifer gesteuert; ein Angreifer, der unter anderem ein SSL / TLS-Backend kontrolliert. Wenn Client-Software versucht, eine Verbindung zu einem legitimen Server herzustellen, kann ein Angreifer außerdem die Netzwerkadresse des Servers ändern (z. B. durch DNS-Vergiftung) und den Client anstelle eines legitimen Servers auf seinen schädlichen Server umleiten.

Wie Sie wissen, hängt die Sicherheit der Kommunikation unter solch rauen Bedingungen vollständig von der Angemessenheit der Überprüfung des vom Server beim Herstellen der Verbindung bereitgestellten kryptografischen Zertifikats ab. Einschließlich der Angemessenheit der Implementierung einer Reihe von Chiffren (Chiffrensuite), die Client und Server beim Datenaustausch verwenden. Damit die SSL / TLS-Verbindung vollständig sicher ist, muss die Client-Software unter anderem Folgendes sorgfältig überprüfen:

• Zertifikat ausgestellt von der aktuellen Zertifizierungsstelle;
• Die Gültigkeitsdauer ist nicht abgelaufen (oder das Zertifikat wurde nicht widerrufen).
• Die Liste der im Zertifikat aufgeführten Namen enthält die Domäne, zu der Sie eine Verbindung herstellen.

... aber es stellte sich wie immer heraus: Beispiele für fehlgeschlagene SSL / TLS-Zertifikatsüberprüfung

In vielen Anwendungen und Bibliotheken, für die die Kommunikationssicherheit sehr wichtig ist, ist das Verfahren zum Überprüfen eines SSL / TLS-Zertifikats - und sogar von EV-SSL, einem erweiterten Überprüfungszertifikat [4] - jedoch nicht erfolgreich. In allen gängigen Betriebssystemen: Linux, Windows, Android und iOS. Unter den anfälligen Software-, Bibliotheks- und Middleware-Diensten kann Folgendes unterschieden werden [1]:

• Die EC2-Java-Bibliothek von Amazon und alle Cloud-basierten Front-End-Clients basieren auf dieser Basis.
• Das Handels-SDK von Amazon und PayPal ist für die Übermittlung von Zahlungsdetails von Websites (auf denen die Infrastruktur des Online-Handels bereitgestellt wird) an Zahlungsgateways verantwortlich.
• Integrierte „Körbe“ wie osCommerce, ZenCart, Ubercart und PrestaShop, die Zertifikate überhaupt nicht validieren.
• AdMob-Code, der von mobiler Software zur Anzeige von Kontextwerbung verwendet wird.
• Schnittstellen-Front-End-Komponenten ElephantDrive und FilesAnywhere, die für die Interaktion mit dem Cloud-Speicher verantwortlich sind.
• Die Pusher-Android-Bibliothek und die gesamte Software, die die Pusher-API zur Steuerung von Instant Messaging verwendet (z. B. GitHubs Gaug.es).
• Apache HttpClient (Version 3.x); Apache Libcloud und alle Clientverbindungen zu Apache ActiveMQ-Servern usw.
• Java SOAP-Middleware-Dienste, einschließlich Apache Axis, Axis 2, Codehaus XFire; sowie die gesamte Software, die auf Basis dieser Middleware-Dienste erstellt wurde.
• API-Tools für den elastischen Lastausgleich
• Weberknecht Implementierung von WebSockets.
• Sowie die gesamte mobile Software, die auf der Grundlage der oben aufgeführten Bibliotheken und Middleware-Dienste erstellt wurde (Informationen zu Middleware-Diensten finden Sie in Abb. 1). einschließlich des iOS-Clients des Hosting-Anbieters Rackspace.

Abbildung 1. Was sind Middleware-Dienste?

Darüber hinaus sind in [2] sogar mehr als hundert anfällige mobile Anwendungen aufgeführt (siehe Abb. 2). Einschließlich: Google Cloud Messaging für Android, Angies List Business Center-Kennwörter, AT & T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (Remotezugriff), technischer Support von Cisco, Cisco Webex, Cisco WebEx-Kennwörter, Dominos Pizza, E-Trade, Freiberufler , Google Earth, Huntington Mobile (Bank), Online-Buchhalter für Intuit Tax, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN-Client), SouthWest Airlines, Uber, US-Bank - Online-Zugriff, WesternUnion, WordPress, Yahoo! Finanzen, Yahoo! Mail

Abbildung 2. Eine kleine Auswahl aus der Liste der anfälligen mobilen Anwendungen

Logische Sicherheitslücken in SSL / TLS

SSL / TLS-Verbindungen all dieser und vieler anderer Software sind für eine Vielzahl von MiTM-Angriffen anfällig. Gleichzeitig kann ein MiTM-Angriff ausgeführt werden, häufig sogar ohne Fälschung von Zertifikaten und ohne Diebstahl der privaten Schlüssel, mit denen Server ihre Zertifikate signieren. Ein MiTM-Angriff kann ausgeführt werden, indem einfach die logischen Schwachstellen ausgenutzt werden, die in der Prozedur zum Überprüfen des SSL / TLS-Zertifikats auf der Seite der Client-Software vorhanden sind. Infolgedessen kann ein MiTM-Angreifer beispielsweise Autorisierungstoken, Kreditkartennummern, Namen, Adressen usw. sammeln. - von jedem Händler, der anfällige Webanwendungen für die Zahlungsverarbeitung verwendet.

Anbieter mobiler Software, die den AdMob-Beispielcode verwenden, um ihre Anwendungen mit dem AdMob-Konto zu verbinden, sind ebenfalls anfällig. Sie ermöglichen es einem Angreifer, Anmeldeinformationen zu erfassen und auf alle seine Google-Dienste zuzugreifen. Beispielsweise kann ein MiTM-Angreifer aufgrund einer falschen Überprüfung von Zertifikaten in Messenger wie Trillian und AIM Anmeldeinformationen für alle Google-Dienste (einschließlich Google Mail), Yahoo!, stehlen. und auch zu Windows Live-Diensten (einschließlich SkyDrive). Andere Schwachstellen, die moderne Nicht-Browser-Web-Software betreffen, sind: die Verwendung falscher regulärer Ausdrücke beim Vergleichen eines Hostnamens; Ignorieren der Ergebnisse der Zertifikatsvalidierung; versehentliches oder absichtliches Herunterfahren der Überprüfung. [1]

Andere häufige Sicherheitslücken bei der Implementierung des SSL / TLS-Protokolls

Und natürlich sollten wir nicht vergessen, dass selbst wenn keine logischen Fehler bei der Implementierung des SSL / TLS-Protokolls vorliegen (es sei denn, jemand glaubt immer noch daran), der Schutz umgangen werden kann, indem der private Schlüssel [12] mit 0day- gestohlen wird. Exploits für Dinge wie Tastaturen, Browser, Betriebssysteme, Dienstprogramme und Firmware [3]; durch Beeinträchtigung des BGP-Routings [10]; oder SSL / TLS über Hardware (siehe Abbildung 3) [8] und / oder Software [9] umgehen.

Abbildung 3. SSL-Angriff auf Hardware-Bypass

Darüber hinaus können Angreifer praktisch unsichtbare MiTM-Angriffe ausführen und den in der SSLSessionCache-Klasse implementierten SSL / TLS-Sitzungs-Caching-Mechanismus missbrauchen. Dieser Mechanismus überprüft die Gültigkeit von Zertifikaten nur bei der ersten Verbindung. Es ist auch nicht in der Lage, eine Kommunikationssitzung nach dem Löschen von Zertifikaten vom Gerät ordnungsgemäß abzubrechen. Darüber hinaus können Sie nach dem Neustart des Android-Geräts (über die Optionen „Neustart“ oder „Ausschalten“) weiterhin den verschlüsselten Datenverkehr einiger Anwendungen anzeigen, die nach dem Neustart nicht gestartet wurden, aber vor dem Neustart funktionierten. So passiert zum Beispiel mit Google Maps. In [2] wird beschrieben, wie ein Angreifer dank dieser Caching-Fehler „unsichtbare Zertifikate“ für den Benutzer vollständig transparent festlegen und entfernen und dann eine Netzwerkverbindung mit einer beliebigen Anwendung herstellen kann.

Abbildung 4. Rückblick auf anfällige Verschlüsselung

Andere häufige Schwachstellen in der Implementierung des SSL / TLS-Protokolls sind anfällige Verschlüsselung (siehe Abbildung 4) [5], Wiederverwendung von GCM (Galois / Counter-Modus; Zähler mit Galois-Authentifizierung) [6] und Trick mit CNG (CryptoAPI-NG) ) in Schannel (siehe Abb. 5) [7], falsche Überprüfung der Vertrauenskette [2], falsche Überprüfung des Hostnamens [11].

Abbildung 5. CNG-Trick: Geheimnisse aus Schannel ziehen

Eine falsche Überprüfung der Vertrauenskette ist eine Situation, in der die Webanwendung absolut jedes Zertifikat akzeptiert, das den richtigen Hostnamen angibt, ohne zu überprüfen, mit welcher Zertifizierungsstelle sie signiert wurde. Auf diese Weise können Sie Passwörter und / oder Kreditkartennummern abfangen und entschlüsseln. In einigen Fällen wird sogar schädlicher Code injiziert. In Android-Software tritt diese Sicherheitsanfälligkeit beispielsweise auf, wenn eine angepasste X509TrustManger-Schnittstelle erstellt wird, die CertificateException-Ausnahmen ignoriert. Oder wenn ein Softwareentwickler einen Aufruf der Methode SslErrorHandler.proceed () in den Code einer WebViews-Komponente einfügt. [2]

Eine falsche Überprüfung des Hostnamens ist eine Situation, in der eine Webanwendung ein Zertifikat akzeptiert, ohne sicherzustellen, dass der Host, von dem dieses Zertifikat stammt, in der Liste der vertrauenswürdigen Hosts aufgeführt ist. In Android-Software tritt diese Sicherheitsanfälligkeit beispielsweise auf, wenn eine HostnameVerifier-Schnittstelle erstellt wird, die unter allen Umständen TRUE zurückgibt. Oder wenn ein Softwareentwickler einen Aufruf der Methode SslErrorHandler.proceed () in den Code einer WebViews-Komponente einfügt. [2]

Die Hauptursache für Sicherheitslücken im SSL / TLS-Protokoll

Die Hauptursache für die überwiegende Mehrheit dieser Sicherheitsanfälligkeiten ist das schreckliche API-Design von SSL / TLS-Bibliotheken (einschließlich JSSE, OpenSSL und GnuTLS). Ebenso wie das ebenso schreckliche Design von Datenübertragungsbibliotheken (wie cURL, Apache HttpClient und urllib), von denen jede ein High-Level-Wrapper für SSL / TLS-Bibliotheken ist. Ganz zu schweigen von Middleware-Diensten (wie Apache Axis, Axis 2 oder Codehaus XFire), die ein noch übergeordneter Wrapper sind und den „Schneeball“ für schreckliches Design noch mehr erhöhen. Anstatt einen Dialog mit einem Anwendungsentwickler (oft weit entfernt von der Systemprogrammierung) in einer Sprache zu führen, die er versteht (in Bezug auf Vertraulichkeit und Authentifizierung) und die von den Details der Implementierung des SSL / TLS-Protokolls auf niedriger Ebene abstrahiert ist, geben diese APIs eine Reihe von SSL / TLS-Parametern auf niedriger Ebene an den armen Kerl weiter für ihn unverständlich. Sie erfordern Software auf hoher Ebene, um Optionen auf niedriger Ebene korrekt verfügbar zu machen. Implementiert Funktionen zur Überprüfung des Hostnamens und kümmert sich um die Interpretation der Werte, die von Operationen auf niedriger Ebene zurückgegeben werden.

Infolgedessen verwenden Anwendungsentwickler die SSL / TLS-API falsch: Sie interpretieren die Vielfalt ihrer Parameter, Optionen, Nebenwirkungen und Rückgabewerte fälschlicherweise. Zum Beispiel [1]:

• Die PHP-Bibliothek des Amazon Flexible Payments Service versucht, die Überprüfung des Hostnamens zu aktivieren, indem der Parameter CURLOPT_SSL_VERIFYHOST auf TRUE gesetzt wird (in der cURL-Bibliothek). Der korrekte Standardwert für diesen Parameter ist jedoch 2; Wenn Sie ihm den Wert TRUE zuweisen, ist dieser Parameter für den Entwickler unsichtbar, dem der Wert 1 zugewiesen wurde, und so weiter. Die Zertifikatsüberprüfung ist deaktiviert.
• PHP-Bibliothek PayPal Payments Standard - hat den gleichen Fehler erhalten; Darüber hinaus wurde zu dem Zeitpunkt, als die vorherige, anfällige Implementierung aktualisiert wurde (d. H. Ein Fehler wurde entfernt, ein anderer hinzugefügt).
• Ein weiteres Beispiel ist Lynx, ein textorientierter Browser. Es überprüft selbstsignierte Zertifikate - jedoch nur, wenn die GnuTLS-Zertifikatüberprüfungsfunktion einen negativen Wert zurückgibt. Diese Funktion gibt jedoch für einige Fehler 0 zurück. auch in Fällen, in denen die Zertifikate von einer nicht vertrauenswürdigen Stelle unterzeichnet wurden. Aus diesem Grund ist die Vertrauenskette in Lynx unterbrochen.

Darüber hinaus verstehen Anwendungsentwickler häufig falsch, welche Sicherheitsgarantien eine bestimmte SSL / TLS-Bibliothek bietet. In freier Wildbahn kann es daher zu klinischen Fällen kommen, wenn in Anwendungen, die grundsätzlich eine sichere Kommunikation benötigen (z. B. die Interaktion mit einem Zahlungsprozessor), eine SSL / TLS-Bibliothek verwendet wird, die SSL / TLS-Zertifikate überhaupt nicht überprüft. Prosaischer, aber noch mörderischer sind Fälle, in denen der Entwickler einer der Zwischensoftwareschichten das Verfahren zum Überprüfen von SSL / TLS-Zertifikaten stillschweigend deaktiviert (er kann dies beispielsweise tun, um das System zu testen, und nach dem Testen vergessen, es erneut zu aktivieren). Gleichzeitig stellt der übergeordnete Programmcode, der diese Zwischenschicht verwendet, sicher, dass die Zertifikatsüberprüfung durchgeführt wird. T.O. SSL / TLS-Fehler werden häufig in den Tiefen einer oder mehrerer Zwischenschichten von Bibliotheken gleichzeitig versteckt, sodass dieses Problem kaum erkannt werden kann.

In JSSE (Java Secure Socket Extension) überspringt die erweiterte SSLSocketFactory-API-Schnittstelle beispielsweise stillschweigend die Überprüfung des Hostnamens, wenn das Feld "Algorithmus" im SSL-Client auf NULL oder eine leere Zeichenfolge und nicht auf HTTPS festgelegt ist. Obwohl diese Tatsache im JSSE-Referenzhandbuch erwähnt wird, verwenden viele Java-SSL-Protokollimplementierungen SSLSocketFactory, ohne die Überprüfung des Hostnamens durchzuführen ...

Ein Löffel Honig in einem Fass Teer

Tatsächlich stellt sich heraus, dass in den meisten modernen Nicht-Browser-Webprogrammen die Überprüfung von SSL / TLS-Zertifikaten entweder vollständig deaktiviert oder falsch implementiert ist. Abbildung 7 zeigt die Klassifizierung der aktuellen Sicherheitslücken im SSL / TLS-Protokoll. Einige dieser Schwachstellen, aber nicht alle, wurden oben beschrieben und / oder erwähnt. Sie können sich mit den genannten, aber nicht beschriebenen Sicherheitslücken vertraut machen, indem Sie die in der Bibliographie aufgeführten Materialien lesen.

Abbildung 6. Klassifizierung der für SSL / TLS relevanten Schwachstellen

Um dem Teerfass einen Löffel Honig hinzuzufügen, ist anzumerken, dass in [1] ausführlich / klar / populär / kompetent beschrieben wurde, wie SSL unter Bezugnahme auf den RFC implementiert werden sollte. Wir haben nie eine bessere Beschreibung gefunden, die technisch korrekt und gleichzeitig verständlich wäre. Ebenfalls in [1] werden die gängigsten SSL-Bibliotheken analysiert, wobei die Klassifizierung nach der Abstraktionsebene (Low-Level / High-Level) erfolgt. Alle mit Diagrammen und prägnanten Algorithmen im Pseudocode. Sicherheitslücken bestimmter Produkte werden ausführlich mit falschem Code und Fehlercodes beschrieben. Wenn also plötzlich wieder jemand den Wunsch hat, eine solche Implementierung des SSL / TLS-Frameworks zu erstellen, was eine Ausnahme von dem Sprichwort „Sie wollten das Beste, aber es stellte sich wie immer heraus“ darstellt, dann ist [1] ein idealer Anfang dafür.