Tylne wejście na SSH
Nieuczciwy lub skompromitowany administrator wprowadził złośliwe zachowanie do biblioteki o nazwie liblzma, część narzędzi kompresujących i bibliotek xz, co skutkuje powstaniem backdoora w SSH. Jest to zaawansowany atak na łańcuch dostaw oprogramowania, ponieważ biblioteka została celowo zmodyfikowana pod kątem backdoora, z zastosowaniem technik zaciemniania i ukrywania, aby ukryć ładunek ataku przed recenzentami.
Został odkryty i ujawniony niedawno (29 marca), a obsługa ataku jest w toku. Jednak szybko go powstrzymano, ponieważ wydaje się, że dotyczy on tylko wersji przedpremierowych ograniczonego zestawu środowisk (pakiety DEB i RPM dla architektury x86_64, zbudowane z wykorzystaniem GCC). Tak czy inaczej, CVE dostał Wynik podstawowy CVSS 10, co jest zarezerwowane dla najpoważniejszych luk w cyberbezpieczeństwie. Gdyby trafiło do stabilnych dystrybucji, skutki byłyby przytłaczające.
Analiza techniczna ataku, obejmująca m.in. szczegółowe wyjaśnienie tylnego wejścia xz, został przeanalizowany w innym miejscu. Ten wpis skupi się na chronologii ataku, sposobach jego wykrycia, dotychczasowym postępowaniu z incydentem oraz wnioskach, jakie można z niego wyciągnąć.
Długi ogon backdoora trwał jeszcze długo po opublikowaniu pierwszej poprawki. W sierpniu 2025 roku, ponad rok po ujawnieniu luki CVE-2024-3094, badacze bezpieczeństwa z Binarly odkryli, że backdoor nadal jest obecny w kilkunastu obrazach Dockera Debiana opublikowanych na Docker Hub, a zespół Debiana odmówił ich usunięcia, traktując je jako historyczne artefakty rozwojowe, a nie aktywne ryzyko. Oddzielnie, OpenSSF a OpenJS wydało wspólne ostrzeżenie krótko po incydencie XZ, że podobne próby przejęcia projektów JavaScript przy użyciu technik socjotechnicznych miały już miejsce. Sugeruje to, że zastosowany tutaj atak polegający na zaufaniu do opiekuna projektu jest wykorzystywany gdzie indziej.
Jak wstrzyknięto tylne drzwi XZ
Uwaga: repozytorium git znajduje się w git.tukaani.org. Jednakże, był też Repozytorium hostowane w GitHub (aktualnie zablokowane), na którym konto GitHub zamieszczało zmiany, które później zostały zintegrowane z repozytorium Git.
Część tylnego wejścia wydaje się znajdować tylko w rozproszonych plikach tarball dla wersji 5.6.0 i 5.6.1, a nie w repozytoriach git i opiera się na pojedyncza linia w pliku build-to-host.m4 Plik makr używany przez autoconf. Pozostała część znajdowała się w dwóch rzekomych plikach testowych bad-3-corrupt_lzma2.xz oraz good-large_compressed.lzma
które były committed przez konto GitHub „Jia Tan” (JiaT75) w repozytorium xz 23 lutego. To była niegroźna zmiana polegająca na dodaniu plików testowych (rzekomo skompresowanych bloków .lzma i .xz). Co ciekawe, pliki testowe nie były używane przez testy! Wiersz w pliku .m4 wstrzykuje zaciemniony skrypt (zawarty w archiwum tarball), który ma zostać wykonany na końcu konfiguracji, jeśli spełnione zostaną pewne warunki. Modyfikuje on plik Makefile dla liblzma biblioteka zawierająca kod, który wyodrębnia dane z pliku .xz, który po odszyfrowaniu kończy się w tym skrypcie, jest wywoływany na końcu programu configure. Decyduje on, czy zmodyfikować proces kompilacji, aby wstrzyknąć kod: tylko w środowisku GCC i linker GCC, w Debianie lub RPM i tylko w systemie Linux x86_64. Po dopasowaniu wstrzyknięty kod przechwytuje wykonywanie, zastępując dwa funkcja ifunc resolvery, dzięki czemu niektóre wywołania są zastępowane. Powoduje to parsowanie tabel symboli w pamięci (zajmuje to trochę czasu, co doprowadziło do wykrycia, jak wyjaśniono później).
Następnie robi się ciekawie: tylne drzwi instalują hak audytu w dynamicznym łączniku, czekając na nadejście symbolu funkcji RSA_public_decrypt, który jest przekierowywany do punktu w kodzie tylnych drzwi, który z kolei wywołuje biblioteka kryptograficzna, prawdopodobnie w celu przeprowadzenia normalnego uwierzytelniania. Ładunek aktywuje się, jeśli uruchomiony program ma nazwę procesu /usr/sbin/sshdByło jasne, że celem były serwery SSH. Tradycyjnie, sshd serwery takie jak OpenSSH nie były połączone z liblzmaale sshd jest często łatane aby obsługiwać systemd-notify, dzięki czemu inne usługi mogą się uruchamiać, gdy działa sshd. Następnie liblzma jest ładowana pośrednio przez systemd, zamykając krąg.
Tylne drzwi nie zostały jeszcze w pełni przeanalizowane, ale wydaje się, że tak. zezwalanie na zdalne wykonywanie poleceń (RCE) z uprawnieniami demona sshd, działający w kontekście wstępnego uwierzytelnienia. Informacje ze zdalnego certyfikatu, po dopasowaniu przez backdoor, są odszyfrowywane za pomocą ChaCha20, a po pomyślnym odszyfrowaniu są przekazywane do system(). Tak więc jest to w zasadzie bramkowane RCE, znacznie gorsze niż zwykłe obejście klucza publicznego.
Późniejszy plik tarball 5.6.1 zawierał dodatkowe próby ukrycia śladów, dodania jeszcze większego zaciemnienia nazw symboli i próby naprawienia zauważonych błędów. mechanizm rozszerzający gdzie przeszukano dodatkowe pliki testowe w celu znalezienia pewnych sygnatur, które można dodać do tylnego wejścia.
Ten dość wyrafinowany atak może pozostać niezauważony, dopóki nie zostaną wydane stabilne dystrybucje Linuksa. Na szczęście niektórzy lubią sprawdzać, dlaczego dzieją się nietypowe rzeczy.
Odkrycie ataku typu backdoor w XZ
Często wstrzyknięte złośliwe zachowanie jest odkrywane przez przypadek lub zbieg okoliczności. Dobrym przykładem jest ostrzeżenie o wycofaniu („Kogo obchodzą ostrzeżenia?”), co doprowadziło do odkrycia atak strumienia zdarzeń w październiku 2018 r. Innym użytkownikiem jest ten, który ostrzegał kodek w kwietniu 2021 r. ich skrypt do przesyłania plików za pomocą bash nie przeszedł testu sumy kontrolnej („Kto weryfikuje integralność artefaktów za pomocą sum kontrolnych”?) Anomalie i nietypowe objawy z ssh logins (logins pochłaniające dużo procesora i wydłużające czas upłynięcia, błędy valgrind) wzbudziły ciekawość Andresa Freunda, czujny programista PostgreSQL, ale nie analityk bezpieczeństwa (jak stwierdził). Po przeprowadzeniu pewnych badań z OpenSSH na Debianie Sid doszedł do wniosku, że problem z czasem reakcji polegał na bibliotece, liblzma, Część narzędzia xz biblioteka kompresji. Powód: „repozytorium xz i pliki tar xz zostały zainfekowane„Ta diagnoza była tak trafna! 29 marca 2024 r. Andres opublikował na Openwall pierwszą analizę: „tylne wejście w upstream xz/liblzma prowadzące do naruszenia bezpieczeństwa serwera sshFakt: Archiwa XZ Utils 5.6.0 i 5.6.1 zawierają backdoora. Archiwa te zostały utworzone i podpisane przez wspomniane konto Jia Tan. He opublikowano w Mastodonie Później tego samego dnia, uznając, że odkrycie było przypadkowe i wymagało wielu zbiegów okoliczności. Warto przeczytać komentarze innych użytkowników. Użytkownik GitHub ten sam (znany również jako Sam James) opublikował ciekawy artykuł FAQ na temat backdoora xz-utils gdzie atak został podsumowany, łącząc się z większą liczbą dogłębne analizy ładunku ataku. Analizy te były technicznie soczyste i pomogły nam lepiej zrozumieć zastrzyk, który był bardzo skomplikowany:- xz/liblzma: Wyjaśnienie zaciemniania na etapie powłoki BashCiekawa analiza deobfuskacji za pomocą skryptu wstrzykiwania, w czterech „etapach”.
- Błękitna nić Filippo Valsordy Analiza samego backdoora w RSA_public_decrypt, która pokazuje jego naturę: RCE, a nie obejście uwierzytelnienia, oraz bramkowanie (akceptuje klucz prywatny autora, a jeśli nie, powraca do normalnego działania) / niemożność spłaty. Autor zamierzał działać dyskretnie, aby uniknąć wykrycia!
- Analiza tylnego wejścia XZ autorstwa @smx-smx (WIP) – Dodatkowa analiza backdoora (prawie się pogubiłem na początku 😀)
- Wiki dokumentacji backdoora xz, kolejna analiza skryptu wstrzykiwania 5.6.1.
Jak potraktowano incydent
Andreas Freund był ostrożny w swoich ujawnieniach, ponieważ, jak sam powiedział:Biorąc pod uwagę widoczne zaangażowanie ze strony twórców, nie zgłosiłem błędu. Początkowo myślałem, że to problem specyficzny dla Debiana, więc wysłałem bardziej wstępne zgłoszenie na adres security@...ian.org. Następnie zgłosiłem problem do distros@. CIS„A został powiadomiony przez dystrybucję.”
Kto jest atakowany?
Albo konto GitHub JiaT75 zostało naruszone (pamiętajmy, że GitHub niedawno wprowadził dwuetapowe uwierzytelnianie), albo fizyczny użytkownik konta przeszedł na ciemną stronę. Istnieją jednak przekonujące przesłanki, by sądzić, że chodzi o zaawansowane, trwałe zagrożenie (APT), być może wspierane przez państwo, ze względu na zaawansowanie techniczne ataku. Dalsze dochodzenie przeprowadzone przez agencje ds. cyberbezpieczeństwa i organy ścigania ujawnią… Ten wpis w YCombinator Hacker News o Jia Tan Rzuca nieco światła na „kto” i jego działalność. Polecam! Zawiera wiele informacji o tym, jak złoczyńcy próbują oszukać innych użytkowników, stosując socjotechnikę.„Bardzo irytujące – domniemany autor backdoora komunikował się ze mną (rwmj) przez kilka tygodni, próbując dodać xz 5.6.x do Fedory 40 i 41 ze względu na jego „świetne nowe funkcje”. Pracowaliśmy nawet z nim nad rozwiązaniem problemu z valgrindem (który, jak się okazuje, był spowodowany przez dodanego przez niego backdoora). Musieliśmy się wczoraj spieszyć, żeby naprawić problem po przypadkowym złamaniu embarga. Jest on częścią projektu xz od dwóch lat, dodając wszelkiego rodzaju binarne pliki testowe i szczerze mówiąc, przy takim poziomie zaawansowania, podchodziłbym z podejrzliwością nawet do starszych wersji xz, dopóki nie udowodniono by inaczej”.
Jia Tan podjął kroki, aby zapobiec śledzeniu: Wygląda na to, że do połączenia użył VPN (vpn.singapore.witopia.net) – co samo w sobie jest w porządku. Wiele zmian wydaje się być popartych tymczasowymi, jednorazowymi e-mailami (w tym przypadku od ProtonMail) nakłaniającymi do scalenia zmian.
Aktor może chcieć zajrzeć jeszcze głębiej, aż do jądra Linuksa, jako współtwórca osadzone w XY projektu. Wstępna analiza nie wykazała dotychczas żadnych dowodów na poronienie.
Uwaga: inny niskoprofilowy współpracownik XZ „Hans Jansen” (użytkownik GitHub „hansjans162”) jest pod lupąJego konto w Debianie jest teraz zablokowanyWprowadził wiele aktualizacji do Debian Games, aby ukryć tę, której chciał w debian/xz-utils, aktualizację do upstream 5.6.1, aby przyspieszyć dystrybucję tylnych drzwi do debian/niestabilna.
Na razie możemy powiedzieć tylko tyle, że jest to (jeszcze niezidentyfikowana) atak APT wykorzystujący różne konta, pracujący nad tą kampanią od co najmniej dwóch lat i cierpliwie próbujący wszczepić RCE w SSH.
W chwili pisania tego tekstu tożsamość „Jia Tan” pozostaje niepotwierdzona. Nie potwierdzono publicznie żadnego wiarygodnego przypisania do konkretnej osoby, organizacji ani podmiotu państwowego, co potwierdza skuteczność dyscypliny operacyjnej tej osoby.
Czy można było zapobiec atakowi tylnego wejścia na XZ?
Niełatwy.
Po pierwsze, część wstrzykniętego backdoora znajdowała się w skompresowanych plikach testowych, które nie były używane przez testy. Z perspektywy czasu mogłoby to wywołać pewne (hałaśliwe) alarmy, ale kogo obchodzi sprawdzanie, czy wszystkie pliki testowe są używane przez rzeczywiste testy w świecie rzeczywistym? Po drugie, część wstrzykniętego backdoora znajdowała się w plikach makr w archiwach tarball z wydaniem i trudno jest ręcznie sprawdzić różnice w stosunku do oczekiwanych tarballi. Automatyzacja jest również skomplikowana, ponieważ oczekiwany wynik z samego procesu kompilacji (dla każdego, kto wie, jak działa automake/autoconf) trudno jest modelować w celu analizy, czy rzeczywisty tarball spełnia oczekiwania. Niektórzy to założyli as „Niezgodność plików tar z drzewem git to funkcja, a nie błąd”. Pochodzenie plików binarnych tarball w kodzie źródłowym pozostaje nierozwiązanym problemem.
Reputacja użytkownika? Cóż, konto JiaTan75 na GitHubie nie robiło nic nieuczciwego, zgodnie z tym, co było w przeszłości commits. Zostało zawieszone dopiero po zgromadzeniu dowodów, ale do 29 marca był to normalny użytkownik, wykonujący normalną działalność. Cóż, nie do końca normalny. Później commits (to, to, to, to (który dostosował kod exploita) próbował naprawić błędy valgrind i awarie w niektórych konfiguracjach, z powodu różnic w układzie stosu oczekiwanym przez tylne drzwi. Commit Recenzje mogłyby to wykryć, ale kto ma cierpliwość, aby analizować zmiany w pliku binarnym lub prawdziwą motywację zmiany atrybutów GCC w kodzie źródłowym C?
Czy należy podnosić alarm, gdy połączenie SSH login Zajmuje 800 ms zamiast 300 ms? Pewnie tylko osoby o dużej rozwadze by to zauważyły. Cyceron powiedział: „Pochopność jest cechą młodości, roztropność zaś starości.”
Infrastruktura ifunc została dodana w czerwcu 2023 roku przez „Hansa Jansena” i „Jia Tan”. To pierwszy commit Dodanie obsługi ifunc do crc64_fast.c (później używanej do wstrzyknięcia backdoora). Miesiące przed wstrzyknięciem plików binarnych backdoora do plików testowych!
Uwaga: Autor i commitTutaj różnice są spore, ale to normalne: Lasse Collin jest opiekunem projektu i to on scalił zmiany. Podziękował nawet „Hansowi Jansenowi”…
Nikt nie zgłaszał obaw przed wpisem Andresa Freunda i ujawnieniem CVE przez RedHat. Jeśli widzisz kaskadę narzędzi, które mogłyby to wykryć, wykryją one teraz podatny komponent. ex post facto.
Prawdopodobnie najlepszym sposobem zapobiegania była natura dystrybucji Linuksa i fakt, że niestabilne, najnowocześniejsze wersje są przekazywane do stabilnych dystrybucji dopiero po pewnym czasie.
Lekcje wyciągnięte z ataku XZ bBackdoor
Zauważyliśmy, jak trudno jest to wykryć zamierzony Tylne furtki. Tylne furtki należy traktować jako zagrożenie wewnętrzne, ponieważ są one instalowane przez pracowników firmy lub za pośrednictwem przejętych kont wewnętrznych. A ci ludzie są w większości zaufani. A kiedy tylna furtka jest wszczepiona w rozproszony artefakt, trudniej ją wykryć.
Niektórzy autorzy, jak Kevin Beaumont wskazywał na system, co otwiera szeroki obszar ataków na usługi zewnętrzne, umożliwiając dostęp tylnymi drzwiami. To właśnie ten zły aktor wykorzystał tutaj. Systemd ma wielu obserwatorów, ale XZ to mało znana biblioteka na wyższym poziomie. „Kiedy upstream jest skażony, wszyscy piją zatrutą wodę na niższym poziomie”.
Niezwiązane żądanie zmiany w systemie dynamiczne ładowanie bibliotek kompresji, który usunie tylne drzwi, został już włączony do systemu, ale nie został jeszcze dostarczony. Dodatkowe zależności wprowadzone przez libsystemd mogą być źródłem luk w zabezpieczeniachi wczoraj ta prośba została otwarta.
A komentarz w „xz: Wyłącz ifunc, aby rozwiązać problem” commit dał jasny wgląd w to, na czym należy się skupić, jeśli chcemy zapobiec takiej działalności (podkreślenie moje):
„Lekcją, którą powinniśmy wyciągnąć jako społeczność, jest zapewnienie większej ochrony software supply chain security Kompleksowo, audytując systemy kompilacji wykraczające poza sam kod źródłowy. Jak w przypadku naruszenia bezpieczeństwa SolarWinds, gdzie atakujący zmodyfikowali aktualizacje oprogramowania do monitorowania o zamkniętym kodzie źródłowym.
FAQ
Czy tylne drzwi XZ nadal stanowią zagrożenie?
W większości opanowane, ale nie całkowicie zniknęło. W sierpniu 2025 roku badacze odkryli, że tylne drzwi są nadal obecne w kilku obrazach Debian Docker Hub, traktowanych przez Debiana jako nieaktywne artefakty historyczne. Zespoły powinny sprawdzić, czy nie budują na przestarzałych, niezałatanych obrazach bazowych, zamiast zakładać, że poprawka z 2024 roku całkowicie zamknęła te drzwi.
