[13/11/2023] Los incidentes en la cadena de suministro de software han aparecido en los titulares recientemente. A pesar de las similitudes entre estos incidentes de seguridad, no todos los ataques a la cadena de suministro son iguales.
¿Qué es un ataque a la cadena de suministro de software?
El término general "ataque a la cadena de suministro de software” cubre cualquier caso en el que un atacante interfiere o secuestra el proceso de fabricación de software (ciclo de vida de desarrollo de software) de modo que múltiples consumidores del producto o servicio terminado se ven perjudicados. Esto puede suceder cuando las bibliotecas de códigos o los componentes individuales que se utilizan en una compilación de software están contaminados, cuando los binarios de actualización de software son troyanizados, los certificados de firma de código han sido robados o incluso cuando un servidor que aloja software como servicio (SaaS) se ve comprometido.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
En cualquier ataque a la cadena de suministro de software, los atacantes se interponen en la fase inicial o intermedia para transmitir sus actividades maliciosas, y posteriormente los efectos perjudican a muchos usuarios. Por lo tanto, en comparación con una brecha de seguridad aislada, los ataques exitosos a la cadena de suministro son de una escala mucho mayor y tienen un impacto de gran alcance.
¿Cuál es el riesgo en la cadena de suministro de software?
Cualquier repositorio o biblioteca de códigos puede contener código malicioso a pesar de los esfuerzos por monitorear y eliminar paquetes sospechosos. Si bien algunos repositorios como GitHub están tomando medidas positivas para mantener el malware fuera de sus sitios, los atacantes siguen encontrando formas exitosas de poner su código a disposición de desarrolladores desprevenidos.
El problema está creciendo. El informe Evolution of Software Supply Chain Security Report del tercer trimestre del 2023 de Phylum reveló aumentos en paquetes sospechosos en la mayoría de las categorías. De los tres millones de paquetes analizados, más de 10 mil archivos hacían referencia a URL maliciosas conocidas. Casi 86 mil contenían archivos binarios precompilados, lo que dificulta que sean analizados en busca de malware. Otros 5.500 intentaron ofuscar su código y cinco mil fueron registrados por autores con cuentas de correo electrónico desechables.
Lo más significativo es que el informe mostró un cambio en las tácticas de los autores de malware, que cada vez se dirigen más a empresas específicas en lugar de adoptar un enfoque más amplio. Casi mil paquetes maliciosos se dirigieron a grupos o empresas específicos, lo que representa un aumento del 47,4% con respecto al segundo trimestre del 2023. Los objetivos de estos ataques dirigidos incluyen la recolección de credenciales y el robo de código fuente o propiedad intelectual.
Los desarrolladores no parecen estar haciendo que la cadena de suministro de software sea más segura con sus prácticas. Phylum señaló que los desarrolladores descargan alrededor de 24 mil millones de paquetes del registro de paquetes Javascript npm cada semana, pero casi ninguno de ellos verifica la integridad del código descargado. Los atacantes lo saben y eso podría animarlos a lanzar campañas más amplias, como ataques de ransomware a gran escala o botnets en el futuro, según el informe.
Ejemplos de ataques a la cadena de suministro de software
A continuación, examinamos seis técnicas diferentes utilizadas en ataques recientes a la cadena de suministro de software que han tenido éxito en el mundo real.
1. Servidor ascendente comprometido: ataque Codecov: En la mayoría de los ataques a la cadena de suministro de software, un atacante vulnera un servidor ascendente o un repositorio de código e inyecta una carga maliciosa (por ejemplo, una línea de código maliciosa o actualizaciones troyanizadas). Luego, esa carga se distribuye a muchos usuarios. Sin embargo, desde un punto de vista técnico, este no es siempre el caso.
El ataque a la cadena de suministro Codecov es un ejemplo de ello. Aunque el incidente ha generado comparaciones con la brecha de SolarWinds, existen diferencias marcadas entre los dos ataques. La violación de la cadena de suministro de SolarWinds fue obra de actores de amenazas sofisticados que alteraron un binario de actualización legítimo, SolarWinds.Orion.Core.BusinessLayer.dll, que formaba parte de Orion, el producto de monitoreo del rendimiento de TI de SolarWinds.
Como lo analizó anteriormente FireEye, se muestra a continuación el código malicioso contenido en el método RefreshInternal() de la DLL falsificada. Este método invoca el backdoor basado en HTTP cuando Orion carga el plugin Inventory Manager:
Versión 2019.4.5200.9083 de la DLL backdoored con el método malicioso RefreshInternal.
Sin embargo, el ataque ascendente de SolarWinds tomó toda su fuerza cuando el binario alterado llegó a más de 18 mil clientes de SolarWinds Orion, incluyendo agencias gubernamentales de Estados Unidos.
En el caso de Codecov, en cambio, no se distribuyó ningún código malicioso, pero sí hubo secuelas del ataque. Los atacantes de Codecov habían obtenido credenciales de un proceso defectuoso de creación de imágenes de Docker que podían usarse para modificar Codecov Bash Uploader, según el aviso de seguridad oficial. Los atacantes modificaron el Codecov Bash Uploader alojado en el propio servidor Codecov para recopilar variables de entorno que se cargaban desde los entornos de integración continua/entrega continua (CI/CD) de los clientes:
Línea modificada del Bash Uploader de Codecov que recopilaba variables de entorno y las enviaba a la dirección IP del atacante.
Aunque el script Codecov Bash Uploader vivía (y continúa viviendo) en el servidor Codecov en codecov[.]io/bash, miles de repositorios ya apuntaban al enlace para enviar información de manera ascendente desde sus entornos CI/CD a este Bash Uploader. De este modo, el código malicioso permaneció presente solo en el servidor ascendente (comprometido) sin que se produjera ninguna distribución descendente del código, porque los denominados repositorios descendentes ya apuntaban al servidor Codecov que alojaba el script Bash Uploader. Sin embargo, los repositorios descendentes se vieron afectados por este ataque ya que estaban configurados para cargar sus datos en Bash Uploader de Codecov:
De hecho, los atacantes de Codecov supuestamente tuvieron acceso a cientos de redes de clientes utilizando credenciales recopiladas del Bash Uploader hackeado. Poco después, HashiCorp reveló que el incidente Codecov provocó la exposición de su clave privada GPG utilizada para firmar y verificar paquetes de software. Twilio también ha revelado algunos de los efectos del ataque, y otras empresas están dando un paso adelante con divulgaciones similares.
2. Compromiso "midstream” para enviar actualizaciones maliciosas: El término "midstream” se aplica de manera imprecisa para referirse a casos en los que los atacantes comprometen una funcionalidad de actualización de software intermedia o una herramienta CI/CD en lugar de la base de código fuente original. El mes pasado, Click Studios, creador del gestor de contraseñas empresariales Passwordstate, utilizado por muchas empresas Fortune 500, notificó a sus clientes de un ataque a la cadena de suministro. Los atacantes comprometieron la "funcionalidad de actualización local” de Passwordstate para distribuir actualizaciones maliciosas a los usuarios de Passwordstate.
La actualización ilícita contenía un archivo DLL modificado titulado Moserware.SecretSplitter.dll. Se muestra una pequeña parte a continuación:
En un aviso de seguridad, Click Studios declaró: "La vulnerabilidad existió durante aproximadamente 28 horas antes de que fuera cerrada. Se cree que solo han sido afectados los clientes que realizaron actualizaciones locales entre las horas indicadas anteriormente. Las actualizaciones manuales de Passwordstate no se vieron comprometidas. Es posible que se hayan recopilado los registros de contraseñas de los clientes afectados”.
Como era de esperar, pronto llegaron los ataques de phishing contra usuarios de Click Studios; los atacantes colocaron enlaces ilícitos a una versión actualizada de malware en estos correos electrónicos.
Además de tener un aspecto técnico (es decir, la manipulación del proceso de actualización), este ataque a la cadena de suministro también tuvo un aspecto de ingeniería social. En el archivo zip de actualización falsificado, de más de 300MB, descubrí que los atacantes habían logrado alterar los manuales de usuario, los archivos de ayuda y los scripts de compilación de PowerShell para dirigir a su servidor de red de distribución de contenido (CDN) malicioso:
Uno de los documentos del manual de ayuda en el que se indica que el servidor CDN malicioso es el oficial.
Un script de instalación de PowerShell que contiene enlaces al servidor CDN malicioso.
El aspecto de ingeniería social de este ataque también demuestra otra debilidad: que los humanos (especialmente los desarrolladores o consumidores de software más nuevos) no siempre sospechan de los enlaces a redes de distribución de contenido (CDN). Esto se debe a que las CDN son utilizadas legítimamente por aplicaciones de software y sitios web para entregar actualizaciones, scripts y otros contenidos.
Los ataques de robo de tarjetas de crédito en línea, como Magecart, son un ejemplo más de este tipo de ataque a la cadena de suministro. En algunos ataques, los buckets CDN de Amazon CloudFront fueron comprometidos para distribuir el código JavaScript malicioso a un mayor número de sitios web que dependían de dichas CDN.
3. Ataques por confusión de dependencias: En el 2021, ningún artículo sobre ataques a la cadena de suministro puede estar completo sin mencionar la confusión de dependencias, especialmente debido a la naturaleza simplista y automatizada de este ataque. Los ataques por confusión de dependencias funcionan con un esfuerzo mínimo por parte del atacante y de forma automatizada debido a una debilidad de diseño inherente que se encuentra en múltiples ecosistemas de código abierto.
En pocas palabras, la confusión de dependencias (o confusión de espacios de nombres) funciona si la compilación de su software utiliza una dependencia privada creada internamente que no existe en un repositorio público de código abierto. Un atacante es capaz de registrar una dependencia con el mismo nombre en un repositorio público, con un número de versión superior. Entonces, es muy probable que la dependencia (pública) del atacante con el número de versión superior sea introducida en la compilación de su software, en lugar de su dependencia interna.
Ilustración de la vulnerabilidad de confusión de dependencias que desconcierta a múltiples ecosistemas.
Al explotar esta simple debilidad en ecosistemas de uso común, como PyPI, npm y RubyGems, el hacker ético Alex Birsan pudo hackear 35 grandes empresas tecnológicas y llevarse más de 130 mil dólares en recompensas por vulnerabilidades.
Días después de la divulgación de la investigación de Birsan, miles de paquetes imitadores de confusión de dependencias comenzaron a inundar PyPI, npm y otros ecosistemas. Aunque la mayoría de estos imitadores fueron creados por otros aspirantes a cazadores de recompensas por vulnerabilidades, algunos llegaron demasiado lejos al dirigirse maliciosamente a empresas conocidas.
Existen varias formas de resolver la confusión de dependencias. Puede registrar (reservar) los nombres de todas sus dependencias privadas en repositorios públicos antes de que lo haga un atacante y usar soluciones automatizadas, como un firewall del ciclo de vida de desarrollo de software (SDLC, por sus siglas en inglés) que evite que entren nombres de dependencias conflictivas en su cadena de suministro.
Los propietarios de repositorios de código abierto pueden adoptar un proceso de verificación más estricto y aplicar namespacing/scoping. Por ejemplo, para publicar paquetes bajo el namespacing o scoping "CSO”, un repositorio de código abierto podría verificar si el desarrollador que carga el paquete tiene derechos para hacerlo bajo el nombre "CSO”.
El repositorio de componentes Java Maven Central emplea una verificación simple basada en dominio para corroborar la propiedad del espacio de nombres, una práctica que puede ser fácilmente modelada por otros ecosistemas.
Del mismo modo, los paquetes publicados en el repositorio de paquetes de Go reciben el nombre de la URL de su repositorio GitHub, lo que hace que los ataques por confusión de dependencias sean mucho más difíciles, si no imposibles.
4. Certificados de firma de código y SSL robados: Con el aumento de los sitios web HTTPS, los certificados SSL/TLS ahora son omnipresentes y protegen las comunicaciones en línea. Por lo tanto, que la clave privada de un certificado SSL se vea comprometida podría amenazar la comunicación segura y la garantía que ofrece una conexión cifrada de extremo a extremo a los usuarios finales.
En enero del 2021, Mimecast reveló que un certificado utilizado por sus clientes para establecer una conexión a los servicios de Microsoft 365 Exchange se había visto comprometido, potencialmente afectando las comunicaciones de alrededor del 10% de los usuarios de Mimecast. Aunque Mimecast no confirmó explícitamente si se trataba de un certificado SSL, es muy probable que sea el caso, como sospechaban algunos investigadores.
Si bien un certificado SSL comprometido es problemático, un certificado de firma de código robado (es decir, una clave privada comprometida) puede tener consecuencias mucho más amplias para la seguridad del software. Los atacantes que consiguen la clave privada de firma de código pueden firmar su malware como si fuera un programa de software auténtico o una actualización enviada por una empresa acreditada.
Aunque Stuxnet sigue siendo un ejemplo significativo de un ataque sofisticado en el que los atacantes utilizaron claves privadas robadas de dos empresas destacadas para firmar su código malicioso como "de confianza”, este tipo de ataques florecieron antes de Stuxnet y continúan haciéndolo incluso años después. Por esta razón es que el ejemplo mencionado anteriormente sobre la exposición de la clave privada GPG de HashiCorp en el ataque a la cadena de suministro de Codecov es problemático. Aunque todavía no hay indicios de que los atacantes hayan abusado de la clave comprometida de HashiCorp para firmar malware, ese incidente era una posibilidad real hasta que la clave comprometida fue revocada.
5. Ataques a la infraestructura CI/CD de los desarrolladores: Sonatype observó recientemente un ataque multifacético a la cadena de suministro de software que no solo se basó en la introducción de solicitudes de extracción maliciosas al proyecto GitHub de un usuario, sino que también abusó de la infraestructura de automatización CI/CD de GitHub, GitHub Actions, para minar criptomonedas. GitHub Actions proporciona a los desarrolladores una forma de programar tareas de CI/CD automatizadas para repositorios alojados en GitHub.
La vulnerabilidad consistió en que los atacantes clonaban repositorios legítimos de GitHub que usaban GitHub Actions, alteraban ligeramente el script de GitHub Action en el repositorio y presentaban una solicitud de extracción para que el propietario del proyecto fusionara este cambio nuevamente en el repositorio original.
Informe_Ataque_Cadena_8.jpg: El atacante (edgarfox1982) presenta una solicitud de extracción para que el propietario legítimo de un proyecto fusione el código alterado.
Si el propietario de un proyecto aprueba casualmente la solicitud de extracción modificada, el ataque a la cadena de suministro ha tenido éxito, pero eso no fue todo lo que pasó en este caso. La solicitud de extracción maliciosa contenía modificaciones en ci.yml, que fueron ejecutadas automáticamente por GitHub Actions tan pronto como el atacante presentó la solicitud de extracción. El código modificado básicamente abusa de los servidores de GitHub para minar criptomonedas.
Un ataque de este tipo mata dos pájaros de un tiro: engaña a un desarrollador para que acepte una solicitud de extracción maliciosa y, si falla, abusa de la infraestructura automatizada de CI/CD existente para llevar a cabo actividades maliciosas.
Asimismo, los investigadores que consiguieron penetrar en los dominios de las Naciones Unidas (ONU) y acceder a más de 100 mil registros de personal del PNUMA, lo lograron principalmente porque encontraron carpetas Git y archivos "git-credentials” expuestos en estos dominios. Un actor de amenazas que obtenga acceso a las credenciales de Git no solo puede clonar repositorios privados de Git, sino que también puede introducir código malicioso en sentido ascendente para desencadenar un ataque a la cadena de suministro que tendría consecuencias mucho más graves.
El objetivo principal de quienes buscan prevenir ataques a la cadena de suministro ha sido recomendar prácticas de codificación seguras a los desarrolladores, o utilizar herramientas de automatización DevSecOps en entornos de desarrollo. Sin embargo, ahora es igualmente importante proteger las canalizaciones de CI/CD (por ejemplo, los servidores Jenkins), los contenedores nativos de la nube y las herramientas e infraestructuras complementarias para desarrolladores.
6. Utilización de la ingeniería social para eliminar códigos maliciosos: Como cualquier profesional de la seguridad sabe, la seguridad es tan fuerte como su eslabón más débil. Ya que el elemento humano sigue siendo el eslabón más débil, la explotación puede venir de donde menos se espera. La Fundación Linux recientemente prohibió el acceso a los investigadores de la Universidad de Minnesota que sugerían "parches” intencionalmente defectuosos que, a su vez, introducían vulnerabilidades en el código fuente del kernel de Linux.
Aunque la situación fue detectada y ya ha sido resuelta, demuestra algunos hechos simples: los desarrolladores están muy dispersos y no siempre disponen del ancho de banda necesario para examinar cada confirmación de código o cambios de código propuestos que podrían tener errores o ser maliciosos. Y, más importante aún, la ingeniería social puede proceder de las fuentes menos sospechosas: en este caso, investigadores universitarios aparentemente creíbles con una dirección de correo electrónico ".edu”.
Otro ejemplo reciente describe cómo cualquier colaborador que contribuye a un proyecto de GitHub puede alterar una versión, incluso después de su publicación. Una vez más, la expectativa del propietario de un proyecto es que la mayoría de los colaboradores envíen código y confirmaciones de buena fe. Basta con que un solo colaborador actúe de forma deshonesta para comprometer la seguridad de la cadena de suministro de muchos.
Durante el último año, los atacantes que han creado paquetes de software de typosquatting y brandjacking se han dirigido repetidamente a desarrolladores de código abierto para introducir código malicioso en sus compilaciones ascendentes, que luego se propaga a muchos consumidores.
Todos estos ejemplos reales demuestran diferentes debilidades, vectores de ataque y técnicas que los actores de amenazas emplean en ataques exitosos a la cadena de suministro. A medida que estos ataques continúan evolucionando y planteando desafíos, se necesitan soluciones y estrategias más innovadoras para abordar la seguridad del software.
Basado en el artículo de Axe Sharma (CSO) y editado por CIO Perú