CVE-2025-32433: krytyczne RCE w serwerze SSH Erlang/OTP

CVE-2025-32433 to krytyczna luka w serwerze SSH biblioteki Erlang/OTP. Otrzymała maksymalną ocenę CVSS 10.0, ponieważ napastnik z dostępem sieciowym może wykonać dowolne polecenia przed uwierzytelnieniem, bez hasła, klucza SSH i interakcji użytkownika. Zagrożone nie są wszystkie aplikacje napisane w Erlangu, lecz te, które uruchamiają serwer SSH oparty na module Erlang/OTP ssh.

Priorytet: znajdź aplikacje używające serwera Erlang/OTP SSH, zainstaluj odpowiednią poprawioną linię OTP, a do czasu aktualizacji wyłącz usługę lub zablokuj ją zaporą. Publiczny PoC istnieje, więc samo ukrycie bannera wersji nie jest zabezpieczeniem.

Najważniejsze fakty

Parametr	Potwierdzona wartość
CVE	CVE-2025-32433
Komponent	serwer SSH w Erlang/OTP
CVSS	10.0 — krytyczna
Wymagane konto	nie
Wymagana interakcja	nie
Skutek	wykonanie poleceń z uprawnieniami procesu usługi
Poprawione OTP	27.3.3, 26.2.5.11, 25.3.2.20
Poprawione `ssh`	5.2.10, 5.1.4.8, 4.15.3.12
Publiczny PoC	tak

Oficjalne advisory Erlang/OTP wskazuje, że podatni są użytkownicy uruchamiający serwer SSH tej biblioteki, niezależnie od przeznaczenia aplikacji. Wersje wcześniejsze niż OTP 17 nie są formalnie ujęte w nowym schemacie wersjonowania, ale maintainerzy uznali, że prawdopodobnie również są zagrożone.

Na czym polega błąd protokołu

SSH ma wyraźne etapy: negocjację transportu, wymianę kluczy, uwierzytelnienie i dopiero potem otwieranie kanałów sesji oraz wykonywanie poleceń. Implementacja musi odrzucać wiadomości, które pojawiają się w niewłaściwym stanie protokołu.

CVE-2025-32433 wynika z nieprawidłowej obsługi komunikatów SSH przed zakończeniem uwierzytelnienia. Podatny serwer przyjmował określone komunikaty połączenia w fazie, w której klient nie udowodnił jeszcze swojej tożsamości. W rezultacie możliwe było dotarcie do funkcji wykonujących akcje przeznaczone dla uwierzytelnionej sesji.

To nie jest błąd konfiguracji haseł ani słaby algorytm kryptograficzny. Zmiana hasła, wyłączenie logowania root czy wymaganie kluczy publicznych nie usuwa luki, ponieważ łańcuch ataku omija samą granicę uwierzytelnienia.

Root cause i mechanizm poprawki

W protokole SSH zakończenie wymiany kluczy nie oznacza jeszcze, że klient został uwierzytelniony. Serwer ma utrzymywać oddzielny stan dla transportu, uwierzytelnienia użytkownika i protokołu połączenia, który obsługuje kanały sesyjne. Problem w Erlang/OTP polegał na tym, że wiadomość należąca do protokołu połączenia mogła zostać obsłużona, mimo że stan użytkownika nadal był nieuwierzytelniony. To naruszało granicę opisaną w RFC 4252 i pozwalało osiągnąć funkcje przeznaczone dla późniejszej fazy sesji.

Commit naprawczy Erlang/OTP pokazuje istotę zmiany bez potrzeby odtwarzania exploita: daemon rozłącza klienta, gdy otrzyma komunikat protokołu połączenia przed uwierzytelnieniem. Poprawka nie „wzmacnia” hasła ani szyfru, lecz egzekwuje prawidłową kolejność stanów. To ważne dla triage: rotacja haseł, wymiana kluczy i ograniczenie logowania administratora mogą być wartościowymi kontrolami ogólnymi, ale nie zastępują aktualizacji biblioteki.

Kod wykonany po wykorzystaniu luki działa w kontekście procesu usługi. Rzeczywisty zasięg szkody zależy więc od konta BEAM VM, dostępu do systemu plików, zamontowanych sekretów, uprawnień kontenera oraz tras sieciowych. CVSS opisuje techniczny potencjał podatności; ocenę ryzyka środowiskowego trzeba uzupełnić o te zależności.

