Bericht zum externen Penetrationstest

Machine Config Server des Clusters offengelegt — Vollständige Offenlegung der Cluster-Bootstrap-Geheimnisse

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Zusammenfassung

Der Machine Config Server (MCS) des Clusters wurde auf einem nicht standardmäßigen Port ohne Authentifizierung offen zugänglich vorgefunden. Dieser Endpunkt liefert vollständige Bootstrap-Konfigurationen sowohl für Control-Plane- als auch Worker-Knoten und legt SSH-Schlüssel mit Root-Zugriff auf alle Cluster-Knoten, das Kubernetes-CA-Zertifikat, die interne API-Server-Adresse und die vollständige Cluster-Infrastrukturkonfiguration offen.

Schritte zur Reproduktion

1. Die Aufklärung enthüllte einen offengelegten HAProxy-Statistik-Endpunkt auf Port 9000, der alle Backend-Dienste auflistete.
2. Die Backend-Liste enthielt einen Dienst namens platform_machine_config_server_be, der Port 22623 zugeordnet war.
3. Eine Anfrage an die Bootstrap-Konfiguration des Master-Knotens lieferte eine 914 KB große JSON-Datei zurück — ohne Authentifizierung.

Technische Details

Die Bootstrap-Konfiguration enthielt SSH-Schlüssel mit Root-Zugriff auf alle Control-Plane- und Worker-Knoten (über den Benutzer core mit passwortlosem sudo), das Kubernetes-CA-Zertifikat (Vertrauensanker des gesamten Clusters), die interne API-Server-Adresse und Dienstnetzwerkkonfiguration, Container-Laufzeitkonfiguration inklusive Registry-Anmeldeinformationen sowie statische Pod-Manifeste für Control-Plane-Komponenten.

Proof of Concept

$ curl -sk https://123.456.789.10:22623/config/master | wc -c
914318

$ curl -sk https://123.456.789.10:22623/config/master | grep -o 'ssh-[^"]*'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFAKEKEYEXAMPLE000000000000 services

$ curl -sk https://123.456.789.10:22623/config/master | grep -o 'api-int\.[^'\\']*'
api-int.c1.xyz-unternehmen.de

Auswirkungen

Vollständige Cluster-Kompromittierung. Mit dem extrahierten SSH-Schlüssel erhält ein Angreifer Root-Shell-Zugriff auf jeden Knoten im Cluster, vollständige Kontrolle über alle Container und Workloads, Zugriff auf alle persistenten Volumes und deren Daten, Kubernetes-Cluster-Admin-Zugriff durch Extrahieren von Service-Account-Tokens aus Knoten-Dateisystemen.

Behebung

1. Sofortige Entfernung des MCS-Backends aus der öffentlichen Load-Balancer-Konfiguration
2. Rotation des offengelegten SSH-Schlüssels auf allen Knoten
3. Rotation des Kubernetes-CA-Zertifikats und aller Knotenzertifikate
4. Firewall für den MCS-Port — nur Zugriff aus dem internen Cluster-Netzwerk
5. Prüfung aller authorized_keys-Dateien auf den Knoten auf unbefugte Ergänzungen

Cluster-Webkonsole & OAuth-Server öffentlich zugänglich mit integriertem Admin-Identitätsanbieter

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Zusammenfassung

Die Cluster-Webkonsole und der OAuth-Authentifizierungsserver sind öffentlich zugänglich. Die Anmeldeseite zeigt zwei Identitätsanbieter, einschließlich des integrierten Plattform-Administratorkontos. Das Anmeldeformular ist voll funktionsfähig und akzeptiert Anmeldeversuche, was Brute-Force-Angriffe gegen das höchstprivilegierte Cluster-Konto ermöglicht.

Schritte zur Reproduktion

1. Die Webkonsole wurde durch Backend-Enumeration aus den offengelegten HAProxy-Statistiken entdeckt.
2. Die Konsole leitete auf den OAuth-Server weiter, der eine Anmeldeseite mit dem integrierten Admin-Identitätsanbieter anzeigte.
3. Das Anmeldeformular akzeptierte Anmeldeinformationen und unterschied sichtbar zwischen gültigen und ungültigen Anmeldedaten.

