Versionsinformationen in HTTP-Headern

Angreifer suchen selten zuerst ein Ziel und dann eine Schwachstelle. Häufiger läuft es umgekehrt: Es gibt ein bekanntes Problem in einer bestimmten Version, und es wird automatisiert nach Systemen gesucht, die diese Version einsetzen. Wer seine Versionsnummer in die Header schreibt, meldet sich freiwillig für diese Suche an. Was dabei preisgegeben wird, ist überschaubar, und das Entfernen ist einfach.

Was verraten die Header?

Bei jeder HTTP-Antwort sendet ein Server eine Reihe von Headern mit, die nichts mit Ihrer Anwendung zu tun haben, sondern mit der darunterliegenden Software. Der bekannteste ist Server, der den Webserver und häufig die genaue Version nennt. Daneben gibt es X-Powered-By für die verwendete Programmiersprache sowie frameworkspezifische Varianten, die das Redaktionssystem oder die Anwendungsumgebung benennen.

Von Versionsinformationen in HTTP-Headern spricht man, wenn diese Angaben so ausführlich sind, dass ein Angreifer unmittelbar bekannte Schwachstellen dazu nachschlagen kann. Der Unterschied zwischen Server: nginx und Server: nginx/1.18.0 (Ubuntu) ist genau das: Ersteres nennt das Produkt, Letzteres nennt das Produkt, die Version und das Betriebssystem.

Der Vergleich mit einem Namensschild trägt nur halb, denn ein Namensschild ist nützlich. Dies ist eher ein Schild mit der Angabe, welches Schloss in der Tür steckt und aus welchem Baujahr es stammt. Für den Bewohner bringt es nichts; für jemanden, der die Rückrufaktionen dieser Marke gelesen hat, sehr wohl.

Wie sieht das in den Antwort-Headern aus?

Verwundbar:

HTTP/1.1 200 OK
Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.2.24
X-AspNet-Version: 4.0.30319
X-Generator: Drupal 9.3.6 (https://www.drupal.org)

Vier Header, vier Angaben, für die ein Angreifer nichts tun musste. Er weiß nun, welcher Webserver, welche Sprachversion, welche Anwendungsplattform und welches Redaktionssystem laufen. Der nächste Schritt ist ein Nachschlagen in einer öffentlichen Schwachstellendatenbank, und das liefert je Version eine Liste bekannter Probleme und mitunter fertigen Angriffscode.

Vor allem macht Sie das für großflächiges automatisiertes Suchen sichtbar. Es wird fortlaufend im Internet nach Systemen gesucht, die eine bestimmte verwundbare Version einsetzen. Ihre Organisation muss dafür nicht interessant sein; es genügt, dass Sie antworten.

Sicher:

# nginx: nur der Produktname, keine Version
server_tokens off;

# Und was die dahinterliegende Anwendung ergänzt, beim Durchreichen entfernen
proxy_hide_header X-Powered-By;
proxy_hide_header X-AspNet-Version;
proxy_hide_header X-Generator;

# Apache
ServerTokens Prod
ServerSignature Off

// Und in der Anwendung selbst
app.disable('x-powered-by');

Die Antwort ist nun deutlich stiller:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff

Ein Reverse Proxy ist dabei die verlässlichste Stelle, um dies durchzusetzen, denn dort können Sie die Header jedes dahinterliegenden Dienstes in einem Zug bereinigen, auch die von Komponenten, deren Konfiguration Sie nicht in der Hand haben.

Welche Auswirkungen haben Versionsinformationen in Headern?

Der Schweregrad ist niedrig, und das ist eine faire Einschätzung: Durch diese Header wird kein Angriff möglich. Was sie bewirken, ist eine Verkürzung der Erkundungsphase eines Angreifers von etwas Suchaufwand auf einen einzigen Blick.

Die praktische Bedeutung liegt in dem Maßstab, in dem heute gescannt wird. Wird eine schwerwiegende Schwachstelle in einem verbreiteten Produkt bekannt, beginnt binnen Stunden das automatisierte Suchen nach Systemen mit der verwundbaren Version. Systeme, die ihre Version nennen, landen auf dieser Liste. Systeme, die das nicht tun, müssen mit mehr Aufwand untersucht werden, und bei großflächigem Scannen wird dieser Aufwand meist nicht betrieben.

Es gibt einen zweiten Effekt, der über diese Header hinausgeht. Eine Antwort, die vollständig auf Standardeinstellungen läuft, ist für einen erfahrenen Tester ein Signal: Wurde diese einfache Anpassung nicht vorgenommen, ist die Wahrscheinlichkeit hoch, dass weitere Standardeinstellungen stehen geblieben sind. Die Header sind dann weniger eine Schwachstelle als ein Anzeichen.

Wie spürt man Versionsinformationen in Headern auf?

Ein Tester betrachtet die Header mehrerer verschiedener Antworten: der Startseite, einer statischen Datei, eines API-Endpunkts und einer Fehlerseite. Diese geben häufig unterschiedliche Angaben preis, da sie von unterschiedlichen Komponenten verarbeitet werden; eine statische Datei stammt vom Webserver, eine API-Antwort von der dahinterliegenden Anwendung.

Zusätzlich wird auf weniger auffällige Quellen geachtet: HTML-Kommentare mit einer Generatorangabe, Meta-Tags, die Dateinamen mitgelieferter Standard-Stylesheets und Cookienamen, die die Plattform verraten. Ebenso werden Fehlerseiten abgerufen, denn diese sind häufig eine Standardseite des Servers mit Versionsangaben in der Fußzeile. Ferner wird geprüft, ob die Header auch auf Routen bereinigt werden, die am Reverse Proxy vorbei bedient werden. AssistSec nutzt die gefundenen Versionen anschließend, um zu prüfen, ob bekannte Schwachstellen darauf zutreffen, denn darauf kommt es letztlich an, nicht auf den Header selbst.

Wie verhindert man Versionsinformationen in Headern?

• Schalten Sie das Mitsenden von Versionsinformationen in Ihrem Webserver ab.
• Entfernen Sie X-Powered-By und frameworkspezifische Header in der Anwendung oder am Reverse Proxy.
• Bereinigen Sie die Header zentral am Proxy, damit auch Komponenten erfasst werden, die Sie nicht verwalten.
• Prüfen Sie die Header bei verschiedenen Arten von Antworten: Seiten, statische Dateien, APIs und Fehlerseiten.
• Ersetzen Sie Standardfehlerseiten durch eigene Seiten ohne Versionsangaben oder Servernamen.
• Entfernen Sie Generator-Meta-Tags und verräterische HTML-Kommentare aus Ihren Vorlagen.
• Betrachten Sie dies als Ergänzung zur Pflege Ihrer Komponenten, nie als Ersatz dafür.
• Prüfen Sie die Einstellung nach einer Migration oder Aktualisierung erneut, denn Standardwerte kehren dann zurück.