Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03427.jsonl.gz/1426

Only in German available.
Published on: Sept. 28, 2023
Author: Thomas Federer
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.
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.
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.
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:
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.
Sind Ihre Webserver richtig konfiguriert? Unser Security-Review bringt Ihnen Klarheit.
A password with 8 characters with numbers, upper and lower case letters and symbols can be cracked in under one hour.
Source: Hive Systems
X
Sind Ihre Webserver richtig konfiguriert? Unser Security-Review bringt Ihnen Klarheit.
Contact us without obligation: