Virtuelle Gespenster

Der neue Asset-Typ " Web-Entitäten" ist jetzt für alle Kunden von Censys allgemein verfügbar. Eine "Web-Entität" in Censys ermöglicht es den Nutzern, ihre webbasierten Assets als ein einziges High-Level-Commodity zu behandeln und Hosts und Services als Teil des Web-Service-Ökosystems einer Organisation zu gruppieren.

Neben der Einführung dieser neuen Datenklassifizierung haben wir neuartige Methoden entwickelt, um potenzielle Shadow IT Assets innerhalb eines Unternehmens aufzuspüren. Shadow IT bezieht sich auf Technologien, Systeme und Anwendungen, die Mitarbeiter ohne Wissen oder Genehmigung der zuständigen IT-Abteilungen nutzen. Solche Systeme werden ohne ordnungsgemäße Genehmigung eingesetzt, entweder aus Versehen oder im Namen der Produktivität. Shadow IT kann verschiedene Formen annehmen, darunter:

• Die Nutzung von persönlichen Cloud-Speicherdiensten wie Dropbox
• Teams, die Projektmanagement-Tools ohne IT-Aufsicht verwenden
• Persönliche mobile Geräte oder Laptops, die nicht zugelassen sind
• Verwendung persönlicher E-Mail-Adressen für arbeitsbezogene Interaktionen
• Unbefugte Nutzung von Cloud- und Web-Hosting-Diensten

Der Einsatz eines Servers ohne die Aufsicht einer IT-Organisation führt wahrscheinlich dazu, dass der Server keinen Zugang zu den Vorteilen der Standard-IT-Automatisierung hat, z. B. Überwachungs- und Telemetriefunktionen, regelmäßige Systemaktualisierungen und ordnungsgemäße Konfigurationshygiene. Diese fehlende Unterstützung kann dazu führen, dass das System anfällig für Sicherheitsrisiken und Ineffizienzen ist.

In diesem Beitrag erläutern wir eine einfache technische Methode, mit der wir Webserver ausfindig machen, die per Definition nicht existieren sollten. Da sowohl auf der Host- als auch auf der DNS-Ebene kein historischer Kontext vorhanden ist, können diese Objekte von den meisten Tools nicht erkannt werden. Durch Hinzufügen von historischem Kontext zur Angriffsfläche eines Unternehmens können wir jedoch weitere Einblicke in potenzielle Datengefährdungen gewinnen.

Aber bevor wir zu den guten Dingen kommen, müssen wir ein grundlegendes Verständnis für die verschiedenen Ansichten haben, die Censys über das Internet hat.

Die Ansichten von Censys

Censys hat zwei einzigartige, aber ähnliche Ansichten über das Internet: die unbenannte und die benannte.

(Ein ungenannter Gastgeber in Censys)

Die Ansicht "unbenanntes Internet" umfasst die Hosts und Dienste, die direkt von einer IP-Adresse aus antworten und genauso reagieren, egal ob man sie über einen Hostnamen oder eine IP-Adresse anfragt. Viele Internetdienste haben keine Möglichkeit, den Hostnamen in der Anfrage anzugeben. So kann z. B. das SSH-Protokoll dem entfernten Server nicht mitteilen, dass Sie an einem bestimmten Hostnamen interessiert sind, so dass die Antwort gleich ausfällt, egal ob Sie sich direkt über eine IP-Adresse oder einen Namen mit ihm verbinden.

(Ein benannter Host in Censys)

Bei der "benannten Internet"-Sicht handelt es sich hingegen um die Hosts und Dienste, die Censys unabhängig von der physischen IP-Adresse anzeigen kann und auf die stattdessen über einen Namen verwiesen wird. Damit Dienste auf einen bestimmten Hostnamen anders reagieren können, muss ein Austausch zwischen Client und Server den Namen nach dem Aufbau der Verbindung angeben. Dieser Prozess bedeutet, dass es im zugrunde liegenden Protokoll eine Methode geben muss, die einen solchen Austausch einleitet.

"...die 'named internet'-Ansicht ist die Ansicht der Hosts und Dienste, die Censys unabhängig von der physischen IP.... einsehen kann."

