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.
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].
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/
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.
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