Ujawniono szczegóły ataku na infrastrukturę wykorzystaną przy tworzeniu frameworku uczenia maszynowego PyTorch, który umożliwił wydobycie kluczy dostępu wystarczających do umieszczenia dowolnych danych w repozytorium z wydaniami projektów na GitHub i AWS, a także podstawienie kodu w głównej gałęzi repozytorium i dodaj backdoora poprzez zależności. Podrabianie wersji PyTorch może zostać wykorzystane do ataku na duże firmy, takie jak Google, Meta, Boeing i Lockheed Martin, które wykorzystują PyTorch w swoich projektach. W ramach programu Bug Bounty firma Meta zapłaciła badaczom 16250 XNUMX dolarów za informacje o problemie.
Istotą ataku jest możliwość uruchomienia Twojego kodu na serwerach ciągłej integracji, które dokonują przebudów i uruchamiają zadania w celu testowania nowych zmian wysyłanych do repozytorium. Problem dotyczy projektów korzystających z własnych zewnętrznych programów obsługi „Self-Hosted Runner” z akcjami GitHub. W przeciwieństwie do tradycyjnych akcji GitHub, programy obsługi na własnym serwerze nie działają w infrastrukturze GitHub, ale na własnych serwerach lub na maszynach wirtualnych utrzymywanych przez programistów.
Wykonywanie zadań montażowych na Twoich serwerach pozwala zorganizować uruchomienie kodu, który może przeskanować sieć wewnętrzną przedsiębiorstwa, przeszukać lokalny FS w poszukiwaniu kluczy szyfrujących i tokenów dostępu oraz przeanalizować zmienne środowiskowe z parametrami dostępu do zewnętrznej pamięci masowej lub usług w chmurze. W przypadku braku odpowiedniej izolacji środowiska asemblera, znalezione poufne dane mogą zostać przesłane na zewnątrz do atakujących, na przykład poprzez dostęp do zewnętrznych API. Aby określić wykorzystanie Self-Hosted Runner w projektach, można zastosować zestaw narzędzi Gato do analizy publicznie dostępnych plików przepływu pracy i dzienników uruchamiania zadań CI.
W PyTorch i wielu innych projektach korzystających z Self-Hosted Runner tylko programiści, których zmiany zostały wcześniej sprawdzone i uwzględnione w bazie kodu projektu, mogą uruchamiać zadania kompilacji. Posiadanie statusu „współautor” przy korzystaniu z domyślnych ustawień w repozytorium umożliwia uruchomienie procedur obsługi GitHub Actions podczas wysyłania pull requestów i odpowiednio wykonanie swojego kodu w dowolnym środowisku GitHub Actions Runner powiązanym z repozytorium lub organizacją nadzorującą projekt.
Link do statusu „współautor” okazał się łatwy do ominięcia – wystarczy najpierw zgłosić drobną zmianę i poczekać, aż zostanie przyjęta do bazy kodu, po czym deweloper automatycznie otrzyma status aktywnego uczestnika, których żądania ściągnięcia mogą być testowane w infrastrukturze CI bez osobnej weryfikacji. Aby osiągnąć status aktywnego programisty, w eksperymencie wprowadzono drobne zmiany kosmetyczne mające na celu skorygowanie literówek w dokumentacji. Aby uzyskać dostęp do repozytorium i przechowywania wydań PyTorch, atak podczas wykonywania kodu w „Self-Hosted Runner” przechwycił token GitHub używany do dostępu do repozytorium z procesów kompilacji, a także klucze AWS używane do zapisywania wyników kompilacji .
Problem nie jest specyficzny dla PyTorch i dotyczy wielu innych dużych projektów, które korzystają z domyślnych ustawień „Self-Hosted Runner” w GitHub Actions. Na przykład wspomniano o realizacji podobnych ataków mających na celu zainstalowanie backdoora w niektórych dużych portfelach kryptowalut i projektach blockchain o kapitalizacji miliardów dolarów, dokonanie zmian w wydaniach Microsoft Deepspeed i TensorFlow, złamanie zabezpieczeń jednej z aplikacji CloudFlare, a także wykonanie kodu na komputerze w sieci Microsoft. Szczegóły tych wydarzeń nie zostały jeszcze ujawnione. W ramach istniejących programów nagród za błędy badacze złożyli ponad 20 wniosków o nagrody o wartości kilkuset tysięcy dolarów.
Źródło: opennet.ru