Od końca października praktycznie każdy dzień przynosi informacje o nowym ataku czy podatności. Część odkrytych przez ten okres luk wymaga złożonych przygotowań po stronie atakującego, a inne działają tylko w specyficznych konfiguracjach. Nie trzeba więc traktować ich jako krytycznych, pomimo ich wysokich pozycji w rankingu CVSS. Realna ocena zagrożenia to przydatna umiejętność.
Jednak dziś dowiedzieliśmy się o podatności, którą naprawdę można określić słowem „krytyczna”. sshole działa niemal z domyślną konfiguracją niektórych systemów. Nie jest to jednak powód do paniki, o ile nie pracujemy w branży IoT czy też nie wystawiamy usługi SSH publicznie w systemach z musl, takich jak Alpine. Udane użycie tej podatności może pozwolić na dostęp jako root czy inny użytkownik bez znajomości jego hasła.
Po stronie serwera muszą był spełnione proste warunki czytelnie przedstawione na wspomnianej stronie. Oprócz hosta z musl „podatne” konto musi mieć przy swoim wpisie w pliku /etc/shadow znak * – w Alpine jest to domyślne dla użytkownika root i oznacza konto bez ustawionego hasła. Serwer SSH nie może być skompilowany z obsługą PAM (openssh-server dla musl jej nie zawiera) bądź też w konfiguracji /etc/ssh/sshd_config opcja UsePAM musi mieć wartość No – to również domyślne ustawienie. Oprócz tego powinno istnieć inne konto z hasłem. Oczywiście logowanie jako root jest zabezpieczone dzięki opcji PermitRootLogin prohibit-password, ale to też nierzadko zmienia się w urządzeniach, dla których podobne systemy są podstawowym wyborem.
Najbardziej zagrożony jest segment IoT oraz urządzeń przemysłowych. choćby jeżeli urządzenia z Alpine nie są osiągalne z zewnątrz, to ich użytkownicy mogą spróbować przeprowadzić ten atak w swojej sieci domowej. Nie są potrzebne zaawansowane umiejętności, a jedynie zainstalowany klient SSH.
Przy pierwszej próbie logowania podajemy dowolne hasło, a następnie kolejne hasło o długości co najmniej 256 znaków. Można też dwukrotnie podać to samo hasło o wspomnianej długości. jeżeli spełnione są założenia podatności, atakujący otrzyma dostęp jako użytkownik, na którego próbował się zalogować.
W zależności od rodzaju konta, na które uda mu się zalogować, kolejne kroki ataku będą odmienne. W przypadku konta root można jednak mówić o rzeczywistej możliwości całkowitego przejęcia systemu.
Od globalnej aktualizacji serwerów SSH dzieli nas fakt, iż podatność występuje wyłącznie w systemach opartych na musl. jeżeli wystawiamy tę usługę publicznie, to pilnie należy wdrożyć aktualizacje, a najlepiej ograniczyć dostęp do tak wrażliwego serwisu.
OpenSSH wydało aktualizację, w której opisie czytamy, iż główna przyczyna błędu znajduje się poza sshd, ale z racji możliwości jego użycia poprzez tę usługę udostępniają poprawkę. Alpine ponadto dostarczyło również backporty dla starszych wersji openssh-server. Wciąż można odtworzyć tę podatność – najprościej z wykorzystaniem kontenera Docker z dowolną wersją Alpine. Trzeba zainstalować też wersję openssh-server poniżej 10.6p2 i dodatkowo z poprzednią rewizją, co wynika z dostępności backportów.
Użycie podatności OpenSSH w systemie Alpine
Alpine jest niewielką dystrybucją Linux, więc znakomicie sprawdza się w zastosowaniach IoT, gdzie liczy się każda dostępna wielkość zasobów. Znajdziemy ją też w domowych urządzeniach sieciowych. Niejednokrotnie spotkamy kontenery wykorzystujące obraz bazowy alpine obsługujące ogromne środowiska produkcyjne o wysokiej wydajności. Minimalizm tego systemu wpływa na jego wysokie bezpieczeństwo, bo powierzchnia ewentualnego ataku jest bardzo ograniczona. Nigdy nie oznacza to jednak, iż system pozostanie odporny na wszystkie formy obchodzenia zabezpieczeń.
Za każdym razem należy przypominać, iż słusznym podejściem pozostaje zasada minimalnego dostępu. Typowy użytkownik nie potrzebuje dostępu SSH, więc dlaczego mamy pozostawiać zainstalowany pakiet openssh-server w urządzeniach przeznaczonych do zakupu? Znacznie łatwiej też utrzymywać rozwiązania nieposiadające zbędnego systemu przede wszystkim w kontekście aktualizacji.
Opisywana podatność różni się od php2shell, Node2Shell czy możliwości RCE podczas aktualizacji WordPress (nad którą pochylimy się w kolejnym artykule) i wielu innych faktem, iż można ją szeroko wykorzystać w praktyce. Nie potrzeba zaawansowanych skryptów, użycia modeli AI do analizy odpowiedzi serwera czy dużej ilości czasu. Przymiotnik „krytyczna” powinien być zarezerwowany właśnie dla przykładów takich podatności. Ostatnio mamy do czynienia z nadużywaniem tego słowa przy okazji niemal każdej luki, pomimo skomplikowanego procesu ich wykorzystania.
