Biuletyn Threat Intelligence Nr 3: Podatność w GitHub i zagrożenia dla programistów

Podsumowanie

W marcu 2025 roku, popularna automatyzacja GitHub tj-actions/changed-files, używana w ponad 23 000 repozytoriów, została skompromitowana w wyniku ataku na łańcuch dostaw. Adwersarze wprowadzili złośliwy kod, który ujawniał w logach poufne informacje CI/CD, narażając je na nieautoryzowany dostęp [1]. Ponadto można zaobserwować coraz większe wyrafinowanie kampanii cyberataków, których celem są programiści. Łączą one socjotechniki, modularne i wieloplatformowe, złośliwe oprogramowanie a także zaawansowaną obfuskację [2].

Kradzież uwierzytelnień przez automatyzację GitHub

Akcje w GitHub są szeroko wykorzystywaną funkcjonalnością, która pozwala na automatyzację procesów związanych z rozwojem oprogramowania bezpośrednio w repozytorium. Przedmiotowa akcja tj-actions/changed-files używana jest w workflow CI/CD (Continuous Integration/Continuous Delivery) do identyfikacji zmienionych plików w repozytorium. Po wprowadzeniu zmian w kodzie, akcja ta pozwala na sprawdzenie, które pliki zostały dodane, zmodyfikowane lub usunięte między commitami, gałęziami lub pull requestami. Workflow CI/CD automatyzuje procesy budowy, testowania i wdrażania kodu, zapewniając szybsze i bardziej niezawodne dostarczanie oprogramowania [1, 3, 4]. Dlatego implementacja tego rozwiązania jest szeroka — aż 23 000 repozytoriów wykorzystuje opisywaną akcję.

Analiza podatności

Podatność w opisywanej akcji tj-actions/changed-files, oznaczona jako CVE-2025-30066 (8.6 CVSS), umożliwia zdalnym atakującym na uzyskanie dostępu do poufnych informacji przez wykorzystanie logów [5]. Atakujący zmodyfikowali kod akcji, wprowadzając złośliwy skrypt Python, który skanował pamięć procesu Runner Worker GitHub Actions w poszukiwaniu poufnych informacji [6, 7]. Złośliwy kod był zaszyfrowany w base64 i uruchamiany przez Node.js, co pozwalało na ukrycie jego prawdziwego celu i utrudniało wykrycie [8, 9]. W efekcie informacje, takie jak klucze dostępu AWS, tokeny GitHub PAT, tokeny npm czy prywatne klucze RSA, były zapisywane w logach (build) lub wysyłane do GitHub Gist [7, 9].

Wskazówki postępowania

Zalecamy niezwłoczną aktualizację tj-actions/changed-files do wersji 46.0.1 lub nowszej, jak również przegląd i weryfikację, czy starsze wersje zostały usunięte. Warto zmienić wszystkie CI/CD secrets, takie jak klucze API, hasła i tokeny. Ponadto logi (build) powinny zostać przejrzane pod kątem nieoczekiwanych wpisów lub wycieku poufnych informacji i uwierzytelnień, a commity mieć wymuszone podpisywanie dla ochrony integralności kodu.

Jednakże powyższa reakcja to dopiero pierwszy krok. Co do zasady zalecamy ograniczenia uprawnienia kont i tokenów do niezbędnego minimum, które pozwala wykonać zlecone działania. Warto też rozważyć ręczną akceptację nowych użytkowników repozytorium przez administratora — oczywiście jeśli jest to organizacyjnie wykonalne. Zdecydowanie pozytywny wpływ na bezpieczeństwo będzie mieć ciągłe monitorowanie. Zaleca się regularne przeprowadzanie audytów repozytorium i przeglądów kodu, a ponadto skorzystać można z takich narzędzi jak Falco lub Sysdig Secure [8, 9].

Zagrożenia dla programistów

Przytoczony przykład podatności w automatyzacji GitHub jest tylko jedną z wielu kampanii skierowanych przeciwko programistom, które można było zaobserwować w ostatnim czasie. Istotnym problemem jest także infekowanie popularnych projektów open source, w szczególności bibliotek i komponentów, czy ich podrabianie. W obu przypadkach cel jest jeden: implementacja złośliwego kodu w projekcie, coraz częściej w celu kradzieży informacji. Odzwierciedla to również opublikowany przez KPMG Poland Barometr Cyberbezpieczeństwa. Phishing, który dotychczas był wiodącym zagrożeniem, został zdetronizowany przez wycieki danych [10]. Co więcej, coraz trudniejsza sytuacja na rynku sprawia, że programiści stają się celem ataków kierowanych bezpośrednio w nich. Fałszywe rekrutacje lub propozycje współpracy dla freelancerów prowadzone są m.in. przez Koreę Północną.

