Du kannst kein Omelett machen, ohne Eier zu zerbrechen - und das gilt auch für den Aufbau unserer Dienste. Aber was passiert, wenn wir beim Stilllegen nicht gründlich genug sind? Wir erstellen regelmässig JFrog-Instanzen dynamisch für die Entwicklung unserer Dienste und bauen sie nach dem Testen wieder ab. Der Prozess ist automatisiert mit Terraform, Crossplane und wird auf Kubernetes bereitgestellt. Ein kleiner, aber entscheidender Punkt wurde jedoch übersehen: die Löschung aller zugehörigen DNS-Einträge.

Auf den ersten Blick scheint das harmlos. Schliesslich existiert die Instanz nicht mehr und es ist nur eine Entwicklungsumgebung. Aber die Realität sieht anders aus! Kürzlich wurden wir von einem Sicherheitsforscher, einem sogenannten Bug-Bounty-Jäger, kontaktiert. Er machte uns auf eine schwerwiegende Sicherheitslücke aufmerksam, die durch das Nichtlöschen von DNS-Einträgen verursacht wurde.

Diese verwaisten DNS-Einträge, auch bekannt als "dangling DNS records", sind immer noch gültig, da sie nach dem Stilllegen des Dienstes nicht entfernt wurden. In einer öffentlichen Cloud wird eine IP-Adresse sofort freigegeben und dem nächsten Kunden zugewiesen. Der Bug-Bounty-Jäger erhielt unsere zuvor verwendete IP-Adresse und einen passenden DNS-Eintrag. Glücklicherweise wurde diese Situation nicht ausgenutzt und wir wurden über die Sicherheitslücke informiert.

Was sind die Gefahren von "dangling DNS records"?

• Verlust der Subdomain: Dies kann zu negativer Presse, Imageschäden und Vertrauensverlust führen.
• Cookie-Diebstahl: Angreifer könnten Cookies stehlen, die auf der Subdomain gespeichert sind.
• Phishing-Kampagnen: Angreifer könnten die Subdomain für Phishing verwenden, was für Benutzer schwer zu erkennen wäre, da sie von einem vertrauenswürdigen Unternehmen stammt.
• Diebstahl von Zertifikaten: Let's Encrypt-Zertifikate sind 90 Tage gültig. Ein Angreifer könnte diese Zertifikate stehlen und für Phishing verwenden.
• Verbreitung von Malware: Angreifer könnten Malware auf der Subdomain hosten und verteilen.

Tools

Es gibt zahlreiche Tools, die von Sicherheitsforschern entwickelt wurden, um "dangling DNS records" zu erkennen. Diese Tools sind frei zugänglich und können von jedem genutzt werden. Hier sind einige Beispiele:

• Eipfish: Ein Tool, das nach dangling DNS mit AWS Lambda Services sucht. Eipfish auf GitHub
• Paydirt: Ein Tool, das nach solchen Diensten auf AWS und DigitalOcean sucht. Paydirt auf GitHub
• Sublist3r: Nutzt verschiedene Suchmaschinen und passive DNS-Dienste. Sublist3r auf GitHub

kmsec.uk bietet ein anschauliches Beispiel in ihrem Blogpost Passive Takeover, der zeigt, wie einfach es ist, eine Subdomain auf DigitalOcean zu übernehmen.

Wie können dangling DNS records vermieden werden?

Hier sind einige Ratschläge:

• Automatisierung: Betrachte DNS-Einträge als Teil des Dokumentationsprozesses und stelle sicher, dass sie gelöscht werden.
• Nutze passive DNS-Dienste: Überprüfe regelmässig die Datenbanken passiver DNS-Dienste und stelle sicher, dass keine verwaisten DNS-Einträge vorhanden sind. Es gibt Dienste wie SecurityTrails: Daten-Sicherheit, Bedrohungsjagd und Angriffsflächenmanagement-Lösungen für Sicherheitsteams oder VirusTotal.
• Überprüfe regelmässig DNS-Einträge: Es gibt einen praktischen Online-Dienst, der kostenlos eine einzelne Domain abfragt: https://hardenize.com.
• Überwachung & Alarmierung: Wir haben noch kein nützliches Tool gefunden, um verwaiste DNS-Einträge zu überwachen.

Wie gehen die bekannten Cloud-Anbieter damit um?

Die bekannten Cloud-Anbieter sind sich dieses Problems bewusst:

• Azure: bietet ein PowerShell-Tool, um "dangling DNS records" zu finden und Subdomain-Übernahmen zu verhindern
• AWS: bietet eine kurze Dokumentation über verwaiste Delegationsdatensätze in Route 53
• Google Cloud: Es gibt keine offizielle Dokumentation, aber ein Github-Projekt bietet einige Hilfestellungen: https://github.com/domain-protect/domain-protect-gcp

Warum haben wir den Bug-Bounty-Jäger bezahlt?

Wie bereits in der Einleitung erwähnt, wo gehobelt wird, da fallen Späne. Wir sind dankbar, dass er diese Schwachstelle mit uns geteilt und uns darauf aufmerksam gemacht hat. Trotz des hohen Automatisierungsgrades nimmt die Komplexität zu und es gibt immer Dinge, die übersehen werden können. Es ist uns wichtig, etwas Positives aus dieser Erfahrung zu ziehen und richtig damit umzugehen.

Wir haben alle unsere verwaisten DNS-Einträge sofort nach dem Hinweis gelöscht und die Sicherheitslücke geschlossen. Jeder bei 4data ist sich bewusst, dass Sicherheit oberste Priorität hat. Und wir haben eine Belohnung für diesen Hinweis gezahlt, da er uns geholfen hat, unsere Dienste zu verbessern und sicherer zu machen.

Warum haben wir diesen Blogpost geschrieben?

Indem wir dies zugeben und nicht versuchen, es zu vertuschen, gewinnen wir das Vertrauen unserer Kunden. Und indem wir diese Erfahrung teilen, können wir anderen helfen, denselben Fehler zu vermeiden.

Fazit: Niemals aufhören zu lernen.