Transcription

Cześć! Na przełomie maja i czerwca bieżącego roku badacze z Qualisa odkryli coś naprawdę interesującego w serwerze OpenSSH. Choć zdaję sobie sprawę, że mogę być dość osamotniony w swoim entuzjazmie, ale dajcie mi chwilę, spróbuję Was nim zarazić. Okazało się, że wszystkie sprzęty będące pod kontrolą Linuxów, a więc miliony urządzeń na całym świecie, prawie cały internet można w dość prosty sposób przejąć. Zdalnie, bez łamania jakichkolwiek haseł. Brzmi jak coś z najgorszego koszmaru administratora? No bo dokładnie tak jest. Opowiem Wam dziś historię pewnej dziury. Zapraszam. Zacznijmy od krótkiego wprowadzenia w paru słowach dla całkowicie zielonych. SSH to skrót od Secure Shell. To taki protokół pozwalający bezpiecznie komunikować się z jakąś zdalną maszyną, np. serwerem, z wykorzystaniem szyfrowania end-to-end. Umożliwia to choćby administrowanie jakąś infrastrukturą z drugiego końca świata, bez większych obaw o bezpieczeństwo danych, które przesyłamy. Aby jednak prowadzić taką komunikację, trzeba móc jakoś zainicjować połączenie. Wiadomo, najtrudniej jest zagadać. Na maszynie, do której się łączymy, potrzebny jest więc jakiś program nasłuchujący i oczekujący, aż ktoś się do niego zgłosi. Tu na scenę wchodzi nasz dzisiejszy główny bohater, czyli najpopularniejsza chyba implementacja serwera SSH, otwarto-źródłowe OpenSSH. Zainstalowane domyślnie w praktycznie każdym Linuxie i nie tylko. Jeżeli chcemy się gdzieś zdalnie łączyć, to instalujemy na takim urządzeniu serwer OpenSSH, konfigurujemy go, nadajemy odpowiednie uprawnienia, et voila. Od tej pory, znając po prostu jego adres, możemy bezpiecznie się do niego połączyć z dowolnego miejsca na ziemi. Zgłaszamy się więc i pukamy do drzwi, grzecznie się przedstawiając. Jeżeli serwer sprawdzi, że jesteśmy na liście zaproszonych gości i znamy sekretne hasło, to taki wirtualny bramkarz osiłek wpuszcza nas do środka. To oczywiście spore uproszczenie, ale wybaczcie je w tym miejscu, to powinno nam wystarczyć do zrozumienia dalszej części historii. Najważniejsze jest to, że to właśnie ta weryfikacja, kto puka, jest krytycznym momentem całego procesu. No i byłoby bardzo, bardzo przykro, gdyby komuś udało się oszukać tego bramkarza, prawda? Cóż, właśnie to się ostatnio stało. Badaczom Squalisa udało się ominąć uwierzytelnianie serwera OpenSSH w taki sposób, że każdy, kto tylko pukał do drzwi, automatycznie był wpuszczany do środka. A to narażało na atak miliony urządzeń będących pod kontrolą Linuxów. Tragedia. W takim jednym zdaniu może i brzmi to prosto, ale wcale takie nie było. A więc po kolei, kiedy pukamy do drzwi serwera OpenSSH, przedstawiamy się swoim loginem, a serwer w odpowiedzi prosi nas o podanie hasła, aby nie wpuszczać byle kogo, zamiast jednak je wpisywać, możemy po prostu zamilknąć. Jeżeli przez jakieś dwie minuty nie odzyskamy języka w gębie, a w sumie to umiejętności pisania na klawiaturze, to serwer będzie chciał po prostu zamknąć połączenie, skoro nie może się doprosić odpowiedzi. Aby to zrobić, musi jednak wywołać kilka funkcji w tle, które działają asynchronicznie, co jest w tym przypadku bardzo istotne. Asynchronicznie, a więc nie po kolei, po sobie, ale równolegle do siebie. Takie rozwiązania, o ile przeważnie są znacznie wydajniejsze, rodzą pewne problemy. Trzeba dobrze przewidywać, co kiedy się wydarzy lub w ogóle co może się wydarzyć. Kiedy nagle stanie się coś, co będzie dla aplikacji zaskoczeniem, albo odwrotnie, nie stanie się coś, na co właśnie czeka, może ona zachować się w totalnie nieoczekiwany sposób. Ten rodzaj błędów nazywamy błędami kategorii Race Condition, a po polsku zjawiskiem hazardu lub zjawiskiem wyścigu. No bo wyobraźcie sobie, że robicie poranną kawkę. Gotujecie wodę, wożycie i mielicie ziarna, przygotowujecie te wszystkie filtry i tak dalej, a w końcu zaparzacie. Te wszystkie zadania mają swoją ustaloną kolejność. O ile woda może się gotować w trakcie, kiedy mielicie kawę, bo to zadania asynchroniczne, o tyle nalanie kawy bez podstawienia pod zbany kubka zakończy się sprzątaniem całej kuchni. Systemy operacyjne, czy szerzej oprogramowanie, też oczekuje pewnej kolejności wykonywania zadań. Jeżeli ją zaburzymy, mogą wydarzyć się niespodziewane rzeczy, w tym różne błędy. I to właśnie błąd tej kategorii odnaleziono w serwerze OpenSSH i nadano mu pieszczotliwą nazwę Regression oraz numer porządkowy CVE-2024-6387. Nie wszystkie funkcje, które były wywoływane przy próbie zamknięcia połączenia przez serwer w sytuacji, gdy ktoś się nie przedstawił, wspierały asynchroniczne sygnały. Wystarczyło takiemu serwerowi przesłać pewien odpowiednio spreparowany pakiet danych, zawierający złośliwy kod, schowany w polu przewidzianym na login użytkownika, aby przy próbie zamknięcia połączenia zostały one wykonane przez wspomniane funkcje. Niestety, pech chciał, że działały one z uprawnieniami administratora systemu. A więc każdy wykonany przez nie kod również działał z tak wysokimi uprawnieniami. W dodatku było to domyślne zachowanie, nie wymagające żadnych zmian w konfiguracji, co zaś oznaczało, że podatny na nie był każdy, kto korzystał z serwera OpenSSH. No, prawie każdy. W dodatku atak taki przeprowadzić można zdalnie i nie jest wymagana żadna interakcja ze strony atakowanego użytkownika. Dramat. Aż dziwne, że w skali CVSS podatność otrzymała tylko 8.1 punkta na 10. Jeżeli wszystko to zdaje się brzmieć trywialnie, to zapewniam, że takie nie jest. Badacze po drodze musieli rozwiązać naprawdę liczne problemy. Jak trafić w tę krótką chwilę, kiedy serwer OpenSSH wysyła do systemu operacyjnego zadanie zerwania połączenia? Jak w ogóle przesłać jakieś polecenie? No i najważniejsze, czym ten złośliwy kod powinien w ogóle być, aby udało się coś nabroić? Jak to zwykle bywa, kiedy uczymy się czegoś nowego, dobrze jest zacząć niespiesznie. Badacze postanowili kierować się dokładnie tą zasadą. Zainstalowali jakąś starą wersję Debiana na komputerze z epoki Kamienia Chrupanego, aby wszystko na nim po prostu działo się wolniej, dzięki czemu mieli więcej czasu na analizy oraz trafienie w dobry moment. Okej, nikt nie wyciągnął z piwnicy komputera dziadka, skorzystano zwyczajnie z maszyny wirtualnej. PeCetowi archeolodzy wybaczcie rozczarowanie, choć to na pewno nie ostatnie. Po wielu próbach i optymalizacjach okazało się, że średnio udaje się spełnić założenia pozwalające na przeprowadzenie takiego ataku w jednej na dziesięć tysięcy prób nawiązania połączenia. Biorąc pod uwagę fakt, że trzeba za każdym razem poczekać na moment rozłączenia przez serwer, oznacza to jakieś kilka dni ciągłych prób. Jeżeli serwer dopuszcza większą ilość połączeń naraz, np. setkę, czas ten spada do kilku godzin, co czyni ten atak już w miarę praktyczny. Jednak to nie tak, że błąd ten występuje tylko na starym komputerze, wolniejszym od dzisiejszych ekspresów do kawy. Badacze oczywiście podjęli próby przeprowadzenia takiego ataku na nowoczesnym sprzęcie. W międzyczasie zauważyli jednak, że do utrzymujących OpenSSH ktoś zgłosił inny błąd. Błąd, z którym często mieli do czynienia w swoich eksperymentach i który solidnie przeszkadzał im w wykorzystaniu luki. Uznali, że jest spora szansa, że ktoś inny również odkrył coś podobnego i szuka możliwości szerszego wykorzystania tej podatności. Porzucili więc na chwilę dalsze badania i niezwłocznie skontaktowali się z deweloperami OpenSSH, aby ostrzec ich, do czego może to prowadzić. Panie i panowie z Qualysa, czapki z głów, dzięki. Jest spora szansa, że po raz kolejny uratowaliście świat przed zagładą. To dzięki takim ludziom jak wy możliwy jest progres. Chwila, chwila. Tylko czy to aby na pewno progres, czy może jednak regres? Tylko o co chodzi z tą całą nazwą? Regression? Czy to jakiś przekaz podprogowy? No trochę tak, bo luka ta w sumie nie jest żadną nowością. Dawno, dawno temu, czyli tak jakoś w 2006 roku, była sobie inna podatność o niezbyt seksownej nazwie CVE-2006-5051. Właściwie nic specjalnego, bo niby pozwalała na dokładnie to samo, co nasza dzisiejsza gwiazda roka, ale jedynie w teorii. Tylko ją naprawiono w serwerze OpenSSH w wersji 4.4 osiemnaście lat temu. Skazana była na zapomnienie, no maksymalnie na wzmiankę w archiwach, gdyby nie fakt, że podczas jednej z aktualizacji serwera OpenSSH do wersji 8.5 gdzieś pod koniec 2020 roku ktoś usunął jedną z linijek kodu, która widocznie wydawała mu się na pierwszy rzut oka zbędna. Cóż, jak się okazuje, wcale zbędna nie była, a naprawiała właśnie tę rzeczoną podatność sprzed prawie dwudziestu lat. Tak właśnie odnotowaliśmy regres, z czego postanowili sobie zażartować badacze z Kualysa. Wyborny żart? Doceniam. Ale tak całkiem na poważnie przypomina to wszystkim, przynajmniej mam taką nadzieję, jak ważne jest dogłębne testowanie kodu trafiającego na produkcję i prowadzenie szczegółowej dokumentacji. Zresztą na podstawie regression udało się znaleźć kolejną, bardzo zbliżoną lukę o swoim własnym numerze CVE – 2024-6409. Na szczęście o mniejszej sile rażenia, bo jej wykorzystanie nie skutkuje zdobyciem uprawnień administratora, a jedynie lokalnego użytkownika. Jeżeli można w takim przypadku w ogóle użyć stwierdzenia jedynie. Czy to wszystko bardzo źle świadczy o deweloperach OpenSSH? No, może i na pierwszy rzut oka tak, ale kiedy przyjrzymy się bliżej – nie do końca. Okej, podatność ta ma w teorii wręcz olbrzymie konsekwencje. Pozwala na zdalny dostęp nieuwierzytelnionemu użytkownikowi, dając mu na srebrnej tacy prawa administratora. W efekcie można masowo przejmować urządzenia, tworząc botnety, instalować złośliwe oprogramowanie, wykradać wrażliwe dane itd. To niebezpieczne nie tylko dla różnych serwerów wielkich korporacji, ale również dla użytkowników domowych, których urządzenia internetu rzeczy często działają właśnie w oparciu o Linuxy. Na szczęście potrzeba przeprowadzić masę prób, aby ten atak mógł się udać. Ale to nie jedyna dobra wiadomość. To przecież w sumie pierwsza tak poważna luka odnaleziona w serwerze OpenSSH od lat – jakichś 20 lat. A warto pamiętać, że serwer SSH pozwala przecież na zdalny dostęp, dlatego jest pod ciągłym ostrzałem, co zresztą każdy administrator jakiegokolwiek wystawionego na świat urządzenia widzi tysiące razy dziennie. Wszyscy tak po dobrej, jak i niestety też po tej złej stronie mocy próbują znaleźć w OpenSSH jakieś podatności, bo są one nie lada świętym gralem w świecie cyberbezpieczeństwa, skoro pozwalają na tak wiele. Dlatego w sumie to jakiś ewenement, że tak rzadko ktoś coś znajduje. Zresztą badacze z Qualisa w pierwszych zdaniach swojej publikacji na temat tej podatności podkreślają swój szacunek i podziw dla ludzi odpowiedzialnych za OpenSSH. A sama luka została załatana 6 czerwca w głównym repozytorium oprogramowania w wersji 9.8 wraz z innymi zdecydowanie mniej groźnymi podatnościami. Co robić i jak żyć? Korzystasz z serwera OpenSSH? Zaktualizuj się jak najszybciej, jeżeli jeszcze tego nie zrobiłeś. A jeżeli z jakiegoś powodu nie możesz tego zrobić, istnieje pewien sposób na obejście tej podatności. Wystarczy skonfigurować serwer OpenSSH w taki sposób, aby nigdy nie wyrzucał pukającego, niezależnie od czasu, który upłynął od pierwszego jego zgłoszenia. Co prawda umożliwia to przeprowadzenie innego rodzaju ataku, denial of service, gdzie ktoś otwierając dużą liczbę takich równoległych połączeń efektywnie pozbawi nas możliwości zdalnego logowania, bo zajmie wszystkie możliwe sloty, ale to nadal mniejsze zło niż oddanie atakującemu pełnej kontroli nad naszą maszyną. Pamiętaj, aby nie tylko w porę wdrażać wszystkie łatki bezpieczeństwa. Warto też zadbać o dodatkowe zabezpieczenia, choćby w postaci kontroli dostępu, kto w ogóle do serwera SSH może się spróbować połączyć. Ja na przykład zawsze ustawiam na firewallu konkretne państwa czy nawet konkretne adresy IP, z których połączenie jest w ogóle dozwolone. Reszta nie może nawet zapukać do drzwi. Dodatkowo automaty do przeczysywania sieci zazwyczaj skanują jedynie porty typowe dla konkretnych usług. W przypadku SSH jest to port TCP22. Warto więc, dla zmylenia przeciwnika, uruchomić OpenSSH na jakimś innym porcie, na przykład 62137. Dodatkowo zawsze warto też odpowiednio podzielić swoją infrastrukturę, tak aby nawet kompletne przejęcie jednej z maszyn nie narażało na atak innych. Czy podatny był każdy? No nie. Po pierwsze Luka występowała w serwerze OpenSSH w wersjach od 8.5 do 9.7 włącznie. I to nawet nie na wszystkich systemach, bo na przykład cała rodzina BSD uruchamia serwer OpenSSH w nieco innym środowisku, wspierającym w lepszy sposób asynchroniczność. Co automatycznie rozwiązuje ten problem. Nie była też podatna najnowsza wersja Ubuntu 24.04 nawet przed opublikowaniem nowej wersji OpenSSH, choć akurat w wyniku łatki, która wprowadza inne potencjalne zagrożenia. Możliwość przeprowadzenia ataku przetestowano też jedynie na maszynach wirtualnych, gdzie stabilność połączenia jest bardzo wysoka. W przypadku łączenia się przez Internet na pewno zdecydowanie trudniej jest przeprowadzić taki atak. To dobra wiadomość. Zła jest taka, że na pewno da się go jeszcze dopracować. Więcej zdecydowanie bardziej technicznych szczegółów znajdziecie w źródłach w opisie materiału. Dociekliwym polecam wnikliwą lekturę i na zachętę dodam, że swoją cegiełkę dołożył też nasz rodak, Lkamtów, czyli Michał Zalewski, na którego odkryciach bazowano i nazwano je wizjonerskimi. I to już wszystko na dziś. Tymczasem dziękuję za Waszą uwagę i do zobaczenia. Napisy stworzone przez społeczność Amara.org