Założyciel Binance Changpeng Zhao (CZ) ostrzegł operatorów serwerów przed krytyczną luką w uwierzytelnianiu OpenSSH, która dotyczy niektórych systemów Alpine Linux, i wezwał ich do zainstalowania poprawek bezpieczeństwa po tym, jak deweloperzy odkryli, że luka istniała od prawie 10 lat.
Podsumowanie
- Założyciel Binance CZ wezwał operatorów serwerów do natychmiastowego załatania dziesięcioletniej luki w obejściu uwierzytelniania OpenSSH.
- Luka dotyczy niektórych serwerów Linux opartych na musl, korzystających z uwierzytelniania hasłem bez włączonej ochrony PAM podczas logowania.
- Atakujący mogli uzyskać dostęp do podatnych kont przy użyciu zbyt długich haseł, nie znając ich rzeczywistych danych uwierzytelniających ani kluczy prywatnych.
- OpenSSH wydało wersję 10.6p2, a Alpine Linux opublikował poprawki bezpieczeństwa dla dotkniętych wydań systemu operacyjnego.
- Niektóre konfiguracje chmurowe Alpine mogą ujawniać uprawnienia administracyjne, choć publicznie nie zgłoszono żadnego potwierdzonego wykorzystania luki.
W poście z 6 listopada na X Zhao zwrócił uwagę na problem bezpieczeństwa po tym, jak OpenSSH i Alpine Linux wydały poprawki 5 listopada. Luka może pozwolić atakującym na dostęp do niektórych kont bez znajomości ich haseł, w tym kont normalnie skonfigurowanych do akceptowania wyłącznie kluczy SSH.
„Błąd bezpieczeństwa OpenSSH w Alpine Linux, który istnieje od 10 lat. Zastosujcie poprawki, jeśli jeszcze tego nie zrobiliście” — napisał CZ.
Ostrzeżenie dotyczy luki w oprogramowaniu wpływającej na niektóre konfiguracje serwerów. Ani post Zhao, ani komunikaty bezpieczeństwa nie ustaliły, że systemy Binance zostały naruszone za pośrednictwem tej luki.
Luka w OpenSSH umożliwia nieautoryzowany dostęp do podatnych serwerów Linux
Zgodnie z oficjalnym biuletynem bezpieczeństwa atakujący mogą obejść uwierzytelnianie na dotkniętych serwerach Alpine Linux, podając hasło o długości od 257 do 1 024 bajtów.
Luka dotyczy systemów z uruchomionym OpenSSH bez modułów uwierzytelniania podłączanych (PAM), pod warunkiem że uwierzytelnianie hasłem pozostaje włączone i istnieją określone konfiguracje kont.
Atakujący musi znać nazwę użytkownika konta, którego przechowywane pole hasła zawiera gwiazdkę, co oznacza, że nie ustawiono hasła. Na maszynie musi znajdować się inne lokalne konto z zgodnym skrótem hasła SHA-256 lub SHA-512.
W takich warunkach serwer może zaakceptować zbyt długie hasło, mimo że nie odpowiada ono prawidłowym danym uwierzytelniającym. W biuletynie stwierdzono, że wykorzystanie luki wymaga tylko jednego połączenia, bez wielokrotnego zgadywania hasła.
Jednak nie każdy serwer Alpine Linux jest podatny. Systemy korzystające z PAM do sprawdzania haseł, te z wyłączonym uwierzytelnianiem hasłem oraz kontenery bez uruchomionego serwera SSH nie są dotknięte.
Luka może wykraczać poza Alpine i dotyczyć innych dystrybucji Linux korzystających z biblioteki musl libc, w tym niektórych konfiguracji OpenWrt, Buildroot i Yocto.
OpenWrt zwykle używa Dropbear do połączeń SSH, który według badacza nie jest dotknięty tym konkretnym problemem.
Badacz bezpieczeństwa wyjaśnia dziesięcioletni błąd uwierzytelniania
Badacz bezpieczeństwa Özgün Kültekin z Wakefield zidentyfikował lukę, którą nazwał „*sshole”, i prześledził jej pochodzenie do zmian wprowadzonych w latach 2012–2016.
W swoim opisie technicznym Kültekin wyjaśnił, że funkcja skrótu hasła w musl zwraca gwiazdkę, gdy hasła przekraczają jej limit przetwarzania wynoszący 256 bajtów.
OpenSSH może pożyczyć sól hasła innego konta podczas sprawdzania kont bez prawidłowych skrótów haseł. Połączenie tych czynników tworzy sytuację, w której zwrócona gwiazdka pasuje do przechowywanego pola hasła, pozwalając nieprawidłowemu logowaniu zakończyć się sukcesem.
Badacz powiązał to zachowanie ze zmianą w OpenSSH wprowadzoną w lipcu 2016 r. w celu rozwiązania odrębnego problemu bezpieczeństwa dotyczącego wykrywania nazw użytkowników.
OpenSSH przyznał w informacjach o wydaniu, że istnieje luka, ale przypisał jej podstawową przyczynę kodowi spoza serwera SSH.
„Uważamy, że główna przyczyna tego błędu leży poza sshd” – stwierdził zespół deweloperski w swoim biuletynie bezpieczeństwa.
Deweloperzy opisali nowe wydanie jako obejście, które zapobiega przyznaniu dostępu w wyniku błędu uwierzytelniania.
Obrazy chmurowe Alpine Linux narażone na możliwy dostęp root
Niektóre obrazy chmurowe Alpine Linux budzą dodatkowe obawy, ponieważ konto ujawnione przez tę lukę może mieć uprawnienia administracyjne.
Biuletyn Alpine wskazuje obrazy tiny-cloud w wersjach od 3.18.11 do 3.24.3 jako potencjalnie zagrożone. Ich domyślne konto alpine ma dostęp bez hasła do narzędzia doas, które pozwala użytkownikom wykonywać polecenia z uprawnieniami administracyjnymi.
Chociaż te obrazy nie są podatne przy pierwszym uruchomieniu, dodanie konta z zgodnym skrótem hasła może stworzyć warunki do wykorzystania luki.
Atakujący, któremu uda się uzyskać dostęp do konta alpine, mógłby następnie wykorzystać jego istniejące uprawnienia do uzyskania dostępu root.
Biuletyn odróżnia te konfiguracje od systemów, w których bezpośrednie logowanie jako root pozostaje ograniczone. Domyślne ustawienia OpenSSH uniemożliwiają dostęp root oparty na haśle, chociaż inne przejęte konto administracyjne nadal mogłoby zapewnić podwyższone uprawnienia.
Ujawnienie to następuje w czasie, gdy CZ nadal wydaje ostrzeżenia bezpieczeństwa dla użytkowników kryptowalut. 5 listopada crypto.news poinformował o jego ostrzeżeniu dotyczącym fałszywej strony internetowej Trust Wallet zaprojektowanej, by oszukać użytkowników i nakłonić ich do połączenia swoich portfeli.
OpenSSH wydaje awaryjną poprawkę bezpieczeństwa
OpenSSH wydał wersję 10.6p2 5 listopada, aby rozwiązać problem obejścia uwierzytelniania. Alpine Linux opublikował załatane pakiety obejmujące bieżące wydania oraz starsze wersje sięgające 3.16.
Jego biuletyn instruuje administratorów, aby zaktualizowali dotknięte pakiety i ponownie uruchomili usługę SSH, ponieważ sama instalacja aktualizacji nie zastępuje działającego procesu serwera.
Operatorom, którzy nie mogą natychmiast zaktualizować, deweloperzy zalecają wyłączenie uwierzytelniania hasłem poprzez ustawienie PasswordAuthentication no i ponowne uruchomienie sshd po potwierdzeniu, że dostęp za pomocą klucza SSH działa.
Alpine wskazał wersje 3.21.10, 3.22.8, 3.23.8 i 3.24.4 jako wydania zawierające poprawione pakiety.
Administratorom zalecano przeglądanie dzienników uwierzytelniania SSH pod kątem nieoczekiwanego dostępu opartego na haśle do kont, które nie powinny akceptować haseł.
Biuletyn bezpieczeństwa stwierdził, że operatorzy, którzy nie mogą wykluczyć nieautoryzowanego dostępu, powinni traktować dotkniętą maszynę jako przejętą.
