Risiko SSL-Inspection
Immer mehr Webseiten nutzen HTTPS und mit Let's Encrypt ist da auch sehr einfach. Browser warnen vor unverschlüsselten Seiten und zeigen kein grün mehr an. Das gilt auch für Seiten mit Malware oder Phishing-Seiten. Da ist es nur logisch, dass Firmen auch verschlüsselten Inhalt inspizieren wollen.
Verschlüsselung sichert Inhalte
Allerdings nutze ich Verschlüsselung ja nicht, um Malware zu verstecken oder mein Tun zu verschleiern. Sie können mir glauben, dass allein die Metainformationen, d.h. wer (User oder Client-IP) welches Ziel (DNS-Name, IP-Adresse, Zertifikatname) zu welcher Zeit und mit welchem Datenvolumen anspricht, verrät mehr über Sie als sie wahrhaben wollen. Bis TLS.12 sieht die Firewall und der Proxy sowieso den TLS-Handshake und kennt daher ihre Ziele und allein an den Paketgrößen und Mustern ist sehr einfach zwischen Websurfen, Radio-Hören und Webcast zu unterscheiden.
Sie können davon ausgehen, dass auch Verbindungsnetzbetreiber und damit auch Geheimdienste diese Informationen abgreifen. Die erforderlichen Befugnisse werden ja im Schlepptau von "Antiterrormaßnahmen" immer weiter ausgedehnt und wenn sie fehlen, dann muss es immer noch jemand geben, der sich dran hält.
Aber die Inhalte selbst sind ein anderes Thema. Wenn ich in einem Forum etwas strafbares poste, dann sollte es für Ermittler nicht allzu schwer sein, diese Ziele vom Netz zu nehmen oder per Durchsuchungsbeschluss die IP-Adresse auf die Person zurückzuführen. DAs kann ich natürlich immer noch per VPN, offene Proxy-Server, Tor oder Dienste wie z.B. Freifunk - warum nicht? entziehen.
Wenn es aber jemandem gelänge an die Inhalte zu kommen, die sich da übertragen, dann ist das ein ganz anderes Kaliber. Die meisten Dienste nutzen nämlich heute z.B. "Formularbasierte Anmeldungen". Die Anmeldedaten wie Benutzername/Kennwort werden als "FORM POST" übertragen und sind nur durch die TLS-Verschlüsselung gesichert. Ohne einen zweiten Faktor bei der Anmeldung (Siehe auch Multi Faktor Authentifizierung (MFA)) könnte jemand sich dann für mich ausgeben. Er kann also Dienste ansprechen und sich damit sogar weiter hangeln.
- Viele Anwender nutzen immer noch das gleiche Kennwort bei
mehreren Diensten
Hat jemand jemand ein Kennwort entschlüsselt, sind die anderen Türen auch offen - Rücksetzdienste per Mail
Viele Dienste erlauben die Rücksetzung eines "vergessenen Kennworts", indem eine Mail mit besonderem Link an eine hinterlegte Adresse gesendet wird. Habe ich Zugriff auf das Postfach, kann ich mir also weitere Konten öffnen - Mail als MFA
Da hilft nicht einmal MFA bei besonders kritischen Diensten, wenn das Einmal-Token für MFA z.B. per Mail übermittelt wird Selbst eine SMS ist nicht ausreichend sicher
Selbst mit MFA ist es also weiter erforderlich das Kennwort zu schützen und zu sichern. Kritisch sind also alle Seiten, die eine Anmeldung verlangen, in dem das Kennwort mit übertragen wird.
Betroffene Systeme
Betroffen ist eigentlich weder Service, bei dem die Anmeldung selbst nicht per Kerberos oder NTLM besser abgesichert sind. Es betrifft also alle Dienste mit formularbasierter Anmeldung oder per Basic-Authentication. Nutzen Dienste entsprechende OAUTH-Tickets oder Cookies, die eine gewisse Zeit gültig sind, dann könnte ein Angreifer nach der erfolgreichen Anmeldung auch diese Informationen nutzen um die Session zu kapern und weiter zu führen. Der legitime Anwender würde dann vermutlich seine Sitzung mit einem Fehler verlieren und sich neu anmelden.
Beispiele für System sind
- Exchange OWA On-Premises
Die meisten Firmen stellen ihren Webzugang per Reverse Proxy ohne PreAuth ins Internet. Das ist seitens Microsoft für Exchange Hybrid sogar für EWS zumindest erforderlich. Mit Exchange 2003 hat Microsoft die Anmeldung aber auf "formularbasierte Anmeldung" umgestellt. Der große Vorteil dabei ist, dass es einen "Abmelden-Button" gibt, der dann den Cookie löscht. Bei einer Anmeldung "im Browser" muss meist der Browser geschlossen werden, damit eine Anmeldung greift. Das ist bei Kiosk-Systemen nicht immer möglich. - ADFS-Server
Wenn Sie einen ADFS-Service betreiben und keine Zertifikate für die Anmeldung nutzen, dann erfolgt auch hier aus dem Internet der Zugriff per Formular. Wenn es einen Angreifer also einfach gelingt, ihre Anmeldung am ADFS-Server abzulauschen, dann hat er kompletten Zugriff auf all ihre Office 365 Dienste. Wenn Sie dann, was üblich ist, zur Anmeldung ihre Windows Anmeldedaten nutzen, steht dem Angreifer vielleicht noch mehr offen.
Die Liste lässt sich ewig weiter führen, denn auch Twitter Facebook, Homebanking (ohne HBCI), Webhoster, Mobilfunk-Kundencenter u.a. nutzen alle eine Anmeldung per Formular. Es wäre also schon wichtig zu wissen, ob die Seite auf der Übertragungsstrecke abgefischt wird.
Root-CA und SSL Inspection
Damit die SSL-Verbindung eines Clients zu einem Server aufgebrochen und inspiziert werden kann, muss das System in der Mitte ein eigenes Zertifikat einschmuggeln, dem der Client natürlich vertraut. Die meisten Produkte machen dies in der Gestalt, dass Sie entweder selbst eine Root-CA sind, die auf den Clients dann als "Trusted" addiert werden muss oder als Subordinate einer vorhandenen FirmenCA arbeitet. Auf Windows Clients eine Zertifizierungsstelle als Trusted zu addieren, ist per Gruppenrichtlinie oder AD-Funktionen eine Sache von Minuten. Eine eigene CA ist aber per Default nicht auf die Ausstellung von bestimmten Zertifikaten beschränkt sondern kann natürlich jede Art von Zertifikat signieren und es hängt allein von der Konfiguration ab, wie diese PKI den Request vorab überprüft.
Natürlich kann ein Firmeninhaber sich darauf berufen, dass privates Surfen nicht erlaubt ist und alle Kommunikation rein dienstlich erfolgen muss. Das wird er auch schon tun, um z.B. Compliance-Anforderungen (z.B. Archiv) zu erfüllen. Aber das Aufbrechen von verschlüsselten Inhalten ist natürlich auch eine Gefahr für die Firma selbst. Der Zugang zu den Daten muss sehr gut geschützt werden.
Der Client ist relevant
Es ist gar nicht so einfach für einen Mitarbeiter zu erkennen, ob die Verbindung aufgebrochen wird. Es gibt drei Szenarien, bei denen nur in zwei Fällen eine Warnung erscheint. Das Szenario ohne Warnung ist allerdings der Standard in Firmen. Hier mal das Bild aus der Sicht einen externen Consultants, der am PC des Kunden arbeiten oder seinen eigenen Notebook verwendet.
Client | Netzwerk | Status |
---|---|---|
Kundenclient |
Kundennetzwerk |
Kritisch: Keine Warnung für SSL Inpection, Zugangsdaten können abgegriffen werden |
Eigener Rechner |
Kundennetzwerk |
Wenn der Root-CA des Kunden nicht vertraut wird, kommt eine SSL-Warnung. Wobei ich es vermeide meinen Notebook direkt in ein Kundennetzwerk anzuschließen, wenn es denn dank 802.1x nicht eh unterbunden wäre |
Eigener Rechner |
Gäste LAN/WLAN |
Üblicherweise findet hier keine SSL Inspection statt. Hier würde nämlich sehr schnell auffallen, wenn das SSL-Zertifikat von einer nicht vertrauenswürdigen CA ausgestellt würde. |
Für mich als Consultant bedeutet da aber, dass ich auf einem Kunden-Rechner mich konsequent nur mit Kundendaten an Systemen dieses Kunden anmelde aber auch nicht zum Test per OWA z.B. mal in meinem anderen Postfächern nachschaue oder eine Testmail sende. Zumindest nicht, ohne mir das Zertifikat und die ausstellende CA anzuschauen. Kritisch also immer der Punkt, wenn der Kunde einen Computerarbeitsplatz stellt, der in der Domäne des Kunden ist. Auch wenn ich einem Kunden erst mal keine böse Absicht unterstelle, so ist es vom Analysieren von HTTPS-Inhalten bis zum Ausleiten von Zugangsdaten nur ein kleiner Schritt. Ich bin sicher, dass die SSL Proxies sehr einfach einfach eine Liste der Anmeldedaten mit den URLs ausleiten können. Die Versuchung ist einfach zu groß. Das gibt es ja schon für Netzwerk-Schnüffler, die es auf unverschlüsselte Pakte abgesehen haben, z.B. Cain&Abel
Inspection erkennen
Die Schwachstelle im System der Zertifikate ist die Root-CA und das blinde Vertrauen, welches ein Client dieser Root-CA entgegenbringt. Zudem gibt es auch 3rd Party Produkte, die ungefragt eine eigene Root-CA während der Installation der Software als Admin auf ihrem PC einschmuggeln. Das kann einfach nur Unfähigkeit der Entwickler sein oder das Produkt macht schon lokal auf ihrem PC eine SSL-Inspektion. Von den üblichen Antiviren-Scannern mal abgesehen kenne und nutze ich nur das Programm Fiddler, mit dem ich absichtlich den HTTPS-Verkehr aufbreche. Es installiert auch eine lokale Root-CA, damit es als Proxy "reinschauen" kann.
Solange die RootCA des Inspecion Systems nicht als Trusted auf ihrem Computer installiert ist, sehen Sie bei einem korrekt konfigurierten Client die entsprechenden Warnung
Wenn jemand ihnen ein passende Root-Zertifikat untergeschoben hat, dann ist es fast nicht möglich zu erkennen, ob ihre SSL-Verbindung wirklich sicher ist.
Besonders kritisch sind hier Produkte, die während der Installation eine eigene RootCA still installieren und möglicherweise noch den Private Key dazu mit auf dem PC hinterlassen. Das passiert "leider" immer wieder auch bekannten Firmen, wie die folgende Liste exemplarisch zeigt:
- Sennheiser Headset Software Could Allow
Man-in-the-Middle SSL Attacks
https://www.bleepingcomputer.com/news/security/sennheiser-headset-software-could-allow-man-in-the-middle-ssl-attacks/ - beA: Schwere Panne beim "besonderen
elektronischen Anwaltspostfach"
https://www.heise.de/newsticker/meldung/beA-Schwere-Panne-beim-besonderen-elektronischen-Anwaltspostfach-3927314.html
Bundesrechtsanwaltskammer verteilt HTTPS-Hintertüre
https://www.golem.de/news/bea-bundesrechtsanwaltskammer-verteilt-https-hintertuere-1712-131845.html
Die BRAK möchte das wohl verschweigen, da der eigene Sondernewsletter https://www.brak.de/zur-rechtspolitik/newsletter/bea-newsletter/2017/sondernewsletter-v-22122017.news.html nicht mehr erreichbar ist. Stattdessen gibt es nun eine vermutlich abgewandelte Version auf https://www.brak.de/zur-rechtspolitik/newsletter/bea-newsletter/2017/sondernewsletter-v-27122017.news.html
Eine Zeitlang haben die öffentlichen Zertifizierungsstellen noch zwischen "normalen" und "Extended Validation" unterschieden. Die Zertifikate mit EV haben dann eine grüne Adressleiste angezeigt.
- Extended Validation Certificate
https://en.wikipedia.org/wiki/Extended_Validation_Certificate
Allerdings was das nur ein Bit im Zertifikat, welches eine andere Root-CA genauso ausstellen kann. Auch dürfte den meisten Anwendern es gar nicht auffallen, wenn die Adressleiste nicht ganz grün ist. Die meisten werden nicht mal auf die Verschlüsselung als solches achten. Daher fangen ja seit Ende 2018 die Browser auch an, nicht mehr HTTPS zu kennzeichnen sondern vor Webseiten ohne Verschlüsselung zu warnen.
Google hat es natürlich einfacher, da sie mit Chrome als Browser die Fingerabdrücke ihrer eigenen Zertifikate für die Google-Domänen im Code hinterlegen können. Wenn also jemand mit Chrome auf der Webseite von Google nach Informationen sucht und ein SSL-Inspection ein anderes Zertifikat unterschieben will, dann kann Chrome Alarm schlagen. Aber dann wird ein Angreifer eben die Installationsquellen von Chrome beim Download verändern. Es gibt also viele Dinge.
Ein großer Schwachpunkt sind die auch die öffentlichen Zertifizierungsstellen, die genauso schludern und Zertifikate ohne ausreichende Überprüfung ausstellen
- Iran fälscht Google-Zertifikat
https://www.n-tv.de/technik/Iran-faelscht-Google-Zertifikat-article4182286.html - Neuer SSL-Gau: Falsches Google-Zertifikat blieb fünf Wochen
unentdeckt
https://www.heise.de/security/meldung/Neuer-SSL-Gau-Falsches-Google-Zertifikat-blieb-fuenf-Wochen-unentdeckt-1333070.html - New Chromium security features, June 2011
https://blog.chromium.org/2011/06/new-chromium-security-features-june.html - Chrome 68: Certificate Transparency wird verbindlich
https://www.dmsolutions.de/blog/chrome-68-certificate-transparency/
Aber das schützt primär GMail und andere Google-Dienste aber für die Allgemeinheit ist es noch keine Lösung. Nun gibt es ja mit HSTS noch einen anderen Standard, um über den HTML-Header dem Client zu sagen, dass diese Seite für eine gewisse Zeit nur per HTTPS erreichbar sein soll. Der Browser kann sich das merken und unverschlüsselte Verbindungen ablehnen. Es schützt aber eben nicht durch eine Verschlüsselung über eine andere Root-CA.
- HTTP Strict Transport Security
https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Die Frage ist eher, wie eine Webseite eine Information zum Zertifikat so sicher veröffentlichen kann, dass kein SSL-Proxy im Weg dazwischen diese Verbindung torpedieren kann. Mit DNSSEC könnte man den Fingerprint ja im DNS hinterlegen. Aber die Abfrage per DNSSEC machen die wenigsten Clients und ein Angreifer wird natürlich genau diese Abfragen stören. Für staatliche Stellen und Internet Provider ist das sehr einfach. Ihr Client wird dann einfach davon ausgehen, dass DNSSEC nicht zur Verfügung steht oder die andere Seite keinen Thumbprint im DNS hinterlegt hat. Also ist auch das eine Sackgasse.
Soweit ich weiß, hat aber auch ein JavaScript in einer HTML-Seite keinen Zugriff auf die Informationen der SSL-Verbindung. Insofern kann z.B. eine Anmeldseite nicht wirklich prüfen, welches Zertifikat beim Client angekommen ist. Aber selbst wenn es diese Funktion gäbe, würde das SSL Inspection-System ja auch den JavaScript sehen und könnte die Überprüfung so verändern, dass immer ein "alles OK" raus kommt. Wobei das durch einen Entwickler schon erschwert werden könnte. Egal, was man sich auch überlegt, solange jemand in der Mitte schon die Daten sehen und ändern kann, weil ihr Client eben der Root-CA der Mitte vertraut, sind sie ausgeliefert.
Lösung: Digest/NTLM im Anmeldeformularen
Ich bin kein Entwickler aber ich könnte mir vorstellen, dass man ein Anmeldeformular bauen kann, welches eine Zufallszahl des Servers bezieht und das Kennwort des Anwenders wie bei NTLM damit verschlüsselt. Nur der Server auf der anderen Seite hat das Kennwort und kann das Ergebnis vergleichen. In dem Zuge wäre selbst eine unverschlüsselte Verbindung für den Anmeldeprozess unkritisch. Zumindest wenn die Verfahren stark genug sind.
- Digest access authentication
https://en.wikipedia.org/wiki/Digest_access_authentication - Integrated Windows Authentication
https://en.wikipedia.org/wiki/Integrated_Windows_Authentication
Dahingegen ist ein "Anmeldedialog" des Browsers nicht sicher, da weder für den Anwender noch den Webserver ersichtlich ist, welches Anmeldeverfahren im Hintergrund genutzt wird. Es kann auch kein Verfahren vorgeschrieben werden, da das mittlere System die starke Anmeldung einfach entfernen kann. Das kann ein Anwender bei einem Formular natürlich auch nicht sicher feststellen.
Lösung: MTLS und Client Zertifikate
Schwer zu knacken sind allerdings Anmeldungen die auf Client-Zertifikaten basieren. Bei richtiger Umsetzung werden die Schlüssel des Clients genutzt. Das Clientzertifikat ist von einer CA ausgestellt, die auf dem Server als "vertrauenswürdig" aufgeführt wird. Bei Firmen ist das in der Regel die CA der Firma. Hier kann der SSL-Inspection-Service sich kein "Client Zertifikat" mit seiner eigenen Root-CA basteln, weil der Server nicht unter der Kontrolle der Client-Firma steht. Allerdings ist die Anmeldung per Client-Zertifikat noch lange nicht üblich. Das Zertifikat muss ja sicher auf dem Client gespeichert sein. Da gibt es mehrere Optionen
- Zertifikat im Benutzerprofil
Das geht natürlich nur, wenn Sie auf ihrem PC arbeiten, auf dem das Client-Zertifikat eingespielt wurde. Das ist in der Regel ja nicht der PC einer anderen Firma sondern mit dem eigenen Computer, der dann aber auch nicht der Root-CA des SSL Inspection-Systems vertraut. Also tut sich da nichts - Zertifikat auf Smartcard
Das ist der präferierte Weg. Aber dann stellt sich die Frage, wie Sie das Zertifikat auf einem Kunden-Client nutzen können. Die wenigsten PCs haben einen SmartCard-Leser und selbst ein USB-Stick benötigt eventuell Treiber, die sie nicht installieren dürfen - PFX-Datei zum Selbst-Import
Auch das ist denkbar aber würden Sie einem Kunden-PC vertrauen, wenn dort schon HTTPS aufgebrochen wird?. Dann kann man ja auch gleich das Zertifikat kopieren und die PIN mitschreiben.
Ich würde ja viel lieber und intensiver mit Client-Zertifikaten arbeiten. Aber viele Seiten sind auf dem Auge noch blind. Vielleicht ändert sich das etwas mit U2F/FIDO-Authentifizierung.
Zwischenstand
Es ist eine nervige Situation, dass man auf einem fremden PC quasi darauf vertrauen muss, dass keine Root-CA eingebunden ist, die ein Aufbrechen des HTTPS-Verkehrs über einen Proxy erlaubt. Klar kann man Kennworte ändern aber dazu muss man erst mal herausfinden, dass jemand Sie hat. Derjenige muss ja die erlangten Daten nicht sofort verwenden. Es fällt dann, wenn überhaupt, erst später auf und ein Rückschluss auf den "Täter" ist kaum mehr möglich. Letztlich läuft es darauf hinaus, dass ich nur von "vertrauenswürdigen" Geräten überhaupt meine Anmeldedaten eingebe und alle anderen Geräte konsequent meide. Das Problem zeig aber gut auf, wie empfindlich doch Kennworte sind und wir uns langsam wirklich mal Gedanken über Einmalkennworte machen sollten, die gar keinen statischen Anteil mehr enthalten.
Sicher muss man abwägen, wie viel Schadcode man schon beim Download auf dem Gateway erwischen will, Aber es ist für Malware sehr einfach immer wieder sich zu verändern um eben nicht erkannt zu werden. Der Schutz auf dem Client und die Weiterbildung der Anwender ist viel bedeutender bei der Abwehr von Schadcode als das Risiko, dass Anmeldedaten in falsche Hände kommen. Microsoft hat ja versprochen, dass sie in einem Jahr die Kennworte ersetzen wollen.
- No password, phone sign in for Microsoft
accounts!
https://blogs.technet.microsoft.com/enterprisemobility/2017/04/18/no-password-phone-sign-in-for-microsoft-accounts/
Weitere Links
- Die Zertifikatsstelle in der eigenen Firma
- Max Root-CA, oder wo Vertrauen schadet
- Let's Encrypt
- TLS 1.2 nforcement
- TLS Handshake mit NetMon
- TLS Security
- Freifunk - warum nicht?
- Steve Gibson's Fingerprint service detects SSL man in the
middle spying
https://www.computerworld.com/article/2475102/cybercrime-hacking/steve-gibson-s-fingerprint-service-detects-ssl-man-in-the-middle-spying.html - Cain&Abel
http://www.oxid.it/cain.html
Schneidet unverschlüsselten Netzwerkverkehr mit und extrahiert gezielt Kennworte, z.B. POP3, IMAP4, HTTP u.a. -
Microsoft Authenticator ermöglicht Anmeldung ohne Passwort
https://www.zdnet.de/88292955/microsoft-authenticator-ermoeglicht-anmeldung-ohne-passwort/