El repositorio de código abierto PyPI sufre una oleada de malware

Los repositorios públicos de código fuente, desde Sourceforge a GitHub, desde Linux Kernel Archives a ReactOS.org, desde PHP Packagist a Python Package Index, más conocido como PyPI, son una fuente fantástica de sistemas operativos, aplicaciones, bibliotecas de programación y conjuntos de herramientas para desarrolladores gratuitos que han hecho bien a la informática.

La mayoría de los proyectos de software necesitan código “auxiliar” que no es una parte fundamental del problema que el propio proyecto intenta resolver, como funciones de utilidad para escribir en el registro del sistema, producir salidas de colores, subir informes de estado a un servicio web, crear archivos de copia de seguridad de datos antiguos, etc.

En casos así, puedes ahorrar tiempo (y beneficiarte gratuitamente de la experiencia de otras personas) buscando un paquete que ya exista en uno de los muchos repositorios disponibles, y enganchando ese paquete externo a tu propio árbol de código fuente.

En la otra dirección, si estás trabajando en un proyecto propio que incluye algunas utilidades que no puedes encontrar en ningún otro sitio, puede que te sientas inclinado a ofrecer algo a la comunidad empaquetando tu código y poniéndolo gratuitamente a disposición de todos los demás.

El coste de la gratuidad

Sin embargo, como  sabrás, los repositorios comunitarios de código fuente conllevan una serie de retos de ciberseguridad:

• Paquetes populares que desaparecen de repente. A veces, los paquetes que un programador bienintencionado ha donado a la comunidad se hacen tan populares que se convierten en una parte fundamental de miles o incluso cientos de miles de proyectos más grandes que los dan por sentados. Pero si el programador original decide retirarse de la comunidad y borrar sus proyectos (cosa que tiene todo el derecho a hacer si no tiene obligaciones contractuales formales con nadie que haya decidido confiar en ellos), los efectos secundarios pueden ser temporalmente desastrosos, ya que los proyectos de otras personas se “actualizan” de repente a un estado en el que falta una parte necesaria de su código.
• Proyectos que son secuestrados activamente con fines maliciosos. Los ciberdelincuentes que adivinan, roban o compran contraseñas de proyectos ajenos pueden inyectar malware en el código, y cualquiera que ya confíe en el paquete antaño inocente se infectará involuntariamente a sí mismo (y quizás a sus propios clientes) con malware si descarga automáticamente la “actualización” fraudulenta. Los delincuentes pueden incluso apoderarse de viejos proyectos utilizando trucos de ingeniería social, uniéndose al proyecto y mostrándose realmente serviciales durante un tiempo, hasta que el mantenedor original decida confiarles el acceso a la carga.
• Paquetes maliciosos que se hacen pasar por inocentes. Los delincuentes suelen subir paquetes con nombres lo suficientemente parecidos a proyectos conocidos como para que otros usuarios los descarguen y utilicen por error, en un ataque conocido como typosquatting. (El mismo truco funciona con los sitios web, con la esperanza de que un usuario que escriba mal una URL, aunque sea ligeramente, acabe en un sitio falso que se le parezca). Por lo general, los delincuentes clonan primero el paquete auténtico, de modo que sigue realizando todas las funciones del original, pero con algún comportamiento malicioso adicional enterrado en lo más profundo del código.
• Comportamiento mezquino de los llamados “investigadores”. Lamentablemente, hemos tenido que escribir varias veces sobre este tipo de comportamiento probablemente legal, pero éticamente dudoso. Algunos ejemplos son un estudiante de doctorado estadounidense y su supervisor que subieron deliberadamente parches falsos al núcleo de Linux como parte de un experimento no autorizado que el equipo principal de Linux tuvo que resolver, y un “experto” interesado con el apodo de Supply Chain Risks que subió un proyecto falso con trampas explosivas al repositorio PyPI para recordar el riesgo de los llamados ataques a la cadena de suministro. SC Risks siguió su paquete de “investigación” de prueba de concepto con otros 3950 paquetes, dejando al equipo de PyPI la tarea de encontrarlos y borrarlos todos.

Contribuidores deshonestos

Desgraciadamente, parece que PyPI se ha visto afectada por un montón de subidas automatizadas y fraudulentas durante el pasado fin de semana.

El equipo, quizás comprensiblemente, aún no ha dado detalles de cómo se llevó a cabo el ataque, pero el sitio bloqueó temporalmente el registro de nuevos usuarios y la creación de nuevos proyectos por parte de los usuarios existentes:

El registro de nuevos usuarios y nuevos nombres de proyectos en PyPI está temporalmente suspendido. El volumen de usuarios maliciosos y proyectos maliciosos que se han creado en el índice en la última semana ha superado nuestra capacidad de responder a tiempo, especialmente con varios administradores de PyPI de baja.

Mientras nos reagrupamos durante el fin de semana, se suspende temporalmente el registro de nuevos usuarios y nuevos proyectos. [2023-05-20T16:02:00Z]

Suponemos que los atacantes utilizaron herramientas automatizadas para inundar el sitio con paquetes maliciosos, presumiblemente con la esperanza de que, si se esforzaban lo suficiente, parte del contenido malicioso escaparía a la detección y quedaría incluso después de los esfuerzos de limpieza del sitio, completando así lo que podríamos llamar un Ataque de Anulación de Seguridad, o tal vez que los administradores del sitio se sintieran obligados a desconectar todo el sitio para solucionarlo, provocando así un Ataque de Denegación de Servicio, o DoS.

La buena noticia es que, en poco más de 24 horas, el equipo se hizo cargo del problema y pudo anunciar: “Se ha levantado la suspensión”.

En otras palabras, aunque PyPI no funcionó al 100% durante el fin de semana, no hubo una verdadera denegación de servicio contra el sitio o sus millones de usuarios.

¿Qué hacer?

• No elijas un paquete del repositorio solo porque el nombre parezca correcto. Comprueba que realmente estás descargando el módulo correcto del editor correcto. Incluso los módulos legítimos tienen a veces nombres que chocan, compiten o confunden.
• No descargues ciegamente actualizaciones de paquetes en tus propios sistemas de desarrollo o compilación. Prueba y revisa todo lo que descargues antes de aprobar su uso. Recuerda que los paquetes suelen incluir scripts de actualización que se ejecutan cuando realizas la actualización, por lo que las infecciones de malware podrían llegar a través del propio proceso de actualización, no como parte del código fuente del paquete.
• No facilites a los atacantes la entrada en tus propios paquetes. Elige contraseñas adecuadas, utiliza 2FA siempre que puedas y no confíes ciegamente en los recién llegados a tu proyecto en cuanto empiecen a pedir acceso como mantenedores, por mucho que estés dispuesto a ceder las riendas a otra persona.
• No seas un sabelotodo. Como esta historia nos recuerda a todos, los voluntarios de la comunidad del código abierto ya tienen suficientes problemas con los auténticos ciberdelincuentes como para tener que lidiar con “investigadores” que realizan ataques de prueba de concepto para su propio beneficio, ya sea con fines académicos o para presumir (o ambas cosas).