Technische Details

Der OAuth-Login-Endpunkt akzeptiert POST-Anfragen mit Benutzername/Passwort-Feldern und einem CSRF-Token. Fehlgeschlagene Versuche werden mit reason=authentication_error umgeleitet, was die Validierung von Anmeldeinformationen bestätigt. Es wurde kein Rate Limiting festgestellt.

Proof of Concept

$ curl -sk -o /dev/null -w "%{http_code}" \
  https://console-openshift-console.apps.c1.xyz-unternehmen.de/
200

$ curl -sk -X POST "https://oauth-openshift.apps.c1.xyz-unternehmen.de/login" \
  -d "username=kubeadmin&password=test123&csrf=..."
→ 302 → /login?reason=authentication_error
(Anmeldeinformationen abgelehnt — Endpunkt funktionsfähig)

Auswirkungen

Brute-Force-Angriffsfläche gegen das höchstprivilegierte Cluster-Konto; vollständige Cluster-Admin-Kompromittierung bei Erraten der Anmeldedaten; Offenlegung der GitHub-OAuth-Client-ID ermöglicht Phishing-Angriffe; in Kombination mit RPT-05 und RPT-06 entsteht eine vollständige Angriffskette.

Behebung

1. Einschränkung der Webkonsole und OAuth-Endpunkte auf interne/VPN-IPs
2. Implementierung von Rate Limiting am OAuth /login-Endpunkt
3. Deaktivierung oder Rotation des integrierten Admin-Kontos (nur SSO/OIDC verwenden)
4. Aktivierung von Audit-Logging für alle Authentifizierungsversuche
5. Erwägung eines OIDC-Anbieters mit MFA anstelle statischer Anmeldeinformationen

Infrastruktur-Monitoring-Schnittstelle ohne Authentifizierung offengelegt

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Zusammenfassung

Die HAProxy-Statistik-Schnittstelle war auf Port 9000 ohne Authentifizierung zugänglich. Dieser Endpunkt enthüllt die vollständige Backend-Infrastruktur-Topologie, einschließlich aller internen Dienst-Hostnamen, Ports, Gesundheitsstatus, Verkehrsmetriken und Sitzungsraten.

Schritte zur Reproduktion

1. Port-Scanning des öffentlichen IP-Bereichs enthüllte einen offenen HTTP-Dienst auf Port 9000.
2. Eine Anfrage an den Root-Pfad lieferte den vollständigen HAProxy-Statistikbericht im HTML-Format zurück.
3. Der Bericht listete jede Backend-Servergruppe mit Servernamen, Adressen, Ports und Betriebsstatus auf.

Technische Details

Die Statistikseite enthüllte Backend-Namen wie platform_machine_config_server_be, platform_k8s_api_be, platform_https_ingress_traffic_be, platform_oauth_be und webmail_be. Jeder Eintrag enthielt Backend-Server-Adresse, aktuelle Sitzungsanzahl, Bytes in/out, Health-Check-Status und Fehlerraten.

Proof of Concept

$ curl -s http://123.456.789.10:9000/ | grep -o 'platform_[a-z_]*_be'
platform_machine_config_server_be
platform_k8s_api_be
platform_https_ingress_traffic_be
platform_oauth_be

$ curl -s http://123.456.789.10:9000/ | grep -E '^[a-z]+.*(UP|DOWN)'
webmail_be   123.456.789.10    UP   0   128   45678   98765
[Vollständige Backend-Tabelle mit Sitzungen, Transfer und Status]

Auswirkungen

Vollständige Offenlegung der Infrastruktur-Topologie. Ein Angreifer erhält eine umfassende Karte aller internen Dienste, ihrer Adressen und Rollen — die Aufklärungsphase entfällt vollständig.

Behebung

1. Entfernung des HAProxy-Statistik-Endpunkts aus der öffentlichen Frontend-Konfiguration
2. Bindung des Statistik-Sockets nur an localhost oder Anforderung von HTTP Basic Authentication
3. Falls Fernzugriff auf die Überwachung erforderlich ist, diesen über VPN oder SSH-Tunnel bereitstellen

Kubernetes-API-Server direkt im Internet offengelegt

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Zusammenfassung

