Subdomains unter der Lupe: SSL Transparency Logs

Seit der Gründung der Zertifizierungsstelle Let’s Encrypt im Jahr 2014 und Inbetriebnahme Ende 2015 wurden bislang mehr als 182 Millionen aktive Zertifikate und 77 Millionen aktive Domänen registriert (Stand 05/2021). [1]

Um die Zertifizierungsvorgänge transparenter zu machen, werden dabei alle Registrierungen öffentlich protokolliert. Im Folgenden betrachten wir, wie diese Information aus der Perspektive eines Angreifers genutzt werden kann, um Subdomänen ausfindig zu machen und welche Maßnahmen Unternehmen treffen können, um diese zu schützen.

Let’s Encrypt

Mittels Let’s Encrypt wurde die Art und Weise der Handhabung von SSL-Zertifikaten revolutioniert. Jeder, der heutzutage einen Domainnamen besitzt, ist in der Lage, ein kostenfreies SSL-Zertifikat über Let’s Encrypt zu beziehen. Mittels quelloffener Tools wie z.B. Certbot kann die Beantragung und Konfiguration von SSL-Zertifikaten intuitiv, sicher und vor allem automatisiert stattfinden. Zertifikate werden automatisch erneuert und dazugehörige Webserver-Dienste wie Apache oder Nginx im Nachhinein vollautomatisch neugestartet. Das Zeitalter von teuren SSL-Zertifikaten und komplexen, manuellen Konfigurationseinstellungen ist nahezu vorüber.

stats 1 Wachstum von Let’s Encrypt

Certificate Transparency (CT) Logs

Weiterhin trägt Let’s Encrypt zur Transparenz bei. Alle ausgestellten Let’s Encrypt Zertifikate werden zu „CT Logs“ gesendet sowie ebenfalls in einem eigenständigen Logging-System mittels Google Trillian in der AWS Cloud von Let’s Encrypt selbst protokolliert. [2]

Die Abkürzung CT steht hierbei für Certificate Transparency und erklärt sich wie folgt:

„Certificate Transparency (CT) ist ein System zur Protokollierung und Überwachung der Ausstellung eines TLS Zertfikates. CT ermöglicht es jederman, Zertifikatsausstellungen zu überprüfen und zu überwachen […].“ [2]

Certificate Transparency war eine Reaktion auf die Angriffe auf DigiNotar [3] und anderen Certificate Authorities im Jahr 2011. Diese Angriffe zeigten, dass die fehlende Transparenz in der Arbeitsweise von CAs ein erhebliches Risiko darstellten. [4]

Durch CT ist es demnach jeder Person mit Zugriff zum Internet möglich, ausgestellte Zertifikate öffentlich einzusehen und zu überprüfen.

Problemstellung

Die Beantragung und Einrichtung von Let’s Encrypt SSL-Zertifikaten erweist sich demnach als äußerst einfach. Dies zeigt ebenfalls die hohe Anzahl an täglich ausgestellten Zertifikaten durch Let’s Encrypt. Pro Tag werden hierbei über 2 Millionen Zertifikate ausgestellt und deren Ausstellung transparent protokolliert (Stand 05/2021) [5].

issued certs Pro Tag ausgestellte Let’s Encrypt-Zertifikate

Zertifikate werden hierbei für allerlei Systeme oder Vorhaben ausgestellt. Seien es Produktivsysteme, Testumgebungen oder temporäre Projekte. Nutzer oder Unternehmen sind in der Lage, kostenfreie Zertifikate für ihre Domänen und Subdomänen zu beantragen. Ebenfalls stehen Wildcard-Zertifikate seit dem Jahr 2018 zur Verfügung. Alles transparent protokolliert und öffentlich einsehbar.

Transparenz ist doch klasse, oder?

