Asset Discovery über Zertifikate

In Projekten werden wir oftmals beauftragt, sogenannte OSINT-Analysen („Open Source Intelligence“) durchzuführen, in denen je nach Anforderung unterschiedliche Aspekte der (IT-) Sicherheit anhand öffentlich zugänglicher Daten näher betrachtet werden sollen. Besonders ausführlich fällt diese Analyse bei TIBER/DORA oder Red/Purple Team Assessments aus, wobei ein möglichst ganzheitliches Bild der potenziellen Angriffsfläche bzw. der Bedrohungslage erfasst werden soll, beispielsweise hinsichtlich:

• Vorhandener IT-Infrastruktur und deren Schwächen
• Möglicher physischer Angriffsvektoren
• Schützenswerten Informationen, die eventuell öffentlich zugänglich sind
• Gestohlener Passwörter
• Bedrohungslage durch reale Akteure
• U.v.m.

Unabhängig davon was genau gefordert wird – das übergeordnete Ziel bleibt immer konstant: Unterschiedlichste Informationen auszumachen, die öffentlich verfügbar und für Angreifer interessant, also einem Angriff zuträglich, sein könnten.
Doch schon beim ersten Punkt (dem Identifizieren von vorhandener IT-Infrastruktur) kann man sich wundern, wie genau das eigentlich funktionieren soll – immerhin gibt es keine öffentlichen Listen oder Datenbanken von Assets, die einer jeden Firma zuzuordnen sind, und speziell in Red Team Assessments ist man auch bestens beraten, nicht an das Brute-Forcing von Subdomains zu denken, da man Verteidiger nicht alarmieren möchte.
Tatsächlich gibt es viele unterschiedliche Methoden und Herangehensweisen, um an die entsprechenden Daten zu kommen – in diesem Artikel soll jedoch vorerst nur ein Ansatz unter Zuhilfenahme von SSL/TLS-Zertifikaten genauer erläutert werden.

SSL/TLS-Zertifikate sind digitale Zertifikate, mit denen sich ein Server, beispielsweise ein Webserver, beim Client, dem Webbrowser, authentifiziert. Dadurch wird gewährleistet, dass die übertragenen Daten vor unbefugtem Zugriff geschützt sind und nicht von Dritten abgefangen oder manipuliert werden können. SSL/TLS-Zertifikate enthalten auch wichtige Informationen wie den Domainnamen, den Zertifikatsaussteller und die Gültigkeitsdauer. Fehlt ein solches Zertifikat, ist die Vertraulichkeit und Integrität der Kommunikation gefährdet – weshalb moderne Browser den Verbindungsaufbau unterbinden und eine entsprechende Warnung anzeigen.

Um einem Missbrauch kompromittierter Zertifizierungsstellen vorzubeugen, wurde der Standard „Certificate Transparency“ ins Leben gerufen – hiermit wird protokolliert, welche Stelle zu welchem Zeitpunkt welches Zertifikat ausgestellt hat.

Die Protokolle („Logs“) hierzu sind öffentlich einsehbar, was für Angreifer, während der Open Source Intelligence Recherche, eine reichhaltige Informationsquelle darstellt. Denn um nicht für jede einzelne Domain oder Subdomain ein eigenes Zertifikat ausstellen lassen zu müssen, können bei der Beantragung eines Zertifikats neben der Hauptdomain weitere Subdomains als Subject Alternative Names (SANs) hinterlegt werden.

Zudem ist es möglich, zusätzliche Domains, auch mit unterschiedlichen TLDs (Top-Level-Domains), einzutragen, falls mehrere Assets über ein einziges Zertifikat verwaltet werden sollen. Dabei muss natürlich für jede eingetragene Domain nachgewiesen werden, dass man deren tatsächlicher Betreiber ist.

Dank Certificate Transparency kann man auf Seiten wie https://crt.sh, welche Certificate Transparency Logs sammeln und in einer Datenbank vorhalten, nach speziellen Bezeichnern, wie beispielsweise der Domain oder dem Firmennamen suchen – hierdurch lassen sich alle verwendeten Zertifikate identifizieren und die Einträge innerhalb der SANs auslesen:

Der nachfolgende Screenshot zeigt beispielhaft einen Ausschnitt der SANs in einem Zertifikat von Google (sandbox.google.com):

Die Abfrage nach google.com liefert sehr viele Zertifikate und nur Anhand dieses einen konnten wir bereits einige weitere Domains und Subdomains identifizieren, die dem Unternehmen Google zuzuordnen sind – im speziellen interessant für Angreifer wären in diesem Fall wohl jegliche Test-, Staging- oder Dev-Umgebungen, da diese oft nicht so gut abgesichert werden wie Seiten, die für reguläre Nutzer angedacht sind.
Mit dieser Methode lassen sich im Übrigen auch Seiten finden, die aufgrund von Beschränkungen in der robots.txt nicht von Suchmaschinen indexiert werden dürfen.

Die NSIDE arbeitet im OSINT während der Asset Discovery mit einer Reihe von Tools und Ressourcen, die eine möglichst vollumfängliche Identifizierung aller Assets ermöglicht. Die Identifizierung über Zertifikate macht hier nur einen kleinen Teil des Prozesses aus, dennoch wollten wir genau diese Methode gerne vorstellen, da sie kostenfrei allen Interessierten und OSINT-Begeisterten zur Verfügung steht. Probieren Sie es doch einfach selbst mal aus – wie viel Infrastruktur gibt ihr Unternehmen über Zertifikate preis?