Investigador secuestró populares paquetes de PHP para “conseguir trabajo”

Un investigador secuestró más de una docena de paquetes de Packagist, y algunos se instalaron cientos de millones de veces a lo largo de su vida.

El investigador afirmó que al secuestrar estos paquetes espera conseguir un trabajo. Y parece bastante seguro de que esto funcionaría.

Al menos 14 paquetes de Packagist secuestrados

Ayer, un investigador con el seudónimo ‘neskafe3v1‘ se comunicó con BleepingComputer y le dijo que se había apoderado de catorce paquetes de Packagist, uno de los cuales tenía más de 500 millones de instalaciones.

Packagist es el registro principal de paquetes PHP que se pueden instalar a través de Composer, una herramienta de administración de dependencias. Sin embargo, en lugar de alojar estos paquetes, Packagist sirve más como un directorio de metadatos que agrega paquetes de código abierto publicados en GitHub. Luego, los desarrolladores pueden instalar estos paquetes en sus máquinas ejecutando el comando composer install.

Los nombres de los paquetes secuestrados incluyen:

El investigador proporcionó pruebas demostrando que el lunes 1 de mayo, las páginas de Packagist para estos paquetes se modificaron para apuntar al repositorio (falso) del investigador, a diferencia del repositorio legítimo de GitHub para cada paquete.

Como ejemplo, así es como apareció la página de Packagist para el paquete  acmephp el lunes, con su enlace de GitHub cambiado al repositorio del investigador en lugar del auténtico github.com/acmephp/acmephp.

Estos cambios ahora han sido revertidos por el equipo de Packagist según lo verificado por diversos expertos.

Publicación de paquetes

El proceso de publicación en Packagist es un poco diferente al de los repositorios de código abierto como npm o PyPI. Un desarrollador, en lugar de cargar archivos binarios o versiones de software directamente en Packagist.org, simplemente crea una cuenta en Packagist.org y “envía” un enlace a su repositorio de GitHub para un paquete en particular. El rastreador de Packagist luego visita el repositorio proporcionado y agrega todos los datos para mostrarlos en la página de Packagist para ese paquete.

Cuando un desarrollador ejecuta Composer con los comandos ‘install’ o ‘update’, su instancia de Composer primero puede buscar la presencia de los paquetes localmente, de lo contrario, buscará este paquete de forma predeterminada en Packagist y recupera la URL de GitHub que aparece para ese paquete. Luego, el contenido del paquete se descarga de este repositorio de GitHub que aparece en la página de Packagist del paquete.

Esto contrasta marcadamente con el funcionamiento de npm o PyPI, es decir, estos registros alojan y distribuyen versiones de software directamente desde sus servidores.

Al modificar la página de Packagist para cada uno de estos paquetes, el investigador secuestró efectivamente el flujo de trabajo de instalación utilizado en los entornos de Composer. Los desarrolladores ahora obtendrían el contenido de un paquete del repositorio de GitHub de neskafe3v1, en lugar del repositorio del proyecto.

Para mantener la demostración al mínimo, el investigador simplemente cambió el archivo composer.json, algo similar a un manifiesto de aplicación, dentro de estos paquetes para que diga:

“Pwned by neskafe3v1…. Busco trabajo como analista de seguridad de aplicaciones, pentester, especialista en seguridad cibernética”.

“Ataque”

Lo hizo bifurcando el repositorio del proyecto original, modificando el campo “description” dentro de composer.json y enviando el cambio a su repositorio bifurcado. En ningún momento volvió a fusionar los cambios en el repositorio original (hacerlo habría requerido acceso adicional y posiblemente habría invitado al escrutinio de los mantenedores).

En cambio, el investigador aparentemente obtuvo acceso a las cuentas de Packagist de los mantenedores y cambió las URLs de GitHub de los paquetes listados a los de sus repositorios bifurcados. Sin embargo, no reveló el método exacto que utilizó para secuestrar. 

Cuando se le presionó para que revelara la técnica exacta que él había usado para secuestrar estos paquetes, él dijo que no se trataba de una técnica de día cero sino de una técnica conocida. Pero también no dijo si el secuestro se logró, por ejemplo, mediante el compromiso de las credenciales, la toma de control de la  dirección de correo electrónico del mantenedor debido a que el dominio caducó u otra técnica más:

“Como puedes ver, estoy buscando trabajo (ese mensaje ‘Ищу работу на позиции…’ significa ‘Estoy buscando trabajo…’), así que divulgaré un informe después de que sea contratado por alguna empresa”, dijo el investigador. Él comparó toda la campaña de secuestro con “un anuncio de mí mismo como empleado”.

“Hasta que no haya éxito, no hay nada de qué hablar”.

Secuestrado a través de compromiso de credenciales

En respuesta al incidente, el equipo de Packagist dijo que hasta el momento no habían observado ningún impacto malicioso en la plataforma como resultado de esta acción. Asimismo, confirmaron que la toma de control resultó del compromiso de las credenciales de las cuentas del mantenedor.

“Hasta donde sabemos, esto no se ha utilizado con fines maliciosos y se limitó a algunas cuentas antiguas con contraseñas inseguras y falta de autenticación de 2 factores“.

Nils Aderman de Packagist.org

Es importante mencionar que Nils Aderman también es uno de los desarrolladores originales de Composer.

“Parece que las cuatro cuentas han estado usando contraseñas compartidas filtradas en incidentes anteriores en otras plataformas.  Por favor, no reutilices las contraseñas”, advirtió a los administradores de Packagist.

“El 2 de mayo, a las 7:21 am UTC, Juha Suni nos notificó sobre el cambio de URLs a varios paquetes de Doctrine”.

Explicación de los administradores en una publicación realizada hoy.

Trabajando junto con Marco Pivetta, también conocido como Ocramius, los administradores de Packagist identificaron rápidamente todas las cuentas a las que se accedió, deshabilitaron el acceso a ellas y restauraron las URLs de GitHub a sus valores anteriores. El esfuerzo de restauración se completó el martes por la mañana.

Sin abusos

El investigador también aseguró que no había abusado de la técnica para distribuir malware, pero al mismo tiempo dijo que no había notificado ni a Packagist ni a los propietarios del paquete sobre el pequeño experimento. Esto sorprende con respecto a la naturaleza ‘ética’ de esta investigación.

“Lo único que hice: modifiqué el campo ‘description” en los archivos composer.json“, dijo el investigador y señaló pruebas como las confirmaciones de Git.

“Acabo de cambiar el enlace de  github.com/acmephp/core  (original) a… mi bifurcación. No hay malware, puedes comparar los archivos originales con los míos. No notifiqué a nadie sobre el ataque, ni administradores de Packagist, ni propietarios de paquetes”.

En la publicación, los administradores de Packagist solicitan que los investigadores informen errores y vulnerabilidades de manera responsable.

“Si eres un investigador de seguridad y conoces una vulnerabilidad de Packagist.org o te gustaría investigar sobre Packagist.org, te pedimos que coordines las pruebas con nosotros para evitar un impacto negativo en el usuario y que divulgues estas vulnerabilidades de manera responsable ” .

“Puedes comunicarte con nosotros en security@packagist.org y responderemos de inmediato a todas las solicitudes o informes. Por supuesto, brindamos crédito y publicamos detalles de las vulnerabilidades informadas…”