Este es el primer episodio de una serie de artículos sobre el tipo más frecuente de ataques a la cadena de suministro de software: aquellos que (ab)utilizan un registro público de componentes de software, destinados a proyectos de código abierto para cargar artefactos que podrían compartirse con otros usuarios. Cuando los malos publican software malicioso allí, utilizando el registro como vehículo para la distribución de malware, tenemos un ataque a la cadena de suministro cuando las organizaciones víctimas instalan o ejecutan el componente de software infectado.
Para simplificar la discusión hablaremos de paquetes de software:, componentes empaquetados producidos por terceros. Esto incluye no sólo componentes utilizados por administradores de paquetes como NPM o Poetry, sino también componentes del sistema operativo incluyendo bibliotecas y binarios ejecutables, imágenes de contenedores, y máquinas virtuales, o extensiones de herramientas para herramientas de desarrollo, compilación e implementación. Hemos visto paquetes maliciosos por todas partes. A los ciberdelincuentes no les importa: están encantados con las alternativas que ofrecen las infraestructuras de software modernas y utilizan el registro y la herramienta que mejor se adapta a sus necesidades. Así que recuerde que los paquetes de software son una abreviatura de imágenes de contenedor, paquetes binarios, repositorios de código abierto y extensiones o complementos de todo tipo (IDE, CI/CD sistemas, herramientas de construcción). Todos están bajo ataques rutinarios.
La serie tendrá 5 episodios:
- ¿Cuál es el problema con los paquetes de código abierto? Este es el tema de este post. ¿Por qué delincuentes de todo tipo publican paquetes maliciosos? ¿Por qué debería preocuparme?
- Anatomía de los paquetes maliciosos: ¿cuáles son las tendencias? En este episodio, nos centramos en la amenaza que monitoreamos con nuestro sistema MEW, día tras día. Con un gran ruido de fondo debido a una gran cantidad de paquetes maliciosos que utilizan errores tipográficos o confusión de dependencias, un porcentaje menor de ataques son mucho más insidiosos y representan un mayor riesgo. ¿Cómo ha cambiado el comportamiento de los malos actores con respecto al sistema operativo en el pasado reciente? ¿Cuales son los numeros? ¿Cuáles son las tácticas, técnicas y procedimientos utilizados y las acciones dañinas observadas?
- Protección contra paquetes maliciosos de código abierto: qué funciona (o no)La mayoría de los profesionales con conciencia de seguridad tienen ideas sobre cómo manejar esta amenaza. Hemos escuchado a los gerentes de seguridad decir sin dudarlo que... SCA Las herramientas ya te indican cuándo una versión de un paquete es malware. O que dependen de componentes de software conocidos y con excelentes reseñas, donde cualquier malware se detectaría y eliminaría rápidamente. Utilizan versiones menores o parches abiertos para obtener automáticamente correcciones de vulnerabilidades, y esa es la forma correcta y recomendada de reducir el riesgo de las dependencias de código abierto, siguiendo el principio de "parchear pronto, parchear con frecuencia". En este episodio, analizaremos por qué estas ideas son erróneas y cómo estos conceptos erróneos contribuyen a la popularidad de este mecanismo de ataque y al riesgo abrumador que enfrentan las organizaciones. Finalizaremos con lo que sí funciona y cuál es el esfuerzo y los recursos necesarios.
- Paquetes maliciosos de código abierto: el enfoque Xygeni. En este episodio presentamos cuál es la estrategia que seguimos en Xygeni para nuestro sistema de Alerta Temprana de Malware (MEW). ¿Cómo funciona este sistema de múltiples etapas en tiempo real cuando se publica una nueva versión del paquete, cómo se captura la evidencia de diferentes fuentes, cómo se realiza la clasificación, qué criterios de clasificación seguimos y por qué aún se necesita algún análisis manual para confirmar? ¿La naturaleza de un candidato a paquete malicioso? Cómo los comentarios de nuestros equipos internos y de registro ayudan al sistema a aprender de la evidencia anterior recopilada para reducir los falsos positivos al mínimo. NosotrosY explicaremos cómo estamos ayudando a NPM, GitHub, PyPI y otras infraestructuras clave en los ecosistemas de código abierto a reducir el tiempo de permanencia..
- Explotación del código abierto: qué esperar de los malos. La serie termina enfocándose en las acciones más recientes que los adversarios están adoptando para hacer que los ataques sean más sigilosos, más difíciles de detectar, más dirigidos a industrias específicas y para extraer más beneficios de esta clase de ataques. ¿Se realizarán ataques de ransomware utilizando este vehículo? ¿Cómo aprovechan los malos las herramientas de inteligencia artificial para entregar paquetes maliciosos más sofisticados? ¿Están en peligro los principales proyectos populares? Esto es para dar a los lectores una idea sobre esta carrera armamentista y qué esperar en el corto plazo (segunda mitad de 2024) y el mediano plazo (2025). Aprenderemos cómo ataques como el reciente Puerta trasera XZ-Utils, o el ataque de vivir de la tierra a generador de electrones en marzo de 2024 están demostrando que debemos permanecer atentos a cómo evolucionan los adversarios.
Abramos el escenario con el primer episodio: ¿Qué está pasando con los paquetes maliciosos de código abierto?
¿Cuál es el problema con los paquetes de código abierto?
En los últimos años, malhechores de todo tipo utilizaron registros de software de código abierto para generar comportamientos maliciosos. Estas actividades son tan antiguas como el código abierto, pero su frecuencia se disparó en los últimos tres años.
Publicar componentes maliciosos en registros públicos (ataques basados en dependencia) es una guerra de guerrillas asimétrica que los actores de amenazas utilizan para distribuir malware, aprovechando la confianza que las organizaciones depositan en componentes de código abierto provenientes de desarrolladores desconocidos (recuerde el dependencia xkcd comic?). Debido a que usted confía en los paquetes y no le importa revisar manualmente el contenido del paquete y sus dependencias, estos ataques son extraordinariamente efectivos. Y la asimetría surge porque pueden automatizarse en gran medida y los malos no necesitan interactuar directamente con la víctima. Simplemente cargan el paquete en el registro público y lo dejan ir.
Paquetes maliciosos se multiplicó por 6 en 2022y continuó creciendo 2.5 veces en 2023. El año pasado se detectaron la friolera de 245,000 paquetes maliciosos, una cifra que duplica con creces el número total de años anteriores combinados. ¡Esto es un crecimiento exponencial! Desde la eliminación de paquetes como malware confirmado por cientos durante 2021 y miles durante 2022, vimos mucho más “ruido” de fondo durante 2023, con un ritmo similar para este año. Y escondidos en ese trasfondo causado por ciberdelincuentes poco sofisticados que siguen el “camino de menor resistencia”, una minoría de ataques de alto perfil llegaron a los titulares incluso en los medios generalistas.
¿Por qué es este un problema de tal magnitud? Hay un exceso de confianza por toda la cadena. El software de código abierto se distribuye con su código fuente y se publica bajo una licencia determinada. Sí, cualquiera puede inspeccionar el código fuente; pero ¿quién lo hace en libertad? ¿Quién, después de inspeccionar que el software no tenga malware, lo construye a partir de las fuentes? Quien, antes de pasar el componente empaquetado (también conocido como PARA DOS) en sentido descendente hasta el administrador de paquetes o la herramienta de compilación, se asegura de que el paquete no esté plagado de malware y se corresponda con el supuesto código fuente del que debería provenir.
¿Por qué la infraestructura permite ataques tan fáciles?
Registros de paquetes son abiertos y a menudo requieren una verificación mínima de la identidad del editor. "¡Cualquiera puede publicar su software aquí!" El listón para los atacantes es bajo: utilizan direcciones de correo electrónico desechables y cuentas de GitHubgithub desechables para crear cientos de paquetes maliciosos en campañas breves similares a las de phishing. Sólo para aquellos específicos se necesita una mayor sofisticación: vimos incluso crear un repositorio de código fuente de GitHub creíble con muchas estrellas y commits de múltiples contribuyentes falsos y otras métricas de popularidad y mantenimiento. Conseguir Observadores de estrellas y reputación de contribuciones falsas. No es difícil de automatizar. Vimos abusos en infraestructuras de software abierto de todo tipo, no sólo malware, como el incidente del protocolo del té.
Los administradores de paquetes fueron diseñados para facilitar su uso y no por seguridad. Pueden ejecutar scripts previos y posteriores a la instalación (a veces es necesario compilar código nativo para una biblioteca). También, Administradores de paquetes instale paquetes de múltiples fuentes y, a veces, el valor predeterminado es utilizar registros públicos. No comprobaron si había una discrepancia entre los metadatos de la solicitud de publicación y los metadatos del paquete mismo.
Las dependencias están anidadas y forman un gráfico. En ciertos ecosistemas como Node (JavaScript), las dependencias de grano pequeño se acumulan por cientos o miles. Una cosa es tener un control estricto sobre las dependencias directas declaradas por mis proyectos de software, pero dependencias transitivas son más difíciles de controlar. El código abierto siguió "los amigos de mis amigos son mis amigos". ¡La hermandad es la norma en el salvaje Lejano Oriente! Los actores de amenazas lo saben y ocultan profundamente el comportamiento malicioso en dependencias oscuras que a menudo son desconocidas. Este fue el caso con el flujo de eventos incidente dirigido a Cartera de copago.
Así funcionó el software de código abierto desde sus inicios. No cambiará mucho. Algunos registros de paquetes exigen, en el mejor de los casos, autenticación de dos factores y, a menudo, solo para los paquetes más populares. Algunos registros proporcionan ámbitos, un espacio de nombres propiedad de una organización examinada, pero trágicamente otros no lo admiten (PyPI) o lo hacen opcional (NPM). Es interesante notar que incluso un esquema de detección simple (basado en el control del DNS o repositorio/organización de GitHub que coincide con el ID del grupo) y haciendo Firmas PGP obligatorias para todos los artefactos, excepto las sumas de comprobación, elimina la mayor parte del "ruido", los paquetes maliciosos tipo typosquatting y limita gran parte de confusión de dependencia. Los ataques sofisticados son posibles pero mucho más difíciles, con sólo unos pocos como el com.github.codingandcoding:maven-compiler-plugin conocido por Maven Central. ¡Y no todos los registros de Maven siguen las mismas prácticas!
Los controles de seguridad en los administradores de paquetes pueden ser una carga, pero no impiden los ataques de dependencia. El problema con la autenticación multifactor es que, para la automatización, se generan credenciales derivadas, como tokens de acceso o claves APIapi, para que las cuentas se utilicen en llamadas APIapi realizadas a partir de scripts de automatización, sin que ningún usuario interactivo de respaldo proporcione un segundo factor. MFA es bueno para proteger las cuentas de usuario de la filtración de contraseñas, pero los tokens de acceso generados o las claves APIapi deben protegerse mientras están activos, o los adversarios se harán pasar por su propietario. Una gran fracción de las campañas de la cadena de suministro basadas en paquetes comienzan con una clave/token filtrado. Sólo recuerda incidentes como Libro mayor, 3CXy muchos más, donde se filtraron por primera vez credenciales no interactivas en una intrusión preliminar para lanzar el ataque a la cadena de suministro.
La respuesta a esta amenaza no fue lo suficientemente contundente. En el tercer episodio, nos centraremos en lo que funcionó y lo que fracasó estrepitosamente. La industria necesita trabajar en conjunto para... standardProcesos, capacitación y herramientas para mitigar los riesgos en las cadenas de suministro globales. Este no es un problema que una sola organización pueda resolver por sí sola.
Para finalizar este apartado, el malentendido crucial: estamos hablando de malicioso paquetes, no vulnerable unos. Las vulnerabilidades provienen de errores de diseño o codificación, introducidos accidentalmente, sin mala intención. Es posible que se aprovechen las vulnerabilidades, pero muchas no. Los paquetes maliciosos siempre son intencionales y su explotabilidad es del 100 % si se ejecutan. ¡No hay riesgo comparable! Por eso Es paradójico ver cuántos esfuerzos se ponen en detectar y mitigar vulnerabilidades, y la falta de medidas equivalentes para los componentes maliciosos..
“Nos tomamos en serio la seguridad”
Imaginemos lo acostumbrado Corporación Acme. Acme, un importante proveedor de WileCoyote.com, tiene la mayor parte de su software proveniente de terceros, con más del 80% de proyectos de código abierto. Producen software para uso interno, pero también proporcionan software para sus socios, proveedores y clientes/usuarios finales. Acme tiene software escrito en Go, JavaScript, Java, C# y Python, y ejecuta la mayor parte de su software en la nube, en clústeres de Kuberneteskubernetes. Acme crea sus imágenes personalizadas a partir de imágenes base tomadas de Docker Hub y otros registros. Y también comparten algunas bibliotecas, paquetes e imágenes de contenedores en registros públicos.
Acme se toma en serio la seguridad. Son bastante conscientes del problema de open source securityy el riesgo que conlleva. Todos los desarrolladores, administradores de sistemas e ingenieros de DevOpsdevops utilizan esas lindas y pequeñas claves criptográficas como autenticación de segundo factor. Todo commitLos repositorios de código están firmados y la protección de ramas está habilitada con revisiones de código obligatorias. CI/CD Bloqueado, los Secretos se almacenan en una bóveda de Secretos y con un registro interno que refleja parcialmente los registros externos, donde solo se almacenan los componentes permitidos y autorizados. El software desarrollado por Acme debe tomar las dependencias de terceros de este registro.
Probablemente la mayoría de las organizaciones encajen en este perfil. Estimado lector, el suyo ciertamente encaja si todavía está aquí, ¿no es así?
Entonces, un día desafortunado, un importante desarrollador frontend en Acme corrió npm instala acme-cute-lib, olvidando que @acme/cute-lib era la dependencia con el ámbito correcto. El error exacto no es importante, muchas cosas pueden salir mal incluso cuando se asume un control perfecto del ciclo de vida del software. Nuestro desarrollador no sabía que un grupo APT estaba apuntando a Acme y publicó un componente malicioso con ese nombre, de una manera astuta para que el comportamiento malicioso se active solo cuando el software está instalado en las computadoras Acme. El paquete no fue detectado durante semanas después de su publicación.
Se ejecuta un script de instalación que busca credenciales (había muchos tokens de acceso jugosos en la computadora portátil de nuestro desarrollador), permitiendo el acceso a los repositorios internos de software, y al repositorio interno antes mencionado, al que por supuesto solo se puede acceder a través de VPN. El código malicioso logró utilizar la conexión VPN existente y publicar un componente malicioso de segunda etapa en el registro interno, afectando una biblioteca de utilidades comunes compartida por la mayor parte del software entregado por Acme.
Semanas después, otras organizaciones que utilizaban las herramientas publicadas de Acme comenzaron a ver tráfico extraño en sus redes, con tráfico que utilizaba el protocolo de Acme pero dirigido a hosts que se parecían al dominio Acme. El tráfico estaba cifrado, pero las herramientas de monitoreo del sistema encontraron acceso a archivos inesperados y la ejecución de procesos que parecen comandos del sistema pero que terminan ejecutando ejecutables descargados.
El resto es historia: Acme primero negó que tal comportamiento fuera imputable a ellos y que se implementaran todas las medidas de seguridad. Solo después de que los medios de ciberseguridad comenzaron a preguntar por qué la fuente del comportamiento detectado se originaba en los componentes de Acme, y el análisis de seguridad publicó cuán plagados estaban esos componentes con malware sigiloso, Acme tuvo que reconocer el incidente y llamó a una empresa de respuesta a incidentes. Una campaña de marketing negativa que minó en un segundo la confianza ganada con tanto esfuerzo. “Acme estaba a una instalación de npm de disaster"Era un titular común. Luego siguieron demandas y contratos cancelados.
¿Ves semejanzas con incidentes pasados conocidos? Acme sufrió un incidente en la cadena de suministro en dos fases, utilizando una combinación de confusión de dependencia/error tipográfico ataques que utilizaban una estación de trabajo de desarrollador como cabeza de puente para infectar componentes que terminaban en software utilizado por terceros. ¿Cómo podría prevenirse o mitigarse esto?
¿Por qué los paquetes envenenados son tan populares?
Este incidente hipotético muestra que incluso con un enfoque razonable de la seguridad de código abierto, las organizaciones necesitan medidas específicas para evitar ser víctimas de malware en componentes de código abierto. Esquemáticamente, el actor de amenazas puede:
- Crear un nuevo paquete (siguiendo los conocidos errores tipográficos o confusión de dependencia, este es el camino más recorrido por los malos en volumen);
- Intente infectar uno existente, ya sea inyectándolo en el código fuente, intentando disfrazarlo como colaborador a través de pull request, o usar ingeniería social para convertirse en un mantenedor (como lo hizo “Jao Tan” en XZ Backdoor o derecha9ctrl usuario de GitHub hizo en el flujo de eventos incidente en el otoño de 2018), o obteniendo credenciales de repositorio de código abierto y haciéndose pasar por el mantenedor;
- Inyectar malware durante la compilación del paquete, ya sea ejecutando un script de compilación malicioso, o interferir con las descargas de paquetes con intercepciones de intermediario (afortunadamente, ahora siempre se requiere TLS en la mayoría de los registros).
- Inyecte el componente empaquetado directamente en el registro, generalmente capturando las credenciales del registro (la alternativa preferida para muchos ataques sofisticados como el de Acme, donde la estación de trabajo comprometida en la primera etapa tenía el token de acceso al registro interno, por ejemplo, en el modo habitual). .env or ~/.m2/configuración.xmlLos ciberdelincuentes saben dónde buscar secretos. También se explotaron vulnerabilidades en los registros.
El envenenamiento de los registros con malware es la base de los ataques de dependencia. Nada nuevo bajo el sol: su prevalencia se disparó, pero ahora funcionan las mismas técnicas que hace cinco años.
Fuente: Colección de cuchillos del traidor.
El paquete malicioso puede operar durante la instalación, la compilación del software o la ejecución. Su comportamiento abarca desde la exfiltración de información (por ejemplo, extrayendo Secretos para un intento de segunda fase) hasta la extracción del código fuente, que incluye malware adicional. En el próximo episodio, analizaremos los paquetes maliciosos y cómo se publican.
Seguí leyendo
El siguiente episodio Anatomía de los paquetes maliciosos: ¿cuáles son las tendencias? Se centrará en casos reales que estamos monitoreando con nuestro sistema de Alerta Temprana de Malware, día tras día. Revisaremos qué tipos de malware se detectaron y qué tácticas, técnicas y procedimientos son los favoritos. Examinaremos la ofuscación y cómo intentan esconderse de posibles revisores, las técnicas de evasión para evitar la detección y cómo están evolucionando con la telemetría y el movimiento lateral. ¡Por favor manténgase al tanto!
Referencias
- Colección de cuchillos del traidor: una revisión de los ataques a la cadena de suministro de software de código abierto. M. Ohm et al., mayo de 2020.
- Protección contra malware de código abierto. Libro blanco de Xygeni.
- Software Supply Chain Security Retrospectiva: Forjando un 2024 más seguro. Informe de Xygeni.
