El pasado 29 de abril, la compañía de ciberseguridad Snyk Security Research anunció que había detectado un ciberataque dirigido contra varias empresas industriales relevantes con sede en Alemania. El método elegido para realizar el ataque se basaba en incluir código maligno en dependencias NPM, lo cual lo difundiría entre los desarrolladores de este popular repositorio y gestor de paquetes de NodeJS.
Los paquetes señalados (como gxm-reference-web-auth-server) contenían archivos package.json que incluían scripts post-instalación que a su vez invocaban a ficheros .js del propio paquete, que permitían recopilar y extraer información de los sistemas afectados, creando puertas traseras que permitían tomar el control de la máquina.
Horas después de ser detectado este ataque, los responsables de NPM borraron los archivos afectados. Pero aún faltaba por identificar a los responsables del ataque.
De modo que, hace dos días, otra compañía de ciberseguridad, JFrog, profundizaba en el estudio de los paquetes maliciosos detectados por Snyk, y analizaba los indicios de que disponían al respecto, dejando abierta la posibilidad de que no se tratara de un ciberataque real, sino de una simulación de uno con el objetivo de poner a prueba la seguridad de las empresas afectadas:
«Por un lado, tenemos fuertes indicadores de que se trataría de un sofisticado actor de amenazas reales:
Todo el código utilizado es personalizado.
El ataque está altamente dirigido y se basa en información privilegiada difícil de obtener (los nombres de los paquetes privados).
La carga útil es extremadamente maliciosa y contiene características que no son necesarias en un simple pentest (por ejemplo, parámetros de configuración dinámica).
Los paquetes cargados no tenían descripciones ni indicaciones de que se están utilizando con fines de pentesting.
Por otro lado, algunos otros indicadores podrían sugerir que estamos ante una prueba de penetración (¡aunque muy agresiva!):
Los nombres de usuario creados en el registro npm no intentaron ocultar la empresa de destino.
El ofuscador utilizado era público, por lo que se podía detectar e invertir fácilmente».
Misterio resuelto
Sin embargo, pocas horas después de la publicación en el blog de JFrog, otra compañía del sector especializada en inteligencia de amenazas y pentesting, Code White, asumía la responsabilidad de un ataque que, como JFrog había sido capaz de intuir, se trataba realmente de un ejercicio de ‘pentesting’ (prueba de penetración, en la que un falso atacante trata de violar las medidas de seguridad de la empresa que ha solicitado ser avaluada). Así, en un tuit dirigido a Snyk, escribían lo siguiente:
@snyksec Tnx for your excellent analysis at https://t.co/UoshhgaDgx and don’t worry, the «malicious actor» is one of our interns ? who was tasked to research dependency confusion as part of our continuous attack simulations for clients. (1/2)
— Code White GmbH (@codewhitesec) May 10, 2022
«Gracias por vuestro excelente análsisis, y no os preocupéis, el actor malicioso es uno de nuestros becarios: se le encargó investigar la confusión de dependencias como parte de nuestras simulaciones de ataques para clientes».
Sin embargo, un directivo de Jfrog —Shachar Menashe, director senior de investigación de seguridad— comentó, tras conocerse la autoinculpación de Code White, que la forma en que esta compañía había llevado a cabo sus pruebas «no era muy normal y podría tener implicaciones problemáticas«. Peor aún:
«También me preocupa que se dé una situación en la que este código de puerta trasera pueda ser secuestrado por un actor de amenazas reales, y utilizada para causar daños reales».
Vía | The Register
Fuente info
Autor: