Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
wazuh-nginx-cve-2026-42945-sca-lab — Zentralisierte Wazuh SCA Assessment für CVE-2026-42945 auf NGINX Servern | Kitploit
Tools/GitHubGitHub/soksofos/wazuh-nginx-cve-2026-42945-sca-lab
DefensivwerkzeugeSchwachstellenanalyseKonfigurationsprüfungWebsicherheitLernen & BildungLabs & Praxis
GitHubsoksofos/wazuh-nginx-cve-2026-42945-sca-lab

wazuh-nginx-cve-2026-42945-sca-lab

Zentralisierte Wazuh SCA Assessment für CVE-2026-42945 auf NGINX Servern

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Repository anzeigen
1vor 3 MonatenNoch nicht geprüft
Teilen

CVE-2026-42945 — NGINX Wazuh SCA Defensives Labor

Übersicht

Dieses Repository dokumentiert ein defensives Labor für CVE-2026-42945, das das NGINX ngx_http_rewrite_module betrifft.

Das Ziel dieses Projekts war es, die CVE aus einer Blue-Team-Perspektive zu betrachten, indem Wazuh Security Configuration Assessment (SCA) verwendet wurde, um die NGINX-Exposition zentral zu bewerten.

Das Labor prüft zwei Expositionsbedingungen:

  1. Eine ungepatchte Ubuntu-NGINX-Paketversion
  2. Ein riskantes NGINX-Rewrite-Konfigurationsmuster im Zusammenhang mit CVE-2026-42945

Das Endergebnis ist eine zentralisierte Wazuh-SCA-Richtlinie, die über die zentrale Wazuh-Agentenkonfiguration auf überwachte NGINX-Server bereitgestellt werden kann.

Laborarchitektur

Das Labor wurde mit einer segmentierten Netzwerkarchitektur aufgebaut.

root@kitploit:~
Internet / WAN
     |
     |
  pfSense Firewall
     |
     |-----------------------------
     |                             |
    LAN                           DMZ
     |                             |
Wazuh Manager                Ubuntu NGINX Server
Wazuh Dashboard              Wazuh Agent
                             NGINX

Komponenten

KomponenteRolle
pfSenseFirewall und LAN/DMZ-Segmentierung
Ubuntu DMZ-ServerNGINX-Server, überwacht von Wazuh
NGINXZieldienst, der auf CVE-Exposition geprüft wird
Wazuh-AgentInstalliert auf dem Ubuntu DMZ-Server
Wazuh ManagerZentraler Überwachungsserver, läuft in Docker
Wazuh DashboardWird zur Überprüfung der SCA-Ergebnisse verwendet

Zielsetzung

Das Ziel war es, einen sicheren und wiederholbaren defensiven Workflow zu erstellen:

root@kitploit:~
Wazuh Manager
     |
     | Zentrale SCA-Richtlinie
     v
Wazuh-Agent auf DMZ-NGINX-Server
     |
     | Prüft Paketversion und NGINX-Konfiguration
     v
Wazuh Dashboard
     |
     | Zeigt bestandene / fehlgeschlagene Prüfungen
     v
Überprüfung der Behebung

Dieser Ansatz ermöglicht die Bewertung der CVE-Exposition ohne Ausführung von Exploit-Code.

Erkennungsstrategie

Die benutzerdefinierte Wazuh-SCA-Richtlinie führt zwei Prüfungen durch.

Prüfung 1 — NGINX-Paketversion

Die Richtlinie prüft, ob die installierte Ubuntu-NGINX-Paketversion der ungepatchten Version aus dem Labor entspricht.

Anfängliche verwundbare Paketversion:

root@kitploit:~
nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

Behobene Paketversion nach der Behebung:

root@kitploit:~
nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Richtliniendatei:

root@kitploit:~
sca-policy/nginx-cve-2026-42945.yml

Prüfung 2 — Riskante NGINX-Rewrite-Konfiguration

Die Richtlinie prüft auch auf ein riskantes Rewrite-Muster im Zusammenhang mit CVE-2026-42945.

Die riskante Testkonfiguration ist hier gespeichert:

root@kitploit:~
nginx-config/vulnerable-example.conf

Die behobene Konfiguration ist hier gespeichert:

root@kitploit:~
nginx-config/remediated-example.conf

Die im Labor getestete riskante Bedingung umfasst:

root@kitploit:~
rewrite-Direktive
unbenannter Capture wie $1
Ersetzung mit ?
Folgedirektive wie set

Repository-Struktur

root@kitploit:~
wazuh-nginx-cve-2026-42945-sca-lab/
├── README.md
├── sca-policy/
│   └── nginx-cve-2026-42945.yml
├── wazuh-config/
│   └── agent.conf
├── nginx-config/
│   ├── vulnerable-example.conf
│   └── remediated-example.conf
├── commands/
│   ├── 01-agent-validation.md
│   ├── 02-nginx-version-check.md
│   ├── 03-sca-policy-deployment.md
│   └── 04-remediation.md
├── screenshots/
│   ├── 01-lab-architecture.png
│   ├── 02-agent-active.png
│   ├── 03-sca-policy-failed.png
│   ├── 04-nginx-package-before.png
│   ├── 05-risky-rewrite-config.png
│   ├── 06-sca-partial-remediation.png
│   ├── 07-nginx-package-after.png
│   └── 08-sca-policy-passed.png
└── docs/
    └── lab-notes.md

