SSL/TLS-Inspektion und Man-in-the-Browser-Angriffe

HTTPS macht inzwischen mehr als 90 % des Webdatenverkehrs aus – einschließlich Malware-Downloads, C2-Kanälen und Datenexfiltration. Sicherheitstools am Perimeter, die TLS nicht überprüfen können, sehen nur verschlüsselte Datenblöcke. Dadurch entsteht eine Schwachstelle, die Angreifer gezielt ausnutzen. SSL/TLS-Inspektion (auch SSL-Interception, SSL-Bumping oder Deep Packet Inspection für HTTPS genannt) ermöglicht es Sicherheitsgateways, HTTPS-Datenverkehr zu entschlüsseln, zu überprüfen und erneut zu verschlüsseln, bevor er den Endpunkt erreicht. Diese Sichtbarkeit ist für Webinhaltsfilterung, DLP und Anti-Malware-Scans in Umgebungen unerlässlich, in denen der Großteil des Datenverkehrs über HTTPS erfolgt.

Bei der SSL-Inspektion handelt es sich technisch um einen kontrollierten Man-in-the-Middle-Angriff, der von der eigenen Sicherheitsinfrastruktur der Organisation durchgeführt wird. Der Ablauf: Schritt 1: Der Client stellt mithilfe des von der Unternehmens-CA signierten Proxy-Zertifikats eine TLS-Verbindung zum Proxy her. Schritt 2: Der Proxy stellt mithilfe des echten Zertifikats des Servers eine separate TLS-Sitzung mit dem tatsächlichen Server her. Schritt 3: Der Proxy entschlüsselt den Datenverkehr vom Client, überprüft ihn, verschlüsselt ihn erneut und leitet ihn an den Server weiter (und umgekehrt). Der Client vertraut dem Zertifikat des Proxys, weil das Zertifikat der Unternehmens-CA über MDM oder Gruppenrichtlinien auf allen verwalteten Endpunkten vorinstalliert wurde.

Nicht jeder Datenverkehr sollte überprüft werden. Organisationen nehmen typischerweise Kategorien aus, die rechtlich oder ethisch sensible Daten übertragen: Banking- und Finanz-Websites, Gesundheitsportale, juristische Recherchedatenbanken, URLs für Certificate Transparency und OCSP (um die Zertifikatsvalidierung nicht zu beeinträchtigen) sowie Websites mit Certificate Pinning (die neu signierte Zertifikate ablehnen und dadurch die Anwendung funktionsunfähig machen). Ausnahmen werden in der Inspektionsrichtlinie als Umgehungsliste gepflegt. In einigen Rechtsordnungen können Gesetze zur Überwachung von Mitarbeitern die Inspektion des persönlichen Surfverhaltens einschränken, sodass eine klare Offenlegung in Richtlinien zur akzeptablen Nutzung erforderlich ist.

Certificate Pinning ist ein Verfahren, bei dem eine Anwendung das erwartete Zertifikat oder den öffentlichen Schlüssel eines bestimmten Servers fest einprogrammiert und die Verbindung ablehnt, wenn das Zertifikat nicht übereinstimmt – selbst wenn es gültig ist und vom CA-Speicher des Betriebssystems als vertrauenswürdig eingestuft wird. Dadurch wird die SSL-Inspektion unterbrochen, weil das vom Proxy neu signierte Zertifikat nicht mit dem festgelegten Wert übereinstimmt. Mobile Apps (Banking- und Zahlungs-Apps) verwenden Certificate Pinning häufig als Schutz gegen MitM-Angriffe. Unternehmen müssen die Inspektion für Apps mit Pinning umgehen, da sie andernfalls nicht funktionieren. Das bedeutet zugleich, dass Angreifer, die SSL-Inspektionen durch ihre Malware umgehen möchten, selbst Pinning implementieren können.

SSL-Stripping ist ein Man-in-the-Middle-Angriff, bei dem ein Angreifer HTTPS-Datenverkehr abfängt und auf HTTP herabstuft, sodass er den Inhalt im Klartext lesen und verändern kann. Der Angriff funktioniert bei Verbindungen, die zunächst mit HTTP beginnen und anschließend zu HTTPS umleiten: Der Angreifer fängt die anfängliche HTTP-Anfrage ab, hält eine HTTP-Verbindung zum Opfer aufrecht, stellt gleichzeitig eine HTTPS-Verbindung mit dem legitimen Server her und leitet den Datenverkehr transparent weiter. Aus Sicht des Opfers scheint die Website HTTP zu verwenden. HTTP Strict Transport Security (HSTS) schützt vor SSL-Stripping, indem es Browser anweist, für eine Domäne immer HTTPS zu verwenden, selbst wenn der Benutzer HTTP eingibt.

Ein Man-in-the-Browser-(MitB)-Angriff ist eine Form von Banking-Trojaner, der sich in den Webbrowser einschleust – als schädliche Erweiterung oder durch die Injektion in den Browserprozess – und Webseiten sowie Transaktionen unbemerkt für den Benutzer verändert. Anders als ein netzwerkbasierter MitM arbeitet MitB innerhalb der verschlüsselten Sitzung auf der Browserebene, sodass TLS keinen Schutz bietet. MitB-Malware (Zeus, SpyEye) kann Zahlungsbeträge ändern, Empfängerkontonummern manipulieren, Einmalpasswörter abfangen und Formulare nach ihrer Ausfüllung durch den Benutzer unbemerkt verändern. Die Änderungen erfolgen nach der TLS-Entschlüsselung und bevor der Benutzer die gerenderte Seite sieht.

MitB-Malware klinkt sich auf der Anwendungsebene in Browser-APIs ein. Unter Windows injiziert sie mithilfe von DLL-Injection oder COM-Hijacking Code in Browserprozesse (Chrome, Firefox, IE) und klinkt sich anschließend in JavaScript-Funktionen sowie APIs zur DOM-Manipulation ein. Wenn eine Benutzerin oder ein Benutzer die Bank-Website aufruft, fängt die Malware das JavaScript ab, das die Seite und die Transaktionsbestätigung rendert, und ändert das Empfängerkonto in das Konto der angreifenden Person. Der Server sieht die korrekte Transaktion; in den HTTPS-Protokollen auf der Serverseite ist nichts Ungewöhnliches zu erkennen. Die Benutzerin oder der Benutzer sieht die korrekte Bestätigung – einschließlich des beabsichtigten Betrags –, während die tatsächliche Überweisung auf das Konto der angreifenden Person geht.

Der Schutz vor MitB erfordert mehrschichtige Kontrollen. Bei der Browser-Isolierung (Menlo Security, Zscaler Browser Isolation) wird das Rendern des Browsers in einer entfernten Cloud-VM ausgeführt und es werden nur Pixel an den Bildschirm der Benutzerin oder des Benutzers übertragen – die Malware kann sich nicht in einen Browserprozess injizieren, der in einer entfernten Umgebung ausgeführt wird. Transaktionsverifizierung: Banken bestätigen Transaktionsdetails (Betrag + Empfänger) über einen Out-of-Band-Kanal (eine SMS-OTP, die die Transaktionsdetails enthält), sodass die Benutzerin oder der Benutzer überprüfen muss, was der Server tatsächlich empfangen hat. Ein Endpoint-EDR, das DLL-Injection in Browserprozesse erkennt, kann MitB-Infektionen identifizieren. Eine Allowlist für Browsererweiterungen verhindert schädliche Erweiterungen.

Schädliche Browsererweiterungen stellen eine erhebliche Bedrohung für Endgeräte dar. Erweiterungen verfügen über weitreichende Berechtigungen – sie können Seiteninhalte lesen, Anfragen ändern, Formularübermittlungen abfangen und auf Cookies zugreifen. Eine Erweiterung, die sich als nützliches Werkzeug (Werbeblocker, Dark Mode) ausgibt, kann Zugangsdaten abgreifen, Werbung einschleusen, Datenverkehr umleiten oder als MitB-Agent fungieren. Unternehmenskontrollen: Verwenden Sie Group Policy oder MDM, um die Installation von Erweiterungen auf eine genehmigte Allowlist zu beschränken. Sperren Sie die Installation von Erweiterungen aus anderen Quellen als dem Chrome Web Store oder Firefox Add-ons. Überprüfen Sie regelmäßig die auf verwalteten Endgeräten installierten Erweiterungen auf Richtlinienverstöße.

Organisationen, die eine SSL-Inspektion implementieren, müssen die Auswirkungen auf den Datenschutz der Beschäftigten berücksichtigen. In vielen Rechtsordnungen und nach vielen arbeitsrechtlichen Vorschriften ist vor der Überwachung verschlüsselten Datenverkehrs ein eindeutiger Hinweis erforderlich. Bewährte Vorgehensweisen: Veröffentlichen Sie eine Richtlinie zur akzeptablen Nutzung (AUP), in der ausdrücklich darauf hingewiesen wird, dass Netzwerkverkehr einschließlich HTTPS inspiziert werden kann; lassen Sie die Beschäftigten die AUP während der Einarbeitung bestätigen; implementieren Sie Umgehungskategorien für persönliche Bank- und medizinische Websites; und speichern Sie Protokolle des entschlüsselten Datenverkehrs nur so lange wie nötig (typischerweise 30–90 Tage). Eine Rechtsberatung sollte das Inspektionsprogramm vor der Einführung prüfen, insbesondere in EU-Ländern, in denen die DSGVO strengere Grenzen für die Überwachung von Beschäftigten setzt.

Certificate Transparency ist ein Framework (RFC 6962), das verlangt, dass alle öffentlich vertrauenswürdigen TLS-Zertifikate in öffentlich prüfbaren, nur erweiterbaren CT-Protokollen protokolliert werden, bevor Browser ihnen vertrauen. CT ermöglicht es Domaininhabern, nach fehlerhaft ausgestellten Zertifikaten zu suchen: Wenn eine angreifende Person eine CA irgendwie dazu bringt, ein Zertifikat für Ihre Domain auszustellen (wie 2011 bei DigiNotar geschehen), ermöglichen CT-Protokolle eine Erkennung nahezu in Echtzeit. Mit Tools wie crt.sh können Sicherheitsteams CT-Protokolle nach allen für ihre Domain ausgestellten Zertifikaten durchsuchen. Browser setzen CT durch, indem sie einen Nachweis der Protokollaufnahme (Signed Certificate Timestamps, SCTs) verlangen, der in den TLS-Handshake eingebettet ist.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Die SSL/TLS-Inspektion entschlüsselt HTTPS-Datenverkehr an einem Proxy mithilfe eines von verwalteten Endgeräten vertrauenswürdigen Unternehmens-CA-Zertifikats, inspiziert ihn und verschlüsselt ihn anschließend wieder. SSL-Stripping stuft HTTPS auf HTTP herab und wird durch HSTS verhindert. Man-in-the-Browser-Angriffe schleusen sich oberhalb der TLS-Schicht in den Browserprozess ein, um Transaktionen unbemerkt zu verändern. Als Gegenmaßnahmen sind Browser-Isolierung oder eine Out-of-Band-Transaktionsverifizierung erforderlich. Als Nächstes geht es darum, unsichere Protokolle durch ihre sicheren Entsprechungen zu ersetzen.