Se ha explotado indiscriminadamente una nueva t\u00e9cnica de ataque a la cadena de suministro dirigida al registro del \u00edndice de paquetes de Python (PyPI) en un intento de infiltrarse en organizaciones posteriores.<\/p>\n
La empresa de seguridad de la cadena de suministro de software JFrog lo ha bautizado como Revival Hijack y ha afirmado que el m\u00e9todo de ataque podr\u00eda utilizarse para secuestrar 22.000 paquetes PyPI existentes y provocar “cientos de miles” de descargas de paquetes maliciosos. Estos paquetes susceptibles tienen m\u00e1s de 100.000 descargas o han estado activos durante m\u00e1s de seis meses.<\/p>\n
“Esta t\u00e9cnica de ataque implica secuestrar paquetes de software de PyPI manipulando la opci\u00f3n de volver a registrarlos una vez que son eliminados del \u00edndice de PyPI por el propietario original”, dijeron los investigadores de seguridad de JFrog Andrey Polkovnychenko y Brian Moussalli en un comunicado. informe<\/a> compartido con The Hacker News.<\/p>\n En esencia, el ataque se basa en el hecho de que varios paquetes de Python publicados en el repositorio PyPI se eliminan, lo que los deja disponibles para que cualquier otro usuario los registre.<\/p>\n Las estad\u00edsticas compartidas por JFrog muestran que, en promedio, se eliminan unos 309 paquetes cada mes. Esto puede suceder por diversas razones: falta de mantenimiento (es decir, abandonware), reedici\u00f3n de paquetes con un nombre diferente o introducci\u00f3n de la misma funcionalidad en bibliotecas oficiales o API integradas.<\/p>\n Esto tambi\u00e9n representa una superficie de ataque lucrativa que es m\u00e1s efectiva que el typosquatting y que un atacante, usando sus propias cuentas, podr\u00eda explotar para publicar paquetes maliciosos bajo el mismo nombre y una versi\u00f3n superior para infectar entornos de desarrolladores.<\/p>\n “La t\u00e9cnica no depende de que la v\u00edctima cometa un error al instalar el paquete”, afirman los investigadores, destacando que Revival Hijack puede ofrecer mejores resultados desde el punto de vista de un adversario. “Actualizar un paquete que antes era seguro a su \u00faltima versi\u00f3n es considerado una operaci\u00f3n segura por muchos usuarios”.<\/p>\n Si bien PyPI cuenta con protecciones contra la suplantaci\u00f3n de autor y los intentos de typosquatting, el an\u00e1lisis de JFrog descubri\u00f3 que ejecutar el “lista de pips –obsoleta<\/a>El comando ” enumera el paquete falsificado como una nueva versi\u00f3n del paquete original, donde el primero corresponde a un paquete diferente de un autor completamente diferente.<\/p>\n A\u00fan m\u00e1s preocupante es el funcionamiento del “instalaci\u00f3n de pip \u2013actualizaci\u00f3n<\/a>El comando ” reemplaza el paquete real con el falso sin ninguna advertencia de que el autor del paquete ha cambiado, lo que potencialmente expone a los desarrolladores involuntarios a un enorme riesgo en la cadena de suministro de software.<\/p>\n JFrog dijo que tom\u00f3 la medida de crear una nueva cuenta de usuario de PyPI llamada “tenencia de seguridad<\/a>” que sol\u00eda secuestrar de forma segura los paquetes susceptibles y reemplazarlos con marcadores de posici\u00f3n vac\u00edos para evitar que actores maliciosos sacaran provecho de los paquetes eliminados.<\/p>\n Adem\u00e1s, a cada uno de estos paquetes se le ha asignado el n\u00famero de versi\u00f3n 0.0.0.1 (lo opuesto a un escenario de ataque de confusi\u00f3n de dependencia) para evitar que los desarrolladores los retiren cuando ejecutan un comando de actualizaci\u00f3n pip.<\/p>\n Lo que es m\u00e1s inquietante es que Revival Hijack ya ha sido explotado en la naturaleza, con un actor de amenaza desconocido llamado Jinnis introduciendo una versi\u00f3n benigna de un paquete llamado “pingdomv3<\/a>” el 30 de marzo de 2024, el mismo d\u00eda en que el propietario original (cheneyyan) elimin\u00f3 el paquete de PyPI.<\/p>\n Se dice que el 12 de abril de 2024, el nuevo desarrollador lanz\u00f3 una actualizaci\u00f3n que contiene una carga \u00fatil codificada en Base64 que verifica la presencia de “JENKINS_URL<\/a>” variable de entorno y, si est\u00e1 presente, ejecuta un m\u00f3dulo desconocido de siguiente etapa recuperado de un servidor remoto.<\/p>\n “Esto sugiere que los atacantes retrasaron la entrega del ataque o lo dise\u00f1aron para que fuera m\u00e1s espec\u00edfico, posiblemente limit\u00e1ndolo a un rango de IP espec\u00edfico”, dijo JFrog.<\/p>\n El nuevo ataque es una se\u00f1al de que los actores de amenazas est\u00e1n considerando realizar ataques a la cadena de suministro a una escala m\u00e1s amplia, al apuntar a los paquetes PyPI eliminados para expandir el alcance de las campa\u00f1as. Se recomienda a las organizaciones y desarrolladores que inspeccionen sus procesos de DevOps para asegurarse de que no est\u00e9n instalando paquetes que ya se hayan eliminado del repositorio.<\/p>\n “El uso de un comportamiento vulnerable en el manejo de paquetes eliminados permiti\u00f3 a los atacantes secuestrar paquetes existentes, lo que hizo posible instalarlos en los sistemas de destino sin realizar cambios en el flujo de trabajo del usuario”, dijo Moussalli, l\u00edder del equipo de investigaci\u00f3n de seguridad de JFrog.<\/p>\n “La superficie de ataque del paquete PyPI crece continuamente. A pesar de la intervenci\u00f3n proactiva en este caso, los usuarios siempre deben permanecer alerta y tomar las precauciones necesarias para protegerse a s\u00ed mismos y a la comunidad PyPI de esta t\u00e9cnica de secuestro”.<\/p>\n <\/p>\n![\"Ciberseguridad\"](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2024\/09\/Los-piratas-informaticos-secuestran-22000-paquetes-PyPI-eliminados-y-difunden.jpg\")
<\/a><\/center><\/div>\n<\/a><\/center><\/section>\n