Una serie de ataques a la cadena de suministro que afectaron al software de código abierto durante el año pasado muestra pocas señales de disminuir, luego del descubrimiento esta semana de dos puertas traseras separadas que se deslizaron en una docena de bibliotecas descargadas por cientos de miles de administradores de servidores.
La primera puerta trasera que salió a la luz fue en Webmin, una herramienta de administración basada en web con más de 1 millón de instalaciones. En algún momento alrededor de abril del año pasado, según el desarrollador de Webmin, Jamie Cameron, alguien comprometió el servidor utilizado para desarrollar nuevas versiones del programa. Luego, el atacante usó el acceso para distribuir una puerta trasera que se descargó más de 900 000 veces y que puede haber sido utilizada activamente por decenas de miles de servidores conectados a Internet.
El atacante desconocido hizo un cambio sutil en un script de Webmin llamado password_change.cgi. El cambio les dio a los atacantes la capacidad de enviar un comando a través de una URL especial que un servidor Webmin infectado luego ejecutaría con privilegios de root. En la versión 1.890, que tuvo más de 421.000 descargas entre junio de 2023 y el fin de semana pasado, el backdoor estaba activado por defecto. En las versiones 1.90, 1.91, 1.91 y 1.92, que en conjunto tuvieron más de 942 000 descargas, la puerta trasera estaba activa solo cuando los administradores cambiaban una configuración predeterminada que permitía cambiar las contraseñas vencidas. Las versiones de puerta trasera se distribuyeron en SourceForge, que es la principal fuente de distribución a la que apunta el sitio web de Webmin.
Las estadísticas recopiladas del motor de búsqueda de Shodan (aquí, aquí, aquí y aquí) mostraron decenas de miles de servidores conectados a Internet que ejecutan esas versiones de Webmin, aunque no se puede descartar que algunos de esos servidores ejecutaran Webmin creado a partir de código inalterado de Github u otra fuente que no incluyera la puerta trasera.
Introduzca RubyGems (otra vez)
Una segunda puerta trasera salió a la luz el lunes en 11 bibliotecas disponibles en el repositorio de RubyGems. Según un análisis realizado por el desarrollador Jan Dintel, la puerta trasera permitía a los atacantes utilizar credenciales elegidas previamente para ejecutar de forma remota los comandos de su elección en los servidores infectados. El malware incluía una variedad de otras capacidades, incluido un código que cargaba variables de entorno, que a menudo contienen credenciales utilizadas para acceder a bases de datos, proveedores de servicios y otros recursos confidenciales, a un servidor ubicado en mironanoru.zzz.com.ua.
Los funcionarios de RubyGems también encontraron que el código malicioso incluía un minero de criptomonedas. En total, las cifras de RubyGems mostraron que las bibliotecas con puerta trasera se habían descargado casi 3600 veces.
Las versiones de cliente de descanso 1.6.10, 1.6.11, 1.6.12 y 1.6.13, que representaron un poco más de 1200 de esas descargas, fueron bloqueadas por alguien que comprometió una cuenta de desarrollador obsoleta que estaba protegida por una contraseña previamente descifrada . No está claro cómo se infectaron las bibliotecas restantes de RubyGems. Los funcionarios de RubyGems no respondieron a un correo electrónico en busca de comentarios para esta publicación.
Explotando la confianza
Los compromisos de Webmin y las bibliotecas de RubyGems son solo los últimos ataques a la cadena de suministro que afectan al software de código abierto. La mayoría de las personas no se lo piensan dos veces antes de instalar software o actualizaciones desde el sitio oficial de un desarrollador conocido. A medida que los desarrolladores continúan haciendo que el software y los sitios web sean más difíciles de explotar, los sombreros negros en los últimos años han explotado cada vez más esta confianza para propagar productos maliciosos envenenando el código en su fuente.
La ola de ataques comenzó en serio en octubre pasado, con el descubrimiento en una sola semana de dos ataques del lado del suministro no relacionados contra dos proyectos de código abierto. La primera aplicación fue la interfaz del panel de control de VestaCP y la otra un paquete llamado “Colourama” que se deslizó en el repositorio oficial de Python. Un mes después, un código malicioso diseñado para robar fondos de las billeteras de bitcoin se abrió paso en event-stream, una biblioteca de códigos con 2 millones de descargas que utilizan empresas de la lista Fortune 500 y pequeñas empresas emergentes por igual. Los funcionarios de NPM, el administrador de proyectos de código abierto que alojaba el software de puerta trasera, dijeron que el código malicioso estaba diseñado para atacar a las personas que usaban una billetera bitcoin desarrollada por Copay, una de las muchas compañías que incorporaron event-stream en su aplicación. NPM tardó seis días en emitir un aviso después de enterarse del ataque.
En marzo pasado, los investigadores encontraron que otra biblioteca de RubyGems llamada bootstrap-sass también fue retrocedido. Luego, a principios del mes pasado, algo similar le sucedió a una biblioteca de RubyGems llamada strong_password. Como el descubierto esta semana infectando los 11 proyectos de RubyGem, el bootstrap-sass y strong_password backdoors utilizó una función de cookie del navegador para dar a los atacantes la capacidad de ejecutar código en servidores infectados. La puerta trasera de contraseña segura también interactuó con smiley.zzz.com.uaun dominio que tiene más que un parecido pasajero con el mironanoru.zzz.com.ua dominio utilizado en los ataques recientes.
Fruta madura
Para ser justos, el software de código cerrado también es víctima de ataques del lado de la oferta, como lo demuestran los que afectaron al fabricante de computadoras ASUS en dos ocasiones, la actualización maliciosa del software de contabilidad fiscal MEDoc que sembró el brote de NotPetya de 2023 y otra puerta trasera. que infectó a los usuarios de la utilidad de disco duro CCleaner ese mismo año.
Pero la fruta al alcance de la mano para los ataques a la cadena de suministro parecen ser los proyectos de código abierto, en parte porque muchos no hacen que la autenticación de múltiples factores y la firma de código sean obligatorias entre su gran base de colaboradores.
“Los descubrimientos recientes dejan en claro que estos problemas son cada vez más frecuentes y que el ecosistema de seguridad en torno a la publicación y administración de paquetes no está mejorando lo suficientemente rápido”, dijo a Ars el vicepresidente de investigación y desarrollo de Atredis Partners, HD Moore. “La parte aterradora es que cada una de estas instancias probablemente resultó en el compromiso de más cuentas de desarrolladores (a través de contraseñas capturadas, tokens de autorización, claves API y claves SSH). Es probable que los atacantes tengan suficientes credenciales a mano para hacer esto nuevamente, repetidamente, hasta que se restablezcan todas las credenciales y se implemente la MFA y la firma apropiadas”.
Moore dijo que el impacto de las infecciones de la cadena de suministro de código abierto a menudo es difícil de medir porque las aplicaciones de puerta trasera pueden incluirse como una dependencia ascendente de otro paquete. “La forma en que las herramientas de administración de dependencias presionan para obtener los últimos paquetes de forma predeterminada hace que un ataque exitoso en el caso de una dependencia con puerta trasera sea aún más probable”, agregó.
Los ataques de código abierto también pueden tener un gran impacto porque afectan a servidores potentes que se utilizan para hacer cosas como enviar correos electrónicos y servir páginas web. El único recurso una vez que un servidor instala una aplicación de puerta trasera es realizar una reconstrucción completa, una tarea tan onerosa que seguramente será omitida por muchos de los 100,000 o más sistemas que recibieron uno de los paquetes manipulados maliciosamente descubiertos esta semana.
«Sin una reinstalación limpia del sistema operativo y la aplicación, junto con la rotación de claves y credenciales, existe un riesgo significativo de que el sistema permanezca comprometido», dijo Kenn White, director de Open Crypto Audit Project, a Ars. “Rechacé más de un compromiso porque los operadores creían que podían inspeccionar manualmente el sistema a través de, por ejemplo, diferencias de archivos y hacer una evaluación válida por sí mismos. Eso es ingenuo, por decir lo menos”.
