blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info service-web-server-cve

Schwachstellen in Webservern (Apache, nginx, IIS, Caddy)

Eine Schwachstelle im Webserver wiegt schwerer als dieselbe Bug-Klasse anderswo. Er sitzt am Eingang, sieht jeden Request, und ein erfolgreicher Angriff endet meist in Code-Ausführung. Warum Patches Vorrang haben und was zu tun ist, wenn ein Patch nicht sofort möglich ist.

Warum diese Kategorie besonders heikel ist

Eine Schwachstelle im Webserver wiegt schwerer als dieselbe Bug-Klasse anderswo, wegen der Position des Webservers:

  • Jeder Besucher-Request läuft hindurch. Jeder Header, jeder Cookie, jede Formularübermittlung: alles ist Eingabe für den Webserver.
  • Er läuft mit erhöhten Rechten. Apache und nginx starten typischerweise als allmächtiger root und droppen anschließend auf einen unprivilegierten Service-User; IIS läuft mit einem Service-Account, der weite Datei-Zugriffe hat. Eine Remote-Code-Execution in einem dieser Dienste ist auf einer schlecht gehärteten Box ein kleiner Schritt von der vollständigen Host-Übernahme entfernt.
  • Er hat direkten Lesezugriff auf Ihre TLS-Private-Keys. Die kryptographische Grundlage Ihrer HTTPS-Zertifikate. Ein Remote-Lese-Bug (die Heartbleed-Familie) kann diese Schlüssel abziehen.
  • Er sieht Request-Bodies aller anderen Mandanten auf derselben Instanz. Multi-Tenant-Hosting wird brüchig, sobald der gemeinsame Webserver einen Memory-Bug hat.

Der blueredix-Scanner liest die laufende Version aus den Response-Headern und der Service-Detection auf Netz-Ebene und fragt anschließend öffentliche Datenbanken, welche CVEs zutreffen, mit Filter gegen die bekannten Falschpositiven (siehe Wie man eine CVE liest).

Welche Bugs die großen Webserver tatsächlich ausliefern

  • Apache HTTP Server. Die meisten Apache-CVEs liegen in drei Bereichen: Request Smuggling (HTTP/1.1- und HTTP/2-Frame-Parsing), Missbrauch von Proxy-Modulen und modulspezifische RCEs (mod_dav, mod_lua, mod_session). Module, die Sie nicht nutzen, sind trotzdem geladen, wenn Apache so paketiert wurde. Deaktivieren reduziert die Angriffsfläche sofort.
  • nginx. Kleinerer Core, weniger CVEs, die wenigen aber oft impactstark: DNS-Resolver-Buffer-Overflows, HTTP/3 (QUIC) Parsing, mp4-Modul-Overflows. Experimentelle Module nicht in Produktion.
  • Microsoft IIS. Historie: ASP.NET-Auth-Bypass und HTTP.sys-Remote-Crashes. Aktuelle Windows-Server-Versionen patchen das per Patch Tuesday. Automatische OS-Updates aktiv lassen.
  • Caddy. Kleine Fläche, moderne Go-Codebasis, weniger CVEs schon durch weniger Features. Sicherheitsarbeit lag eher in der Zertifikats-Ausstellung als im Request-Handling.

Triage bei einer Webserver-CVE

Reihenfolge:

  1. KEV-Flag oder EPSS > 0,5? Same-Day, Out-of-Band patchen. Webserver-CVEs werden schnell aktiv ausgenutzt; jeder internet-sichtbare Dienst der betroffenen Version ist Ziel.
  2. Remote Code Execution? Diese Woche patchen, unabhängig vom EPSS-Wert. Die Schlagzeilen-RCEs der letzten Jahre (Apache Path Traversal CVE-2021-41773, log4j CVE-2021-44228 in Java-Application-Servern) sind alle innerhalb von 24 Stunden von “interessant” zu “aktiv ausgenutzt” gewandert.
  3. Information Disclosure oder DoS? Im nächsten regulären Wartungsfenster patchen, sofern EPSS keine bevorstehende Ausnutzung nahelegt.

Der blueredix-Bericht zeigt alle drei Signale (Schwere, Ausnutzungs-Wahrscheinlichkeit, KEV-Flag) je Befund.

Wenn Patchen warten muss

Manchmal ist sofortiges Patchen nicht möglich (Change-Freeze, Vendor-Appliance, regulierte Umgebung). Mitigationen, die wirklich Zeit kaufen:

  • Den schädlichen Request vor dem Bug abfangen. Die meisten Webserver-CVEs triggern auf einem bestimmten URL-Muster, Header oder Method. Eine Web Application Firewall (Cloudflare, AWS WAF, ModSecurity) kann passende Requests am Edge verwerfen. Vendor-Advisories veröffentlichen solche Muster typischerweise; Stichwort “mitigation” oder “workaround” in den Referenzen.
  • Verwundbares Modul deaktivieren. Erstaunlich viele Webserver-CVEs sind auf ein einzelnes Modul beschränkt (mod_lua, mod_session, nchan). Modul aus, Bug nicht mehr erreichbar; der Rest des Servers bleibt unverändert.
  • Quell-IPs einschränken. Interne Admin-Pfade lassen sich meist auf Büro-IPs gaten; auch die öffentliche Fläche lässt sich enger ziehen, wenn die Kund:innenbasis bekannt ist.
  • Reverse-Proxy davorstellen. Ein Caddy oder nginx vor einem Apache-Backend kann den Request normalisieren und das Angriffsmuster abfangen, bevor es den verwundbaren Server erreicht. Keine dauerhafte Lösung, aber für kurze Fenster nützlich.

Hinweis zu OS-Paketen

Kommt Ihr Webserver aus dem Paketmanager Ihrer Distribution (apt, yum, dnf unter Linux), erzählt die Upstream-Versionsnummer nicht die ganze Geschichte. Distros backporten Sicherheitsfixes auf stabile Upstream-Versionen. “Apache 2.4.52” auf Ubuntu 22.04 kann zehn Patches haben, die das Upstream-2.4.52 nicht kennt. Der blueredix-Scanner erkennt das Distro-Tag und überspringt den öffentlichen Datenbank-Lookup für solche Builds; stattdessen kommt eine Info-Level-Notiz “distribution-managed”. Maßgeblich ist der Sicherheits-Tracker Ihrer Distribution:

Mehr dazu