Złośliwe obrazy Docker i rozszerzenia VS Code uderzają w łańcuch dostaw Checkmarx

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla organizacji rozwijających i wdrażających aplikacje w modelu DevSecOps. Najnowszy incydent związany z ekosystemem Checkmarx pokazuje, że nawet narzędzia bezpieczeństwa mogą stać się wektorem kompromitacji. Sprawa dotyczy złośliwych obrazów Docker dla KICS oraz podejrzanych rozszerzeń Visual Studio Code, które mogły zostać wykorzystane do kradzieży danych i dalszej propagacji ataku.

Problem jest szczególnie istotny, ponieważ KICS to narzędzie służące do skanowania infrastruktury jako kodu. Jeśli taki komponent zostanie podmieniony, organizacja może nieświadomie uruchomić złośliwe oprogramowanie w środowisku mającym dostęp do sekretów, repozytoriów i zasobów chmurowych.

W skrócie

Incydent obejmował złośliwe artefakty opublikowane w oficjalnych kanałach dystrybucji powiązanych z Checkmarx. Zmodyfikowane obrazy Docker zawierały podmieniony binarny skaner KICS z funkcjami zbierania i eksfiltracji danych, a wybrane wersje rozszerzeń VS Code pobierały dodatkowy kod JavaScript i uruchamiały go bez weryfikacji integralności.

• atakujący celowali w tokeny GitHub, poświadczenia AWS, Azure i GCP, klucze SSH oraz zmienne środowiskowe,
• zagrożenie mogło rozprzestrzeniać się do środowisk CI/CD,
• możliwa była także dalsza propagacja przez ekosystem npm,
• nadpisano wybrane tagi obrazów Docker, co zwiększyło ryzyko pobrania złośliwego artefaktu przez legalnych użytkowników.

Kontekst / historia

KICS to otwartoźródłowe narzędzie do analizy Infrastructure as Code, wykorzystywane do wykrywania błędnych konfiguracji i podatności w szablonach Terraform, Kubernetes, Docker, Helm oraz AWS CloudFormation. Ze względu na szerokie wykorzystanie w procesach bezpieczeństwa, kompromitacja jego kanałów dystrybucji może bezpośrednio uderzyć w zespoły programistyczne, potoki budowania i infrastrukturę chmurową.

W opisywanym przypadku wykryto nadpisanie istniejących tagów obrazów Docker, między innymi v2.1.20 i alpine, a także pojawienie się nowego tagu v2.1.21, który nie odpowiadał prawidłowemu wydaniu upstream. Równolegle zidentyfikowano kompromitację wybranych wersji rozszerzeń deweloperskich, co wskazuje na incydent obejmujący więcej niż jeden kanał dystrybucji.

Checkmarx potwierdził prowadzenie dochodzenia i opublikował listę artefaktów uznanych za potencjalnie dotknięte incydentem. To ważny sygnał dla organizacji, które korzystały z tych komponentów w codziennych procesach bezpieczeństwa i automatyzacji.

Analiza techniczna

Od strony technicznej incydent wpisuje się w model wieloetapowego ataku supply chain. W przypadku obrazów Docker złośliwy komponent podszywał się pod prawidłowy skaner kics, ale zawierał dodatkową logikę odpowiedzialną za zbieranie danych i ich przesyłanie do infrastruktury kontrolowanej przez atakujących. To szczególnie niebezpieczne w środowiskach, gdzie skanowane artefakty mogą zawierać sekrety, klucze dostępu i wrażliwe konfiguracje.

W rozszerzeniach VS Code wykryto mechanizm pobierania zewnętrznego dodatku JavaScript z osadzonego adresu oraz jego uruchamiania przez środowisko Bun. Kod działał etapowo: najpierw ładował kolejny komponent, potem wyszukiwał poświadczenia i konfiguracje w środowisku deweloperskim, a następnie kompresował i szyfrował zebrane dane przed eksfiltracją.

Szczególnie groźny był mechanizm dalszej propagacji. Złośliwy kod wykorzystywał przejęte tokeny GitHub do tworzenia publicznych repozytoriów służących jako magazyn przejściowy dla wykradzionych danych. Mógł także wstrzykiwać nowe workflow GitHub Actions do repozytoriów ofiary w celu przechwytywania sekretów dostępnych podczas działania pipeline’ów CI/CD. Po zakończeniu operacji część śladów była usuwana, co sugeruje działanie z elementami antyforensycznymi.

