Schwachstellenforschung & -behebung: Azure Cloud-Infrastruktur
Projektübersicht
Dieses Projekt dokumentiert den End-to-End-Lebenszyklus des Schwachstellenmanagements für eine in der Cloud gehostete Windows Server 2025-Instanz (CyberVM). Das Labor demonstriert einen proaktiven Ansatz zur Identifizierung, Analyse und Neutralisierung von Sicherheitsrisiken mit hohem Schweregrad – sowohl durch direktes Software-Patching als auch durch architektonische kompensierende Kontrollen.
1. Identifizierung & Basisbewertung
Ein erster authentifizierter Scan wurde mit Nessus Essentials durchgeführt, um eine Sicherheitsbasislinie zu etablieren. Der Scan ergab insgesamt 66 Schwachstellen, darunter zwei Ziele mit hoher Priorität.
| Schweregrad | ID | Beschreibung | CVSS v3.0 |
|---|
| Hoch | KB5075899 | Fehlendes kumulatives Update für Windows Server 2026 | 7.0 |
| Hoch | CVE-2025-14847 | Nicht initialisiertes Heap-Speicherleck in MongoDB (Splunk) | 7.5 |
Abbildung 1: Erster Basis-Scan zur Identifizierung kritischer Angriffspunkte.
2. Technische Risikoanalyse
- KB5075899: Fehlende Patches für mehrere CVEs, die zu Remote-Codeausführung (RCE) oder lokaler Rechteausweitung führen könnten.
- CVE-2025-14847: Eine Längeninkonsistenz im Protokollheader der gebündelten MongoDB-Instanz (v4.2.24), die von Splunk verwendet wird. Diese Schwachstelle ermöglicht es nicht authentifizierten Clients, nicht initialisierten Heap-Speicher zu lesen.
3. Behebung & Implementierung
Aufgabe A: Betriebssystem-Patching (KB5075899)
- Herausforderung: Automatisierte Windows-Updates kamen nicht voran.
- Lösung: Manueller Eingriff durch Herunterladen des eigenständigen
.msu-Installers aus dem Microsoft Update Catalog und Bereitstellung mit Administratorrechten.
- Ergebnis: Systembinärdateien wurden erfolgreich aktualisiert und ein obligatorischer Neustart durchgeführt, um die Härtung abzuschließen.
Aufgabe B: Netzwerk-Isolation (CVE-2025-14847)
- Das Dilemma: Ein Upgrade der gebündelten MongoDB war aufgrund von Splunk-Abhängigkeitsbeschränkungen nicht durchführbar (Verfügbarkeitsrisiko).
- Die Wende: Obwohl ich zunächst eine Azure Firewall Policy entworfen hatte, wechselte ich erfolgreich zu einer Network Security Group (NSG)-Eingangsregel, da auf Abonnementebene Ressourcenbeschränkungen bestanden. Dies zeigt die Fähigkeit, wirksame Sicherheitskontrollen innerhalb von Infrastrukturbeschränkungen umzusetzen.
- Umgesetzte Kontrolle:
- Regel:
Deny_MongoDB_8191
- Priorität: 105
- Aktion: Verweigern
- Beschreibung: Präventive kompensierende Kontrolle für CVE-2025-14847. Blockiert den Exploit-Pfad des Heap-Speicherlecks der gebündelten MongoDB auf CyberVM.
Abbildung 2: Implementierung der Isolation auf Host-Ebene über Azure NSG.
4. Verifizierung & Validierung
Nach der Behebung wurde ein abschließender Validierungsscan durchgeführt, um die Reduzierung der Angriffsfläche zu bestätigen.
- Status: BEHOBEN
- Technisches Ergebnis: Sowohl das RCE-Risiko auf Betriebssystemebene als auch der Pfad des Speicherlecks auf Netzwerkebene wurden erfolgreich geschlossen.
Abbildung 3: Abschließender Nessus-Scan, der die erfolgreiche Risikominderung bestätigt.
Demonstrierte technische Fähigkeiten
- Schwachstellenmanagement: End-to-End-Lebenszyklus von der Erkennung bis zur Verifizierung.
- Cloud-Infrastruktur: Konfiguration von Azure-NSGs und Entwurf von Enterprise-Firewall-Richtlinien.
- Bedrohungssuche (KQL): Entwicklung von Kusto-Abfragen zur Überwachung unbefugter Zugriffsversuche auf verweigerte Ports.
- Kritisches Denken: Umgang mit Infrastrukturbeschränkungen, um wirksame Sicherheitsergebnisse zu erzielen.