Detecção de Confusão de Dependência

Aviso Legal: Esta habilidade destina-se apenas a testes de segurança autorizados, engenharia defensiva e fins educacionais. Registrar ou reivindicar namespaces de pacotes que você não possui, ou testar pipelines de build sem autorização por escrito, pode ser ilegal e violar os termos de serviço de registros públicos. Execute atividades de reivindicação de namespace ou teste de resolução apenas contra nomes e infraestrutura que você controla ou para os quais está explicitamente autorizado a avaliar.

Visão Geral

A confusão de dependência (também chamada de ataque de substituição ou sombreamento de namespace) foi popularizada por Alex Birsan em 2021, quando ele forçou código malicioso nos sistemas de build internos da Apple, Microsoft, PayPal e dezenas de outras empresas. A causa raiz é que muitos gerenciadores de pacotes, quando configurados para resolver de um registro interno/privado e um público, preferirão a cópia que tiver o número de versão mais alto em vez de honrar a origem. Um atacante que descobre o nome de um pacote interno (@acme/internal-utils, acme-billing-sdk) pode publicar um pacote malicioso com o mesmo nome no registro público (npmjs.com, PyPI, Maven Central) com uma versão muito alta (por exemplo, 99.0.0). Quando o runner de CI/CD da vítima ou uma máquina de desenvolvedor resolve as dependências, ele puxa o pacote público do atacante, executa seus scripts de instalação e a cadeia de suprimentos é comprometida.

Esta habilidade abrange ambas as partes do problema: detecção — enumerando nomes de pacotes internos que não estão registrados (reservados defensivamente) em registros públicos e, portanto, podem ser reivindicados, usando confused e OWASP dep-scan — e prevenção — fixando escopos/namespaces em registros privados, registrando pacotes de placeholder e aplicando restrições de origem em .npmrc, pip.conf/pyproject.toml e Maven settings.xml. Nomes de pacotes internos vazam constantemente: em lockfiles commitados, sourcemaps, bundles JS públicos, camadas Docker e rastros de pilha de erros, então isso é tratado como um problema de gerenciamento de superfície de ataque, não uma verificação única.

Quando Usar

• Ao integrar um repositório ou organização a um programa de segurança de cadeia de suprimentos e você precisa estabelecer uma linha de base de quais pacotes internos podem ser reivindicados em registros públicos.
• Quando pipelines de CI/CD resolvem dependências de registros privados e públicos (feeds mistos/híbridos).
• Após qualquer incidente em que nomes de pacotes internos possam ter sido expostos (código-fonte vazado, bundle público, repositório comprometido).
• Ao auditar arquivos package.json, requirements.txt, pom.xml, composer.json ou Gemfile.lock em busca de dependências confusas.
• Como um controle recorrente agendado para detectar pacotes internos recém-adicionados que ainda não foram registrados defensivamente.

Pré-requisitos

• Go 1.20+ para instalar confused:

  go install github.com/visma-prodsec/confused@latest
  # binary lands in $(go env GOPATH)/bin/confused
  

• Python 3.10+ para OWASP dep-scan:

  pip install owasp-depscan
  # or container: docker pull ghcr.io/owasp-dep-scan/dep-scan
  

• Node.js + npm (para remediação de .npmrc e npm config) e acesso ao seu registro privado (Artifactory, Nexus, Azure Artifacts, GitHub Packages, AWS CodeArtifact).
• Acesso de leitura aos repositórios / lockfiles que estão sendo avaliados e acesso de gravação ao seu registro privado para registro defensivo.

Objetivos

• Enumerar todas as dependências internas declaradas nos manifestos de projeto em npm, PyPI, Maven, Composer e RubyGems.
• Determinar quais nomes internos não estão presentes no registro público correspondente e, portanto, podem ser reivindicados.
• Distinguir exposição real de falsos positivos (pacotes com escopo, nomes já espelhados).
• Aplicar controles de fixação de registro e restrição de escopo que tornam a substituição pública impossível.
• Registrar defensivamente pacotes de placeholder para nomes internos não reivindicados.
• Estabelecer um controle de detecção recorrente em CI para capturar dependências confusas recém-introduzidas.

Mapeamento MITRE ATT&CK

…