Ya hemos escrito antes sobre el ecosistema Packagist de PHP.
Al igual que PyPI para los Pythonistas, Gems para los fans de Ruby, NPM para los programadores de JavaScript o LuaRocks para los Luáfilos, Packagist es un repositorio donde los colaboradores de la comunidad pueden publicar detalles de los paquetes PHP que han creado.
Esto facilita que otros programadores PHP se hagan con código de bibliotecas que quieran utilizar en sus propios proyectos, y que lo mantengan actualizado automáticamente si lo desean.
A diferencia de PyPI, que proporciona sus propios servidores donde se almacena el código real de la biblioteca (o LuaRocks, que a veces almacena el propio código fuente del proyecto y a veces enlaza con otros repositorios), Packagist enlaza con el código que necesitas descargar, pero no conserva copias del mismo.
Hacerlo así tiene sus ventajas, sobre todo que los proyectos que se gestionan a través de servicios de código fuente bien conocidos, como GitHub, no necesitan mantener dos copias de sus versiones oficiales, lo que ayuda a evitar el problema de la “deriva de versiones” entre el sistema de control del código fuente y el sistema de empaquetado.
Y hay un inconveniente, sobre todo que inevitablemente hay dos formas distintas de que los paquetes puedan ser objeto de trampas.
El propio gestor de paquetes podría ser pirateado, y bastaría con cambiar una sola URL para desviar a los usuarios del paquete.
O el repositorio de código fuente al que está vinculado podría ser pirateado, de modo que los usuarios que siguieran lo que parecía la URL correcta, acabarían de todos modos con contenido falso.
Cuentas antiguas consideradas dañinas
Este ataque (lo llamaremos así, aunque el ciberdelincuenteen cuestión no publicó ningún código trampa) utilizó lo que podríamos llamar un enfoque híbrido.
El atacante encontró cuatro cuentas antiguas e inactivas de Packagist para las que había conseguido de algún modo las contraseñas de acceso.
A continuación, identificó 14 proyectos de GitHub a los que estaban vinculadas estas cuentas inactivas y los copiaron a una cuenta de GitHub recién creada.
Por último, modificaron los paquetes del sistema Packagist para que apuntaran a los nuevos repositorios de GitHub.
Clonar proyectos de GitHub es increíblemente común. A veces, los desarrolladores quieren crear una auténtica bifurcación (versión alternativa) del proyecto bajo una nueva dirección, u ofreciendo características diferentes; otras veces, los proyectos bifurcados parecen copiarse por lo que podría llamarse, de forma poco halagadora, “razones volumétricas”, haciendo que las cuentas de GitHub parezcan más grandes, mejores, más ocupadas y más comprometidas con la comunidad (si me permites el juego de palabras) de lo que realmente son.
Aunque el ciberdelincuentepodría haber insertado código malicioso en la fuente PHP clonada de GitHub, como añadir rastreadores, keyloggers, puertas traseras u otro malware, parece que lo único que cambiaron fue un único elemento en cada proyecto: un archivo llamado composer.json.
Este archivo incluye una entrada titulada description, que suele contener exactamente lo que esperarías ver: una cadena de texto que describe para qué sirve el código fuente.
Y eso es todo lo que nuestro hacker modificó, cambiando el texto de algo informativo, como Proyecto PPP implementa el protocolo QQQ para que puedas RRR, para que sus proyectos en cambio informaran:
Pwned by XXX@XXXX.com. Ищу работу на позиции Application
Security, Penetration Tester, Cyber Security Specialist.
La segunda frase, escrita mitad en ruso y mitad en inglés, significa: Busco trabajo en Seguridad de Aplicaciones… etc.
No podemos hablar por todos, pero en lo que respecta a los CV, este no nos pareció muy convincente.
Además, el equipo de Packagist afirma que ya se han revertido todos los cambios no autorizados, y que los 14 proyectos clonados de GitHub no habían sido modificados más que para incluir la solicitud de empleo del propietario.
Por si sirve de algo, la cuenta de GitHub del supuesto experto en seguridad de aplicaciones sigue activa, y todavía tiene esos proyectos “bifurcados”.
No sabemos si GitHub aún no ha eliminado la cuenta o los proyectos, o si el sitio ha decidido no eliminarlos.
Al fin y al cabo, bifurcar proyectos es algo habitual y permisible (cuando las condiciones de licencia lo permiten, al menos), y aunque describir un proyecto de código no malicioso con el texto Pwned by XXXX@XXXX.com es poco útil, difícilmente es ilegal.
¿Qué hacer?
- No lo hagas. Definitivamente no vas a atraer el interés de ningún empleador legítimo, y (si somos sinceros) tampoco vas a impresionar a ningún ciberdelincuente.
- No dejes activas las cuentas que no utilices si puedes evitarlo. Como dijimos con motivo del Día Mundial de las Contraseñas, considera la posibilidad de cerrar las cuentas que ya no necesites, porque cuantas menos contraseñas tengas en uso, menos habrá para que te las roben.
- No reutilices contraseñas en más de una cuenta. Packagist supone que las contraseñas de las que se abusó en este caso se encontraban en los registros de violación de datos de otras cuentas en las que las víctimas habían utilizado la misma contraseña que en su cuenta de Packagist.
- No olvides tu 2FA. Packagists insta a todos sus usuarios a que activen el 2FA, de modo que una contraseña por sí sola no sea suficiente para que un atacante acceda a tu cuenta, y recomienda hacer lo mismo también en tu cuenta de GitHub.
- No aceptes las actualizaciones de la cadena de suministro sin revisar si son correctas. Si tienes una complicada red de dependencias de paquetes, es tentador dejar de lado tus responsabilidades y dejar que el sistema busque todas las actualizaciones automáticamente, pero eso solo te pone a ti y a tus usuarios intermedios en un riesgo adicional.