33 Sekunden – so lange dauert es, bis ein neuer Webserver angegriffen wird

Stellen Sie sich vor, Sie eröffnen ein Geschäft – und bevor das Türschild richtig hängt, stehen schon die ersten Einbrecher davor und prüfen, ob das Schloss hält.

Wer schon einmal einen Webserver betreut hat, kennt dieses Phänomen: Sie sind ständig Anfragen von automatisierten Crawlern und Bots ausgesetzt – und das oft schon in den ersten Sekunden nach der initialen Inbetriebnahme.

In diesem Blog-Post wollen wir untersuchen, woher diese Bots kommen und wonach sie suchen. Außerdem zeigen wir einige Möglichkeiten, wie Bots neue Webdienste überhaupt finden und wie Sie Ihren Webserver am effektivsten gegen automatisierte Angriffe schützen.

Versuchsaufbau

Um für diesen Blogartikel die ersten Minuten eines Webservers beobachten zu können, haben wir mit Caddy einen ganz neuen Webserver aufgesetzt. Dabei nutzten wir die folgende Konfiguration („Caddyfile“):

Diese Konfiguration weist Caddy an, alle Anfragen in einer JSON-Datei namens „access.jsonl“ zu protokollieren. Den Clients gegenüber werden die Anfragen mit dem Text „Hello World!“ beantwortet.

Anschließend wurde noch der DNS-Eintrag „demo.nsd.li“ mit der entsprechenden IP-Adresse angelegt und Datenverkehr auf TCP-Port 443 in der Firewall zugelassen. Dann wurde der Server mit dem Befehl „caddy run“ gestartet. Direkt nach dem Start beantragte Caddy ein passendes TLS-Zertifikat von der Zertifizierungsstelle „Let’s Encrypt“. Nach einigen Sekunden war der „frische“ Webserver dann endgültig online.

Zeitlicher Ablauf

Die folgenden Abschnitte beziehen sich auf eine Auswertung der „access.jsonl“ nach 24 Stunden. Wie erwartet trafen bereits in den ersten 15 Sekunden nach Inbetriebnahme die ersten Anfragen ein:

Die folgende Abbildung zeigt die Anzahl der eintreffenden Anfragen in den ersten fünf Minuten:

Die Abbildung zeigt einen initialen „Burst“ nach ungefähr einer Minute und ein Abklingen nach rund drei Minuten. Danach fällt die Rate der Anfragen auf ein „Hintergrundrauschen“ ab, wie die folgende Darstellung der ersten 24 Stunden zeigt:

Auch eine längere Beobachtung von mehreren Tagen zeigte dieses „Hintergrundrauschen“. Insgesamt zeigt schon diese kleine Auswertung, dass Bots bereits Sekunden nach Inbetriebnahme erste Angriffe bzw. „Probes“ zum Aufspüren von Schwachstellen durchführen. Doch woher kommen sie und wonach suchen sie?

Quelle der Anfragen

Die Frage nach dem Urheber der Anfragen ist, wie so oft in der IT-Security, äußerst schwer zu beantworten. Um einen groben Überblick zu geben, haben wir zunächst die Quell-IP-Adressen mithilfe einer Datenbank den jeweiligen Organisationen und Ländern zugeordnet:

Diese Darstellung der häufigsten Quellen zeigt hauptsächlich Cloud-Provider wie Amazon/AWS, DigitalOcean, Iway und Google. Doch man kann nicht davon ausgehen, dass diese Unternehmen selbst diese Scans beauftragen.

Vielmehr greifen Angreifer gerne auf solche Infrastruktur zurück: Server lassen sich damit relativ günstig und schnell aufsetzen und eben auch wieder heruntergefahren, spätestens, sobald die zugehörige IP-Adresse (aufgrund der Scans) in Blocklisten landet. Außerdem werden dieselben Cloud-Provider von einer Vielzahl legitimer Dienste genutzt, weshalb Security-Teams die den Cloud-Providern zugeordneten IP-Netze nicht generell blockieren können.

Analyse der ersten Anfragen

Nun zur zweiten Frage: Wonach suchen die Angreifer? Um diese Frage zu beantworten, haben wir die ersten Anfragen manuell analysiert und versucht, sie spezifischen Schwachstellen oder zumindest bestimmten Schnittstellen zuzuordnen. Die folgende Tabelle zeigt unsere Interpretation der ersten ungefähr 25 Anfragen:

Insgesamt lassen sich die Anfragen grob in die folgenden Kategorien einsortieren:

• „Fingerprinting“, also das Identifizieren eingesetzter Software
• Suche nach Schnittstellen (z.B. für die Administration oder das Debugging)
• Suche nach Konfigurationsdateien, Backups oder Quelltext-Repositorys
• Prüfung auf Verwundbarkeit für bekannte Schwachstellen

Außerdem fällt auf, dass Bots direkt und zielgerichtet auf für Angreifer interessante Pfade zugehen – sie brauchen dafür keine Verlinkungen oder andere Verweise.

Wie werden die Pfade ausgesucht?

Um genau zu sein, sind hier zwei Tätigkeiten relevant: das Aufspüren der Webserver selbst und anschließend die Auswahl der Pfade.

Zunächst zu den Webservern selbst: Eine sehr verlässliche Quelle für Domain-Namen neuer Webserver sind Certificate Transparency Logs, über die wir in einem vorherigen Blogbeitrag bereits berichteten. Dabei handelt es sich um Protokolle, in denen alle bei öffentlichen Zertifizierungsstellen (CAs) beantragten TLS-Zertifikate hinterlegt sind. Da heutzutage fast alle Webseiten über HTTPS erreichbar sind (und das ist auch gut so!), lassen sich dort ihre Hostnamen finden. Eintragungen in Certificate Transparency Logs können sogar „live“ beobachtet werden, z.B. mit certstream, bzw. einer neueren Implementierung wie certstream-server-go. Diese Datenquelle ermöglicht Angreifern, neue (HTTPS-geschützte) Webserver in Sekundenschnelle zu entdecken, ohne dabei Anfragen an die Systeme selbst zu stellen. Es ist davon auszugehen, dass auch unser Demo-Webserver auf diese Weise gefunden wurde.

Es gibt noch viele weitere Möglichkeiten, Dienste aufzuspüren, auch wenn diese nicht per TLS gesichert sind, beispielsweise (ebenfalls passiv) durch DNS-Datenbanken, Verlinkungen oder aktiv mittels Port-Scans oder DNS-Brute-Force, also dem systematischen Durchprobieren möglicher Hostnamen. Alle Techniken hier aufzuführen, würde den Umfang dieses Blogposts sprengen.

Nun zu den Pfaden: Zunächst existieren Wörterlisten mit URLs wie den oben gezeigten. Die wohl bekannteste Wörterlisten-Sammlung befindet sich im GitHub-Repository SecLists. Ein weiteres Projekt ist „Assetnote Wordlists“, hier werden Listen mit URLs, bzw. relativen Pfaden, automatisch aus öffentlichen Quellen erstellt. Mithilfe spezieller Programme (z.B. ffuf, gobuster und feroxbuster) kann automatisiert für jeden Eintrag eine Anfrage gestellt werden und das Ergebnis ausgewertet werden. Dabei machen sich Angreifer außerdem zunutze, dass manche Webserver die Existenz von Verzeichnissen durch Weiterleitungen preisgeben. Das folgende Listing zeigt den Unterschied anhand dieser Webseite: Zunächst wird ein nicht existierender Pfad angefragt – der Server antwortet mit HTTP-Statuscode 404:

Wird stattdessen ein existierender Pfad angefragt, so leitet der Webserver automatisch auf eine URL mit dem hinten angehängten Slash (/) weiter:

In diesem Fall zeigt das einem Angreifer, dass das Verzeichnis „/wp-admin“ offenbar existiert – auch wenn der Angreifer auf das Verzeichnis selbst keinen Zugriff hat.

Einige der zuvor genannten Tools nutzen dieses Verhalten aus, um systematisch Verzeichnisse zu entdecken und dort nach Ressourcen unter den zuvor erwähnten relativen Pfaden der Wörterliste zu suchen.

Gegenmaßnahmen

Kurzes Zwischenfazit: Angreifer, bzw. ihre automatisierten Bots versuchen öffentliche Webserver bereits Sekunden nach deren Inbetriebnahme anzugreifen. Hostnamen von Zielsystemen entnehmen sie beispielsweise den Certificate Transparency Logs. Gesucht wird nach bekannten Schwachstellen (also: veralteter Software), versehentlich exponierten sensiblen Informationen, Fehlkonfigurationen, sowie Administrations- und Debugschnittstellen.

Es ist natürlich verlockend, zu versuchen, den eigenen Webserver vor Angreifern zu verstecken. Beispielsweise könnte man sich durch die Verwendung eines Wildcard-Zertifikats einen gewissen zeitlichen Vorsprung erarbeiten, da hierdurch die genutzte Subdomain verschleiert werden würde. Unsere Erfahrung zeigt aber, dass solche Maßnahmen unter „Security by Obscurity“ fallen. In den letzten Jahren haben sich Certificate Transparency Logs als geeignete Quelle etabliert – doch es ist keinesfalls gesichert, dass in den nächsten Jahren nicht weitere Quellen hinzukommen. Und sobald ein System einmal aufgedeckt und in einer öffentlichen Datenbank zu finden ist, sind alle in „Security by Obscurity“ investierten Aufwände hinfällig.

Daher ist die einzige tatsächlich wirksame Gegenmaßnahme, Webserver vor ihrem Anschluss an das Internet sicher zu konfigurieren. Was genau „sicher“ bedeutet, ist von der speziellen Anwendung abhängig, zumindest sollten jedoch folgende Best-Practices befolgt werden:

• Angriffsfläche minimieren – nicht benötigte Funktionalität abschalten.
• Zugriff auf „interne“ Schnittstellen (zur Administration/Debugging) besonders absichern, z.B. durch eine IP-Adressen-Beschränkung zusätzlich zur Anmeldung mit Zugangsdaten (Defense-in-Depth).
• Standardpasswörter durch sichere Passwörter ersetzen.
• Updates installieren – das System sollte keine bekannten Schwachstellen aufweisen.
• Prinzip der geringsten Berechtigungen befolgen – z.B. indem der Webserver von anderen Systemen und dem internen Netz netzwerkseitig separiert wird.

Bereits eine Härtung gemäß dieser Best-Practices schließt die meisten automatisierten Angreifer aus.