Aufgrund der Tatsache, dass alle ausgestellten Zertifikate transparent protokolliert werden, können diese Informationen von jeder Person eingesehen werden. Zu diesen Informationen zählt z.B. der Common Name eines Zertifikats, welcher den Domänennamen oder die Subdomäne eines Dienstes preisgibt. Ein Angreifer oder Pentester ist dadurch in der Lage, den Hostnamen und potenziell sensitive Systeme in den Certificate Transparency Logs zu identifizieren.

Dies stellt auf erste Sicht kein Problem dar, unter der Prämisse, dass die Systeme bzw. angebotenen Dienste hinter den Domänennamen gewollt öffentlich erreichbar sind, aktuelle Softwareversionen einsetzen und ggf. durch eine Authentifizierung vor unbefugten Zugriffen geschützt sind.

Unsere Erfahrung bei Penetrationstests und Sicherheitsanalysen zeigt jedoch auf, dass oftmals Systeme ungewollt im Internet preisgegeben werden. Entweder geschieht dies aus Versehen oder unter der Annahme, dass ein Angreifer ja den Hostnamen benötige, um überhaupt Zugriff zu erhalten. Weiterhin haben viele Unternehmen aufgrund von gewachsenen Strukturen keine Übersicht mehr über Ihre vorhandenen und aktiven IT-Assets. Durch ein Ausschalten der Indexierung von Webseiteninhalte (z.B. durch Google) wird zusätzlich ein vermeintlicher Schutz bei Testumgebungen implementiert. Ein Angreifer habe demnach keinerlei Kenntnisse über das System und man sei sicher. Entwicklern oder IT-Admins ist zudem meist nicht bekannt, dass die Beantragung von SSL-Zertifikaten protokolliert wird und hierdurch Domänennamen öffentlich eingesehen werden können.

Auslesen von CT-Logs

Um auf die Informationen öffentlicher CT-Logs zugreifen zu können, gibt es mittlerweile eine Vielzahl von Methoden. Diese Methoden kommen oftmals in so genannten Open Source Intelligence (OSINT) Operationen zum Einsatz, um interessante Informationen und Angriffsvektoren eines Unternehmens zu identifizieren. Auch wir als Pentest Factory greifen auf diese Methoden und Webdienste zu, um bei unserer passiven Reconnaissance an interessante Systeme unserer Kunden zu gelangen.

Ein bekannter Webdienst lautet: https://crt.sh/

certsh 1 Beispielhafter Auszug aus öffentlichen CT-Logs der Domäne pentestfactory.de

Weiterhin bestehen eine Vielzahl automatisierter Skripte im Internet (z.B. GitHub), um die Informationen auch automatisiert extrahieren zu können.

Der Mythos des Wildcard-Zertifikats

Nach Erkenntnis der Möglichkeit zum Auslesen von CT-Logs und der daher eingehenden, potenziellen Problematik, kommen Unternehmen oftmals auf eine grandiose Idee. Anstelle der Beantragung von individuellen SSL-Zertifikaten für unterschiedliche Subdomänen und Dienste, wird ein allgemeines Wildcard-Zertifikat generiert und über alle Systeme bzw. Dienste eingerichtet.

Die Subdomänen werden hierdurch nicht mehr in Transparency Logs veröffentlicht, da der Common Name des Zertifikats lediglich einen Wildcard-Eintrag wie z.B. *.domain.tld darstellt. Externe Angreifer sind dadurch nicht mehr in der Lage, die unterschiedlichen Subdomains und Dienste eines Unternehmens zu enumerieren. Problem gelöst, oder?

Teilweise. Korrekterweise werden die Hostnamen oder Subdomains nicht mehr in Transparency Logs veröffentlicht. Jedoch bestehen weiterhin viele Möglichkeiten für einen Angreifer, passiv an interessante Dienste bzw. Subdomains eines Unternehmens zu gelangen. Die unterliegende Problematik, dass Systeme ggf. ungewollt im Internet stehen, veraltete Software mit öffentlichen Schwachstellen einsetzen oder keinen Schutz vor unbefugten Zugriffen implementieren, besteht weiterhin. Der Ansatz, mithilfe eines Wildcard-Zertifikats für mehr Sicherheit zu sorgen, bei dem Informationen lediglich versteckt werden, nennt man Security through Obscurity. In Wirklichkeit wird die Sicherheit eines Unternehmens durch die Wiederverwendung eines einzigen Wildcard-Zertifikats über mehrere Dienste und Server verringert.

Ein Angreifer kann beispielsweise einen Brute-Force-Angriff mit Hilfe einer großen Liste oft genutzter Domänennamen durchführen. Öffentliche DNS-Server wie Google (8.8.8.8) oder Cloudflare (1.1.1.1) geben hierbei Rückmeldung, ob eine Domäne erfolgreich aufgelöst werden kann oder nicht. Dies gibt einem Angreifer erneut die Möglichkeit, interessante Dienste und Subdomänen zu identifizieren.

gobuster 2
Beispielhafter Brute-Force-Angriff auf die Domäne pentestfactory.de zur Enumeration valider Subdomains

Die Gefahren eines Wildcard-Zertifikats

Von der Wiederverwendung eines Wildcard-Zertifikats über mehrere Subdomains und unterschiedlichen Servern wird dringend abgeraten. Die Problematik liegt hierbei in der Wiederverwendung des Zertifikats.

Sollte es einem Angreifer gelingen, einen Webserver erfolgreich zu kompromittieren, der ein Wildcard-Zertifikat einsetzt, so muss das Zertifikat als vollständig kompromittiert angesehen werden. Die Vertraulichkeit und Integrität des Datenverkehrs zu jedem Dienst eines Unternehmens, der das Zertifikat einsetzt, wird dadurch gefährdet. Ein Angreifer, im Besitz des Wildcard-Zertifikats, wäre in der Lage, den Datenverkehr von allen Diensten, die das Zertifikat verwenden, zu entschlüsseln, auszulesen oder sogar zu verändern. Ein Angreifer muss sich hierbei in einer Man-in-the-Middle (MitM) Position zwischen Client und dem Server befinden, um den Datenverkehr abfangen zu können. Dieser Angriff ist demnach nicht trivial, jedoch von versierten Angreifern praktisch durchführbar.

Wäre bei dem obigen Angriff anstelle eines Wildcard-Zertifikats ein einzigartiges SSL-Zertifikat für jede Domäne/Dienst verwendet worden, so wäre der Angreifer lediglich in der Lage gewesen, den Datenverkehr der kompromittierten Domäne zu attackieren. Anderweitige Domänen und Unternehmensdienste wären hierbei nicht betroffen, da einzigartige Zertifikate zum Einsatz gekommen wären und lediglich eines davon erfolgreich kompromittiert wurde. Das Unternehmen müsste demnach lediglich ein einzelnes Zertifikat widerrufen sowie neu ausstellen und nicht das umfangreich wiederverwendete Wildcard-Zertifikat über mehrere Server und Dienste. Weiterhin kann der Schaden durch die Verwendung von einzigartigen Zertifikaten reduziert und im Falle eines erfolgreichen Angriffs in seinem Umfang bemessen werden. Unternehmen wissen dann genau, welches Zertifikat für welche Domäne oder Dienst kompromittiert wurde und wo gegebenenfalls bereits Angriffe stattgefunden haben können. Bei der Verwendung von Wildcard-Zertifikaten und eines erfolgreichen Angriffs sind potenziell alle Domänen und Dienste kompromittiert und die Auswirkungen des Schadens undurchsichtig bzw. schwer einzuschätzen.

Weitere Informationen über Wildcard-Zertifikate:

Empfehlung

Seien Sie sich stets bewusst, dass Angreifer an viele Informationen über Ihr Unternehmen gelangen können. Seien es öffentliche Quellen oder aktive Tests zum Erhalt von wertvollen Informationen. Die Sicherheit und Widerstandsfähigkeit eines Unternehmens steht und fällt mit dem schwächsten Kettenglied der IT-Infrastruktur. Nehmen Sie allgemein Abstand von Security through Obscurity Praktiken und halten Sie Ihre Systeme stets auf einem aktuellen Stand (Patch-Management).