Gdzie szukać podatnego komponentu

Erlang/OTP SSH może być częścią urządzenia sieciowego, systemu telekomunikacyjnego, platformy zarządzania, produktu IoT albo własnej aplikacji udostępniającej konsolę administracyjną. Czasem zależność jest wbudowana w zamknięty produkt i zespół nie kojarzy jej z osobną usługą SSH.

Inwentaryzacja powinna połączyć kilka źródeł:

nasłuchujące porty i procesy powiązane z BEAM VM;
SBOM i zależności obrazów kontenerów;
konfiguracje aplikacji wywołujące ssh:daemon lub równoważną funkcję;
dokumentację dostawców appliance i systemów wbudowanych;
skany sieci wewnętrznej, OT i segmentów zarządzających;
pakiety systemowe OTP, które mogą różnić się numeracją od upstreamu.

Model powierzchni ataku

Pytanie	Co należy potwierdzić	Znaczenie dla priorytetu
Czy działa serwer OTP SSH?	konfigurację `ssh:daemon`, uruchomiony listener i proces BEAM	sama obecność Erlanga lub klienta SSH nie oznacza ekspozycji
Kto może nawiązać połączenie?	trasy z Internetu, sieci użytkowników, klastrów, VPN, OT i segmentów zarządzania	luka nie wymaga konta, ale wymaga osiągalności sieciowej
Jaki kod jest faktycznie załadowany?	pełną wersję OTP oraz aplikacji `ssh` w działającym runtime	numer obrazu lub pakietu nie dowodzi, że proces został zrestartowany
Z jakimi prawami działa BEAM?	UID, capabilities, dostęp do hosta, wolumenów i sekretów	określa bezpośredni blast radius RCE
Dokąd może łączyć się usługa?	reguły egress, dostęp do baz, control plane i usług wewnętrznych	pokazuje możliwe ścieżki dalszego ruchu po przejęciu procesu
Kto odpowiada za aktualizację?	zespół aplikacji, dystrybucję czy producenta appliance	zapobiega ręcznym, niewspieranym podmianom biblioteki

W środowisku kontenerowym warto zestawić SBOM z faktycznie uruchomionym artefaktem oraz kontrolami opisanymi w poradniku bezpieczeństwa obrazów kontenerów. Dla usług administracyjnych dostępnych przez kilka segmentów mapa tras jest ważniejsza niż etykieta „internal”. Model Zero Trust i segmentacja sieci pomagają ograniczyć osiągalność, ale nie zmieniają statusu wersji podatnej.

Nie należy patchować każdego hosta z Erlangiem w trybie awaryjnym bez ustalenia ekspozycji. Jednak każdy aktywny serwer Erlang/OTP SSH powinien mieć najwyższy priorytet, zwłaszcza gdy jest dostępny z sieci użytkowników, Internetu lub niezaufanych workloadów.

Publiczny PoC i bezpieczny test

Publiczne repozytorium ProDefense/CVE-2025-32433 zawiera PoC demonstrujący podatność. Kod może wywołać wykonanie polecenia na zdalnym systemie, dlatego wolno go używać wyłącznie w odizolowanym laboratorium lub w ramach pisemnie autoryzowanego testu.

Bezpieczna ścieżka weryfikacji:

potwierdź, że usługa rzeczywiście używa serwera Erlang/OTP SSH, a nie OpenSSH;
ustal pełną wersję OTP i aplikacji ssh z pakietu lub runtime;
porównaj ją z poprawioną linią właściwą dla OTP 25, 26 albo 27;
przed testem dynamicznym zbuduj bliźniaczą instancję bez prawdziwych danych;
wykonaj wyłącznie test osiągalności TCP/SSH i potwierdź tożsamość komponentu bez wysyłania sekwencji uruchamiającej kod;
jeżeli dynamiczny test regresyjny jest konieczny, przeprowadź go na odtworzonej instancji laboratoryjnej z monitoringiem procesu i bez danych produkcyjnych;
po poprawce potwierdź, że zrestartowano runtime i działa nowy kod.

Nie opieraj decyzji wyłącznie na bannerze SSH. Banner może być zmieniony, ukryty lub dostarczany przez warstwę pośrednią.