Glücklicherweise unterstützen zwei der gängigsten Protokolle im Internet einen solchen Mechanismus, wenn auch aus leicht unterschiedlichen Gründen:

• Das HTTP-Protokoll (ab Version 1.1) schreibt vor, dass jeder Client-Anfrage ein "Host"-Header beigefügt werden muss, der den Server über den spezifischen Hostnamen und die angeforderte Ressource informiert. Ohne diesen Header würde jeder Domänenname eine eigene IP-Adresse benötigen.
• TLS SNI (Server Name Indication) ist eine Erweiterung des TLS-Protokolls (Transport Layer Security), die es einem Client ermöglicht, den Hostnamen des Servers, zu dem er eine Verbindung herstellen möchte, anzugeben, bevor er eine sichere Verbindung herstellt. Ohne SNI könnte der Server den korrekten Hostnamen und das zugehörige zugrundeliegende Zertifikat nicht ermitteln und würde das Standardzertifikat zurückgeben, das der Server konfiguriert hat - dies würde bedeuten, dass jedes SSL-Zertifikat eine eigene dedizierte IP-Adresse benötigt, um sicher zu funktionieren.

Zusammenfassend lässt sich sagen, dass der Webserver SNI verwendet, um mit einem für den Hostnamen spezifischen Zertifikat zu antworten, und dass der HTTP-Host-Header die Anforderung einer bestimmten Backend-Einheit zuweist, z. B. einem Dateisystemverzeichnis. Dieser gesamte Prozess wird üblicherweise als "virtuelles Hosting" bezeichnet.

Viele moderne Webserver wie Nginx verfügen über erweiterte Konfigurationsoptionen, mit denen Sie nicht nur verschiedene Verzeichnisse auf der Grundlage der eingehenden Client-Header bereitstellen können, sondern diese Anfragen auch transparent an separate Listener und Anwendungen weiterleiten können, was die Sicht auf einen einzelnen Host erheblich verändern kann.

In Anbetracht der Tatsache, dass die meisten Webserver je nach Anfrage des Kunden unterschiedlich reagieren, hätte Censys , wenn es die Welt nur anhand der bloßen IP-Adressen der Hosts scannen würde, nur ein minimales Bild davon, wie das Internet tatsächlich aussieht, und unsere Daten wären völlig unvollständig. Aus diesem Grund haben wir vor einigen Jahren das namensbasierte Scannen eingeführt, das genau das oben beschriebene für HTTP- und TLS-basierte Protokolle leistet.

Diese namensbasierten Scans können einige einzigartige Fragen beantworten, die jemand vielleicht hat. Mit unseren Daten können wir zum Beispiel leicht einen Bericht über die Anzahl der IPs pro Name erstellen: "Letzten Dienstag gab es 325.484.066 Hostnamen mit nur einer einzigen IP-Adresse, und auf der anderen Seite der Skala gab es EINEN Hostnamen, der 10.733 IP-Adressen zugeordnet war".

Und wenn man diese benannten Scandaten mit dem historischen Kontext mischt, wird es noch interessanter.

---

 

Tote Hosts und virtuelle Geister

Bei der Analyse einer Angriffsfläche ist es oft ein Fehler, sich nur auf beobachtbare Aspekte der Gegenwart zu konzentrieren, wie z. B. den aktuellen Zustand des DNS. Das Übersehen von Artefakten aus der Vergangenheit kann zu einer erheblichen Unterschätzung des aktuellen, verborgenen Zustands einer Angriffsfläche führen.

"...es ist oft ein Fehler, sich nur auf die beobachtbaren Aspekte des gegenwärtigen Augenblicks zu konzentrieren...."

In HTTP sind sowohl der Host-Header als auch der TLS-SNI-Wert beliebige Zeichenfolgen. Nichts in den Protokollspezifikationen besagt, dass diese Werte eine Funktion haben oder sogar rechtmäßig sein müssen. Ein Client kann google.com von einer twitter.com-IP-Adresse aus anfragen, und nichts würde ihn daran hindern, dies zu tun. Natürlich könnte der Server eine Fehlermeldung ausgeben, die besagt, dass der Host keine Daten für den angeforderten Hostnamen finden konnte, aber nichts hält diesen Austausch auf.