Stellen Sie vielmehr sicher, dass alle Ihre öffentlich erreichbaren Systeme gewollt im Internet stehen und eine Zugriffskontrolle implementieren, falls notwendig. Entwicklungsumgebungen oder Testinstanzen sollten stets vor der Öffentlichkeit verborgen bleiben und lediglich dem Unternehmen selbst und seinen Entwicklern zur Verfügung stellen. Dies kann über eine Firewall-Whitelist Ihrer unternehmensweiten IP-Adressen erfolgen oder einfach halber mittels einer vorgeschalteten Abfrage von Nutzername und Passwort (z.B. mittels Basic-Authentication für Webdienste). Setzen Sie hierbei ein komplexes Passwort mit einer ausreichend großen Länge (> 12 Zeichen) ein.

SSL-Zertifikate sollten den exakten (Sub)Domänennamen im Common Name des Zertifikats definieren sowie von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt worden sein. Stellen Sie weiterhin sicher, dass das Zertifikat gültig ist und vor Ablauf frühzeitig erneuert wird. Weiterhin wird empfohlen, lediglich starke Algorithmen für die Hash-Signierung des Zertifikats zu verwenden, wie z.B. SHA-256. Von der Verwendung des veralteten SHA-1 Algorithmus sollte Abstand genommen werden, da dieser anfällig gegenüber praktischen Kollisions-Angriffen ist [6].

Professionelle Unterstützung

Sie sind sich unsicher, welche Informationen über Sie im Internet kursieren und welche Systeme öffentlich aus dem Internet erreichbar sind? Beauftragen Sie eine passive Reconnaissance über unseren Pentest Konfigurator und wir tragen diese Informationen gerne für Sie zusammen.

Sie interessieren sich für die Widerstandsfähigkeit Ihrer öffentlichen IT-Infrastruktur gegenüber externen Angreifern? Sie möchten das schwächste Glied Ihrer IT-Assets identifizieren und Ihre SSL-Konfiguration technisch überprüfen lassen? Dann beauftragen Sie einen Penetrationstest Ihrer öffentlichen IT-Infrastruktur über unseren Pentest Konfigurator.

Quellen

[1] https://letsencrypt.org/de/stats/#
[2] https://letsencrypt.org/de/docs/ct-logs/
[3] https://www.eff.org/de/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
[4] https://certificate.transparency.dev/community/
[5] https://letsencrypt.org/de/stats/#
[6] https://portswigger.net/daily-swig/researchers-demonstrate-practical-break-of-sha-1-hash-function

Code-Assisted Pentests

Zahlreiche Unternehmen setzen auf regelmäßige Penetrationstests, um ihre Anwendungen und IT-Infrastrukturen auf Schwachstellen zu prüfen. Meist wird hier aus der Sicht eines externen Angreifers mit einem Black-Box Ansatz, also ohne Informationen über die Anwendung oder Infrastruktur, getestet. Dies ist in vielen Situationen ein Kompromiss aus Testtiefe und der verfügbaren Testzeit. Ein beauftragter Penetrationstest hat das Ziel, in einer definierten Zeit möglichst viele potenzielle Schwachstellen aufzufinden.

Bei einem Code-Assisted Pentest steht dem Pentester der Quellcode oder zumindest ein Auszug relevanter Quellcode-Teile während der Analyse zur Verfügung. Diese Analysemethode bringt wesentliche Vorteile hinsichtlich der Effektivität und der Prüftiefe eines Pentests mit sich.

Im Folgenden betrachten wir die Vorteile aus Unternehmenssicht sowie konkrete Probleme, die sich für einen Tester ergeben und wie diese mit einem Code-Assisted Pentest gelöst werden können.

Code-Assisted Pentesting bedeutet Effizienz

Viele Penetrationstest gehen von der Annahme aus, dass ein möglicher Angriff durch einen externen Hacker nachgestellt werden soll. Die Frage, die oft hinter der Beauftragung steht, lautet: Kann ein externer Angreifer meine Anwendung kompromittieren?