Der Kubernetes-API-Server ist direkt aus dem öffentlichen Internet auf Port 6443 erreichbar. Während der anonyme Zugriff auf API-Ressourcen ordnungsgemäß eingeschränkt ist (HTTP 403), gibt der API-Server Versionsinformationen, Gesundheitsstatus und OAuth-Discovery-Metadaten ohne Authentifizierung preis.

Schritte zur Reproduktion

1. Zugriff auf Port 6443 auf beiden öffentlichen IPs — beide antworteten mit dem TLS-Handshake des Kubernetes-API-Servers.
2. Der /version-Endpunkt gab die genaue Kubernetes-Version, Go-Compiler-Version und Build-Datum zurück.
3. Die /healthz, /readyz und /livez-Endpunkte antworteten ohne Authentifizierung.

Technische Details

Der API-Server gab Kubernetes v1.34.7, kompiliert mit Go 1.24.13 (Red Hat Build), preis. Der OAuth-Discovery-Endpunkt gab Issuer-URL, Autorisierungs-Endpunkt, Token-Endpunkt und unterstützte Scopes zurück.

Proof of Concept

$ curl -sk https://123.456.789.10:6443/version
{"major":"1","minor":"34","gitVersion":"v1.34.7",
 "goVersion":"go1.24.13","platform":"linux/amd64"}

$ curl -sk https://123.456.789.10:6443/healthz
ok

$ curl -sk https://123.456.789.11:6443/version
{"major":"1","minor":"34",...}
[Auf beiden öffentlichen IPs erreichbar]

Auswirkungen

Direkte Angriffsfläche für Kubernetes-API-CVEs ohne VPN- oder Bastion-Zugang. Die Versionsoffenlegung ermöglicht gezielte Schwachstellenforschung. In Kombination mit dem extrahierten CA-Zertifikat und den offengelegten OAuth-Endpunkten entsteht eine vollständige Angriffskette.

Behebung

1. Firewall für Port 6443 — Zugriff nur aus dem internen Cluster-Netzwerk und vertrauenswürdigen Management-IPs
2. Überprüfung, dass das Load-Balancer-Frontend nur an interne Schnittstellen gebunden ist
3. Einrichtung eines VPN für administrativen Kubernetes-API-Zugriff
4. Aktivierung von API-Server-Audit-Logging

Session-Token in URL-Query-String offengelegt

AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Zusammenfassung

Das authentifizierte Session-Token wird als URL-Query-Parameter bei einer Weiterleitung von der Hauptanwendung zur Builder-Subdomain übergeben. Dies legt das Session-Token über den Referer-Header gegenüber Drittanbieterdiensten offen, speichert es im Browser-Verlauf und hinterlässt es in Server- und Proxy-Protokollen.

Schritte zur Reproduktion

1. Anmeldung bei der Hauptanwendung als normaler Benutzer.
2. Navigation zur Kampagnenerstellungsseite löste eine Weiterleitung zur Builder-Subdomain aus.
3. Der HTTP-302-Weiterleitungs-Location-Header enthielt das vollständige Session-Token als session_id-Query-Parameter.
4. Der session_id-Wert war identisch mit dem bestehenden Session-Cookie.

Technische Details

Das Weiterleitungs-URL-Muster war https://builder.xyz-unternehmen.de/?type=popup&session_id=<token>&lang=de. Der session_id-Parameterwert stimmte exakt mit dem xyz_sessionid-Cookie überein. Die Builder-Seite lädt Ressourcen von 4 externen Domains.

Proof of Concept

$ curl -sI "https://app.xyz-unternehmen.de/on-site/create/popup/" \
  -H 'Cookie: xyz_sessionid=sm38ntmftuj2q6adf3f5lv4kd2tpb5o9'

HTTP/2 302
Location: https://builder.xyz-unternehmen.de/?type=popup\
&session_id=sm38ntmftuj2q6adf3f5lv4kd2tpb5o9&lang=de&referrer=xyz

# session_id == xyz_sessionid (identisch)
# 4 externe Domains erhalten Token im Referer

Auswirkungen

