TLS sollte für jede Website obligatorisch sein. Achten Sie aber bei der Einrichtung darauf, dass Sie das Zertifikat richtig konfigurieren. Dazu gehört, dass keine sensiblen Daten in einem der Felder des Zertifikats enthalten sind. Denn dieses Zertifikat wird öffentlich zugänglich, wenn Sie eine Zertifizierungsstelle verwenden, die Certificate Transparency unterstützt.
Von Marinus Kuivenhoven und Jeroen Willemsen .

Beginnen wir mit dem wichtigsten Teil dieses Artikels: An Certificate Transparency (CT) gibt es nichts auszusetzen. CT ermöglicht es Ihnen, "...SSL-Zertifikate zu erkennen, die fälschlicherweise von einer Zertifizierungsstelle ausgestellt oder böswillig von einer ansonsten unanfechtbaren Zertifizierungsstelle erworben wurden. Sie ermöglicht es auch, Zertifizierungsstellen zu identifizieren, die abtrünnig geworden sind und böswillig Zertifikate ausstellen." (Quelle: certificate-transparency.org/).
Browser wie Chrome verwenden CT, um zu überprüfen, ob ein Zertifikat korrekt ausgestellt wurde und ob er dem Zertifikat vertrauen kann. Chrome kann verschiedene Dinge im CT-System sehen, z.B. welches korrekte Zertifikat einer bestimmten CA verwendet werden sollte.
Aber CT hat auch eine gewisse Kehrseite: Dienste wie censys.io, die versuchen, das Internet zu indizieren, erlauben es Ihnen, die Zertifikate zu durchsuchen. Und das sind ziemlich viele:
[caption id="attachment_27362" align="aligncenter" width="220"]

Quelle: censys.io[/caption]
In dieser sehr langen Liste von Zertifikaten haben wir interne APIs, Middleware, Endpunkte von IoT-Geräten, Intranet-Websites usw. gefunden, die nicht indiziert oder veröffentlicht werden sollten. Die meisten von ihnen enthalten Hostnamen, die auf bestimmte Frameworks, wie K8s und Cucumber, oder Tools, wie Timeserver und Datenbanken, hinweisen.
Warum ist das ein Problem?
Wann immer ein Angreifer oder ein Pentester beginnt, wird er oder sie zunächst eine Erkundung durchführen. Eine Erkundung führt zu einer funktionalen und technischen Karte der IT-Landschaft. In der Vergangenheit konnten Fehler in
DNS-Zonentransfers oder
Reverse-Lookup-Tabellen dem Angreifer Aufschluss darüber geben, welche Hosts was im Netzwerk ausführen, aber nicht offengelegt oder von außen erreichbar sind. Aufgrund der Fortschritte im Bereich der Sicherheit sind diese Arten der Offenlegung von Informationen inzwischen recht selten geworden. CertShout legt die Informationen auf ähnliche Weise offen, ohne dass der Besitzer weiß, dass die Informationen nach außen gelangt sind.
Großartig. Wie soll ich vorgehen?
Hier sind ein paar Dinge zu beachten:
- Verzichten Sie nicht auf die Verwendung von TLS.
- Versuchen Sie nicht, Ihr eigener CA zu sein. Es sei denn, Sie sind wirklich sicher, dass Sie wissen, worauf Sie sich einlassen. Es ist keine triviale Angelegenheit.
- Verstehen Sie, dass alles, was Sie in ein Zertifikat eingeben, das von einer Zertifizierungsstelle erstellt wurde, die CT unterstützt, öffentlich ist: Geben Sie keine sensiblen Informationen in die Felder ein.
- Überprüfen Sie den Inhalt Ihrer Zertifikate mit Diensten wie censys.io oder crt.sh.
- Wenn Sie nicht möchten, dass ein Server von außen erreichbar ist, sollten Sie zusätzliche Sicherheitsvorkehrungen auf Netzwerkebene treffen.
Nachgedacht
Es gibt viele Möglichkeiten, Ihre mit dem Internet verbundenen Dienste/Geräte zu finden, CT ist nur eine davon. Denken Sie daran, Suchmaschinen
(Google Dorking) oder Repositories
(Github oder Bitbucket) zu verwenden, um Sicherheitsprobleme bei öffentlich verfügbaren Ressourcen zu finden - oder Dienste wie Shodan, um alle mit dem Internet verbundenen Geräte zu finden. Die Automatisierung des Scannens dieser Ressourcen nach neuen Instanzen ist eine großartige Möglichkeit, Ihre Security Orchestration, Automation and Response (SOAR) zu verbessern.
Dieses Sommer-CERT wird Ihnen von Xebia Security präsentiert.