Un error d'un sol caràcter que va enviar programari maliciós
Va començar amb una errada tipogràfica. En algun moment de la gran quantitat de publicacions de notícies i fusions de relacions públiques, algú va escriure @utils_core en lloc de @utils-core a la paquet.jsonAquell error d'un sol caràcter no va generar cap error. En canvi, va introduir silenciosament un paquet maliciós semblant durant el següent CI/CD executar, aprofitant la confiança en les versions fixades i l'automatització. Benvinguts al món del typosquatting en codi obert.
Typosquatting: el vector d'atac que prospera gràcies a l'error humà
El typosquatting és exactament el que sembla: actors maliciosos que registren paquets amb noms gairebé idèntics als legítims. En entorns ràpids, això funciona perquè els desenvolupadors confien que els seus paquet.json i package-lock.json reflecteix el que esperen. Un personatge fora? Podria ser invisible en un diferencial de relacions públiques.
NPM té un historial d'explotació a través de typosquatting. Paquets com entorn creuat en lloc de entorn creuat or flux d'esdeveniments Les portes del darrere ja han demostrat l'efectivitat d'aquests programes similars. Aquests paquets falsos sovint passen revisions simplement perquè semblen correctes i no generen errors d'execució immediats.
Les trampes comunes inclouen:
- Guió vs subratllat: lnucli d'odash vs lodash_core
- Plurals: sol · licitar vs peticions
- Caràcters substituïts: expressar en lloc de exprés
On package-lock.json es converteix en un punt cec
El desenvolupador corregeix la seva errada tipogràfica. O això creuen. Però a hores d'ara, package-lock.json ja ha bloquejat el paquet de l'atacant. I aquí és on s'amaga el veritable risc.
Desemejante paquet.json, que s'edita manualment i rep més atenció, package-lock.json es genera automàticament per NPMCom a resultat, sovint es tracta com una formalitat, s'omet o només es passa per alt. pull request revisions. No és estrany que els equips ho marquin com a "massa sorollós" o que hi confiïn implícitament sense una anàlisi profunda.
Els atacants ho saben. Hi confien. Un cop paquet maliciós es fa referència, gràcies a una errada tipogràfica a paquet.json, bloqueig de paquet.json registra la versió resolta. Fins i tot si l'error tipogràfic es corregeix més tard, l'entrada maliciosa pot persistir tret que el fitxer de bloqueig es regeneri explícitament.
Per empitjorar les coses, la fixació de versions, que se suposa que garanteix la coherència, pot ser contraproduent. Els atacants poden versionar el seu paquet fals de manera idèntica al legítim. Si el CI/CD Si el sistema confia cegament en les versions fixades, no detectarà que està instal·lant un paquet amb un número de versió conegut com a correcte però d'una font diferent i maliciosa.
Aquesta persistència silenciosa és el que fa package-lock.json tan perillós. Assegura compilacions deterministes, sí, però també garanteix que un paquet defectuós es mantingui a menys que es detecti i es netegi manualment.
CI/CDOn afecta el programari maliciós – package.json
En un típic CI/CD pipeline, el paquet maliciós no necessita esperar fins al temps d'execució. Es resol i s'activa molt abans en el flux:
Resolució de dependències
L' pipeline extreu les versions exactes de la dependència de package-lock.json, que ara inclou la paquet typosquatted a causa de l'error tipogràfic a paquet.json.
Fase d'instal·lació
Durant l'execució de npm, s'instal·len totes les dependències, inclosa la maliciosa. Sense avisos, sense indicacions, només instal·lació silenciosa.
Execució de scripts posteriors a la instal·lació
El paquet similar inclou un script de postinstal·lació que s'executa automàticament un cop finalitzada la instal·lació. Aquí és on es produeix el compromís.
Exemple de pseudocodi:
if (installation_phase_active) {
runHiddenPayload()
}
Descripció del pseudocodi:
Durant la fase d'instal·lació, si el ganxo del cicle de vida posterior a la instal·lació és present, el paquet fals activa la seva lògica oculta, sovint abans que s'executin les compilacions o les proves. Això pot implicar fer sol·licituds externes, injectar portes del darrere o altres accions no autoritzades.
⚠️ Avís: Aquest pseudocodi és només per a fins demostratius i no s'ha d'utilitzar en entorns reals.
No s'activa cap alerta. Res falla. L'entorn ja està compromès, abans que el vostre pipeline fins i tot arriba a la fase de proves.
Trobar la diferència abans que sigui massa tard
Un error comú: suposar paquet.json explica tota la història. No ho fa. El veritable poder rau en la combinació de paquet.json + paquet-lock.json.
Això és el que cal cercar:
- Fa el package-lock.json incloure paquets inesperats?
- Hi ha dependències que provenen de registres desconeguts o que tenen àmbits estranys?
- Els números de versió són massa específics o estan mal alineats?
Utilitzeu eines CLI com ara:
- auditoria npm per marcar problemes coneguts
- npm ls per veure l'arbre de dependències complet
- dif per comparar versions entre paquet.json i package-lock.json
Endurir el vostre Pipeline: Defenses que funcionen
Per defensar-se contra el typosquatting:
- Aplicar restriccions d'abast a paquet.json.
- Afegeix una precombinació hooks per lint i validar dependències.
- Ús npm ci per evitar la deriva involuntària de versions.
- Escaneja regularment package-lock.json per anomalies.
I el més important: tractar les entrades no verificades a package-lock.json com a riscos potencials. Cada commit s'ha de tractar com un punt de control de la cadena de subministrament.
Detecció automatitzada: com ajuden eines com Xygeni
Tot i que no són una solució milagrosa, eines automatitzades com ara Xígeni tenen un paper fonamental en la reducció del factor d'error humà en què prospera el typosquatting. Xygeni s'integra directament al flux de treball de DevOps, afegint una capa de protecció en temps real contra el segrest de dependències abans que arribi a l'execució.
Així és com ajuda Xygeni:
- Detecció de noms de paquets sospitosos:
Utilitza heurístiques intel·ligents per detectar patrons de typosquatting en paquet.json, buscant variacions menors en noms de paquets coneguts (com ara subratllats afegits, transposicions o intercanvis de lletres). - Verificació de hash desconegut:
Compara el hash de cada dependència de package-lock.json contra una base de dades d'artefactes coneguts com a vàlids de registres de confiança. Fins i tot si un nom i una versió de paquet semblen correctes, una discrepància de hash fa aixecar un senyal d'alerta. - Bloqueig abans de la compilació:
Intercepta i bloqueja la instal·lació de qualsevol paquet no verificat o sospitós abans que arribin a les fases d'instal·lació o postinstal·lació del CI/CD pipeline. - Anàlisi de grafs de dependències:
Inspecciona contínuament tot l'arbre de dependències per detectar intents de typosquatting indirecte o dependències transitives malicioses. - Alertes i informes:
Proporciona alertes detallades i accionables que mostren què s'ha marcat, per què i d'on prové a la cadena de dependències.
A mesura que els ecosistemes de paquets es tornen més complexos, eines com Xygeni esdevenen essencials. La revisió manual no s'escala amb l'expansió de dependències o la iteració ràpida. Xygeni intervé per automatitzar les comprovacions crítiques modernes. pipelines necessitat, tancant la bretxa entre la confiança i la verificació.
Un personatge. Conseqüències reals.
Això no era exòtic dia zeroEra una errada tipogràfica. Un caràcter mal col·locat a paquet.json, reforçat silenciosament per package-lock.json, i el programari maliciós es va enviar automàticament durant una rutina CI/CD correr.
Aquest és el veritable perill de la typosquatting: no necessita complexitat. Explota la velocitat, la confiança i l'automatització. Aquest compromís s'hauria pogut evitar amb els controls adequats:
- Escaneig automatitzat per detectar noms i versions de paquets sospitosos abans de la instal·lació.
- Auditoria de fitxers de bloqueig per detectar entrades no revisades o inesperades a package-lock.json.
- Heurística de verificació de noms per marcar coincidències quasi exactes amb paquets de confiança.
Només calia un caràcter. Les proves adequades l'haurien aturat abans que toqués el teu pipelineLa confiança no és suficient. En els DevSecOps moderns, o ho verifiques tot o ho arrisques tot.