Pułapki w dostępnych repozytoriach

W ostatnich miesiącach szczególnie widoczna była działalność grupy Lazarus, działającej w ramach 110. Centrum Wywiadowczego z Wydziału III Głównego Biura Rozpoznania Korei Północnej [11]. Kampania o kryptonimie Phantom Circuit, która wciąż jest prowadzona, polega na klonowaniu popularnych narzędzi open source, dodawaniu do nich złośliwego kodu (poddanego obfuskacji) i umieszczaniu ich z powrotem w repozytoriach.

Atakujący celują głównie w deweloperów w Europie, Indiach i Brazylii. Zmodyfikowane repozytoria zawierają m.in. narzędzia takie jak Codementor, CoinProperty i Web3 E-Store [13]. W efekcie, dane są eksfiltrowane i przesyłane do serwerów dowodzenia i kontroli (C2).

Z punktu widzenia zarządzania projektami programistycznymi, kampania ta podkreśla konieczność wprowadzenia rygorystycznych procesów weryfikacji kodu i monitorowania ruchu sieciowego. Programiści muszą być świadomi ryzyka związanego z używaniem zewnętrznych pakietów oprogramowania i wdrażać procedury, które minimalizują możliwość wprowadzenia złośliwego kodu do projektów. Warto też wdrożyć monitorowanie łańcucha dostaw oprogramowania, aby w porę wykrywać podejrzane aktywności.

Fałszywe rekrutacje

Inna kampania grupy Lazarus, Operacja 99, celuje bezpośrednio w programistów, w tym wypadku specjalizujących się w Web3 i kryptowalutach. Funkcjonariusze z Korei Północnej tworzą fałszywe profile na LinkedIn, prowadząc rzekome rekrutacje. Ich celem jest jednak wykradanie tajnych informacji, w tym portfeli kryptowalutowych, jak również uzyskiwanie długotrwałego dostępu do systemów. W ramach spreparowanych procesów naboru, atakujący zachęcają deweloperów do klonowania repozytoriów GitLab, które zawierają złośliwe oprogramowanie [14]:

• Main99 — komponent służący do łączenia się z serwerami C2 i pobierania dodatkowego kodu.
• Payload99/73 — keyloggery, monitorowanie schowka, eksfiltracja plików.
• MCLIP — dedykowany komponent do monitorowania klawiatury i schowka.

Oprogramowanie wykorzystywane przez grupę Lazarus stale ewoluuje. Aktualnie osiągnęło pełną wieloplatformowość (Windows, macOS, Linux), a ponadto osadza się w procesach związanych z pracami programistycznymi. Co więcej, komunikacja z serwerami C2 prowadzona jest z użyciem kompresji ZLIB, a sam złośliwy kod jest dopasowywany do ofiar. To znacząco utrudnia dopasowanie go do istniejących sygnatur, zapewniając niską wykrywalność [15].

Operacja 99, w przeciwieństwie do poprzednich kampanii, nie stosuje już mechanizmów autodestrukcji złośliwego oprogramowania. W zamian grupa Lazarus stara się je maskować w systemach ofiary, by zapewnić jak najdłuższy dostęp. Pomaga w tym 65-warstwowy schemat kodowania (obfuskacji), który utrudnia analizy. Większy nacisk położono też na modułowość ataku, co ułatwia prowadzenie działań skrojonych pod konkretny cel [15].

Wnioski

Przedstawione zagrożenia wskazują na konieczność holistycznego podejścia do bezpieczeństwa rozwoju oprogramowania. Choć wiązać się to może z mniejszą wygodą, to warto wdrożyć silne uwierzytelnianie, restrykcyjne reguły dostępu i pracy w repozytoriach, a także stałe ich monitorowanie. To nie tylko pozwoli ograniczyć ryzyko ataku, lecz zapobiec lateralnemu przemieszczaniu się atakującego, jeżeli już przełamie któreś z zabezpieczeń.

Ważnym pozostaje czynnik ludzki. Choć świadomość problemów stwarzanych przez użytkowników wydaje się być wysoka wśród programistów, to również oni padają ofiarą rutyny, pracy pod presją lub nieuwagi. Wówczas brak właściwej weryfikacji wykorzystywanych pakietów i bibliotek czy proponowanych zmian w kodzie, mogą stać się wektorem poważnego ataku.

Opracowanie: Mateusz Rakowski