Odkryto krytyczne luki w zabezpieczeniach OpenSSH (CVE-2024-6387 oraz CVE-2024-6409). RegreSSHion umożliwia nieuwierzytelnionemu atakującemu zdalne wykonanie kodu (RCE). Poniżej przedstawiamy skutki wykorzystania luki i możliwości zapewnienia ochrony, jeżeli korzystasz z tego niezwykle popularnego protokołu open source.
Krótko o OpenSSH
OpenSSH to jedno z najlepszych i najpopularniejszych narzędzi łączności umożliwiających zdalne logowanie dzięki protokołu SSH. Szyfruje cały ruch, dzięki czemu eliminuje podsłuchiwanie, przejmowanie połączeń i inne ataki. Ponadto zapewnia duży zestaw możliwości bezpiecznego tunelowania, kilka metod uwierzytelniania i zaawansowane opcje konfiguracji. Jest używane jako pierwsza i jedyna linia obrony milionów serwerów w całym Internecie, dlatego jego bezpieczeństwo jest kluczowe. Równocześnie jest to jednak powód, dla którego OpenSSH stał się celem o dużej wartości dla potencjalnych atakujących.
Podatności w OpenSSH
Bezpieczeństwo OpenSSH wysunęło się na pierwszy plan dwa miesiące temu wraz z odkryciem budzącej strach luki dnia zerowego w xz-utils, atakującej plik binarny OpenSSH w celu uzyskania dostępu backdoorem do systemów operacyjnych opartych na Linuksie.
Problem z OpenSSH powrócił z luką typu zero-day, która okazuje się ogromną luką umożliwiającą zdalne wykonanie kodu na serwerach OpenSSH. Firma Qualys, która znalazła wady dzięki swoim badaniom, nadała luce nazwę „RegreSSHion”.
Analizując dane z kilku źródeł, takich jak Shodan czy Censys, można zaobserwować, iż na dzień publikacji tego artykułu istnieje prawie 7 milionów odsłoniętych instancji OpenSSH, które są potencjalnie podatne na RegresSSHion. Zapytanie w Shodan:
port:22 product:"OpenSSH" version:8.5,8.5p1,8.6,8.6p1,8.7,8.7p1,8.8,8.8p1,8.9,8.9p1,9.0,9.0p1,9.1,9.1p1,9.2,9.2p1,9.3,9.3p1,9.4,9.4p1,9.5,9.5p1,9.6,9.6p1,9.7,9.7p1
Ciekawostką jest, iż w chwili publikacji podatności przez firmę Qualys było ich aż 14 milionów!
CVE-2024-6387: wpływ na główny proces serwera OpenSSH
Luka potencjalnie umożliwia nieuwierzytelnione zdalne wykonanie kodu z uprawnieniami roota.
Wpływa na domyślną instalację OpenSSH i polega na skorzystaniu z sytuacji wyścigu w celu uzyskania zdalnego wykonania kodu. Mimo iż udana eksploitacja regresSSHion ma poważny skutek (eskalacja uprawnień do root), pozom krytyczności podatności został oceniony jako wysoki z powodu dość skomplikowanego ataku. W celu osiągnięcia RCE konieczne jest wykonanie dużej liczby prób uwierzytelniania w długim czasie.
W kontekście tej luki, jeżeli klientowi nie uda się uwierzytelnić w określonym czasie (LoginGraceTime), który domyślnie wynosi 120 sekund, uruchamiana jest procedura obsługi sygnału serwera, aby obsłużyć przekroczenie limitu czasu.
Luka CVE-2024-6409
Przy okazji omawiania luki CVE-2024-6387 warto wspomnieć o innej – CVE-2024-6409, wpływającej na proces podrzędny separacji uprawnień z ograniczonymi uprawnieniami, co dotyczy OpenSSH w wersjach 8.7 i 8.8.
- Sytuacja wyścigu w funkcji Grace_alarm_handler() stwarza możliwość zdalnego wykonania kodu w procesie potomnym privsep.
- Nowa luka ma mniejsze bezpośrednie skutki, ale przez cały czas stwarza poważne ryzyko bezpieczeństwa.
Które systemy są podatne?
Luka dotyczy wielu wersji OpenSSH, w tym większości dystrybucji Linuksa, ponieważ są one domyślnie dostarczane z OpenSSH.
Jako iż główną przyczyną luki jest regresja w kodzie OpenSSH, oryginalne CVE wpływa na bardzo stare wersje serwera OpenSSH, nie dotykając nowszych wersji (przed regresją).
W dniu publikacji tego artykułu sytuacja prezentuje się następująco:
- Stara wersja luki (CVE-2006-5051) dotyczy wersji OpenSSH wcześniejszych niż OpenSSH 4.4/4.4p1 (2006-09-27) (chyba iż zostały one załatane dla CVE-2006-5051 i CVE-2008-4109).
- Regresja luki została wprowadzona w wersji OpenSSH 8.5/8.5p1 (2021-03-03).
- Opiekunowie OpenSSH naprawili lukę w wersji OpenSSH 9.8/9.8p1(2024-07-01).
Łatajcie systemy!
Dostępna poprawka polega na usunięciu problematycznego kodu z procedury obsługi sygnału, zapewniając, iż w tym kontekście wykonywane są tylko bezpieczne operacje.
Administratorzy powinni priorytetowo potraktować zastosowanie poprawek lub obejścia w celu ograniczenia luki wysokiego ryzyka na serwerach OpenSSH działających w systemach Linux opartych na glibc.
Dla systemów, w przypadku których nie możesz zastosować poprawki, jest dostępne obejście problemu poprzez:
- ustawienie parametru „LoginGraceTime” na 0 w pliku konfiguracyjnym „/etc/ssh/sshd_config”
- oraz wykonanie restartu usługi dzięki polecenia: „systemctl restart sshd”.
Zastosowanie poprawki stanowi skuteczne zabezpieczenie w przypadku obu opisanych wyżej luk.
