Raport z Zewnętrznego Testu Penetracyjnego

Serwer Machine Config klastra ujawniony — pełne ujawnienie sekretów bootstrap klastra

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

Opis

Serwer Machine Config Server (MCS) klastra został znaleziony ujawniony na niestandardowym porcie bez uwierzytelnienia. Ten endpoint udostępnia kompletne konfiguracje bootstrap dla węzłów control-plane i worker, ujawniając klucze SSH dające dostęp root do wszystkich węzłów klastra, certyfikat CA Kubernetes, wewnętrzny adres API serwera oraz pełną konfigurację infrastruktury klastra.

Kroki do Odtworzenia

1. Rekonesans ujawnił ujawniony endpoint statystyk HAProxy na porcie 9000, wyświetlający wszystkie usługi backendowe.
2. Lista backendów zawierała usługę o nazwie platform_machine_config_server_be przypisaną do portu 22623.
3. Zapytanie o konfigurację bootstrap węzła master zwróciło 914 KB plik JSON — bez wymaganego uwierzytelnienia.

Szczegóły Techniczne

Konfiguracja bootstrap zawierała klucze SSH dające dostęp root do wszystkich węzłów control-plane i worker (poprzez użytkownika core z bezhasłowym sudo), certyfikat CA Kubernetes (korzeń zaufania dla całego klastra), wewnętrzny adres API serwera i konfigurację sieci serwisowej, konfigurację środowiska uruchomieniowego kontenerów wraz z poświadczeniami rejestru oraz manifesty statycznych podów dla komponentów control-plane.

