Hacker kompromittieren NGINX-Server, um den Benutzerverkehr umzuleiten!
Ein Angreifer kompromittiert NGINX-Server in einer Kampagne, die den Benutzerdatenverkehr abfängt und über die Backend-Infrastruktur des Angreifers umleitet.
NGINX ist eine Open-Source-Software für das Web-Traffic-Management. Sie vermittelt Verbindungen zwischen Benutzern und Servern und wird für Webservering, Lastverteilung, Caching und Reverse-Proxying eingesetzt.
Die von Forschern der DataDog Security Labs entdeckte Schadsoftware-Kampagne zielt auf NGINX-Installationen und Baota-Hosting-Management-Panels ab, die von Websites mit asiatischen Top-Level-Domains (.in, .id, .pe, .bd und .th) sowie von Regierungs- und Bildungswebsites (.edu und .gov) verwendet werden.
Angreifer verändern bestehende NGINX-Konfigurationsdateien, indem sie bösartige „Location“ -Blöcke einfügen, die eingehende Anfragen auf vom Angreifer ausgewählten URL-Pfaden abfangen.
Anschließend werden sie so umgeschrieben, dass sie die vollständige ursprüngliche URL enthalten, und der Datenverkehr wird über die Direktive ‚proxy_pass‘ an vom Angreifer kontrollierte Domains weitergeleitet.
Die missbräuchliche Direktive wird normalerweise für den Lastausgleich verwendet und ermöglicht es NGINX, Anfragen über alternative Backend-Servergruppen umzuleiten, um die Leistung oder Zuverlässigkeit zu verbessern; daher löst ihr Missbrauch keine Sicherheitswarnungen aus.
Anfrage-Header wie ‚Host‘, ‚X-Real-IP‘, ‚User-Agent‘ und ‚Referer‘ werden beibehalten, um den Datenverkehr als legitim erscheinen zu lassen.
Der Angriff nutzt ein skriptbasiertes, mehrstufiges Toolkit, um die NGINX-Konfigurationsmanipulationen durchzuführen. Das Toolkit arbeitet in fünf Phasen:
- Phase 1 – zx.sh: Fungiert als initiales Steuerungsskript und ist für das Herunterladen und Ausführen der übrigen Phasen zuständig. Es enthält einen Ausweichmechanismus, der HTTP-Anfragen über TCP sendet, falls curl oder wget nicht verfügbar sind.
- Phase 2 – bt.sh: Greift auf die vom Baota-Panel verwalteten NGINX-Konfigurationsdateien zu. Es wählt dynamisch Injektionsvorlagen anhand des Werts von server_name aus, überschreibt die Konfiguration sicher und lädt NGINX neu, um Ausfallzeiten zu vermeiden.
- Phase 3 – 4zdh.sh : Listet gängige NGINX-Konfigurationsverzeichnisse wie sites-enabled, conf.d und sites-available auf. Es verwendet Parsing-Tools wie csplit und awk, um Konfigurationsbeschädigungen zu verhindern, erkennt vorherige Einschleusungen durch Hashing und eine globale Mapping-Datei und validiert Änderungen mit nginx -t vor dem Neuladen.
- Phase 4 – zdh.sh: Verwendet einen gezielteren Ansatz, der sich hauptsächlich auf /etc/nginx/sites-enabled konzentriert, insbesondere auf .in- und .id-Domains. Es folgt dem gleichen Konfigurationstest- und Neuladeprozess, wobei ein erzwungener Neustart (pkill) als Ausweichlösung dient.
- Phase 5 – ok.sh: Durchsucht kompromittierte NGINX-Konfigurationen, um eine Karte der gekaperten Domains, Injection-Templates und Proxy-Ziele zu erstellen. Die gesammelten Daten werden anschließend an einen Command-and-Control-Server (C2) unter 158.94.210[.]227 exfiltriert.
Diese Angriffe sind schwer zu erkennen, da sie keine NGINX-Schwachstelle ausnutzen; stattdessen verstecken sie bösartige Anweisungen in den Konfigurationsdateien, die selten überprüft werden.
Außerdem erreicht der Benutzerverkehr weiterhin sein Ziel, oft direkt, sodass die durchlaufende Angreiferinfrastruktur wahrscheinlich nicht bemerkt wird, es sei denn, es wird eine gezielte Überwachung durchgeführt.
Weitere Infos, siehe → https://securitylabs.datadoghq.com/articles/web-traffic-hijacking-nginx-configuration-malicious/