SSHole w OpenSSH: aktywne ataki na systemy Linux z musl libc i obejście logowania hasłem

Wprowadzenie do problemu / definicja

SSHole to nowo ujawniona podatność w serwerze OpenSSH, oznaczona jako CVE-2026-123158, która w określonych konfiguracjach może prowadzić do obejścia uwierzytelniania hasłem. Problem dotyczy przede wszystkim systemów Linux korzystających z biblioteki musl libc, uruchamiających sshd bez aktywnego PAM oraz z włączonym logowaniem hasłem.

To groźny scenariusz, ponieważ napastnik może uzyskać zdalny dostęp do hosta bez znajomości prawidłowego hasła. Szczególnie narażone są środowiska oparte na Alpine Linux, lekkie obrazy kontenerowe oraz systemy wykorzystywane w chmurze i automatyzacji infrastruktury.

W skrócie

Podatność została publicznie ujawniona 5 listopada 2026 roku, a poprawka trafiła do OpenSSH 10.6p2 tego samego dnia. W bardzo krótkim czasie od publikacji pojawił się kod PoC, a już 6 i 7 listopada zaczęto obserwować skuteczne próby wykorzystania luki w realnych atakach.

• Zagrożone są systemy z musl libc i bez PAM.
• Warunkiem podatności jest aktywne PasswordAuthentication.
• Szczególnie ryzykowne są konta z polem hasła ustawionym na znak *.
• Ataki obejmują rekonesans, kradzież poświadczeń i utrwalanie dostępu.

Kontekst / historia

OpenSSH od lat stanowi jeden z najważniejszych komponentów dostępowych w środowiskach Unix i Linux. Z tego powodu każda luka umożliwiająca obejście procesu logowania ma wysoki priorytet operacyjny i wymaga szybkiej reakcji po stronie administratorów.

W przypadku SSHole istotne jest to, że problem nie występuje w całym ekosystemie OpenSSH w jednakowy sposób. Do skutecznego nadużycia wymagane jest spełnienie kilku warunków konfiguracyjnych jednocześnie. Oznacza to, że zagrożenie nie jest uniwersalne, ale w określonych wdrożeniach może być wyjątkowo praktyczne dla atakującego.

Sprawa wpisuje się również w szerszy trend bezpieczeństwa: czas między ujawnieniem luki a jej wykorzystaniem w rzeczywistych kampaniach stale się skraca. W praktyce okno reakcji dla zespołów bezpieczeństwa liczone jest już nie w tygodniach, lecz w godzinach lub kilku dniach.

Analiza techniczna

Źródłem problemu jest interakcja między sshd a sposobem działania funkcji crypt() w musl libc. W podatnych konfiguracjach OpenSSH próbuje przetworzyć i porównać wynik haszowania hasła nawet w sytuacjach, które dotyczą kont bez używalnego hasha logowania.

W musl libc błąd podczas haszowania bardzo długiego hasła może skutkować zwróceniem ciągu *. Ten sam znak bywa używany w polu hasła konta jako znacznik braku prawidłowego hasła do logowania. Jeśli system błędnie uzna taki wynik za zgodny z wartością przechowywaną dla konta, dochodzi do obejścia uwierzytelniania.

Skuteczny atak wymaga zwykle spełnienia następujących warunków:

• system działa na musl libc,
• sshd nie korzysta z PAM lub działa w równoważnym podatnym przepływie,
• PasswordAuthentication jest ustawione na yes,
• istnieje konto z polem hasła ustawionym na *,
• w systemie obecne jest co najmniej jedno konto z hashem zgodnym z wykorzystywaną ścieżką walidacji.

Z publicznych analiz wynika, że atak często wykorzystuje bardzo długie hasło, zwykle o długości od 257 do 1024 bajtów. Po uzyskaniu dostępu napastnicy prowadzili rekonesans hosta i kontenerów, sprawdzali usługi metadanych chmurowych, odczytywali materiał uwierzytelniający oraz modyfikowali pliki authorized_keys.