Wie das Labor aufgebaut wurde

Schritt 1 — Netzwerksegmentierung

Das Labor verwendete pfSense, um die Umgebung zu trennen in:

root@kitploit:~
LAN:
- Wazuh Manager
- Wazuh Dashboard

DMZ:
- Ubuntu-NGINX-Server
- Wazuh-Agent

Der Ubuntu-NGINX-Server wurde in der DMZ platziert.
Der Wazuh Manager wurde im LAN platziert.

Nur die erforderliche Wazuh-Kommunikation wurde vom DMZ-Server zum Wazuh Manager erlaubt.

Schritt 2 — Bereitstellung des Wazuh-Agenten

Der Ubuntu-DMZ-Server wurde als Wazuh-Agent registriert.

Der Agent wurde vom Wazuh Manager verifiziert und als aktiv bestätigt.

Validierungsbefehle sind dokumentiert in:

root@kitploit:~
commands/01-agent-validation.md

Erwarteter Status:

root@kitploit:~
Agent: ubuntu-dmz-nginx2
Status: Active

Schritt 3 — NGINX-Versionsbewertung

Die installierte NGINX-Paketversion wurde auf dem Ubuntu-DMZ-Server überprüft.

Befehle zur Versionsprüfung sind dokumentiert in:

root@kitploit:~
commands/02-nginx-version-check.md

Anfänglicher Zustand:

root@kitploit:~
nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

Nach dem Paketindex-Update stand die behobene Kandidatenversion zur Verfügung:

root@kitploit:~
1.28.3-2ubuntu1.1

Schritt 4 — Riskante NGINX-Konfiguration

Es wurde eine Test-NGINX-Konfiguration erstellt, um das riskante Rewrite-Muster zu simulieren.

Das verwundbare Beispiel ist gespeichert in:

root@kitploit:~
nginx-config/vulnerable-example.conf

Die behobene Version ist gespeichert in:

root@kitploit:~
nginx-config/remediated-example.conf

Der Zweck war nicht, den Dienst auszunutzen, sondern zu validieren, ob Wazuh SCA eine riskante lokale Konfigurationsexposition identifizieren kann.

Schritt 5 — Benutzerdefinierte Wazuh-SCA-Richtlinie

Eine benutzerdefinierte SCA-Richtlinie wurde auf dem Wazuh Manager erstellt.

Richtliniendatei:

root@kitploit:~
sca-policy/nginx-cve-2026-42945.yml

Im Labor wurde diese Richtlinie aus dem gemeinsamen Verzeichnis des Wazuh Manager bereitgestellt:

root@kitploit:~
/var/ossec/etc/shared/default/nginx-cve-2026-42945.yml

Die Richtlinie enthält zwei Prüfungen:

Prüf-IDZweck
100449Verwundbare/unbehobene NGINX-Ubuntu-Paketversion erkennen
100450Riskantes NGINX-Rewrite-Konfigurationsmuster erkennen

Schritt 6 — Zentrale Agentenkonfiguration

Die benutzerdefinierte SCA-Richtlinie wurde mit der zentralen Wazuh-Agentenkonfiguration bereitgestellt.

Die zentrale Konfigurationsdatei ist in diesem Repository gespeichert als:

root@kitploit:~
wazuh-config/agent.conf

Im Labor wurde sie bereitgestellt unter:

root@kitploit:~
/var/ossec/etc/shared/default/agent.conf

Der Wazuh Manager lief in Docker:

root@kitploit:~
single-node-wazuh.manager-1

Bereitstellungsbefehle sind dokumentiert in:

root@kitploit:~
commands/03-sca-policy-deployment.md

Schritt 7 — Richtlinienvalidierung auf dem Agenten

Nach dem Neustart des Wazuh-Agenten wurde die benutzerdefinierte SCA-Richtlinie vom Ubuntu-DMZ-Server empfangen.

Die empfangene Richtlinie erschien unter:

root@kitploit:~
/var/ossec/etc/shared/nginx-cve-2026-42945.yml

Die Wazuh-Agentenprotokolle bestätigten, dass die Richtlinie geladen und ausgewertet wurde.

Erwartete Protokollindikatoren:

root@kitploit:~
Loaded policy
Starting evaluation of policy
Evaluation finished for policy

Erstes Ergebnis

Bei Vorliegen beider Expositionsbedingungen zeigte das Wazuh Dashboard:

root@kitploit:~
Passed: 0
Failed: 2
Score: 0%

Das bedeutet, dass beide Prüfungen fehlgeschlagen sind:

PrüfungErgebnis
NGINX-PaketversionFehlgeschlagen
Riskante Rewrite-KonfigurationFehlgeschlagen

Screenshot:

root@kitploit:~
screenshots/03-sca-policy-failed.png