Wenn ein Administrator einen DNS-Eintrag entfernt, der auf eine IP-Adresse verweist, aber die Webserverkonfiguration beibehält, die diesen Namen einer lokalen Ressource zuordnet, könnte jemand, der weiß, dass der Hostname zu dieser IP-Adresse gehört, weiterhin auf die Daten zugreifen, als ob der DNS-Eintrag noch vorhanden wäre.

Wenn ein Administrator einen neuen Server für seine Ticketplattform kauft und den DNS-Eintrag so ändert, dass er auf die IP-Adresse des neuen Servers verweist, ohne die Konfiguration des alten Webservers zu entfernen, und dann eine kritische Sicherheitslücke in der Software auf dem neuen, aber nicht auf dem alten Server schließt, könnte ein Angreifer historische Informationen nutzen, um die Software auf dem alten Host auszunutzen.

Zusammenfassend lässt sich sagen, dass, wenn der DNS-Eintrag für einen Hostnamen so geändert wird, dass er auf eine neue IP-Adresse verweist, oder wenn er ganz aus dem DNS entfernt wird, die vorherige IP-Adresse aber noch mit einer gültigen Virtual-Host-Konfiguration für denselben Hostnamen in Betrieb ist, ein Angreifer mit historischem Wissen über den Host immer noch Zugang zu den alten Daten auf dem alten Server erhalten kann.

In Ermangelung eines etablierten Begriffs zur Beschreibung dieser Methode der Host-Analyse haben wir solche Hosts informell als "Virtuelle Geister" bezeichnet,", eine Anspielung auf den Begriff "Virtual Host".

Virtuelle Geisterjäger

Dieses "Virtual Ghost"-Konzept ähnelt auf den ersten Blick dem "Dangling DNS" oder der Übernahme von Subdomains, unterscheidet sich aber in der Ausführung erheblich. Erstens spielen die Angreifer dabei keine aktive Rolle, sondern zielen nur auf den Host mit Vorkenntnissen ab. Zweitens handelt es sich nicht um ein DNS-Problem, sondern um ein DNS-nahes Problem - das Problem besteht ausschließlich in einer unzureichenden Hygiene der Serverkonfiguration.

Censys wollte das Ausmaß dieses "Virtual Ghosting"-Effekts im Internet messen, indem wir zwei namenbasierte Censys -Scan-Snapshots im Abstand von jeweils einer Woche abfragten und alle IP-basierten Hosts analysierten, die immer noch Inhalte für einen DNS-Eintrag bereitstellen, der nicht mehr existiert (d. h., der DNS-Eintrag liefert jetzt eine NXDOMAIN).

Wir haben diese Tests mit zwei Datensätzen durchgeführt, einer Zufallsstichprobe und einem gezielteren Ansatz.

Unsere erste Testeingabe waren 50.000 zufällige Hosts, die am 02. Februar 2022 einen Eintrag in unserer Named-Scan-Datenbank hatten, aber am 14. Februar waren sie verschwunden. Diese Entfernung könnte zwei Dinge bedeuten:

1. Der Host ist ausgefallen, oder ein Administrator hat die Netzwerkdienste eingestellt.
2. Censys konnte den DNS-Namen nicht in eine IP-Adresse auflösen.

Die Hosts, die uns am meisten interessieren, sind diejenigen, deren DNS-Namen nicht mehr in eine IP-Adresse aufgelöst werden können. Daher überprüfen wir zunächst jeden Hostnamen aus unserer Stichprobe und stellen sicher, dass der maßgebliche Nameserver für diesen Hostnamen eine NXDOMAIN zurückgibt. Dieser Prozess reduzierte die Anzahl der potenziellen Ziele auf 8.227 Hosts, was bedeutet, dass 41.773 Hosts in unseren Beispieldaten noch gültige DNS-Einträge haben (aber keine Dienste mit ihnen verbunden sind).

Für jeden verifizierten DNS-Eintrag, der jetzt eine NXDOMAIN zurückgibt, die in unserer Stichprobe gefunden wurde, erstellen wir eine historische Kopie der zugehörigen Host-Details und notieren die folgenden Informationen:

• Die IP-Adresse, nach der der DNS-Eintrag aufgelöst wurde 
• Der alte Sha256Summe des HTTP-Antwortkörpers
• Der alte HTML-Titel aus der HTTP-Antwort
• Die alte Sha256-Summe des TLS-Server-Zertifikats

Wir stellen dann eine Verbindung zur IP-Adresse des Hosts her, der früher Inhalte für diesen abgelaufenen DNS-Eintrag bereitgestellt hat, und stellen drei funktional getrennte HTTP-Anfragen:

1. Eine GET-Anfrage an die alte IP-Adresse mit dem HTTP-Host-Header und dem TLS-SNI-Feld, das auf den nicht mehr existierenden DNS-Namen eingestellt ist.
2. GET-Anfrage an die alte IP-Adresse mit einem Zufallswert, der an den Anfang des Hostnamens angehängt wird. Wenn der angestrebte Hostname beispielsweise "search.censys.io" lautet, würden wir eine GET-Anfrage für "Host: $random_string.search.censys.io" stellen - die Ausgabe wird dann zum Testen auf potenzielle Domainnamen-Parking-Sites oder Standard-HTTP-Handler verwendet.
3. GET-Anfrage ohne den Host-Header oder das SNI-Feld im TLS-Handshake-Set. Wir wollen sicherstellen, dass sich die Antwort auf unsere Host-Header-Anfrage von der bloßen IP-Adresse unterscheidet.

Unser Ziel bei dieser speziellen Studie war es, nur "echte" Websites zu analysieren, die nicht nur die Standard-HTTP-Handler oder Wildcard-Domain-Parking-Webseiten zurückgeben. Daher haben wir die beiden Nicht-Host+SNI-Abfragen in den Schritten 2 und 3 zum Vergleich mit der Abfrage aus Schritt 1 verwendet. Wenn die Antwort aus den Abfragen 2 und 3 beispielsweise ähnlich aussieht wie die aus Abfrage 1, halten wir sie nicht für eine "echte" Website.

Wenn der Hostname und die IP-Adresse die obige Validierungsprüfung bestehen (d. h. wir halten sie für eine "echte" Website), prüfen wir die Antwort der ersten Abfrage auf die folgenden Kriterien:

• Hat der Antwortkörper die gleiche SHA256SUM wie in unseren historischen Daten?
• Stimmt der HTML-Titel der Antwort mit dem in unseren historischen Daten überein?
• Stimmt das Serverzertifikat mit unseren historischen Daten überein?

Wenn alle drei Kriterien zutreffen, ist es sehr wahrscheinlich, dass der Host noch Inhalte für einen DNS-Eintrag bereitstellt, der nicht mehr existiert. Wenn nur zwei der drei Kriterien zutreffen, ist die Wahrscheinlichkeit mittel bis hoch, und wenn nur ein Kriterium zutrifft, ist die Wahrscheinlichkeit gering bis mittel, dass dieser Host Inhalte für abgelaufene DNS-Einträge bereitstellt.

Von den 50.000 zufällig ausgewählten Hosts erfüllten insgesamt 694 Server mindestens eines dieser drei Kriterien und stellten eine "echte" Website zur Verfügung. 112 dieser Hosts (16,1 %) erfüllten alle drei Kriterien, während nur 52 (7,5 %) Hosts nur ein Kriterium erfüllten.

Nachstehend finden Sie eine Tabelle mit der Aufschlüsselung aller drei Kriterienkombinationen, aufgeschlüsselt nach der Anzahl der Hosts.

HTTP Body stimmt mit alten Daten überein	HTML-Titel stimmt mit alten Daten überein	Server-Zertifikat stimmt mit alten Daten überein	Host-Zahl	%
YES	NO	YES	1	0.1
YES	YES	NO	52	7.5
NO	NO	YES	99	14.3
YES	YES	YES	112	16.1
NO	YES	NO	181	26.1
NO	YES	YES	249	35.9
		Insgesamt	694

Bei unserem zweiten Test wollten wir dieselbe Analyse auch mit einem nicht untersuchten, aber gezielten Datensatz durchführen. Also haben wir eine Liste aller Hostnamen und IP-Adressen vom 02. Februar 2023 erstellt, die am 14. Februar nicht auftauchten und die das Wort "admin" irgendwo in der Subdomain des DNS-Namens enthielten.

