Um erro de um caractere que enviou malware
Tudo começou com um erro de digitação. Em algum lugar na correria de lançamentos de recursos e fusões de RP, alguém digitou @utils_core em vez de @utils-core no package.json. Esse deslize de um único caractere não gerou um erro. Em vez disso, ele silenciosamente puxou um pacote malicioso semelhante durante o próximo CI/CD executar, alavancando a confiança em versões fixadas e automação. Bem-vindo ao mundo do typosquatting em código aberto.
Typosquatting: o vetor de ataque que prospera com o erro humano
Typosquatting é exatamente o que parece: agentes maliciosos registrando pacotes com nomes quase idênticos aos legítimos. Em ambientes de ritmo acelerado, isso funciona porque os desenvolvedores confiam que seus package.json e Pacote-lock.json Refletir o que eles esperam. Um caractere a menos? Poderia muito bem ser invisível em uma comparação de RP.
NPM tem um histórico de exploração por meio de typosquatting. Pacotes como crossenv em vez de ambiente cruzado or fluxo de eventos Backdoors já demonstraram a eficácia desses pacotes falsos. Esses pacotes falsos geralmente passam nas avaliações simplesmente porque parecem corretos e não geram erros de execução imediatos.
As armadilhas comuns incluem:
- Hífen vs sublinhado: lodash-core vs lodash_core
- Plurais: solicitar vs pedidos
- Caracteres substituídos: expresso em vez de expresso
Onde o package-lock.json se torna um ponto cego
O desenvolvedor corrige o erro de digitação. Ou pelo menos é o que eles pensam. Mas agora, Pacote-lock.json já bloqueou o pacote do invasor. E é aqui que reside o verdadeiro risco.
Diferentemente dos package.json, que é editado manualmente e recebe mais escrutínio, Pacote-lock.json é gerado automaticamente por NPM. Como resultado, muitas vezes é tratado como uma formalidade, ignorado ou apenas superficialmente pull request avaliações. Não é incomum que equipes o classifiquem como "muito barulhento" ou confiem nele implicitamente, sem uma análise aprofundada.
Os invasores sabem disso. Eles confiam nisso. Uma vez por pacote malicioso é referenciado, graças a um erro de digitação em pacote.json, pacote-lock.json registra a versão resolvida. Mesmo que o erro de digitação seja corrigido posteriormente, a entrada maliciosa pode persistir, a menos que o arquivo de bloqueio seja explicitamente regenerado.
Para piorar a situação, a fixação de versões, que supostamente garante consistência, pode sair pela culatra. Os invasores podem criar versões de seus pacotes falsos idênticas às do pacote legítimo. Se o CI/CD o sistema confia cegamente nas versões fixadas, ele não detectará que está instalando um pacote com um número de versão conhecido como bom, mas de uma fonte diferente e maliciosa.
Essa persistência silenciosa é o que faz Pacote-lock.json tão perigoso. Garante compilações determinísticas, sim, mas também garante que um pacote defeituoso permaneça, a menos que seja detectado e limpo manualmente.
CI/CD:Onde o Malware Chega – package.json
Em um típico CI/CD pipeline, o pacote malicioso não precisa esperar pelo tempo de execução. Ele é resolvido e acionado muito antes no fluxo:
Resolução de dependência
O processo de pipeline extrai as versões exatas de dependência de package-lock.json, que agora inclui o pacote typosquatted devido ao erro de digitação em pacote.json.
Fase de instalação
Durante o npm ci, todas as dependências são instaladas, incluindo a maliciosa. Sem avisos, sem prompts, apenas uma instalação silenciosa.
Execução do script pós-instalação
O pacote lookalike inclui um script de pós-instalação que é executado automaticamente após a conclusão da instalação. É aqui que o comprometimento acontece.
Exemplo de pseudocódigo:
if (installation_phase_active) {
runHiddenPayload()
}Descrição do pseudocódigo:
Durante a fase de instalação, se o gancho do ciclo de vida pós-instalação estiver presente, o pacote falso aciona sua lógica oculta — geralmente antes mesmo de compilações ou testes serem executados. Isso pode envolver solicitações externas, injeção de backdoors ou outras ações não autorizadas.
⚠️ Aviso: Este pseudocódigo é apenas para fins de demonstração e não deve ser usado em ambientes reais.
Nenhum alerta é acionado. Nada falha. O ambiente já está comprometido, antes mesmo de você pipeline chega até a fase de testes.
Identificando a diferença antes que seja tarde demais
Um erro comum: presumir package.json conta toda a história. Não conta. O verdadeiro poder está na combinação de pacote.json + pacote-lock.json.
Aqui está o que procurar:
- Faz o Pacote-lock.json incluir pacotes inesperados?
- Há alguma dependência originada de registros desconhecidos ou com escopos estranhos?
- Os números de versão são muito específicos ou desalinhados?
Use ferramentas CLI como:
- auditoria npm para sinalizar problemas conhecidos
- npm ls para visualizar a árvore de dependências completa
- diff para comparar versões entre package.json e Pacote-lock.json
Endureça seu Pipeline: Defesas que funcionam
Para se defender contra typosquatting:
- Aplicar restrições de escopo em pacote.json.
- Adicionar pré-mesclagem hooks para verificar e validar dependências.
- Uso npmci para evitar desvios de versão não intencionais.
- Faça uma varredura regularmente Pacote-lock.json para anomalias.
E o mais importante: trate as entradas não verificadas em Pacote-lock.json como riscos potenciais. Cada commit deve ser tratado como um ponto de verificação da cadeia de suprimentos.
Detecção automatizada: como ferramentas como o Xygeni ajudam
Embora não seja uma solução mágica, ferramentas automatizadas como Xygeni desempenham um papel fundamental na redução do fator de erro humano que alimenta o typosquatting. O Xygeni integra-se diretamente ao seu fluxo de trabalho de DevOps, adicionando uma camada de proteção em tempo real contra o sequestro de dependências antes mesmo de elas serem executadas.
Veja como o Xygeni ajuda:
- Detecção de nome de pacote suspeito:
Utiliza heurística inteligente para detectar padrões de typosquatting em package.json, procurando por pequenas variações em nomes de pacotes conhecidos (como sublinhados adicionados, transposições ou trocas de letras). - Verificação de Hash Desconhecida:
Compara o hash de cada dependência em Pacote-lock.json em um banco de dados de artefatos conhecidos e válidos de registros confiáveis. Mesmo que o nome e a versão de um pacote pareçam corretos, uma incompatibilidade de hash levanta um sinal de alerta. - Bloqueio antes da construção:
Intercepta e bloqueia a instalação de quaisquer pacotes não verificados ou suspeitos antes que eles cheguem às fases de instalação ou pós-instalação. CI/CD pipeline. - Análise de gráfico de dependência:
Inspeciona continuamente a árvore de dependências completa em busca de tentativas indiretas de typosquatting ou dependências transitivas maliciosas. - Alertas e relatórios:
Fornece alertas detalhados e acionáveis, mostrando o que foi sinalizado, por que e de onde veio na cadeia de dependência.
À medida que os ecossistemas de pacotes se tornam mais complexos, ferramentas como o Xygeni se tornam essenciais. A revisão manual não se adapta à expansão de dependências ou à iteração rápida. O Xygeni intervém para automatizar as verificações críticas modernas. pipelinenecessidade, fechando a lacuna entre confiança e verificação.
Um personagem. Consequências reais.
Isso não era exótico dia zero. Foi um erro de digitação. Um caractere errado em package.json, silenciosamente reforçado por Pacote-lock.json, e o malware foi enviado, automaticamente, durante uma rotina CI/CD executar.
Esse é o verdadeiro perigo do typosquatting: ele não precisa de complexidade. Ele explora velocidade, confiança e automação. Esse comprometimento poderia ter sido evitado com os controles corretos em vigor:
- Escaneamento Automatizado para detectar nomes e versões de pacotes suspeitos antes da instalação.
- Auditoria de Lockfile para detectar entradas não revisadas ou inesperadas em Pacote-lock.json.
- Heurística de verificação de nome para sinalizar correspondências próximas a pacotes confiáveis.
Bastou um personagem. As verificações corretas o teriam parado antes que tocasse em você pipelineConfiança não é suficiente. No DevSecOps moderno, você verifica tudo ou arrisca tudo.