Behebung

Behebungsschritt 1 — Riskante Rewrite-Konfiguration beheben

Die riskante NGINX-Rewrite-Konfiguration wurde durch eine sicherere Konfiguration ersetzt.

Referenzdatei:

root@kitploit:~
nginx-config/remediated-example.conf

Nachdem die Konfiguration behoben und der Wazuh-SCA-Scan erneut durchgeführt wurde, war das erwartete Ergebnis:

root@kitploit:~
Passed: 1
Failed: 1
Score: 50%

In diesem Stadium:

PrüfungErgebnis
Riskante Rewrite-KonfigurationBestanden
NGINX-PaketversionFehlgeschlagen

Screenshot:

root@kitploit:~
screenshots/06-sca-partial-remediation.png

Behebungsschritt 2 — NGINX-Pakete aktualisieren

Die NGINX-Pakete wurden mittels einer gezielten Paketaktualisierung aktualisiert.

Behebungsbefehle sind dokumentiert in:

root@kitploit:~
commands/04-remediation.md

Vor der Aktualisierung:

root@kitploit:~
Installed: 1.28.3-2ubuntu1
Candidate: 1.28.3-2ubuntu1.1

Nach der Aktualisierung:

root@kitploit:~
nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Screenshot:

root@kitploit:~
screenshots/07-nginx-package-after.png

Endgültiges Ergebnis

Nach Abschluss beider Behebungsschritte änderte sich das Wazuh-SCA-Ergebnis zu:

root@kitploit:~
Passed: 2
Failed: 0
Score: 100%

Dies bestätigte, dass:

  1. Die riskante Rewrite-Konfiguration behoben wurde
  2. Die NGINX-Pakete auf die behobene Version aktualisiert wurden

Screenshot:

root@kitploit:~
screenshots/08-sca-policy-passed.png

Zusammenfassung der Ergebnisse

PhasePaketprüfungKonfigurationsprüfungWazuh-Ergebnis
AusgangszustandFehlgeschlagenFehlgeschlagen0%
Nach KonfigurationsbehebungFehlgeschlagenBestanden50%
Nach PaketaktualisierungBestandenBestanden100%

Screenshots

Empfohlene Screenshots:

DateiBeschreibung
01-lab-architecture.pngpfSense-LAN/DMZ-Architektur
02-agent-active.pngAktiver Status des Wazuh-Agenten
03-sca-policy-failed.pngAnfängliches fehlgeschlagenes SCA-Ergebnis
04-nginx-package-before.pngVerwundbare NGINX-Paketversion
05-risky-rewrite-config.pngNachweis der riskanten Rewrite-Konfiguration
06-sca-partial-remediation.pngTeilergebnis der Behebung
07-nginx-package-after.pngAktualisierte NGINX-Paketversion
08-sca-policy-passed.pngEndgültiges bestandenes SCA-Ergebnis

Produktionsüberlegungen

Für das Labor wurde die Richtlinie über die Wazuh-Standardgruppe default bereitgestellt.

In der Produktion ist es besser, eine dedizierte Wazuh-Agenten-Gruppe zu erstellen, zum Beispiel:

root@kitploit:~
nginx-servers

Nur Server, die NGINX ausführen, sollten dieser Gruppe zugewiesen werden.

Empfohlene Produktionsbereitstellung:

root@kitploit:~
Wazuh Manager
     |
     | Zentrale SCA-Richtlinie
     v
nginx-servers Agenten-Gruppe
     |
     | Nur auf NGINX-Systeme angewendet
     v
Wazuh Dashboard

Dies vermeidet die Anwendung NGINX-spezifischer Prüfungen auf nicht verwandte Systeme.

Warum kein Exploit-Code verwendet wurde

Dieses Projekt verzichtet bewusst auf Exploit-Code.

Der Zweck des Labors war es, defensive Sicherheitstechnik zu demonstrieren, nicht Ausnutzung.

Die Bewertung basierte auf:

root@kitploit:~
Paketversionsexposition
Konfigurationsexposition
zentrale Wazuh-SCA-Validierung
Überprüfung der Behebung

Wichtige Erkenntnisse

  • Wazuh SCA kann verwendet werden, um die CVE-Exposition zentral zu bewerten.
  • CVE-Validierung erfordert nicht immer die Ausführung von Exploits.
  • pfSense-DMZ-Segmentierung macht das Labor realistischer.
  • Benutzerdefinierte SCA-Richtlinien können sowohl Paketversionen als auch riskante Konfigurationen prüfen.
  • Die Behebung sollte mit messbaren Vorher-Nachher-Ergebnissen validiert werden.
  • Für die Produktionsbereitstellung sollte eine dedizierte Wazuh-Agenten-Gruppe verwendet werden.

Haftungsausschluss

Dieses Repository dient ausschließlich Bildungs- und defensiven Sicherheitszwecken.

Es ist kein Exploit-Code enthalten.

Die Prüfungen sind für eine kontrollierte Laborumgebung ausgelegt und sollten vor dem Einsatz in der Produktion überprüft werden.

Tool herunterladen