Miles de aplicaciones que han aprovechado los paquetes de software de código abierto Python Package Index (PyPI) pueden correr el riesgo de ser secuestradas y subvertidas por actores maliciosos, lo que abre la posibilidad de importantes ataques a la cadena de suministro que afecten a un número aún mayor de organizaciones y usuarios. Esto es según los investigadores de amenazas de jFrog, que identificaron la técnica que se está explotando en la naturaleza contra el paquete pingdomv3, parte del servicio de monitoreo de sitios web de la API Pingdom ampliamente utilizado, propiedad de SolarWinds, mientras monitoreaban el ecosistema de código abierto. El equipo ha denominado a la técnica Revival Hijacking. La técnica en sí es similar en sus fundamentos al typosquatting, donde los actores de amenazas se aprovechan de los errores ortográficos comunes para registrar dominios maliciosos. En el ataque Revival Hijack contra el paquete pingdomV3, un actor de amenazas no revelado aprovechó una característica de PyPl por la cual cuando un paquete se elimina o se quita del repositorio, su nombre queda inmediatamente disponible para su uso nuevamente. Como sugiere el nombre, esto significa que el paquete puede ser revivido y secuestrado de manera efectiva para fines nefastos. Brian Moussali, líder del equipo de investigación de malware de JFrog y coautor del informe resultante, afirmó que la técnica Revival Hijack era particularmente peligrosa por tres razones principales. En primer lugar, a diferencia del typosquatting, la técnica no depende de que la víctima cometa un error al instalar el paquete malicioso. En segundo lugar, actualizar un paquete seguro conocido a su última versión es una práctica común que muchos desarrolladores consideran mínima en cuanto a su riesgo, aunque ese no sea el caso. En tercer lugar, muchas máquinas CI/CD se configurarán para instalar actualizaciones de paquetes automáticamente. “Revival Hijack no es solo un ataque teórico: nuestro equipo de investigación ya lo ha visto explotado en la naturaleza. El uso de un comportamiento vulnerable en el manejo de paquetes eliminados permitió a los atacantes secuestrar paquetes existentes, lo que hizo posible instalarlos en los sistemas de destino sin ningún cambio en el flujo de trabajo del usuario”, dijo Moussali. “La superficie de ataque del paquete PyPI crece continuamente. A pesar de la intervención proactiva en este caso, los usuarios siempre deben permanecer alerta y tomar las precauciones necesarias para protegerse a sí mismos y a la comunidad PyPI de esta técnica de secuestro”. Moussali y su coinvestigador Andrey Polkovnichenko afirman que, basándose en un recuento aproximado de los paquetes PyPI eliminados, podrían haber sido secuestrados hasta 120.000. Si se filtran los que tienen menos de 100.000 descargas, los que no llevan mucho tiempo activos o los que son obviamente dudosos, la cifra sigue superando los 22.000. Y con una media de 309 proyectos PyPI eliminados cada mes, cualquiera que esté dispuesto a explotar la técnica Revival Hijack tiene un flujo constante de nuevas víctimas potenciales. ¿Qué pasó con pingdomV3? En el caso de pingdomV3, el propietario original del paquete, que parece haber seguido adelante, lo actualizó por última vez en abril de 2020 y luego se quedó en silencio hasta el 27 de marzo de 2024, cuando enviaron una breve actualización en la que les decían a los usuarios que evitaran usar el paquete porque estaba abandonado. Luego lo eliminaron el 30 de marzo, momento en el que apareció el nombre para su registro. Casi inmediatamente, un usuario con una dirección de Gmail publicó un paquete con el mismo nombre con un número de versión más reciente, afirmando que se trataba de un rediseño y apuntando a un repositorio de GitHub. Esta versión contenía el código estándar de pingdomV3, aunque el repositorio de GitHub vinculado en realidad nunca existió. Luego, el 12 de abril, los escáneres automáticos de jFrog detectaron una actividad extraña cuando el propietario introdujo una carga útil sospechosa ofuscada en Base64. Esto hizo sonar las alarmas y provocó la investigación y la posterior divulgación. PyPI eliminó el paquete por completo el 12 de abril, y se ha prohibido el uso de su nombre. La carga útil en sí parecía ser un malware troyano de Python diseñado para descubrir si se está ejecutando en una configuración de CI de Jenkins, en cuyo caso realiza una solicitud HTTP GET a una URL controlada por el atacante. El equipo de JFrog no pudo recuperar la carga útil final que esto habría entregado, lo que sugiere que el actor malicioso quería retrasar su ataque o lo estaba limitando a un rango de IP específico. En cualquier caso, fue frustrado. Preocupados por el alcance potencial del problema, Moussali y Polkovnichenko se propusieron secuestrar ellos mismos los paquetes abandonados más descargados y reemplazarlos con paquetes vacíos e inofensivos, todos con el número de versión 0.0.0.1 para asegurarse de que no se descargaran accidentalmente en actualizaciones automáticas. Al volver a comprobar después de unos días, descubrieron que sus paquetes PyPI vacíos se habían descargado más de 200.000 veces. Por supuesto, dado que los paquetes de reemplazo están vacíos, no es posible decir con mucha confianza que un actor malicioso podría haber logrado la ejecución del código cada vez, pero «sería muy seguro decir» que en la mayoría de los casos lo harían, dijo Moussali. La respuesta de PyPI Según jFrog, PyPI ha estado considerando un cambio de política sobre los paquetes eliminados que eliminaría esta laguna, pero por alguna razón no se ha llegado a ninguna conclusión al respecto en más de dos años de deliberación. Deja claro, al eliminarlo, que el nombre se liberará para que lo usen otros, y también evita que se eliminen versiones específicas de paquetes, de acuerdo con las recomendaciones de OpenSSF. Sin embargo, dijo Moussali, si bien esto es útil, el alcance potencial de la técnica Revival Hijack es tan amplio que se necesitan más acciones. «Recomendamos plenamente a PyPI que adopte una política más estricta que prohíba por completo la reutilización de un nombre de paquete. Además, los usuarios de PyPI deben ser conscientes de este posible vector de ataque cuando consideren actualizar a una nueva versión de paquete», escribió. Henrik Plate, un investigador de seguridad de Endor Labs, dijo: «Este riesgo es real y depende de la popularidad del paquete. El riesgo probablemente disminuye si los paquetes se han eliminado hace mucho tiempo, porque cuanto más tiempo lleva un paquete fuera de servicio, más desarrolladores y canales han notado su falta de disponibilidad y han adaptado sus declaraciones de dependencia. “En este contexto, cabe destacar que el ejemplo proporcionado se restableció poco después de la eliminación, lo que podría indicar que el atacante monitoreó las eliminaciones de paquetes en PyPI. “Revivir los paquetes eliminados es un problema conocido. La taxonomía de vectores de ataque a la cadena de suministro visualizada por Endor Labs Risk Explorer (una bifurcación del proyecto de GitHub sap/risk-explorer) cubre este vector como [AV-501] «Dangling Reference y los ejemplos de apoyo incluyen repositorios de GitHub revividos, repositorios de GitHub renombrados y paquetes npm revividos», dijo Plate a Computer Weekly en comentarios enviados por correo electrónico. Plate continuó afirmando que esto subraya la importancia de pautas de seguridad más estrictas para los repositorios de paquetes, como las sugeridas por OpenSSF. Para los defensores, dijo, el uso de registros de paquetes internos debería proteger a los desarrolladores de tales ataques al reflejar los paquetes de código abierto de modo que permanezcan disponibles incluso si se eliminan. Sin embargo, advirtió Plate, dichos registros internos deben configurarse para que las nuevas versiones de paquetes potencialmente maliciosos se examinen minuciosamente antes de la duplicación.