Unser Ziel bei diesem Test war es, Webadministrationsschnittstellen zu finden, die jemand versehentlich online gestellt und mit einem gültigen DNS-Namen versehen hat, die aber inzwischen nur aus dem DNS, nicht aber aus der Konfiguration des virtuellen Hosts des Webservers entfernt wurden. Diese "virtuellen Geister" sind zwar nicht direkt zugänglich, können aber dennoch ein Problem darstellen, wenn ein Angreifer den alten Hostnamen und die IP-Adresse kennt.

Zwischen dem 02. und dem 14. Februar sahen wir 21.502 IP- und Hostnamen-Kombinationen, die potenzielle "virtuelle Geister" waren (Hostnamen, die am 2. Februar gesehen wurden, wurden am 14. Februar nicht gesehen). Nachdem wir die NXDOMAIN-Validierung durchgeführt hatten, sank diese Zahl auf nur noch 5.101 Möglichkeiten. Bei der Überprüfung dieser 5.101 Hosts durch den gleichen Prozess, den wir für die Stichprobendaten durchgeführt haben, wurden 223 Hosts gefunden, die ein oder mehrere Kriterien für "virtuelle Geister" erfüllten. Nachfolgend finden Sie die vollständige Zuordnung:

HTTP Body stimmt mit alten Daten überein	HTML-Titel stimmt mit alten Daten überein	Server-Zertifikat stimmt mit alten Daten überein	Host-Zahl	%
NO	NO	YES	16	7.2
NO	YES	NO	18	8.1
YES	YES	NO	24	10.8
NO	YES	YES	73	32.7
YES	YES	YES	92	41.3
		Insgesamt	223

Anschließend richteten wir einen lokalen DNS-Server ein und integrierten alle nicht existierenden DNS-Namen in die entsprechenden Zonen, wobei wir die vergessenen DNS-Namen ihren ursprünglichen IP-Adressen zuordneten. Der DNS-Server ermöglichte es uns, diese "virtuellen Geister" über eine beliebige HTTP-fähige Schnittstelle, wie z. B. Chromium, zu durchsuchen und zu prüfen, ob der Prozess irgendwelche bemerkenswerten Erkenntnisse zutage gefördert hatte. Im Folgenden finden Sie einige interessante Beispiele für Websites, die nicht zugänglich sein sollten, oder wie wir sie nennen, "virtuelle Geister".

Wir haben eine ganze Reihe von administrativen Anmeldeformularen beobachtet.

 

Einige Verwaltungs-Dashboards, von denen einige nur Testdaten enthalten.

 

Viele Verzeichniseinträge enthalten den gesamten Quellcode einer Website.

Vergrößerung der Angriffsfläche

Die vorgelegten Daten zeigen, dass "virtuelle Geister" keine Seltenheit sind. Sie zu entdecken ist eine einfache Aufgabe, wenn man Zugang zu Informationen über jeden Host, jeden Dienst und jede Website hat, die jemals existiert haben. Dies unterstreicht den Gedanken, dass nicht alle Angriffsflächen sichtbar sind und dass der historische Kontext entscheidend ist, um einen genauen Überblick über den digitalen Fußabdruck eines Unternehmens zu erhalten.

In Anbetracht dieser Erkenntnisse sind wir stolz darauf, unsere neue Funktion "Web Entities" in der Censys Plattform einzuführen, die automatisch Assets aufspürt, die als "Virtual Ghosts" eingestuft werden, und davor warnt. - Dabei handelt es sich um Hosts, die von ihren DNS-Namen abgekoppelt wurden, aber immer noch Inhalte auf dem Webserver hosten. Wir empfehlen Unternehmen dringend, diese Funktion in ihre Sicherheitsprotokolle einzubauen, um sich vor potenziellen Bedrohungen zu schützen.

Machen Sie den ersten Schritt zur Sicherung Ihrer digitalen Assets, indem Sie unsere Funktion Web Entities noch heute in Ihre Sicherheitsstrategie integrieren. Kontaktieren Sie uns, um eine Demo zu vereinbaren.