Miles de aplicaciones que han aprovechado los paquetes de software Python Package Index (PyPI) de código abierto pueden correr el riesgo de ser secuestradas y subvertidas por actores maliciosos, lo que abre la posibilidad de que se produzcan importantes ataques a la cadena de suministro que afecten a un número aún mayor de organizaciones y usuarios intermedios.
Esto es según los investigadores de amenazas de jFrog, quienes identificaron la técnica que se estaba explotando en la naturaleza contra el paquete pingdomv3, parte del ampliamente utilizado servicio de monitoreo de sitios web Pingdom API, propiedad de SolarWinds, mientras monitoreaban el ecosistema de código abierto. El equipo ha denominado la técnica Revival Hijacking.
La técnica en sí es similar en sus fundamentos a la typosquatting, donde los actores de amenazas se aprovechan de 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 función PyPl mediante la cual cuando un paquete se elimina o se elimina del repositorio, su nombre vuelve a estar inmediatamente disponible para su uso.
Como sugiere el nombre, esto significa que el paquete puede reactivarse y secuestrarse de manera efectiva con fines nefastos.
Brian Moussali, líder del equipo de investigación de malware de JFrog y coautor del informe resultante, dijo 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 ven como un riesgo mínimo, aunque ese no sea el caso. En tercer lugar, muchas máquinas CI/CD se configurarán para instalar actualizaciones de paquetes automáticamente.
“El Revival Hijack no es sólo 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, haciendo 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 aquí, 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 co-investigador Andrey Polkovnichenko dicen que, según un recuento de paquetes PyPI eliminados, hasta 120.000 podrían ser potencialmente secuestrados. Si filtramos aquellos que tienen menos de 100.000 descargas, que no han estado activos por mucho tiempo o que son obviamente dudosos, la cifra aún supera las 22.000.
Y con un promedio de 309 proyectos PyPI que se eliminan cada mes, cualquiera que esté interesado en 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, luego permaneció en silencio hasta el 27 de marzo de 2024, cuando envió una breve actualización indicando a los usuarios que evitaran usar el paquete tal como estaba. abandonado. Luego lo eliminaron el 30 de marzo, momento en el que apareció el nombre para su registro.
Casi de inmediato, 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 era una reurbanización y apuntándolo a un repositorio de GitHub. Esta versión contenía el código estándar pingdomV3, aunque el repositorio de GitHub vinculado en realidad nunca existió.
Luego, el 12 de abril, los escáneres automatizados de jFrog detectaron una actividad extraña cuando el propietario introdujo una carga útil sospechosa ofuscada en Base64. Esto hizo sonar las alarmas y motivó la investigación y posterior divulgación. PyPI eliminó el paquete por completo el 12 de abril y se prohibió el uso de su nombre.
La carga útil en sí parecía ser un malware troyano Python diseñado para descubrir si se está ejecutando en una configuración de Jenkins CI, 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 por otros vacíos y benignos, todos con el número de versión 0.0.0.1 para asegurarse de que no fueran automáticamente extraídos accidentalmente. actualizaciones.
Al volver a comprobarlo 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 en todas las ocasiones, pero “sería muy seguro decir” que en la mayoría de los casos lo haría. dijo Moussali.
La respuesta de PyPI
Según jFrog, PyPI ha estado considerando un cambio de política sobre 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 deliberaciones.
Deja claro, al eliminarlo, que el nombre se liberará para que otros lo utilicen 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 extenso que se necesitan más acciones.
“Abogamos plenamente por que PyPI adopte una política más estricta que prohíba por completo la reutilización del nombre de un paquete. Además, los usuarios de PyPI deben ser conscientes de este posible vector de ataque cuando consideren actualizar a una nueva versión del paquete”, escribió.
Henrik Plate, 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 eliminaron hace mucho tiempo, porque cuanto más tiempo lleva eliminado un paquete, más desarrolladores y canalizaciones notaron su indisponibilidad y adaptaron sus declaraciones de dependencia.
“En este contexto, cabe destacar que el ejemplo proporcionado se revivió poco después de la eliminación, lo que podría indicar que el atacante monitoreó las eliminaciones de paquetes en PyPI.
“Revivir paquetes eliminados es un problema conocido. La taxonomía de los vectores de ataque a la cadena de suministro visualizada por Endor Labs Risk Explorer (una bifurcación del proyecto GitHub sap/risk-explorer) cubre este vector como [AV-501] La referencia colgante 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 directrices 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 manera que permanezcan disponibles incluso si se eliminan. Sin embargo, advirtió Plate, dichos registros internos deben configurarse de modo que las versiones nuevas de paquetes potencialmente maliciosos sean examinadas minuciosamente antes de la duplicación.