Session-Token werden über mehrere Kanäle offengelegt: Referer-Header an mindestens 4 externe Domains, Browser-Verlauf im Klartext, Server-Zugriffsprotokolle auf der Builder-Subdomain und zwischengeschaltete Proxy-Protokolle.

Behebung

1. Übermittlung des Session-Tokens nur über das bestehende sichere HttpOnly-Cookie — nicht in URL-Parametern duplizieren
2. Die Builder-Subdomain sollte die Session aus dem Cookie lesen, nicht aus der URL
3. Alternativ: Verwendung eines kurzlebigen Einmal-Tokens, das nach der ersten Verwendung abläuft

Virtualisierungs-Management-Schnittstelle offengelegt

Zusammenfassung

Die Proxmox Virtual Environment Management-Schnittstelle ist auf Port 8006 ohne IP-Einschränkung offengelegt. Obwohl die Schnittstelle eine Authentifizierung erfordert, gibt sie über API-Antworten den Authentifizierungsbereich preis und vergrößert die Angriffsfläche für Credential-Angriffe und CVE-Exploitation.

Schritte zur Reproduktion

1. Port-Scanning enthüllte einen HTTPS-Dienst auf Port 8006 mit Proxmox VE.
2. Die Proxmox-VE-API gab Realm-Informationen ohne Authentifizierung zurück.
3. Die Anmeldeseite war vollständig zugänglich und akzeptierte Anmeldeversuche.

Technische Details

Die Proxmox-VE-API unter /api2/json/access/domains gab konfigurierte Authentifizierungs-Realms preis. Die Versionsinformationen der Management-Schnittstelle ermöglichen gezielte CVE-Recherche.

Proof of Concept

$ curl -sk https://123.456.789.10:8006/api2/json/access/domains
{"data":[{"realm":"pam"},{"realm":"pve"}]}

$ curl -sk https://123.456.789.10:8006/ | grep -o 'Proxmox.*<'
Proxmox Virtual Environment

Auswirkungen

Vergrößerte Angriffsfläche für Infrastrukturkompromittierung. Proxmox VE bietet vollständige Kontrolle über alle virtuellen Maschinen, einschließlich der Kubernetes-Cluster-Knoten.

Behebung

1. Zugriff auf die Management-Schnittstelle über VPN oder IP-Allowlisting einschränken
2. Rate Limiting und Fail2ban für Anmeldeversuche implementieren
3. Management-Schnittstellen in ein dediziertes Management-Netzwerk verlagern

Offengelegte Webmail- & Groupware-Schnittstelle

Zusammenfassung

Eine Webmail-Schnittstelle und Groupware-Installation sind ohne IP-Einschränkung offengelegt. Obwohl die Anmeldeseite selbst keine Daten preisgibt, vergrößert die Offenlegung die Angriffsfläche für Brute-Force-Angriffe, Phishing und CVE-Exploitation.

Schritte zur Reproduktion

1. Der Webmail-Hostname wurde durch HAProxy-Statistik-Enumeration entdeckt.
2. Es wurde bestätigt, dass die Webmail- und Groupware-Anmeldeseiten ohne Einschränkung zugänglich sind.
3. API-Status-Endpunkte waren erreichbar (Umleitung zur Anmeldung für nicht authentifizierte Anfragen).

Technische Details

Die Webmail-Installation wurde durch HTML-Quellcode-Analyse bestätigt. Die Groupware-Schnittstelle war unter einem vorhersagbaren Pfad zugänglich. Interne API-Endpunkte für den Container-Status waren erreichbar (HTTP 200).

Proof of Concept

$ curl -s https://mail.xyz-unternehmen.de/ | grep -o 'mailcow'
mailcow (Installation bestätigt)

$ curl -s -o /dev/null -w "%{http_code}" https://mail.xyz-unternehmen.de/SOGo/
200

Auswirkungen

Vergrößerte Angriffsfläche für E-Mail-Konto-Kompromittierung, Brute-Force von Anmeldeinformationen, CVE-Exploitation und Phishing.

Behebung

1. Zugriff auf die Webmail-Schnittstelle über VPN oder IP-Allowlisting einschränken
2. Rate Limiting für Anmeldeversuche implementieren
3. Fail2ban für wiederholte Authentifizierungsfehler einsetzen