Transcription

Cześć! Jak przejąć władzę nad światem? Cóż, być może wystarczą lata cierpliwości, olbrzymiej umiejętności i bardzo głębokie kieszenie. Ale przede wszystkim trzeba nie mieć pecha, bo to w sumie właśnie łód z szczęścia uratował nas wszystkich przed katastrofą. O co chodzi? Aby korzystać z internetu, jaki znamy, potrzebujemy serwerów. Sporo serwerów. Te najczęściej działają pod kontrolą różnej maści linuksów i im podobnych. A kiedy trzeba mieć do nich zdalny dostęp, bez czego ani rusz, wykorzystuje się protokół SSH, czyli Secure Shell. Jego implementacja, Open SSH, działa na praktycznie każdym linuksowym i nie tylko serwerze. Nic dziwnego. Pozwala na zdalny, a zarazem naprawdę całkiem bezpieczny dostęp. Potencjalnie więc Open SSH mogłoby być bardzo łakomym kąskiem dla kogoś o złych zamiarach, chcącego uzyskać nieautoryzowany dostęp do tysięcy czy nawet milionów urządzeń podłączonych do internetu. Wystarczyłoby przecież w jakiś sprytny sposób dodać do kodu źródłowego Open SSH kilka swoich linijek i tylko czekać, aż jakaś kolejna aktualizacja wypchnie je na urządzenia na całym świecie. Pomysł może i genialny, ale z wykonaniem zdecydowanie trudniej. No bo na tak istotne oprogramowanie patrzą tysiące oczu pieczołowicie sprawdzając, co trafia na produkcję. Szansa, że uda się prześlizgnąć jest więc naprawdę bliska zeru. Jak się jednak okazuje, istnieją sposoby, aby solidnie namieszać wcale nie dotykając kodu źródłowego Open SSH, a stosując tak popularny ostatnimi czasy atak na supply chain. W jaki sposób zepsuto minioną wielkanoc tysiącom bezpieczników i administratorów systemów na całym globie? Mnie zresztą też. Usiądźcie wygodnie. Czas na opowieść. Zapraszam. Dawno, dawno temu, czyli ta jakość na początku 2015 roku, pewien użytkownik Debiana zauważył, że kiedy podczas uruchamiania systemu usługa Open SSH nie wystartuje z powodu jakiegoś błędu, to wcale nie widać tego faktu i wygląda na to, że wszystko poszło zgodnie z planem. Problem leżał na linii komunikacji Open SSH z demonem odpowiedzialnym m.in. za uruchomienie systemu operacyjnego, czyli system D. Powstała więc łatka, która miała to zachowanie naprawić. Jednak okazało się to wcale nie tak trywialnym zadaniem, jak początkowo sądzono. Aby poprawka została dołączona w procesie budowania pakietu gotowego do instalacji, potrzebne było skorzystanie z jakiegoś programu do kompresji danych. Wybór padł na algorytm LZMA, będący częścią linuksowego pakietu XZ. To dość popularne narzędzie, stworzone i utrzymywane w dużej mierze przez jedną osobę, Lasse Collina. Popularność XZ urosła z czasem do bardzo wysokiego poziomu, bo aż ciężko sobie wyobrazić, ile oprogramowania na całym świecie jest dziś od niego zależnych. Sprawiło to, że chcąc nie chcąc Lasse stał się poniekąd za działanie tego oprogramowania częściowo odpowiedzialny, bo cokolwiek popsutego w XZ tak naprawdę może mieć wpływ na miliony urządzeń na całym świecie. Co warto jednak w tym miejscu podkreślić, serwer OpenSSH sam w sobie nie wymaga do instalacji pakietu XZ. Jednak sposób, w który jest on dostarczany na system użytkowników Debiana już tej paczki potrzebuje. W październiku 2021 roku w sumie znikąd do dziesiątek milionów użytkowników GitHuba dołącza Jiatan korzystając z loginu Jiate75. Sugeruje jakieś drobne poprawki w różnych projektach, aby po roku zainteresować się pakietem XZ. Szybko zaczyna istotnie wspierać głównodowodzącego do tej pory projektem Lasse. Tworząc choćby testy, co jest żmudnym zadaniem, którego nikt nigdy nie chce się podjąć. Mija niecały rok, gdy w okolicach czerwca 2022 roku zaczynają pojawiać się w stosunku do Lasse zarzuty, że zaniedbuje tak istotny przecież projekt. Badają one z klawiatur kont, które w sumie nie za wiele innego na GitHubie zrobiły. Lasse w odpowiedzi informuje o swoich osobistych problemach, w tym mentalnych, które uniemożliwiają mu poświęcenie na rozwój XZ więcej czasu. Zresztą warto pamiętać, że to projekt otwartoźródłowy, za który nikt mu nie płaci złamanego centa, a robi to tylko z własnej nieprzymuszonej woli, więc jakiekolwiek wymagania w tej kwestii są dość niedorzeczne. Niestety, zamiast zrozumienia i wsparcia spotyka się głównie z dalszymi zarzutami i obwinianiem go o duszenie projektu oraz sugestiami, żeby przekazał go komuś innemu. Lasse odpowiada, że Gia ostatnio sporo mu pomaga i być może jest to jakieś rozwiązanie w przyszłości. Zresztą Gia w wątku broni Lasse, tłumacząc, że jest to projekt hobbystyczny, dokładnie jak w metodzie na dobrego i złego policjanta. W końcu po jakimś czasie następuje zmiana na stanowisku głównego lidera XZ, bo rolę tę sukcesywnie przyjmuje Gia. Na początku 2023 roku konto GiaT75 zatwierdza samo po raz pierwszy zmiany w projekcie, a w marcu adres do kontaktów w sprawie repozytorium zostaje zmieniony z pierwotnego, należącego do Lasse, na maila Gia. W tym miejscu pojawia się jeszcze jedno konto pod imieniem i nazwiskiem Hans Janssen, które wprowadza jedną poprawkę i nic więcej. Gia ją akceptuje, mało znaczący fakt, który jednak będzie dość istotny później. W czerwcu Gia zgłasza bardzo drobną poprawkę do narzędzia OSS Fuzz autorstwa Google, służącego do testowania otwartego oprogramowania. Rzekomym powodem są problemy z kompatybilnością po wprowadzeniu wcześniejszych zmian w XZ. Poprawka zostaje bez zastrzeżeń zaakceptowana. W lutym bieżącego roku Gia informuje utrzymujących OSS Fuzz, że adres projektu XZ uległ zmianie, bo doszła do niego dodatkowa subdomena. Adres nie prowadzi już jak dotychczas do hostingu w Finlandii, ale prosto do repozytorium na GitHubie. Osoba Lasse coraz bardziej znika ze świadomości, a Gia w międzyczasie rośnie w siłę w ramach XZ. Pojawiają się kolejne poprawki oraz wypuszczane są kolejne wersje XZ. Zaczyna się też sugerowanie utrzymującym paczki w poszczególnych dystrybucjach Linuxów, aby szybko, jak najprędzej wrzucali aktualizacje do swoich testowych gałęzi. Jednym z nalegających jest Hans Janssen. Ten od jednej, jedynej poprawki. Wtórują mu inne konta, które w sumie nie robiły do tej pory nic innego albo zostały dopiero co utworzone. Jest 29 marca. Wielkanocny piątek. Osobiście nie mogę się doczekać, kiedy moją krew zastąpi ekstrakt sałatki jarzynowej, jednak okazuje się, że to tylko cisza przed burzą. Z samego rana na grupie dyskusyjnej OSS Security na Openwallu pojawia się wiadomość zaniepokojonego Andresa Freunda, pracownika Microsoftu rozwijającego postgres QL-a. Twierdzi on, że w ostatnich tygodniach zaobserwował jakieś dziwne zachowania swojej instalacji Debian Asset, czyli wersji testowej. Zdalne logowanie poprzez serwer SSH zajmowało zdecydowanie więcej czasu niż zwykle i nie dawało mu tu spokoju. Więcej o ile? Zapytacie? A no jakieś 500 milisekund, czyli pół sekundy. Tak, pół sekundy opóźnienia spędzało Andresowi sens powiek tak bardzo, że postanowił poświęcić na rozwikłanie tej zagadki dobrych parę tygodni. Andres szybko zdementował jednak przypisywane mu nadludzkie zdolności, bo to nie jego chronograf w głowie wykazał różnicę, a po prostu akurat przeprowadzał testy w tej sprawie. Jego uwagę przykuł fakt, że nieudane próby logowania z podaniem złych danych powodowały znaczny wzrost zużycia procesora, co nie miało na pierwszy rzut oka większego sensu. No i tu zaczęło się łączenie kropek. Źródłem problemu, jego zdaniem, miała być biblioteka LIB LZMA, czyli część pakietu XZ. Głębsza diagnoza jednak mroziła krew w żyłach. Zdaniem Andresa produkcyjny pakiet XZ stał się koniem trojańskim. Początkowo sądził, że dotyczy to jedynie repozytorium Debiana, jednak szybko okazało się to sporym niedoszacowaniem, bo chodziło o większość dystrybucji. Co ciekawe, problem występował tylko w prekompilowanych paczkach. W programie kompilowanym ze źródła wszystko działało jak należy. Dlaczego? Ponieważ złośliwy kod dodawany był w bardzo sprytny sposób poprzez skrypty na etapie automatycznej kompilacji do formatu DEP lub RPM. W dodatku wszystko było bardzo, ale to bardzo dobrze ukryte, udając prowadzenie testów w taki sposób, że na pierwszy rzut oka nie było tam niczego niepokojącego. Andres postawił też tezę, że nie jest to po prostu wykorzystanie czyjegoś zaufanego konta, aby coś na szybko wstrzyknąć, a metodyczne, od paru tygodni zachowanie jest to jego zwieńczenie. Wiadomość ta gruchnęła jak grom z jasnego nieba, w dodatku w idealnym wręcz momencie. Łączę się w bólu z wszystkimi administratorami, którzy w całym tym zamieszaniu, zresztą tak jak ja, próbowali łapać wszelkie ochłapy informacji, aby ustalić czy ich systemy również mogły potencjalnie zostać zaatakowane. Całej sytuacji wcale nie pomógł github. Zawiesili oni co prawda szybko konto GAT75, ale też zablokowali dostęp do repozytorium XZ, więc aby dokonać analizy kodu trzeba było uciekać się do lokalnych kopii albo forków projektu. Niestety zbanowali też konto Lasse, choć w tej sytuacji wydawał się on osobą, która mogła o sprawie wiedzieć najwięcej i najbardziej pomóc w rozwiązaniu tego palącego problemu. No ale nie dziwne, że w całym tym ferworze dopiero później zaczęto weryfikować jego intencje. Konto Lasse zostało na szczęście szybko odblokowane i ruszył on na pomoc i gdzie tylko mógł zaczął wycofywać wprowadzone przez GIA zmiany oraz informował na bieżąco społeczność o swoich odkryciach. Podatności przypisano oczywiście odpowiedni numer – CVE-2024-3094 i jest to podatność 10 na 10. Szybko ustalono, że zawierają ją tylko dwie wersje XZ-560 oraz 561 podpisane cyfrowo przez GIA. Wcześniejsze wersje podpisane przez Lasse nie zawierały złośliwego kodu. Kiedy już kurz opadnie, ma ukazać się wersja 580, która odetnie projekt od przeszłości. Większość dystrybucji szybko usunęła ze swoich repozytoriów zainfekowane wersje XZ, wymuszając tym samym instalację starszej wersji w momencie, kiedy ich użytkownicy przeprowadzą aktualizację. Tylko co właściwie wykombinował ten cały GIA? Ten atak to majstersztyk, ale wytłumaczenie w pełni jak został przeprowadzony nie jest wcale proste. Zainteresowanych szczególnie zachęcam do sprawdzenia bloga Genvaela Coldwinda oraz innych źródeł, do których linki znajdziecie w opisie. Ja postaram się o szybkie streszczenie i z góry przepraszam za ewentualne uproszczenia. Cały łańcuch, który prowadzi do finalnego zaatakowania gotowej paczki XZ złośliwym kodem ma kilka etapów. Każdy z nich jest na swój sposób ofuskowany, aby nie budzić podejrzeń na pierwszy rzut oka. GIA dodał do repozytorium dwa niewielkie binarne pliki, które wyglądały po prostu jak pliki wykorzystywane do testów. A to pewnie ostatnie miejsce, w które ktokolwiek z deweloperów by zaglądał, bo i po co. Wiadomo, potrzebna sprawa, ale nuda straszna. Lepiej zająć się czymś innym. Podczas budowania gotowego pakietu przeznaczonego do szerokiej dystrybucji, dwie dodane do skryptów konfiguracyjnych linijki kodu sięgają po te rzekome testowe pliki, rozpakowują je, a potem zamieniają ze sobą dwie pary znaków, tak samo jak funkcją znajdź i zamień. W ten sposób coś, co wyglądało wcześniej jak nieistotny był kod, staje się nagle działającym fragmentem kodu. Drugi z plików testowych też jest filtrowany i modyfikowany w inny sposób, jednak w tym samym celu. Złożenie tego w całość tworzy skompresowany plik, który wystarczy po prostu rozpakować. Klocki zaczynają sukcesywnie trafiać na swoje miejsce. Następnym krokiem jest przygotowanie na tej podstawie pliku zawierającego kod maszynowy, który niepostrzeżenie integrowany jest w trakcie kompilacji programu. Miesza się tu kod źródłowy, kod maszynowy, korzysta szeroko z grepa, awka, kompresji i dekompresji. Ogólnie naprawdę wyrafinowana sprawa. Voilà, gotowe. Właśnie do XZ trafiła jakaś magiczna funkcja, której nie znajdziemy nigdzie w kodzie źródłowym, a jest zwyczajnym backdoorem. Ba, Gia przygotował nawet mechanizm, który pozwalałby na dalszy rozwój możliwości tego konia trojańskiego, dodając po prostu następne pliki testowe, aby nie wzbudzać podejrzeń. Na drodze do próby przejęcia władzy nad światem, pierwsza wersja zawierająca dodatki okazała się generować błędy przy kompilacji, co, wraz z pomocą innych specjalistów, zostało szybko naprawione w kolejnej, szybko wypuszczonej wersji XZ. I nikt nie zauważył, że coś jest bardzo nie tak, aż do czasu, gdy Anders nie zwrócił uwagi na półsekundowe opóźnienie przy logowaniu. Dodajmy, zwrócił w ostatnim momencie, bo gdyby minęło parę dni albo tygodni, luka ta rozeszłaby się pewnie szeroko po całym świecie. Tylko na co tak właściwie pozwalała? Po przeprowadzeniu procesu inżynierii wstecznej przez społeczność dowiedzieliśmy się, co chciano osiągnąć. No bo co XZ, odpowiedzialne za kompresowanie danych, ma w ogóle z logowaniem przez SSH wspólnego? No bezpośrednio to nimi nic. Ale, uwaga, będzie grubo. Żeby system operacyjny w ogóle wiedział, że usługa SSH działa, to musi ona o sobie dać znać demonowi system D. Korzysta więc z funkcji sd.notify, która zawarta jest w bibliotece lib.system.d. Żeby móc to zrobić, OpenSSH musi załadować ją do pamięci. Ta biblioteka zależna jest od innej biblioteki, lib.lzma, a więc siłą rzeczy ją też trzeba wczytać. A to ona właśnie jest częścią zainfekowanego pakietu XZ. Wiemy już więc, jak się tam znalazła, ale teraz jak to wykorzystać? Łącząc się do serwera SSH przesyłamy swój klucz publiczny, aby się niejako przedstawić i potwierdzić, kim właściwie jesteśmy. W miejsce tego klucza atakujący wstawia specjalnie spreparowany łańcuch znaków, który też jest kluczem, ale zaszyfrowanym w inny sposób. Z wykorzystaniem mechanizmu ED488, a nie RSA. I funkcja, która ma za zadanie ten klucz sprawdzić, została po prostu podmieniona, aby robiła coś więcej. Zamiast po prostu sprawdzić poprawność klucza, najpierw próbuje porównać go z posiadanym wzorcem. Jeżeli to porównanie się zgadza, to znaczy, że do drzwi puka atakujący. Jeżeli jednak się nie zgadza, to po prostu wykonuje się dalej, tak jak pierwotnie miała, i sprawdza poprawność danych uwierzytelniania. Proces ten jest praktycznie niewidoczny dla końcowego użytkownika, ale jak widzicie, do sprawdzania klucza dochodzi w tym przypadku dwukrotnie, co trwa nieco dłużej. A więc nieco prościej. Złośliwy kod wykonywany był praktycznie natychmiast po połączeniu do serwera, jeszcze przed przeprowadzeniem procesu uwierzytelniania. Sprawdzano, czy ktoś, kto puka do drzwi, dysponuje odpowiednim, sekretnym kluczem. Jeżeli nie, to po prostu uwierzytelniano się tak jak zwykle, nie budąc podejrzeń. Jeżeli jednak ktoś był w posiadaniu klucza, to wpuszczano go do środka, aby wygodnie rozsiadł się w fotelu i czuł jak u siebie w domu. Nic innego nie było potrzebne, żeby przejąć setki, a może i miliony urządzeń na całym świecie. To dodatkowe sprawdzenie trwało te magiczne pół sekundy i położyło cały, latami pieczołowicie przygotowywany atak. Tylko kto za tym wszystkim stoi? Kim właściwie jest sprawca całego tego zamieszania, Jia Tan? Mamy w tej sprawie sporo poszlak, do których analizy ruszyli ochoczo osintowcy z Twixera. Wgląd w to dają nam choćby narzędzia GitHuba, pozwalające prześledzić historię wprowadzanych zmian, ale nie tylko. Jia łączył się do IRCA projektu XZ. Połączenie nawiązywał za każdym razem przez VPN prowadzący przez Singapur. Adres mailowy Jia nie występuje nigdzie poza GitHubem, wliczając to w wycieki baz użytkowników. Biorąc pod uwagę czas trwania takiej operacji, ciężko uznać to za normalne zachowanie. Wskazuje raczej na kogoś, kto nie tylko chciał pozostać anonimowy, ale też doskonale wiedział, jak to zrobić. Zdecydowanie lepiej niż zwykły użytkownik internetu, bo tacy zawsze popełniają jakieś obsekowe błędy. A tu ich nie ma. Grzebanie w logach GitHuba pozwoliło odkryć, że adres mailowy, z którego korzystał Jia, został raz użyty w połączeniu z drugim imieniem Cheong. Nie znam mandaryńskiego, ale źródła, które znalazłem, wskazują, że takie połączenie w takiej transkrypcji na łaciński alfabet nie jest możliwe. Sugeruje się więc, że to po prostu przypadkowy zlepek imion użyty przez kogoś, kto o Chinach nie ma zbyt wiele pojęcia, ale chce, aby wszyscy wokół bez zastanowienia wskazali oczywistego według nich sprawcę. Jednym ze sposobów na sprawdzenie lokalizacji Jia jest analiza godzin, w których był aktywny. Ktoś używający tego konta, owszem, korzystał z urządzenia z ustawioną strefą czasową wskazującą na Chiny albo przynajmniej kraje na tych południkach. Jednak jego aktywność pozwala też wysnuć tezę, że znajdował się we wschodniej Europie lub na przykład Izraelu lub Iranie. Mogą to potwierdzać zmiany wprowadzone do repozytorium z wykorzystaniem innej strefy czasowej niż chińska w bardzo krótkich, niemożliwych fizycznie do realizacji odstępach. Kolejną wskazówką jest praca w święta, w które ktoś z Chin raczej miałby wolne, za to brak aktywności choćby w Nowy Rok czy Boże Narodzenie. Ukrywanie się przez dwa lata, aby coś takiego zrobić, ciężko nazwać hobby. Trzeba w tym czasie mieć co jeść. W dodatku do przeprowadzenia tak wyrafinowanego ataku potrzeba naprawdę ogromnej wiedzy. Mając takie umiejętności można w krótkim czasie zarobić pieniądze, które pozwolą przejść na emeryturę przed 40, w jakimś kraju, gdzie nigdy nie ma brzydkiej pogody i to bez ryzyka trafienia do aresztu. To wszystko pozwala sądzić, że nie był to ktoś przypadkowy. Ba, pewnie nie była to nawet jedna osoba. Wszystko wskazuje na bardzo pieczołowicie zaplanowaną, spektakularną akcję prowadzoną latami przez np. wywiad jakiegoś państwa. Społeczność zebrana wokół otwarto-źródłowych projektów szybko wskazała prawdziwego winnego całego zamieszania. Oberwało się oczywiście wszystkim firmom pasożytniczo korzystającym ze zdobyczy wolnego oprogramowania. Te często opierają swoje wielomiliardowe biznesy o jakąś małą bibliotekę rozwijaną po godzinach przez jakiegoś jednego pasjonata bez żadnych finansowych korzyści z tego płynących. Nie mają więc prawa niczego w zamian wymagać. A już w szczególności tego, że jakiś przypadkowy Andrzej pracując z czeluści swojej piwnicy sam jeden dzielnie stawi czoła latami szkolonym szpiegom ze służby wywiadu jakiegoś mocarstwa. Pojawiła się zresztą w internecie masa memów nabijających się z tego, że przecież projekty open source nawoływały do ich szerszego finansowego wsparcia, więc w sumie nie powinno się narzekać, że zainteresował się nimi w końcu ktoś, kto jest w stanie płacić rozwijającym je programistom. Ale dobra, żarty na bok, bo nie jest to cała prawda. Wiele firm, szczególnie tych największych, wspiera otwarte oprogramowanie, delegując do jego rozwoju swoich etatowych pracowników czy trzymając nad nimi mecenat. Problemem często jest też po prostu wypalenie, szczególnie w przypadku jakichś bardzo wyspecjalizowanych, małych bibliotek. No bo co w nich można ciekawego i kreatywnego dodawać? Łata się jakieś drobne błędy, a zapał z czasem opada. I jak w końcu znajdzie się ktoś, kto chce przejąć taki zapomniany projekt, a w dodatku ma na to jakiś interesujący pomysł, to po prostu łatwo temu przyklasnąć, myśląc, że robi się to dla dobra wszystkich. Co robić i jak żyć? Jeżeli lubisz być na bieżąco z technologią, to pewnie kusicie korzystanie z testowych albo nawet eksperymentalnych gałęzi oprogramowania. O ile gwarantuje to dostęp do najnowszych funkcji, to przysparza też więcej siwych włosów na głowie niż sukcesywną utratę. Bo nie tylko coś częściej może nie działać, ale też nie jest wystarczająco dobrze przetestowane, co w skrajnych przypadkach może prowadzić do takich właśnie sytuacji. A z dużą dozą pewności można stwierdzić, że był to najpoważniejszy atak na otwartoźródłowy projekt w historii. Choćby dlatego lepiej nie testuj na produkcji. Z jednej strony widzimy, że przeprowadzenie takiej operacji w tej skali jest możliwe. Z drugiej szerokie próby ingerowania w różne projekty mogą paradoksalnie zwiększyć czujność i utrudnić przeprowadzenie z sukcesem takiej operacji w przyszłości. A więc jak zwykle, jeden rabin powie tak, drugi rabin powie nie. Pierwszą teorię potwierdzać jednak może fakt, że Androida to jedna z największych repozytorium wolnych i otwartoźródłowych aplikacji dla Androida. Chciano wymusić na nich, aby dokonali zmian w kodzie swojego projektu, które mogły wprowadzić bokiem podatność kategorii SQL Injection. Cała sprawa miała miejsce jakieś 3 lata temu i o szczegółach możecie przeczytać na 404media. Link oczywiście znajdziecie w opisie pod filmem. Ostatni rabin na GitHubie do 7 różnych projektów, więc audyt i nieuchronnie nadciągające po nim sprzątanie tego bałaganu zajmie pewnie długie tygodnie. Ale co to jest dla pasjonatów? Powstał już nawet honeypot, który ma nasłuchiwać, czy ktoś próbuje wykorzystać lukę. Ale błagam, nie rób tego w domu. No a jeżeli jesteś programistą, nie dołączaj do swojego oprogramowania na ślepo z zamkniętych bibliotek. Nigdy nie wiesz, co może siedzieć w ich wnętrzu. I to już wszystko na dziś. Tymczasem dziękuję za Waszą uwagę i do zobaczenia!