Badacze wskazali również ryzyko ekspansji do ekosystemu npm. Po przejęciu odpowiednich poświadczeń napastnicy mogli identyfikować pakiety, do których ofiara miała prawa publikacji, a następnie publikować ich zainfekowane wersje. To oznacza, że incydent mógł wykraczać poza pojedyncze stacje robocze i obejmować kolejne warstwy łańcucha dostaw oprogramowania.

Konsekwencje / ryzyko

Ryzyko operacyjne należy ocenić jako wysokie, ponieważ kompromitowane narzędzia działały w środowiskach uprzywilejowanych. Rozszerzenia IDE, skanery bezpieczeństwa oraz zadania CI/CD zwykle mają dostęp do repozytoriów kodu, sekretów pipeline’ów, tokenów API i poświadczeń chmurowych.

• ujawnienie sekretów obecnych w skanowanych plikach IaC,
• kradzież tokenów GitHub i przejęcie repozytoriów,
• nadużycie poświadczeń w AWS, Azure i GCP,
• kompromitacja kluczy SSH i konfiguracji developerskich,
• przejęcie lub zatrucie pipeline’ów CI/CD,
• wtórna propagacja do pakietów npm i innych komponentów łańcucha dostaw.

Z punktu widzenia obrony szczególnie niepokojące jest to, że atak nie ograniczał się do kradzieży danych. Jego architektura umożliwiała aktywne rozszerzanie zasięgu poprzez automatyczne workflow, nadużycie uprawnień publikacyjnych i wykorzystanie legalnych kanałów deweloperskich. Organizacje korzystające z dotkniętych artefaktów powinny traktować wszystkie sekrety przetwarzane przez te komponenty jako potencjalnie ujawnione.

Rekomendacje

W przypadku podejrzenia użycia złośliwych lub podatnych artefaktów należy przyjąć scenariusz pełnej kompromitacji i uruchomić procedurę reagowania na incydent. Sama aktualizacja wersji nie jest wystarczająca.

• natychmiast usunąć wskazane obrazy Docker, rozszerzenia IDE i powiązane artefakty z systemów deweloperskich oraz środowisk build,
• przeprowadzić rotację wszystkich potencjalnie ujawnionych sekretów, w tym tokenów GitHub, poświadczeń npm, kluczy SSH, sekretów CI/CD i danych dostępowych do chmury,
• przeanalizować repozytoria GitHub pod kątem nieautoryzowanych branchy, repozytoriów i workflow,
• zweryfikować konta npm oraz historię publikacji pakietów,
• sprawdzić logi w usługach chmurowych i systemach tożsamości pod kątem nietypowych logowań i operacji,
• zrezygnować z zaufania do zmiennych tagów takich jak latest i przejść na przypinanie konkretnych, zweryfikowanych wersji,
• wdrożyć monitorowanie integralności artefaktów i polityki dopuszczania wyłącznie podpisanych komponentów,
• ograniczyć uprawnienia narzędzi bezpieczeństwa i pipeline’ów do absolutnego minimum,
• zablokować wskazaną infrastrukturę atakujących w systemach detekcji sieciowej i EDR,
• potwierdzić użycie wyłącznie wersji uznanych przez producenta za bezpieczne.

Podsumowanie

Incydent związany z KICS i rozszerzeniami VS Code pokazuje, że kompromitacja narzędzi bezpieczeństwa może być równie groźna jak atak na popularną bibliotekę open source. Dla napastników to bardzo atrakcyjny wektor, ponieważ otwiera drogę do uprzywilejowanych środowisk deweloperskich, sekretów i procesów CI/CD.

Najważniejszy wniosek dla organizacji jest prosty: każde użycie dotkniętych artefaktów należy traktować jako potencjalne naruszenie bezpieczeństwa, a nie jedynie błąd integralności pakietu. Skuteczna odpowiedź powinna obejmować nie tylko wymianę komponentów, lecz także pełny przegląd poświadczeń, repozytoriów, workflow i opublikowanych pakietów.

Źródła

• The Hacker News — https://thehackernews.com/2026/04/malicious-kics-docker-images-and-vs.html
• Socket — Malicious Checkmarx Artifacts Found in Official KICS Docker Repository and Code Extensions — https://socket.dev/blog/checkmarx-supply-chain-compromise
• Checkmarx — Checkmarx Security Update: April 22 — https://checkmarx.com/blog/checkmarx-security-update-april-22/
• Checkmarx — Checkmarx Security Update — https://checkmarx.com/blog/checkmarx-security-update/
• Checkmarx Documentation — KICS Auto Scanning Extension for VS Code — https://docs.checkmarx.com/en/34965-68771-kics-auto-scanning-extension-for-vs-code.html