Más de 100,000 repositorios infectados descubiertos en GitHub

Más de 100,000 repositorios infectados descubiertos en GitHub

• Un equipo de investigación en seguridad y ciencia de datos detectó el resurgimiento a gran escala de una campaña maliciosa de confusión de repositorios que comenzó a mediados del año pasado.
• Este ataque afecta a más de 100,000 repositorios de GitHub (y se estima que a millones), cuando los desarrolladores usan repositorios que parecen similares a otros conocidos y confiables, pero que en realidad contienen código malicioso.

¿Cómo ocurre un ataque de confusión de repositorios?

• Un ataque de confusión de repositorios es similar a un ataque de confusión de dependencias, ya que los actores maliciosos logran que el objetivo descargue una versión maliciosa en lugar de la versión legítima.
• Mientras que los ataques de confusión de dependencias aprovechan la forma en que funcionan los gestores de paquetes, los ataques de confusión de repositorios dependen de que las personas elijan por error la versión maliciosa en lugar de la legítima, a veces usando también técnicas de ingeniería social.

Qué sucede cuando se usa un repositorio malicioso

• Cuando los desarrolladores usan sin sospechar un repositorio malicioso, una carga oculta deshace 7 capas de ofuscación y descarga código malicioso en Python, seguido posteriormente por ejecutables binarios.
• El malware recopila credenciales de inicio de sesión de varias aplicaciones, contraseñas y cookies del navegador, y otros datos confidenciales, para enviarlos al servidor C&C del actor malicioso y realizar actividades maliciosas adicionales.

Impacto de la automatización en GitHub

• La mayoría de los repositorios bifurcados son eliminados rápidamente por GitHub, pero la detección automatizada pasa por alto muchos repositorios y los que se suben manualmente sobreviven.
• Como toda la cadena del ataque está mayormente automatizada a gran escala, incluso el 1% que sobrevive sigue representando miles de repositorios maliciosos.

Cuándo comenzó la campaña

• Mayo de 2023: según lo reportado inicialmente por Phylum, varios paquetes maliciosos que incluían la parte inicial de la carga actual se subieron a PyPI.
• Julio - agosto de 2023: después de que PyPI eliminó los paquetes maliciosos y la comunidad de seguridad puso más atención en ese ecosistema, varios repositorios maliciosos fueron subidos a GitHub; esta vez entregaban la carga directamente en lugar de descargarla desde paquetes de PyPI.
• Noviembre de 2023 - presente: se han detectado más de 100,000 repositorios que contienen cargas maliciosas similares, y el número sigue aumentando.

Cambio del malware desde los gestores de paquetes hacia la gestión de código fuente (SCM)

• A partir de muchos incidentes observados tanto en gestores de paquetes como en plataformas SCM, este cambio de paquetes maliciosos en PyPI a repositorios maliciosos en GitHub parece reflejar una tendencia general.

Cómo protegerte contra la confusión de repositorios

• Aunque se notificó a GitHub y la mayoría de los repositorios maliciosos ya fueron eliminados, la campaña continúa y los ataques que intentan inyectar código malicioso en la cadena de suministro son cada vez más comunes.
• En Apiiro se construyó un sistema de detección de malware para monitorear codebases conectados.
• Para detectar ataques se usan diversas técnicas avanzadas, incluidas análisis de código basados en LLM, descomposición del código en un grafo completo de flujo de ejecución, un motor heurístico sofisticado, decodificación dinámica, descifrado y desofuscación.

Opinión de GN⁺

• Este artículo ofrece información importante para alertar a los desarrolladores sobre amenazas de seguridad que deben considerar al usar repositorios de GitHub.
• Al entender cómo el código malicioso penetra en la cadena de suministro de software, los desarrolladores y profesionales de seguridad pueden construir mecanismos de defensa más sólidos.
• Estos ataques resaltan no solo la capacidad de los desarrolladores para elegir repositorios confiables, sino también la dependencia de la exactitud de las configuraciones de CI/CD y de la seguridad del código de terceros.
• Desde una perspectiva crítica, estos ataques muestran que los sistemas automatizados de plataformas como GitHub y la existencia de repositorios a gran escala pueden ser un arma de doble filo.
• Algunas herramientas de seguridad con funciones similares son SonarQube, Snyk y WhiteSource, que pueden ayudar a detectar vulnerabilidades en el código y reforzar la seguridad.
• Antes de adoptar esta tecnología, es necesario considerar la compatibilidad con las políticas de seguridad de la organización, el costo de implementación y las capacidades técnicas del equipo.
• Entre los beneficios de elegir esta tecnología están una mayor seguridad y la reducción de riesgos, aunque posibles desventajas incluyen la curva de aprendizaje de un sistema nuevo y la complejidad de su gestión.

[GN⁺]

Comentarios de Hacker News

• Hay que tener cuidado al obtener código de repositorios públicos, y es importante verificar el árbol de dependencias. Esto plantea la pregunta de qué impacto puede tener el malware en repositorios públicos sobre herramientas automatizadas como los modelos de lenguaje grandes (Large Language Models, LLMs). Por ejemplo, existe la posibilidad de que herramientas como GitHub Copilot incluyan malware por error en sus respuestas a preguntas de programación.
• Se señala que GitHub está fallando de la misma manera en que fracasó Usenet. Cualquiera puede crear un repositorio en GitHub, y no hay forma de distinguir entre un repositorio oficial y uno de spammers. Cuando Amazon aspiró a ser "la tienda que vende de todo", se encontró con el problema de que la mayoría de los productos eran basura. GitHub necesita definir su identidad: si es un "repositorio para todos" o si responde a la pregunta de "¿se puede confiar en este código?".
• Se lamenta que el problema de la cadena de suministro es grave. Aunque no apunta a lanzamientos de npm, usa socket.dev para monitorear proyectos. El proyecto BrowserBox usa alrededor de 800 dependencias, de las cuales 19 son dependencias de nivel superior. Está considerando hacer snapshots de todas las dependencias bajo el namespace @browserbox de npm para rastrear vulnerabilidades y aplicar parches.
• Se enfatiza que los desarrolladores deberían separar al menos tres entornos: trabajo, hobby y uso personal. Incluso con repositorios y propietarios confiables, es prudente ejecutar el código en una máquina virtual sandbox.
• Si se desarrolla un SDK con muchas descargas semanales en un equipo pequeño, se están evaluando soluciones basadas en snyk, aikido.dev y renovate, entre otras. No está claro si estas herramientas ayudarán a resolver el problema, y manejar muchos falsos positivos, como ocurrió con snyk, es difícil.
• Se expresa curiosidad sobre si la forma de instalación con scripts de shell usando curl y sudo pronto llegará a su fin. Este método está estrechamente relacionado con el software infectado mencionado en el artículo.
• En npm se puede usar la opción --ignore-scripts para evitar la ejecución de malware.
• Se menciona que hubo un repositorio con un virus troyano hace menos de un año.
• Se critica que una publicación reciente sobre problemas de seguridad termine en un anuncio para financiar startups de LLM. Estas startups solo pueden resolver una parte de las brechas de seguridad, y firmar contratos con muchas startups puede generar problemas de costos e integración.
• Se está mejorando gradualmente la seguridad del entorno de desarrollo en respuesta a reportes continuos de seguridad. Se están probando contenedores de desarrollo de VSCode, GitHub Codespaces, la lectura de guías de OWASP y revisiones de paquetes npm/python usando socket.dev.