Odkrycie backdoora XZ ujawnia atak na łańcuch dostaw systemu Linux
W powszechnie używanej bibliotece kompresji dystrybucji Linuksa wykryto backdoora, który mógł zapewnić nieautoryzowanym użytkownikom dostęp do zainfekowanych systemów.
29 marca Andres Freund, programista PostgreSQL w firmie Microsoft, ujawnił, że odkrył backdoora ukrytego w pakiecie liblzma o otwartym kodzie źródłowym dla XZ, popularnej biblioteki kompresji używanej w wielu dystrybucjach Linuksa. W ujawnieniu opublikowanym na liście mailingowej Open Source Security Freund napisał, że zaobserwował w ostatnich tygodniach dziwne zachowanie liblzmy działającej w Debianie, takie jak powolne logowanie przez SSH i zaskakująco wysokie użycie procesora przez procesy SSHD. Po dalszym dochodzeniu doszedł do wniosku, że nadrzędne repozytorium XZ zostało naruszone w wyniku ataku na łańcuch dostaw.
Fruend prześledził złośliwy kod i odkrył, że backdoor został dołączony do projektu open source poprzez legalnie wyglądające aktualizacje wykonane przez opiekuna XZ, później zidentyfikowanego jako Jia Tan. „Biorąc pod uwagę kilkutygodniowe działania, sprawca jest albo bezpośrednio zaangażowany, albo doszło do dość poważnego naruszenia jego systemu” – napisał w ujawnieniu. „Niestety to drugie wyjaśnienie wydaje się mniej prawdopodobne, biorąc pod uwagę, że na różnych listach informowano o „poprawkach” wspomnianych powyżej”.
Freund odkrył również, że backdoor obecny w XZ Utils w wersjach 5.6.0 i 5.6.1 był zawarty jedynie w zarchiwizowanych pakietach do pobrania, zwanych „tarballami”, które są wydawane wcześniej. Szkodliwy kod nie występował w dystrybucjach Git.
W piątkowym poradniku dotyczącym bezpieczeństwa firma Red Hat zauważyła, że backdoor, który jest śledzony jako CVE-2024-3094 z wynikiem 10 w CVSS, składa się z dwóch etapów. „W dystrybucji Git brakuje makra M4, które uruchamia kompilację złośliwego kodu” – stwierdzono w poradniku. „Artefakty drugiego etapu są obecne w repozytorium Git do wstrzyknięcia w czasie kompilacji, na wypadek obecności złośliwego makra M4. Bez połączenia z kompilacją plik drugiego etapu jest nieszkodliwy”.
W piątkowym poście na blogu badacze Tenable stwierdzili, że backdoor dotyczy kilku dystrybucji Linuksa, w tym Fedory Rawhide i Fedory 41. Miał także wpływ na testy Debaina oraz dystrybucje niestabilne i eksperymentalne w wersjach od 5.5.1alpha-0.1 do 5.6.1-1.
Inne dystrybucje, których dotyczy problem, to openSUSE Tumbleweed i openSUSE MicroOSm, które miały backdoora między 7 a 28 marca; Kali Linux, który miał backdoora między 26 a 28 marca; i nośnik instalacyjny Arch Linux 2024.03.01, a także obrazy maszyn wirtualnych 20240301.218094 i 20240315.221711 oraz obrazy kontenerów utworzone między 24 lutego a 28 marca.
Nie jest jasne, ile organizacji pobrało dystrybucje ze złośliwymi wersjami XZ ani czy którakolwiek z tych organizacji została naruszona za pomocą backdoora.
CISA wydała w piątek ostrzeżenie, w którym zwróciła uwagę na zalecenie firmy Red Hat i nalegała, aby programiści i użytkownicy Linuksa przeszli na nienaruszoną wersję XZ Utils, na przykład stabilną wersję 5.4.6, oraz aby wyszukali w swoich środowiskach jakąkolwiek złośliwą aktywność.
Inne popularne dystrybucje Linuksa, w tym Red Hat Enterprise, SUSE Linux Enterprise i Leap, Amazon Linux i Ubuntu, nie zostały naruszone przez backdoora.
„Na szczęście wersje xz 5.6.0 i 5.6.1 nie zostały jeszcze powszechnie zintegrowane z dystrybucjami Linuksa, a jeśli tak, to głównie w wersjach przedpremierowych” – napisał Freund.
Harmonogram ataku
Według wielu dostawców rozwiązań cyberbezpieczeństwa i analityków zagrożeń backdoor powstał w wyniku skomplikowanego, wieloletniego ataku wykorzystującego socjotechnikę. W centrum znajdował się użytkownik GitHuba JiaT75, znany również jako Jia Tan. Ten programista współpracował z biblioteką XZ przez dwa lata, zbudował zaufanie wśród społeczności programistów i ostatecznie uzyskał uprawnienia do utrzymywania repozytorium XZ i zatwierdzania scalania.
Według harmonogramu stworzonego przez programistę Evana Boehsa Tan założył konto na GitHubie w listopadzie 2021 r. i utworzył w libarchive żądanie ściągnięcia, które pod przykrywką zmiany tekstu błędu zastąpiło jeden fragment kodu mniej bezpiecznym wariantem. W kwietniu 2022 roku Jia Tan przesłał łatkę do XZ za pośrednictwem listy mailingowej, a inny użytkownik, „Jigar Kumar” – być może pseudonim lub współspiskowiec – naciskał na opiekunów łatki, aby połączyli ją.
Następnie Jigar Kumar wywarł presję na opiekuna projektu XZ, aby dodał kolejnego opiekuna, który będzie mógł swobodnie dokonywać zatwierdzeń. Od tego momentu Tan zaczął regularnie wnosić wkład w projekt i najwyraźniej zyskał wystarczające zaufanie, aby na początku stycznia 2023 r. połączyć swój własny kod. Następnie na przestrzeni miesięcy i na początku 2024 r. Tan podjął działania, aby zwiększyć swój wpływ w ramach projektu i zbuduj infrastrukturę dla backdoora.
Backdoor został ostatecznie sfinalizowany na początku tego roku, zanim został wykryty w marcu.
Przypisano CVE
Backdoorowi XZ przypisano CVE i jest on wymieniony w krajowej bazie danych o lukach w zabezpieczeniach NIST, co nie jest typowe dla złośliwego oprogramowania.
„Poprzez serię skomplikowanych zaciemnień proces kompilacji liblzma wyodrębnia wstępnie skompilowany plik obiektowy z ukrytego pliku testowego istniejącego w kodzie źródłowym, który jest następnie używany do modyfikowania określonych funkcji w kodzie liblzma” – czytamy w wykazie NIST. „Dzięki temu powstała zmodyfikowana biblioteka liblzma, z której może korzystać dowolne oprogramowanie powiązane z tą biblioteką, przechwytując i modyfikując interakcję danych z tą biblioteką”.
Chociaż jest to złożony incydent, który wciąż jest badany, Michael Skelton, wiceprezes Bugcrowd ds. operacji bezpieczeństwa i sukcesu hakerów, określił przypisanie CVE jako podejście proaktywne i zapobiegawcze.
„Należy wyjaśnić, że CVE nie są przypisane do samego złośliwego oprogramowania ani backdoorów, ale raczej do luk w zabezpieczeniach, które takie złośliwe podmioty mogą wykorzystać” – Skelton powiedział redakcji TechTarget. „Przypisując CVE do podejrzanej, ale niepotwierdzonej luki, społeczność uznaje potencjał wykorzystania i priorytetowo traktuje bezpieczeństwo ekosystemu, zapewniając podjęcie środków ostrożności nawet w przypadku braku natychmiastowego dowodu możliwości wykorzystania”.
Scott Caveza, inżynier ds. badań w Tenable, zgodził się, że wydanie certyfikatu CVE jest w tym przypadku mniej typowe, ale stwierdził, że decyzja firmy Red Hat o jego wydaniu „znacznie ułatwia identyfikację systemów, których dotyczy problem”.
„Każda dystrybucja Linuksa, której dotyczy lub nie, może odpowiedzieć swoim klientom za pomocą wspólnego identyfikatora wyznaczającego tego backdoora, a zainteresowane strony nie próbują przeszukiwać mnóstwa możliwych fraz, lecz mogą odnieść się do tej sytuacji za pomocą identyfikatora CVE” – Caveza powiedział. „Chociaż jest to dość rzadki scenariusz, kiedy program CVE został wprowadzony po raz pierwszy w 1999 r., jest mało prawdopodobne, aby ataki na łańcuch dostaw były wówczas w ogóle brane pod uwagę”.
Konsekwencje bezpieczeństwa open source
W poście na blogu Bugcrowd na temat backdoora Skelton podkreślił konsekwencje odkrycia i potencjalne skutki dla innych projektów open source.
„Jedną z konsekwencji tego odkrycia jest to, że Jia Tan wniosła swój wkład nie tylko w tę bibliotekę, ale także w inne, co spowodowało konieczność przeprowadzenia szerszego przeglądu w celu sprawdzenia, czy inne komponenty również mogą znajdować się w obecnie zagrożonym stanie” – napisał. „Poza tym pojawia się pytanie, jak uniknąć tych problemów w łańcuchu dostaw – i czy w ogóle można ich uniknąć. Oprogramowanie typu open source stanowi podstawę wielu usług i firm, na których polegamy – i nie wszystko można dokładnie zbadane pod kątem poziomu szczegółowości niezbędnego do uniknięcia tych ataków.”
Omkhar Arasaratnam, dyrektor generalny Open Source Software Foundation, napisał w sobotnim poście na blogu, że charakter oprogramowania typu open source pozwala na szybkie wykrycie backdoora, jego zgłoszenie i zajęcie się nim, a liczba systemów dotkniętych backdoorem jest „stosunkowo Niski.”
„Takie sytuacje przypominają nam wszystkim, że musimy zachować czujność w ekosystemie oprogramowania open source” – napisał Arasaratnam. „Open source polega na tym, że ludzie mający dobre intencje ofiarowują swój czas i talenty, aby pomóc w rozwiązywaniu problemów, co niestety może zostać zagrożone”.
Arasaratnam powiedział redakcji TechTarget, że w przypadku bezpieczeństwa open source nie ma doskonałych zestawów narzędzi i praktyk, które zapobiegłyby tego typu atakom na łańcuch dostaw. „Możemy pewnego dnia dojść do punktu, w którym będziemy mieć możliwości zabezpieczeń typu open source, które pomogą zabezpieczyć oprogramowanie typu open source” – powiedział. „Myślę, że będzie to wymagało podejścia angażującego wszystkie ręce, wykorzystującego zbiór technologii i procesów, aby pomóc opiekunom i konsumentom zachować bezpieczeństwo podczas tworzenia i korzystania z cyfrowych dóbr publicznych, takich jak oprogramowanie typu open source”.
John Bambenek, prezes firmy konsultingowej ds. bezpieczeństwa Bambenek Consulting, podobnie zauważył, że „nie mamy świetnych narzędzi do radzenia sobie z wektorami ataków wprowadzanymi w powszechnie używanym oprogramowaniu open source”, takim jak XZ.
„To powiedziawszy, jesteśmy coraz lepsi w wykrywaniu złośliwej aktywności w środowisku naturalnym, a ponieważ dotknęło to tak wiele organizacji na raz, byliśmy w stanie szybko powstrzymać zagrożenie” – powiedział. „Jedynie niewiele możemy zrobić dla oprogramowania obsługiwanego przez wolontariuszy i jasne jest, że musimy znaleźć sposoby na szybką poprawę sytuacji, w przeciwnym razie taka sytuacja będzie się powtarzać”.
Rob Wright jest wieloletnim reporterem i starszym dyrektorem ds. wiadomości w zespole ds. bezpieczeństwa redakcji TechTarget. Kieruje najświeższymi wiadomościami i trendami w zakresie bezpieczeństwa informacji. Masz wskazówkę? Wyślij mu e-mail. Alexander Culafi jest starszym autorem wiadomości na temat bezpieczeństwa informacji i gospodarzem podcastów w redakcji TechTarget.
