Kriminelle tricksen Web-Filter aus
Malware-Verteilung per SSL/TLS
Die SophosLabs haben die Nutzung von SSL/TLS bei der Verteilung von Malware und der Kommunikation infizierter Rechner mit C2-Servern (Command and Control) untersucht. Das Ergebnis: In beiden Fällen findet mehr als ein Viertel der Kommunikation mittlerweile SSL/TLS-verschlüsselt statt. Kriminelle haben offenbar erkannt, dass sie damit der Erkennung durch Web-Filter und IPSLösungen (Intrusion Protection System) besser entgehen können.
Die Gründe für die Kommunikation per TLS (Transport Layer Security, in einer Vorversion als Secure Sockets Layer oder kurz SSL bekannt) sind die klassischen Schutzziele Vertraulichkeit, Authentizität und Integrität. Die Vertraulichkeit ist bei SSL/TLS durch Verschlüsselung realisiert – und bei Verwendung aktueller Verschlüsselungsalgorithmen und ausreichender Schlüssellängen auch einfach sicherzustellen. Dabei tauschen die Nutzer mittels asymmetrischer Verschlüsselung einen symmetrischen Sitzungsschlüssel aus, mit dem dann eine SSL/TLS-Sitzung ressourceneffizient chiffriert wird.
Elektronische Zertifikate garantieren die Authentizität des Kommunikationspartners, etwa eines Web-Servers, und die Integrität der Kommunikation, also die Gewissheit, dass niemand die Kommunikation manipuliert hat. Eine Zertifizierungsstelle gewährleistet dabei als unabhängige externe Partei die Vertrauensstellung, also die Zugehörigkeit eines Web-Server-Zertifikats zu einer realen oder juristischen Person. Dies geschieht, indem die Zertifizierungsstelle nach Überprüfung der Identität des Antragstellers dessen Zertifikat für seinen Web-Server digital unterschreibt. In den Web-Browsern sind die Zertifikate der Zertifizierungsstellen fest „eingebrannt“, sodass der Browser bei jedem Web-Server-Zertifikat überprüfen kann, ob es von einer vertrauenswürdigen Zertifizierungsstelle unterschrieben ist. Dies verhindert unter anderem „Man in der Middle“-Angriffe, bei denen ein Angreifer sich in eine Kommunikation zwischenschaltet und sie dadurch mitlesen oder manipulieren kann. Genau das ist es aber, was Unternehmen die SSL/TLS-Entschlüsselung erschwert oder in manchen Fällen unmöglich macht.
SSL/TLS-Verbindungen untersuchen
Für Unternehmen ist es durchaus sinnvoll, SSL/TLS-Verbindungen zu untersuchen. Dafür gibt es mehrere Gründe. So müssen sie erstens sicherstellen, dass keine unsicheren Verschlüsselungsverfahren zum Einsatz kommen. Im Rahmen der SSL/TLS-Verschlüsselungsprotokolle gibt es ältere und manchmal zu Kompatibilitätszwecken von Web-Servern und Browsern eingesetzte Verschlüsselungs- oder Hash-Algorithmen, die nach dem heutigen Stand der Technik nicht mehr sicher sind.
Zweitens müssen Unternehmen dafür sorgen, dass Anwender nur mit vertrauenswürdigen Gegenstellen kommunizieren. Dazu gehört beispielsweise das Unterbinden von Kommunikation zu Web-Servern, deren Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle unterschrieben ist oder das zwischenzeitlich widerrufen wurde. Drittens ist zu vermeiden, dass Schadsoftware per SSL/TLS übertragen wird. Zu diesem Zweck muss die per Malware-Scanner oder Sandboxing zu untersuchende Datei unverschlüsselt vorliegen. Viertens schließlich gilt es, die Inhalte einer Kommunikation zu überprüfen und gegebenenfalls einzuschränken. Dazu gehört insbesondere die Möglichkeit sicherzustellen, dass nur Applikationen kommunizieren, die das Unternehmen explizit zugelassen hat.
Die Schwierigkeit der SSL/TLS-Entschlüsselung besteht darin, dass die IT-Abteilung dazu de facto die SSL/TLS-Sicherheitsmechanismen unterlaufen muss, indem das entsprechende SSL/TLS-Entschlüsselungs-Gateway praktisch als „Man in the Middle“ agiert. Denn um den Netzwerkverkehr zu inspizieren und je nach Inhalt oder anderen Kriterien einschränken zu können, muss das Gateway zumindest Teile der Daten im Klartext analysieren. Die SSL/TLS-Kommunikation wird zunächst entschlüsselt, dann analysiert und schließlich wieder verschlüsselt zum Zielrechner geschickt.
Dazu fangen die SSL/TLS-Entschlüsselungs-Gateways den Verbindungsaufbau ab und geben vor, der angesprochene SSL/TLS-Kommunikationspartner zu sein. Gleichzeitig baut das Gateway als Client per HTTPS eine Verbindung zum tatsächlichen Endpunkt – etwa einem Web-Server – auf. Auf diese Weise kann es die Verschlüsselungsverfahren, Zertifikate und Inhalte überprüfen und je nach Richtlinie einschränken. Die Herausforderung liegt darin, dass die Client-Anwendung die am Gateway abgefangene und terminierte SSL/TLS-Verbindung als vertrauenswürdig einstuft. Denn das Gateway stellt dabei für den Zugriff auf jeden Web-Server während der Übertragug ein neues Zertifikat aus und unterschreibt es selbst. Damit dieser Mechanismus funktioniert, muss die Client-Anwendug das Zertifikat des Gateways ebenfalls als vertrauenswürde Zertifizierungsstelle ansehen.
Bei Browsern gibt es genau zu diesem Zweck einen Mechanismus, mit dem sich weitere vertrauenswürde Zertifizierungsstellen hinzufügen lassen. Aus diesem Grund ist SSL/TLS-Entschlüsselung bei Browser-basierten Anwendungen in der Regel kein Problem. Schwierigkeiten bereiten an dieser Stelle Applikationen, die ebenfalls per SSL/TLS kommunizieren und nur festgelegte Server-Zertifikate akzeptieren (Certificate Pinning). Beispiele sind Windows-Updates, Microsoft Office 365, der Dropbox-Client oder iTunes. Aus diesen Gründen müssen moderne SSL/TLS-Entschlüsselungs-Gateways folgende Funktionen beinhalten:
- eine vom Hersteller gepflegte Liste unsicherer SSL/TLS-Verfahren samt Möglichkeit, diese Verfahren automatisch zu blockieren,
- eine vom Hersteller gepflegt Liste von Zielen und Applikationen, bei denen SSL/TLS-Entschlüsselung nicht funktioniert und die man deshalb von der Entschlüsselung ausnehmen kann, sowie
- eine Möglichkeit der Kontrolle und Einschränkung der Applikationen, die per SSL/TLS kommunizierend.
Gerade der letzte Punkt stellt Unternehmen vor große Herausforderungen. Denn selbst wenn eine SSL/TLS-Entschlüsselung erfolgt, muss ein traditionelles Web-Gateway versuchen, die kommunizierende Applikation anhand von Kommunikationsparametern zu identifizieren. Dazu gehören die IP-Adresse und der Name des Web-Servers oder der User Agent, mit dem eine Client-Anwendung sich dem Web-Server gegenüber beispielsweise als Chrome oder Safari for iOS identifiziert, damit die Website im passenden Format dargestellt wird. Und da die meisten Web-Gateways diese Browser zulassen, nutzen Kriminelle diesen Umstand aus, indem sie die C2-Kommunikation infizierter Rechner mit genau diesen Merkmalen versehen. Die Malware identifiziert sich dann auf einem infizierten Client ebenfalls gegenüber dem SSL/TLS-Gateway als Chrome und wird in der Regel durchgelassen.
Security Heartbeat
Um dem entgegenzuwirken, ist eine Security-Lösung ratsam, die einen Kommunikationskanal (Security Heartbeat) zwischen den Endpoints und Firewall schafft. Über diesen erfährt die Firewall, welche Anwendung tatsächlich auf der Workstation oder dem Server die SSL/TLS-Verbindung aufbauen möchte. Diese Funktion kann das IT-Team auch verwenden, um Schatten-IT im Unternehmen drastisch einzuschränken: Die IT legt dazu einfach fest, dass nur vom Unternehmen autorisierte Anwendungen via Firewall und SSL/TLS-Entschlüsselungs-Gateway kommunizieren dürfen.
Michael Veit ist Technology Evangelist bei Sophos, www.sophos.com.
Lesen Sie mehr zum Thema