Bezpieczna walidacja ekspozycji nie wymaga uruchamiania PoC. Zespół może ustalić stan na podstawie manifestu wdrożenia, wersji załadowanej aplikacji ssh, konfiguracji listenera i testu ścieżki sieciowej. Jeżeli nie da się odczytać wersji z runtime, traktuj niejednoznaczny, osiągalny serwer jako wymagający wyjaśnienia przez właściciela lub dostawcę — nie jako automatycznie bezpieczny.

Drzewo decyzji dla triage

Serwer Erlang/OTP SSH nie działa: udokumentuj dowód z konfiguracji i runtime, sprawdź czy funkcja nie jest uruchamiana warunkowo, a następnie zamknij alert jako brak aktywnej powierzchni ataku.
Serwer działa i ma poprawioną wersję: potwierdź załadowaną wersję ssh, restart procesu oraz politykę dostępu. Przejdź do kontrolowanego retestu.
Wersja jest podatna i listener jest osiągalny z niezaufanej strefy: wyłącz usługę albo zablokuj ruch, wdroż poprawkę w trybie pilnym i rozpocznij przegląd telemetrii od chwili, gdy usługa stała się osiągalna.
Wersja jest podatna, lecz dostęp jest ograniczony: utrzymaj regułę deny-by-default, zweryfikuj ją z każdej istotnej strefy i zaplanuj aktualizację. Izolacja zmniejsza prawdopodobieństwo, ale nie naprawia błędu.
Występują anomalie hosta lub ruchu: przejdź z obsługi podatności do procedury incydentowej — izolacja, zabezpieczenie dowodów, analiza procesu i rotacja sekretów powinny wyprzedzić zwykły retest.

Takie rozdzielenie pozwala uniknąć dwóch błędów: masowego alarmowania wszystkich hostów z Erlangiem oraz zbyt szybkiego uznania za bezpieczny listener, który „nie jest w Internecie”, ale pozostaje dostępny z przejętego workloadu lub sieci użytkowników.

Jak naprawić CVE-2025-32433

Aktualizacja musi pasować do używanej linii:

OTP 27: 27.3.3 lub nowsza;
OTP 26: 26.2.5.11 lub nowsza;
OTP 25: 25.3.2.20 lub nowsza.

Odpowiadające poprawione wersje aplikacji ssh to odpowiednio 5.2.10, 5.1.4.8 oraz 4.15.3.12. Szczegóły wydania potwierdza strona patcha OTP 27.3.3.

Jeżeli producent dostarcza Erlang jako element appliance, stosuj wyłącznie jego pakiet i instrukcję. Ręczna podmiana biblioteki może złamać podpisy, zależności lub wsparcie. Do czasu dostępności poprawki oficjalnym obejściem jest wyłączenie serwera SSH albo zablokowanie dostępu regułami firewall. Dopuszczenie tylko wydzielonych hostów administracyjnych znacząco zmniejsza ryzyko, lecz nie jest trwałą naprawą.

Hardening ograniczający blast radius

Po aktualizacji warto utrzymać warstwy ochronne, które ograniczają skutki kolejnego błędu w usłudze administracyjnej:

dopuść ruch tylko z jawnie zdefiniowanych hostów zarządzających i kontroluj reguły w obu kierunkach;
uruchamiaj BEAM na koncie bez praw administratora, bez zbędnych capabilities i bez dostępu do gniazda runtime kontenerów;
montuj wyłącznie potrzebne wolumeny oraz sekrety, preferując system plików tylko do odczytu tam, gdzie produkt to wspiera;
ogranicz egress do konkretnych zależności zamiast pozostawiać pełny dostęp do sieci wewnętrznej i Internetu;
rejestruj właściciela, wersję i uzasadnienie biznesowe każdego listenera administracyjnego;
testuj segmentację z perspektywy Internetu, VPN, sieci użytkowników oraz workloadów chmurowych.

Praktyczne scenariusze sprawdzenia tras opisuje pentest chmury AWS, Azure i GCP. W środowisku on-premise tę samą rolę pełni pentest sieci wewnętrznej i segmentacji, wykonywany z reprezentatywnych stref źródłowych. Hardening nie zmienia podatnej wersji w poprawioną, ale ogranicza możliwość dotarcia do usługi i dalszego ruchu z przejętego procesu.

Detekcja i analiza możliwego włamania

Monitoruj przede wszystkim ruch i zachowanie przed uwierzytelnieniem:

nietypowe sekwencje pakietów SSH kończące się bez standardowego logowania;
krótkie połączenia z wielu adresów i skanowanie nietypowych portów;
procesy potomne uruchomione przez BEAM lub konto usługi;
polecenia systemowe niepasujące do funkcji aplikacji;
nowe pliki, konta, klucze autoryzowane i zadania cykliczne;
outbound traffic z hostów, które zwykle odpowiadają tylko na żądania;
błędy protokołu i rozłączenia powtarzające się tuż przed anomalią procesu.

Brak logu „successful login” nie wyklucza ataku — właśnie uwierzytelnienie jest omijane. Przy podejrzeniu naruszenia zabezpiecz pamięć i logi, odizoluj host, obróć dostępne sekrety oraz sprawdź systemy osiągalne z konta procesu.

Nie istnieje jeden uniwersalny IOC, który potwierdza wykorzystanie CVE-2025-32433. Po wymianie kluczy treść ruchu SSH jest chroniona, dlatego same NetFlow, liczba bajtów lub krótka sesja nie pokażą, jaki komunikat protokołu został obsłużony. Telemetria sieciowa służy do wskazania źródła, czasu i częstotliwości połączeń; dowód hostowy powinien pochodzić z procesu BEAM, audytu systemowego, EDR, zmian plików i połączeń wychodzących.

W poprawionym kodzie może pojawić się zdarzenie odpowiadające komunikatowi „Unexpected message for unauthenticated user”, po którym serwer rozłącza klienta. To użyteczny sygnał próby naruszenia kolejności protokołu na poprawionym serwerze, ale nie dowód udanego RCE. W starszych buildach format logów może zależeć od produktu i konfiguracji, więc brak takiego tekstu nie dowodzi bezpieczeństwa.

Minimalny pakiet danych do triage powinien obejmować: czas i adres źródłowy połączenia, docelowy listener, wersję OTP i ssh, identyfikator procesu BEAM, procesy potomne, zdarzenia wykonania poleceń, zmiany w katalogach zapisywalnych, odczyty sekretów oraz egress w tym samym oknie czasowym. Korelacja tych warstw jest znacznie bardziej wiarygodna niż pojedyncza sygnatura sieciowa.

Jak zweryfikować naprawę i wykonać retest

Samo zamknięcie zgłoszenia po aktualizacji obrazu jest niewystarczające. Retest powinien potwierdzić kolejno:

dokładną wersję OTP i aplikacji ssh załadowaną przez działający proces;
restart wszystkich replik, węzłów klastra i instancji appliance korzystających z poprzedniego kodu;
poprawne działanie legalnego logowania oraz wymaganych funkcji administracyjnych;
rozłączenie nieprawidłowej sekwencji stanów w izolowanym teście regresyjnym, bez uruchomienia procesu potomnego, utworzenia pliku ani połączenia wychodzącego;
skuteczność reguł firewall z każdej strefy, która nie powinna mieć dostępu;
obecność oczekiwanej telemetrii i brak oznak wcześniejszego przejęcia.

Test negatywny należy wykonać w laboratorium lub na dedykowanej instancji stagingowej. Na produkcji wystarczają dowody wersji, restartu, konfiguracji i osiągalności. Dla produktu dostawcy końcowym kryterium jest jego poprawiony pakiet, nie sam numer systemowego Erlanga widoczny poza appliance. Ten sam sposób dokumentowania wersji, ekspozycji i retestu powinien wejść do stałego procesu zarządzania podatnościami.

Dlaczego CVSS 10.0 jest uzasadnione

Wektor opisuje zdalny atak o niskiej złożoności, bez poświadczeń i interakcji użytkownika, z wysokim wpływem na poufność, integralność i dostępność oraz zmianą zakresu bezpieczeństwa. Kontekst biznesowy może obniżyć priorytet wyłącznie wtedy, gdy serwer SSH nie działa lub jest całkowicie nieosiągalny z niezaufanych stref. Sam fakt, że port jest „wewnętrzny”, nie wystarcza.

Firmy utrzymujące niestandardowe usługi powinny łączyć priorytet CVSS z faktyczną osiągalnością i uprawnieniami procesu. Autoryzowany pentest infrastruktury może sprawdzić, czy usługi administracyjne są rzeczywiście odizolowane, bez wykonywania destrukcyjnego RCE.