Dementsprechend wird die Vorgehensweise eines Angriffs von außen oftmals gewählt und entspricht üblicherweise einem Black-Box-Ansatz. Der Pentester hat also keinerlei Informationen über die Anwendung, wie vermeintlich ein echter Hacker. Allerdings muss berücksichtigt werden, dass ein Pentester auch nur eine endliche Zeit für seinen Pentest zur Verfügung hat. Dies trifft auf einen realen Angreifer nicht unbedingt in gleichem Maße zu. Daher ist der Pentester darauf angewiesen, möglichst effektiv in der vorgegebenen Zeit zu testen.

Durch einen Code-Assisted Pentest kann sich der Testfokus hauptsächlich auf das Auffinden von Schwachstellen konzentrieren und ist beispielsweise nicht davon abhängig, eine zeitraubende, initiale Informationsgewinnungsphase (Enumeration) durchgeführt zu haben. Die folgenden Beispiele veranschaulichen die Probleme bei einem Black-Box-Ansatz.

Problematik 1: Enumerieren von Verzeichnissen und Endpunkten

Zu Beginn eines jeden Penetrationstests ist es notwendig, die Struktur der Applikation kennenzulernen und so viele Endpunkte wie möglich ausfindig zu machen. Die einzelnen Endpunkte interagieren mit dem Nutzer und können potenziell Schwachstellen beinhalten.

Da der Tester von außen auf den Applikationsserver zugreift, hat er nicht die Möglichkeit sich die Verzeichnis- oder Routenstruktur auf dem Server selbst anzusehen. Er muss somit eine Wörterliste mit möglichen Endpunkten nutzen und jeden einzelnen Eintrag vom Applikationsserver anfragen, um herauszufinden welche Endpunkte existieren. Die folgende Abbildung zeigt diesen Vorgang:

cap 1
Abbildung 1: Enumerieren von Applikationsendpunkten mit Wortlisten

Die Wortliste enthält meist mehrere 100.000 Einträge.  Oft sind Scan-Wiederholungen erforderlich, um die Scankonfiguration optimal auf das Antwortverhalten des Servers anzupassen.

Enthält die Wortliste den Namen eines verwundbaren Endpunktes nicht, so bleibt dieser meist unangetastet und wir nicht entdeckt. Gerade die zeitliche Begrenzung eines Penetrationstests limitiert den Tester in seinen Möglichkeiten zum Auffinden von Endpunkten oder Routen. Sollen Produktnamen des Kunden in die Wortliste aufgenommen werden, um so potenzielle Endpunkte zu finden? Soll die Webpräsenz des Kunden herunterladen und alle auf ihr enthaltenen Wörter in einem Scan inkludieren? Dies sind Entscheidungen mit meist unbekannten Folgen – auf jeden Fall erfordern sie zusätzliche Zeit, ohne die Trefferquote zum Auffinden eines Endpunkts sicher zu erhöhen.

Ohne einen Code-Assisted Pentest können Endpunkte und damit mögliche Schwachstellen unentdeckt bleiben.

Problematik 2: Eingabevalidierung

Nachdem eine Übersicht der Endpunkte erstellt wurde, identifiziert der Tester, welche Schnittstellen Nutzereingaben verarbeiten und prüft diese auf gängige Schwachstellentypen wie Cross-Site Scripting (XSS), Command Injection oder SQL Injection (SQLi). Hierbei tritt oft das Problem auf, dass der Anwendungsserver die Eingaben filtert und bösartige Zeichen entfernt, dem Pentester im Black-Box-Ansatz jedoch unbekannt ist, wie diese Filterung implementiert wurde.

Im Folgenden ist ein Codebeispiel (download.php) zu sehen, dass den Download von Systembackups in einer Webanwendung implementiert.

<?php
$file = str_replace('../', '', $_GET['file']);
if(isset($file)){ 
   downloadBackup("backups/$file");
}

