R-CON
confused
CLI en Go que compara el manifiesto de dependencias de un proyecto con los registros públicos para marcar paquetes secuestrables por dependency confusion.
Sitio oficialVolver al catálogo
RESUMEN
confused (github.com/visma-prodsec/confused), escrito en Go por Joona Hoikkala en Visma, automatiza la comprobación detrás de la clase de ataque dependency confusion popularizada públicamente en 2021: lee el manifiesto de dependencias de un proyecto — package.json para npm, requirements.txt para pip, composer.json, un pom.xml de Maven o un Gemfile — y busca cada nombre de paquete listado en el registro público correspondiente.
Cualquier nombre de paquete de aspecto interno que no resuelva a nada en el registro público se marca como candidato: si el tooling de build interno de una empresa alguna vez resuelve ese mismo nombre desde el registro público en vez del privado previsto — una mala configuración común —, un atacante que publique públicamente un paquete con el mismo nombre puede lograr que se instale y ejecute dentro del pipeline de build de la empresa. confused solo reporta el hueco; no publica nada por sí mismo.
CASOS DE USO
Casos de uso en un engagement
- 01
Escanear el package.json, requirements.txt u otro manifiesto de un cliente en busca de nombres de paquete internos ausentes en el registro público.
- 02
Auditar varios ecosistemas (npm, PyPI, RubyGems, Maven, Composer) en una sola pasada sobre un monorepo.
- 03
Alimentar una sección de cadena de suministro del informe con nombres de paquete concretos que necesitan scoping en registro privado o reclamo de namespace.
- 04
Ejecutarlo como chequeo periódico de CI para detectar una dependencia nueva de aspecto interno antes de que se publique.
PRIMEROS PASOS
Durante el recon del código o la configuración de CI de un cliente, para marcar nombres de paquete de aspecto interno sin entrada en el registro público que podrían ser ocupados.
- Consigue el/los manifiesto(s) de dependencias del cliente — package.json, requirements.txt, etc. — dentro del alcance de revisión.
- Instala confused con go install o un binario de release ya compilado.
- Ejecútalo contra el manifiesto con el flag -l fijado al ecosistema correspondiente.
- Revisa los nombres de paquete marcados que no tienen coincidencia en el registro público.
- Recomienda scoping en registro privado o reclamo defensivo de namespace para cada paquete marcado — nunca intentes publicar tú mismo un paquete con el mismo nombre.
confused -l npm package.jsonANTES DE USARLA
Qué revisar antes de lanzarla
Un nombre de paquete marcado es un riesgo candidato, no una vulnerabilidad confirmada — también depende de cómo esté configurado el tooling de build del cliente para resolver scopes privados, algo que confused no prueba directamente.
Nunca registres ni publiques de verdad un paquete con un nombre marcado en un registro público sin autorización explícita por escrito — hacerlo afecta a un registro público compartido y a otros usuarios, no solo al cliente, y puede disparar instalaciones reales fuera del engagement.
Los archivos de manifiesto pueden referenciar por diseño paquetes privados con scope de organización (p. ej. el scoping @org/ de npm); confirma que un flag es un riesgo de confusión genuino antes de reportarlo, no un scope privado intencional.