Zaobserwowano również działania typowe dla utrwalania dostępu, w tym próby instalacji implantów umożliwiających wykonywanie poleceń, przesyłanie plików i aktualizację własnego kodu. Warto podkreślić, że sama instalacja aktualizacji może nie wystarczyć, jeśli po wdrożeniu poprawki nie zostanie zrestartowany działający proces sshd.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem SSHole jest zdalne uzyskanie dostępu do systemu bez znajomości poprawnego hasła. Jeśli przejęte konto ma szerokie uprawnienia lub umożliwia lokalną eskalację uprawnień, incydent może zakończyć się pełnym przejęciem hosta.

Podwyższone ryzyko dotyczy przede wszystkim środowisk, w których SSH jest publicznie dostępne lub pełni istotną rolę operacyjną:

• serwery administracyjne wystawione do Internetu,
• hosty oparte na Alpine Linux,
• kontenery uruchamiające sshd,
• środowiska DevOps i CI/CD z kluczami, tokenami i sekretami,
• systemy z dostępem do metadanych chmurowych oraz dalszych zasobów infrastruktury.

Praktyczne konsekwencje mogą obejmować kradzież poświadczeń, ruch boczny, trwałe utrwalenie dostępu przez klucze SSH, wykorzystanie hosta do dalszych ataków, a nawet uruchamianie szkodliwych narzędzi takich jak koparki kryptowalut czy komponenty botnetów.

Dodatkowym problemem obronnym jest fakt, że naruszenie może wyglądać jak legalne logowanie hasłem. Jeśli organizacja nie monitoruje anomalii związanych z kontami, które formalnie nie powinny akceptować takiej formy logowania, incydent może pozostać niewykryty przez dłuższy czas.

Rekomendacje

Priorytetem powinno być szybkie ustalenie, czy środowisko spełnia warunki podatności. W praktyce oznacza to identyfikację hostów z OpenSSH działającym na musl libc, zwłaszcza na Alpine Linux, oraz weryfikację konfiguracji logowania hasłem.

• Zaktualizować OpenSSH do wersji naprawionej lub wdrożyć poprawki dostarczone przez dystrybucję.
• Bezwzględnie zrestartować usługę sshd po aktualizacji.
• Jeśli szybkie wdrożenie poprawki nie jest możliwe, wyłączyć logowanie hasłem przez ustawienie PasswordAuthentication no.
• Zweryfikować, czy dostęp administracyjny odbywa się wyłącznie z użyciem kluczy SSH.
• Przeprowadzić przegląd kont, których pole hasła ustawiono na *.
• Ograniczyć ekspozycję SSH do zaufanych adresów, VPN lub warstwy bastionowej.
• Przeanalizować logi pod kątem nieoczekiwanych wpisów akceptacji logowania hasłem dla kont technicznych.
• Sprawdzić pliki authorized_keys, nowe usługi startowe, nietypowe procesy oraz ślady implantów.
• Skontrolować dostęp do metadanych chmurowych i możliwy wyciek poświadczeń.
• W przypadku podejrzanego logowania traktować host jako potencjalnie skompromitowany i uruchomić pełną procedurę reagowania na incydent.

Dobrą praktyką będzie także wdrożenie detekcji behawioralnej dla bardzo długich prób hasła kierowanych do sshd, modyfikacji authorized_keys, prób odczytu /etc/shadow oraz nagłego wzrostu aktywności rekonesansowej po zalogowaniu.

Podsumowanie

SSHole pokazuje, że nawet luka zależna od konkretnej kombinacji warunków konfiguracyjnych może stać się poważnym zagrożeniem operacyjnym. W podatnych środowiskach opartych na musl libc i Alpine Linux błąd może prowadzić do zdalnego obejścia logowania hasłem, a następnie do pełnego przejęcia systemu.

Z uwagi na potwierdzone wykorzystanie w aktywnych atakach organizacje powinny potraktować ten problem jako pilny. Sama aktualizacja nie wystarczy, jeśli nie towarzyszy jej restart sshd, przegląd śladów kompromitacji oraz ograniczenie powierzchni ataku dla usług SSH.

Źródła

• https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/
• https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
• https://www.alpinelinux.org/posts/alpine-3.21.10-3.22.8-3.23.8-3.24.4-released/
• https://github.com/advisories/GHSA-4fcc-vm97-gx3x
• https://www.openssh.org/releasenotes.html#10.6p2