Cyberbezpieczeństwo
RCE w OpenSSH. „14 milionów potencjalnie podatnych urządzeń”
Autor. Pixabay.com
Wykryto krytyczną podatność w OpenSSH, która umożliwia zdalne wykonanie kodu. Luka bezpieczeństwa została nazwana „regreSSHion” i można ją wykorzystać przy domyślnej konfiguracji sshd. Należy niezwłocznie pobrać aktualizację oprogramowania.
Podatność opisał Qualys w poście na blogu. W oparciu o Censys i Shodana stwierdzono, że istnieje „14 milionów potencjalnie podatnych serwerów OpenSSH widocznych z poziomu Internetu”.
Podatności nadano ID CVE-2024-6387. Podkreślono również, że podatność po raz pierwszy została wykryta i załatana 18 lat temu, lecz stosowne poprawki zostały później wycofane. Podatne są wersje oprogramowania od 8.5p1 do 9.7p1 i starsze niż 4.4p1.
Skutki wykorzystania podatności
RegreSSHion jest krytyczną podatnością, ponieważ umożliwia zdalne wykonanie kodu z uprawieniami administratora. Oznacza to, że podatne są sshd wystawione do internetu, używające wersji oprogramowania opublikowanej między 3 marca 2021 roku a 30 czerwca 2024 roku. W wersji 9.8p1 załatano podatność, ponieważ „przypadkowo usunięto krytyczny komponent w jednej z funkcji”.
Wykorzystanie podatności może ostatecznie skutkować przejęciem pełnej kontroli nad danym systemem czy kradzieżą danych wrażliwych. Qualys zaznacza również, że uzyskanie uprawnień roota pozwala na ominięcie wielu zabezpieczeń, m.in. IDS czy firewalli. Skompromitowane urządzenie może również służyć do przeprowadzania kolejnych ataków w sieci.
Czytaj też
Opis podatności
Lukę bezpieczeństwa opisano na openwall. Podatność udało się wykorzystać na 32-bitowych dystrybucjach Linuksa wykorzystujących glibc i korzystających z ASLR (Address Space Layout Randomization). W tym celu wymagane było 6-8 godzin ciągłego wysyłania zapytań do serwera.
Na systemach 64-bitowych nie potwierdzono w praktyce wykorzystania podatności, lecz „wierzy się, że to jest możliwe”. Stwierdzono również, że luka nie dotyczy OpenBSD.
Ochrona przed zagrożeniami
Tak jak w przypadku wielu innych krytycznych podatności – najlepszym rozwiązaniem jest zainstalowanie poprawki bezpieczeństwa opublikowanej przez producenta.
Jeżeli aktualizacja jest niemożliwa, należy ustawić wartość parametru LoginGraceTime na 0 w pliku konfiguracyjnym. O próbach wykorzystania podatności może świadczyć wiele logów o treści „Timeout before authentication”.
Czytaj też
Serwis CyberDefence24.pl otrzymał tytuł #DigitalEUAmbassador (Ambasadora polityki cyfrowej UE). Jeśli są sprawy, które Was nurtują; pytania, na które nie znacie odpowiedzi; tematy, o których trzeba napisać – zapraszamy do kontaktu. Piszcie do nas na: [email protected].
