Krytyczna luka w implementacji SSH Erlanga – CVSS 10.0 – nieuwierzytelnione wykonanie kodu oraz AI, które pisze PoC-a

Na wstępie uspokajamy, luka w żadnym wypadku nie dotyka OpenSSH (ani innych popularnych implementacji) czy protokołu SSH jako takiego. Problem wystąpił tylko w zestawie bibliotek Erlang/OTP, które implementują protokół SSH. Podatność otrzymała 10.0 punktów w skali CVSS v3, ponieważ umożliwia nieuwierzytelnionemu atakującemu na wykonanie kodu, na zdalnym systemie z uprawnieniami daemona SSH (często użytkownik root). Luka otrzymała identyfikator CVE-2025-32433.

TLDR:

• Badacze z Ruhr University Bochum odkryli poważną podatność w implementacji SSH w Erlangu. 
• Luka pozwala na pominięcie etapu uwierzytelniania i zdalne wykonanie kodu z uprawnieniami… daemona usługi SSH (czyli roota).
• Podatność otrzymała maksymalną wycenę w skali CVSS 10.0, co akurat w tym przypadku jest zrozumiałym wyborem.
• Do tego udało się zmusić AI do pomocy w stworzeniu PoC-a na wykorzystanie tej podatności.

Czasu na reakcję nie ma, więc jeśli wiecie, że korzystanie z ekosystemu Erlanga, to patchujcie teraz, a do lektury wrócicie później. Odkrywcy podatności nie opublikowali wprawdzie kodu źródłowego proof-of-concept, pokazującego jak wykorzystać podatność, jednak odtworzenie luki i znalezienie wektora ataku było stosunkowo proste. Może nawet zbyt proste, bo wykorzystano do tego celu AI… 

Problem wynika ze sposobu, w jaki zaimplementowano obsługę wiadomości SSH. A konsekwencją ataku może być pełne przejęcie hosta. 

Erlang to funkcyjny język stworzony w 1986 roku w Ericssonie na potrzeby projektowania aplikacji współbieżnych. Jest znany przede wszystkim z odporności na błędy, co jest cechą bardzo pożądaną w środowiskach telekomunikacyjnych. Cały ekosystem jest otwartoźródłowy i udostępniany z bibliotekami pozwalającymi na obsługę popularnych protokołów sieciowych, rozproszonych baz danych i nie tylko. Zbiór przydatnych narzędzi i bibliotek nazywa się Open Telecom Platform (w skrócie OTP). 

Chwilę po publikacji zaczęły się pojawiać głosy, takie jak ten z Horizon3 Attack Team, które twierdziły, że odtworzenie ataku jest trywialne:

https://x.com/Horizon3Attack/status/1912945580902334793

Wpisy takie jak te zostały zauważone przez innych badaczy, którzy postanowili wziąć na warsztat podatność CVE-2025-32433 i wykorzystując dostępne modele LLM, stworzyć działający PoC (swoją drogą, artykuł prezentujący wyniki również wygląda na wspomagany przez AI). 

Poszukiwanie znanych podatności jest łatwiejsze, gdy znany jest kod źródłowy wersji podatnej oraz poprawionej. I tak było tym razem. 

Badacze wygenerowali skrypt, który diffował dwie pobrane wersje (podatną i załataną). Oczywiście mogli skorzystać z gotowych rozwiązań do porównywania commitów, ale wtedy trudniej byłoby dodać AI do tego wątku…

Na etapie porównywania kodu, natrafiono na poniższy listing:

....omitted for brevity...
+early_rce(Config) ->
+    ...
+    TypeReq = "exec",
+    DataReq = <<?STRING(<<"lists:seq(1,10).">>)>>,
+    ...
+    {send, SshMsgChannelRequest},
+    {match, disconnect(), receive_msg}
....omitted for brevity...

Listing 1. Wprowadzone zmiany latające podatność (źródło)

Okazuje się, że wykorzystując modele od OpenAI oraz Anthropic (przez zwykły prompt engineering oraz jako agenta obsługującego inteligentne IDE Coursor) udało się uzyskać PoC (ang. Proof of Concept) służący do eksploitacji tej podatności. Model GPT-4, analizując dokładnie przyczynę powstania podatności, zadał jedno, bliskie sercu każdego hackera pytanie (cytując za autorami posta) – „Want a full PoC client? A Metasploit-style demo? A patched SSH server to trace further?„

Po kilku wprowadzonych zmianach i niewielkiej sesji debuggowania, udało się otrzymać działający PoC – nic zresztą dziwnego, błąd pozwalał na przesłanie po prostu wykonywanej komendy na etapie negocjacji połączenia. 

W sieci znajduje się też gotowy szablon nuclei, gdybyście chcieli wykorzystać tę podatność podczas udziału w różnych programach bug bounty. 

Czy taki rozwój sytuacji jest zaskakujący? Absolutnie nie, bazując na fakcie, że implementacja SSH w Erlangu zawierała całkiem prosty błąd, nie dziwi nas, że badacz nie znający konkretnego środowiska, był w stanie otrzymać działający eksploit przy wykorzystaniu LLM-ów. Nie zaskakuje nas też fakt, że pierwsze iteracje nie działały. Nowe możliwości, jakie dają modele językowe, powodują obniżenie progu wejścia w research związany z bezpieczeństwem. Oczywiście takie narzędzia są też dostępne dla tych czarnych kapeluszy, więc nie należy opierać swojego bezpieczeństwa na założeniu niskich zdolności atakujących. Naszym zdaniem dalszy rozwój i włączenie AI w proces wykrywania i wykorzystywania podatności może pozytywnie wpłynąć na branżę oraz poprawić ogólny obraz bezpieczeństwa. 

Mamy jednak nadzieję, że integracja inteligencji (sztucznej) będzie wymagała umieszczenia tej naturalnej w całym procesie. Bo tylko wtedy (tzn. kiedy badacze są wspierani, a nie zamieniani przez LLM-y), takie działania mają szansę powodzenia. Na ten moment nie istnieje metoda na zastąpienie człowieka w procesie wyszukiwania podatności. A patrząc na koszty utrzymywania niezbyt zdolnych modeli LLM, ograniczonych między innymi wielkością kontekstu – raczej prędko to nie nastąpi. 

Pozostaje liczyć, że zadania na CTF-ach rozwiązujecie sami, aby się czegoś nauczyć ;) 

~Black Hat Logan