Die Applikation liest den file Parameter einer Nutzeranfrage und gibt die angegebene Datei als Download zurück. Um das Ausbrechen aus dem aktuellen Verzeichnis zu verhindern, wird die Verzeichniswechselsequenz “../” mit einem Aufruf von str_replace() gefiltert. Ein Angreifer kann somit keinen unmittelbaren Angriff auf die Applikation ausführen, indem er mit einer Anfrage wie GET /download.php?file=../../../../../etc/passwd die Passwortdatei des Systems herunterlädt (sogenanntes Path Traversal). Als externer Tester ist jedoch ebenso unklar, wie der Server die Eingabe validiert.

Durch die zeitliche Begrenzung des Penetrationstests beginnt ein Spiel, bei dem der Tester abwägen muss, wie viele Eingaben er an den Server schickt, um mit hoher Wahrscheinlichkeit eine korrekte Aussage treffen zu können, dass die Komponente sicher implementiert wurde. In unserem Beispiel könnte er ein weiteres “../” an seine bösartige Anfrage anhängen – vielleicht waren es zu wenige Wechselsequenzen um in das Stammverzeichnis des Servers zu wechseln?

Nach einigen weiteren Tests kommt er möglicherweise zu der Entscheidung, dass die Komponente kein ausnutzbares Verhalten zeigt. Mit Sicht auf den Code wäre die Schwachstelle eindeutig: Die str_replace() Funktion ersetzt bösartige Sequenzen nicht rekursiv, sondern lediglich einmalig. Ein Angreifer könnte folgende Anfrage an den Server stellen, um die Passwortdatei auszulesen:

GET /download.php?file=….//….//….//….//….//etc/passwd

Die str_replace() Funktion ersetzt im file Parameter nun alle bösartigen “../” Sequenzen – was bleibt ist der Parameterwert: ../../../../../etc/passwd – dieser enthält nun die Wechselsequenz, die ein Ausbrechen aus dem backup Verzeichnis ermöglicht!

Bei einem Black-Box-Pentest ist es praktisch unmöglich alle denkbaren Varianten durchzuprobieren. Ein Code-Assisted Pentest würde diese Schwachstelle schnell und effizient identifizieren.

Code-Assisted Pentesting als Ansatz zur Lösung

Wie in den Beispielen erläutert, weitet sich diese Problematik auf viele Testabschnitte eines Penetrationstests aus. Folgende Fragen stehen beispielhaft für weitere Themen, die in einem Black-Box-Verfahren nicht oder nur unzureichend getestet werden können:

  • Wie sind die Passwörter in der Applikation gespeichert? Sind Kundenpasswörter bei einer Kompromittierung unmittelbar auslesbar oder als „Salted Hash“ gesichert?
  • Sind zufällige Tokens (z.B. zum Zurücksetzen eines Nutzeraccounts) tatsächlich zufällig? Existiert genügend Entropie, um einen Brute-Force Angriff zu verhindern?
  • Wurde ein Endpunkt in der Implementierung der Zugriffskontrolle vergessen?

Um diese Fragen beantworten zu können und kritische Applikationen mit der notwendigen Detailtiefe zu testen, bietet sich ein Code-Assisted Pentest an. Gemeinsam mit dem Penetrationstester werden kritische Applikationskomponenten identifiziert und der Quellcode selektiert. Dadurch kann sichergestellt werden, dass der Quellcode nicht vollständig beim Pentester vorliegen muss, sondern nur die Teile, die für die Analyse zwingend notwendig sind.

Der Aufwand eines Code-Assisted Pentests ist nur unwesentlich höher als bei einem Pentest nach dem Black-Box-Ansatz. Dieser Aufwand wird durch einen Gewinn an Effektivität und Prüftiefe problemlos ausgeglichen. Das Ergebnis ist ein Pentest, der deutlich mehr Schwachstellen abdeckt und in der vorgegebenen Zeit daher wesentlich genauere Ergebnisse liefert.