Dowód (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.firma-xyz.pl

Wpływ

Pełna kompromitacja klastra. Z wyodrębnionym kluczem SSH atakujący uzyskuje dostęp root do każdego węzła w klastrze, pełną kontrolę nad wszystkimi kontenerami i workloadami, dostęp do wszystkich wolumenów i ich danych, dostęp admina Kubernetes poprzez wyodrębnienie tokenów kont serwisowych z systemów plików węzłów oraz możliwość wdrażania złośliwych workloadów.

Rekomendacje

1. Natychmiastowe usunięcie backendu MCS z publicznej konfiguracji load balancera
2. Rotacja ujawnionego klucza SSH na wszystkich węzłach
3. Rotacja certyfikatu CA Kubernetes i wszystkich certyfikatów węzłów
4. Zapora ogniowa na porcie MCS — dostęp tylko z wewnętrznej sieci klastra
5. Audyt wszystkich plików authorized_keys na węzłach pod kątem nieautoryzowanych dodatków

Konsola webowa klastra i serwer OAuth publicznie dostępne z wbudowanym dostawcą tożsamości admin

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

Opis

Konsola webowa klastra i serwer uwierzytelniania OAuth są publicznie dostępne. Strona logowania ujawnia dwóch dostawców tożsamości, w tym wbudowane konto administratora platformy. Formularz logowania jest w pełni funkcjonalny i przyjmuje próby uwierzytelnienia, umożliwiając ataki brute force na najbardziej uprzywilejowane konto klastra.

Kroki do Odtworzenia

1. Konsola webowa została odkryta poprzez enumerację backendów z ujawnionych statystyk HAProxy.
2. Konsola przekierowała na serwer OAuth, który wyświetlił stronę logowania z wbudowanym dostawcą tożsamości admin.
3. Formularz logowania przyjmował dane uwierzytelniające i widocznie rozróżniał poprawne od niepoprawnych poświadczeń.

Szczegóły Techniczne

Endpoint logowania OAuth akceptuje żądania POST z polami username/password i tokenem CSRF. Nieudane próby przekierowują z reason=authentication_error, potwierdzając walidację poświadczeń. Nie zaobserwowano ograniczeń szybkości — każde żądanie było przetwarzane bez opóźnień.

Dowód (Proof of Concept)

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

$ curl -sk -X POST "https://oauth-openshift.apps.c1.firma-xyz.pl/login" \
  -d "username=kubeadmin&password=test123&csrf=..."
→ 302 → /login?reason=authentication_error
(poświadczenia odrzucone — endpoint funkcjonalny)

Wpływ

Powierzchnia ataku brute force na najbardziej uprzywilejowane konto klastra; pełna kompromitacja admina klastra w przypadku odgadnięcia poświadczeń; ujawnienie client_id GitHub OAuth umożliwia ataki phishingowe; w połączeniu z RPT-05 i RPT-06 tworzy kompletny łańcuch ataku.

Rekomendacje

1. Ograniczenie konsoli webowej i endpointów OAuth tylko do wewnętrznych/VPN IP
2. Wdrożenie rate limiting na endpointcie /login OAuth
3. Wyłączenie lub rotacja wbudowanego konta admin (używać tylko SSO/OIDC)
4. Włączenie audit logowania dla wszystkich prób uwierzytelnienia
5. Rozważenie dostawcy OIDC z MFA zamiast statycznych poświadczeń

Interfejs monitorowania infrastruktury dostępny bez uwierzytelnienia

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

Opis

Interfejs statystyk HAProxy był dostępny na porcie 9000 bez uwierzytelnienia. Ten endpoint ujawnia pełną topologię infrastruktury backendowej, w tym wszystkie wewnętrzne nazwy hostów, porty, statusy, metryki ruchu — dając atakującemu szczegółową mapę sieci do ukierunkowanej eksploitacji.

Kroki do Odtworzenia

1. Skanowanie portów publicznego zakresu IP ujawniło otwartą usługę HTTP na porcie 9000.
2. Zapytanie o ścieżkę główną zwróciło pełny Raport Statystyk HAProxy w formacie HTML.
3. Raport wymieniał każdą grupę serwerów backendowych z nazwami, adresami, portami i statusem.

Szczegóły Techniczne

Strona statystyk ujawniała nazwy backendów takie jak platform_machine_config_server_be (port 22623), platform_k8s_api_be (port 6443), platform_https_ingress_traffic_be, platform_oauth_be i webmail_be. Każdy wpis zawierał adres serwera backendowego, bieżącą liczbę sesji, bajty wejściowe/wyjściowe, status health check i liczbę błędów.

Dowód (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
[Pełna tabela backendów z liczbą sesji, transferem i statusem]

Wpływ

Pełne ujawnienie topologii infrastruktury. Atakujący uzyskuje kompleksową mapę wszystkich usług wewnętrznych, ich adresów i ról — całkowicie eliminując fazę rekonesansu. Nazwy backendów bezpośrednio ujawniły stos technologiczny i umożliwiły ukierunkowane ataki.

Rekomendacje

1. Usunięcie endpointu statystyk HAProxy z publicznej konfiguracji frontendu
2. Zbindowanie socketu statystyk tylko do localhost lub wymaganie HTTP Basic Authentication
3. Jeśli zdalny dostęp do monitorowania jest potrzebny, udostępnienie przez VPN lub tunel SSH

Serwer API Kubernetes bezpośrednio dostępny z internetu

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

Opis

Serwer API Kubernetes jest bezpośrednio dostępny z publicznego internetu na porcie 6443. Chociaż anonimowy dostęp do zasobów API jest poprawnie ograniczony (HTTP 403), serwer API zwraca informacje o wersji, status health i metadane OAuth discovery bez uwierzytelnienia.

Kroki do Odtworzenia

1. Dostęp do portu 6443 na obu publicznych IP — oba odpowiedziały handshake TLS serwera API Kubernetes.
2. Endpoint /version zwrócił dokładną wersję Kubernetes, wersję kompilatora Go i datę budowy.
3. Endpointy /healthz, /readyz, /livez odpowiadały bez uwierzytelnienia.

Szczegóły Techniczne

Serwer API ujawnił Kubernetes v1.34.7 skompilowany z Go 1.24.13 (kompilacja Red Hat). Endpoint OAuth discovery zwrócił URL issuera, endpoint autoryzacji, endpoint tokena i obsługiwane zakresy.

Dowód (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",...}
[Dostępny na obu publicznych IP]

Wpływ

Bezpośrednia powierzchnia ataku dla CVE API Kubernetes bez konieczności VPN lub bastionu. Ujawnienie wersji umożliwia ukierunkowane badanie podatności. W połączeniu z wyodrębnionym certyfikatem CA i endpointami OAuth tworzy to kompletny łańcuch ataku.

Rekomendacje

1. Zapora ogniowa na porcie 6443 — dostęp tylko z wewnętrznej sieci klastra i zaufanych IP
2. Weryfikacja, że frontend load balancera jest zbindowany tylko do wewnętrznych interfejsów
3. Skonfigurowanie VPN dla administracyjnego dostępu do API Kubernetes
4. Włączenie audit logowania API

Token sesji ujawniony w parametrze URL

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

Opis

Uwierzytelniony token sesji jest przekazywany jako parametr query URL podczas przekierowania z głównej aplikacji do subdomeny buildera. Ujawnia to token sesji poprzez nagłówek Referer do usług zewnętrznych, przechowuje go w historii przeglądarki i pozostawia w logach serwerowych.

Kroki do Odtworzenia

1. Uwierzytelnienie do głównej aplikacji jako zwykły użytkownik.
2. Nawigacja do strony tworzenia kampanii wywołała przekierowanie do subdomeny buildera.
3. Nagłówek Location przekierowania HTTP 302 zawierał pełny token sesji jako parametr session_id.
4. Token session_id był identyczny z istniejącym ciasteczkiem sesyjnym.

Szczegóły Techniczne

Wzorzec URL przekierowania: https://builder.firma-xyz.pl/?type=popup&session_id=<token>&lang=en. Wartość session_id odpowiadała dokładnie ciasteczku firma_sessionid. Strona buildera ładuje zasoby z 4 zewnętrznych domen, z których każda otrzymuje token w nagłówku Referer.

Dowód (Proof of Concept)

$ curl -sI "https://app.firma-xyz.pl/on-site/create/popup/" \
  -H 'Cookie: firma_sessionid=sm38ntmftuj2q6adf3f5lv4kd2tpb5o9'

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

# session_id == firma_sessionid (identyczne)
# 4 zewnętrzne domeny otrzymują token w Referer

Wpływ

Tokeny sesji wyciekają wieloma kanałami: nagłówek Referer do co najmniej 4 zewnętrznych domen, historia przeglądarki w plaintext, logi serwera na subdomenie buildera oraz logi proxy. Atakujący, który uzyska token, może podszyć się pod ofiarę.

Rekomendacje

1. Przekazywanie tokenu sesji tylko przez istniejące bezpieczne ciasteczko HttpOnly — nie duplikować w parametrach URL
2. Subdomena buildera powinna odczytywać sesję z ciasteczka, nie z URL
3. Alternatywnie: użyć krótkoterminowego, jednorazowego tokenu który wygasa po pierwszym użyciu

Interfejs zarządzania wirtualizacją ujawniony

Opis

Interfejs zarządzania Proxmox Virtual Environment jest dostępny na porcie 8006 bez ograniczeń IP. Choć interfejs wymaga uwierzytelnienia, ujawnia on realm uwierzytelniania poprzez odpowiedzi API i zwiększa powierzchnię ataku dla ataków na poświadczenia i CVE.

Kroki do Odtworzenia

1. Skanowanie portów ujawniło usługę HTTPS na porcie 8006 z Proxmox VE.
2. API Proxmox VE zwróciło informacje o realmie bez uwierzytelnienia.
3. Strona logowania była w pełni dostępna i przyjmowała dane uwierzytelniające.

Szczegóły Techniczne

API Proxmox VE pod /api2/json/access/domains ujawniło skonfigurowane realmy uwierzytelniania. Informacje o wersji interfejsu zarządzania umożliwiają ukierunkowane badanie CVE.

Dowód (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

Wpływ

Zwiększona powierzchnia ataku dla kompromitacji infrastruktury. Proxmox VE zapewnia pełną kontrolę nad wszystkimi maszynami wirtualnymi, w tym węzłami klastra Kubernetes.

Rekomendacje

1. Ograniczenie dostępu do interfejsu zarządzania przez VPN lub allowlistę IP
2. Wdrożenie rate limiting i fail2ban dla prób logowania
3. Rozważenie przeniesienia interfejsów zarządzania do dedykowanej sieci zarządzania

Ujawniony interfejs webmail i groupware

Opis

Interfejs webmail i instalacja groupware są dostępne bez ograniczeń IP. Choć strona logowania nie wycieka danych, ekspozycja zwiększa powierzchnię ataku dla brute force, phishingu i eksploitacji CVE.

Kroki do Odtworzenia

1. Odkryto nazwę hosta webmail poprzez enumerację statystyk HAProxy.
2. Potwierdzono dostępność stron logowania webmail i groupware bez ograniczeń.
3. Endpointy API były osiągalne (przekierowanie do logowania dla nieuwierzytelnionych).

Szczegóły Techniczne

Instalacja webmail została potwierdzona przez analizę źródła HTML. Interfejs groupware był dostępny pod przewidywalną ścieżką. Wewnętrzne endpointy API dla statusu kontenerów były osiągalne (HTTP 200).

Dowód (Proof of Concept)

$ curl -s https://mail.firma-xyz.pl/ | grep -o 'mailcow'
mailcow (potwierdzona instalacja)

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

Wpływ

Zwiększona powierzchnia ataku dla kompromitacji kont email, brute force poświadczeń, eksploitacji CVE i phishingu.

Rekomendacje

1. Ograniczenie dostępu do interfejsu webmail przez VPN lub allowlistę IP
2. Wdrożenie rate limiting dla prób logowania
3. Wdrożenie fail2ban dla powtarzających się nieudanych uwierzytelnień