Alte Nginx-Miskonfiguration: Eine aktuelle Analyse

Schon vor einigen Jahren hat Orange Tsai in einem Blackhat-Talk auf einen Konfigurationsfehler des Nginx Webservers hingewiesen.

Nginx ist einer der am weitesten verbreiteten Webserver. Etwa 34% aller Webseiten im Internet werden über einen Nginx-Webserver ausgeliefert. Gemäss Docker ist Nginx einer der am meisten verwendeten Technologien in ihren Containern.

Somit ist das Ausmass einer Sicherheitslücke in Nginx riesig.

Konfigurationsfehler

Bei diesem Sicherheitsproblem handelt es sich jedoch nicht um eine Lücke im Source-Code von Nginx. Es ist mehr ein Konfigurationsfehler, welcher Zugriff auf geschützte Dateien erlaubt. Dieser Konfigurationsfehler ist sehr schnell passiert, da er sehr subtil ist.

Anfällige Konfiguration:

location /assets { 
    alias /data/assets/; 
}

Sichere Konfiguration

location /assets/ { 
    alias /data/assets/; 
}

Der einzige Unterschied ist, dass die Location bei der sicheren Konfiguration mit einem Slash (/) endet.

Das Problem

Schauen wir uns den Http-Request "/assets/favicon.ico" an. Bei diesem Request liefert der Nginx folgende Datei aus seinem Speicher aus: "/data/assets/favicon.ico"

Was passiert nun aber bei folgendem Request?

GET /i../app/config.py HTTP/1.1

Bei der unsicheren Konfiguration erstellt Nginx folgenden Pfad, um die Datei vom Speicher zu lesen: /data/assets/../app/config.py was dazu führt, dass die Datei /data/app/config.py gelesen und ausgeliefert wird. In diesem Beispiel sendet Nginx die config.py Datei, in welcher Datenbankzugänge, API-Tokens, etc. vorhanden sind.

.ch und .li Domains

Ein Scan auf Domains und Subdomains von .ch und .li Domains, welche via Nginx ausgeliefert wird ergab, dass von 3’872’502 gescannten Domains/Subdomains 557 (0.014%) den oben erwähnten Konfigurationsfehler aufweisen.

Um dies ausnutzen zu können, müsste ein möglicher Angreifer jedoch noch etwas mehr Zeit investieren und über die verwendete Technologie oder das verwendete Framework Rückschlüsse über mögliche sensitive Dateien zu ziehen und diese Dateien dann herunterladen und analysieren.

Wir fanden das Problem bei Shared-Hostern und bei dedizierten Webservern von Firmen. Dabei handelt es sich um folgende Webapplikationen:

• Webmail
• Remote-Meeting-Plattformen
• Wiki
• Zeiterfassungs-Systeme
• Remote-Report-Systeme
• Interne Colaboration-Plattformen
• Moodle
• Admin-Plattform von Sensor-System
• Raumverwaltungssystem
• Platzreservationssystem
• Issue-Tracker
• Webshop

Schutz

Das Abwehren dieser Art von Angriffen ist simpel. Bei Nginx location Direktiven, welche ein Alias haben, die URI immer mit einem Slash abschliessen.

Da die Nginx-Einstellungen bei Shared-Hostern oft vom Benutzer selber gesetzt werden können, ist jeder Benutzer selber für diese Einstellung verantwortlich.