Thu. Mar 7th, 2024

Un actor de amenazas competente puede infiltrarse fácilmente en el entorno de desarrollo de una organización y llevar a cabo un ataque a la cadena de suministro al estilo SolarWinds o Kaseya en cuestión de días, según una nueva inteligencia de Palo Alto Networks, que advierte que muchas empresas de software se han adormecido en un falsa sensación de seguridad en la cadena de suministro en la nube.

En un informe recientemente publicado sobre el estado del mercado de seguridad en la nube, que se puede descargar completo aquí, el equipo de la Unidad 42 de la empresa compartió la historia de cómo lograron penetrar con éxito en un importante proveedor de software como servicio (SaaS) y ‘ ejecutó ‘un ataque a la cadena de suministro en apenas 72 horas.

La compañía de software, que no puede ser nombrada por razones obvias, contrató los servicios de Unit 42 para irrumpir en su entorno de desarrollo de software en la nube después de haber sido asustada por el incidente de SolarWinds.

El equipo rojo de la Unidad 42 aprovechó las configuraciones incorrectas en el entorno de desarrollo para tomar el control del proceso de desarrollo de software del cliente de una manera similar a cómo un grupo de amenazas persistentes avanzadas (APT) vinculado a China pudo penetrar la plataforma de SolarWinds para introducir un actualización de código.

“Los riesgos relacionados con las cadenas de suministro han recibido mucha atención en los medios recientemente, lo que las discusiones a menudo pasan por alto es que los atacantes no necesariamente modifican los repositorios de código fuente para facilitar estas violaciones. Ellos no tienen por qué hacerlo. Encuentran debilidades en el proceso de desarrollo de software y las atacan ”, escribió Matthew Chiodi, director de seguridad en la nube de Palo Alto en el preámbulo del informe.

Los equipos rojos se hicieron pasar por desarrolladores maliciosos con acceso limitado al entorno de integración continua (CI) del cliente desde donde intentaron obtener derechos de administrador para el entorno de nube más amplio; aunque esto es algo diferente a lo que sucedió en SolarWinds, de manera similar demuestra cómo un atacante o una persona interna malintencionada podría aprovechar un repositorio de CI.

Para comenzar, a los investigadores se les asignó un rol de DevOps que el cliente comúnmente otorgaría a todos los desarrolladores en su entorno, incluido el acceso a sus repositorios internos de GitLab. Esta fue la primera falla del cliente: si hubieran seguido las mejores prácticas recomendadas sobre la separación de tareas para cada desarrollador, es posible que el ejercicio no hubiera funcionado tan bien.

Recursos en la nube

Desde aquí, los equipos rojos pudieron descargar todos los repositorios de GitLab desde la ubicación de almacenamiento del software en la nube del cliente. Aquí encontraron aproximadamente 80.000 recursos de nube individuales, incluidas máquinas virtuales (VM), bases de datos, instancias de almacenamiento, infraestructura de red y puertas de enlace de red dentro de 154 repositorios únicos. Fundamentalmente, también encontraron 26 pares de claves de administración de acceso e identidad (IAM) codificadas, cinco de los cuales eran tokens de sesión, el resto claves de acceso.

Desde aquí, el equipo rojo escaló sus privilegios utilizando las claves de IAM robadas para explotar una configuración incorrecta en una funcionalidad específica de Amazon Web Services (AWS), iam: PassRole, que les permitió crear una instancia EC2 con acceso de administrador al entorno de nube más amplio.

Con dicho acceso establecido, el equipo rojo tenía la capacidad total para realizar cualquier cantidad de acciones dentro del entorno de nube del cliente afortunado o de la víctima desafortunada. Esto incluyó el envenenamiento de operaciones de CI para insertar código malicioso en su canal de desarrollo de software, aunque como esto estaba fuera del alcance del compromiso, el ejercicio se detuvo en ese momento.

Luego se llevó a cabo un análisis más amplio de las operaciones de seguridad del cliente y la respuesta, lo que finalmente provocó que la actividad sospechosa surgiera en el centro de operaciones de seguridad del cliente (SOC) por el servicio GuardDuty de Amazon, que funcionó según lo previsto pero no se configuró correctamente en todos los AWS del cliente. cuentas y, por lo tanto, solo detectó una pequeña fracción del ejercicio general.

Sin embargo, una vez alertado, el equipo de SOC pudo identificar rápidamente cada clave de IAM comprometida utilizada por el equipo rojo y desplegó de manera efectiva sus herramientas de orquestación de seguridad, automatización y respuesta (SOAR) para desactivar las claves y cerrar el acceso.

Plan de seguridad

Posteriormente, la Unidad 42 ha trabajado extensamente con la organización confirmada para implementar un plan de seguridad de “cambio a la izquierda”, cuyos elementos (detallados en su totalidad en el informe) incluyen controles de acceso más estrictos y basados ​​en roles para que los desarrolladores eviten que los repositorios de DevOps se desvíen; la implementación de reglas de detección de plataforma en la nube para solicitudes de API sensibles provenientes de fuera del rango de red de la organización; y reglas de detección de plataforma en la nube para solicitudes de API específicas de usuario dirigidas a cuentas de servicio de IAM.

“Los ejercicios del equipo rojo … demuestran un ejemplo de cómo la mala higiene de la seguridad en la cadena de suministro puede afectar la infraestructura de la nube. El cliente, en este caso, un gran proveedor de SaaS, mantiene lo que la mayoría consideraría una postura de seguridad en la nube madura. Sin embargo, los investigadores de Unit 42 encontraron que el 21% de los análisis de seguridad que ejecutaron en el entorno de desarrollo del cliente dieron como resultado configuraciones incorrectas o vulnerabilidades, un número que se alinea directamente con el promedio de la industria del 20% ”, dijo el equipo de Unit 42 en el informe.

“Los investigadores creen que es muy probable que las técnicas empleadas durante el ejercicio del equipo rojo se puedan realizar con éxito contra muchas organizaciones que desarrollan aplicaciones en la nube”, dijeron, aunque de nuevo también es importante señalar que esta ruta de ataque en particular no era idéntica a el utilizado contra SolarWinds.

El equipo dijo que a pesar de muchas conversaciones en la comunidad de seguridad sobre el llamado modelo de cambio a la izquierda, las organizaciones evidentemente continúan descuidando la seguridad de DevOps, en parte, creen, debido a la falta de atención a las amenazas de la cadena de suministro.

Debido a que las aplicaciones nativas de la nube tienen una cadena de dependencias tan larga, como herramientas de código abierto y varios componentes de otros proveedores y desarrolladores, y estas dependencias probablemente también tengan dependencias, es fundamental que tanto los equipos de DevOps como de seguridad obtengan visibilidad completa “Lista de materiales” en cada carga de trabajo en la nube.

Demasiados, dijeron, todavía parecen creer que el escaneo de código al final del ciclo de vida del desarrollo es lo suficientemente bueno, y mientras persista esta creencia errónea, los entornos de desarrollo en la nube seguirán siendo el objetivo de los actores de amenazas.

“Este fue ciertamente el caso de la violación de SolarWinds, así como podría ha sido una infracción importante para nuestro cliente hizo que el equipo de la Unidad 42 no identificara las vulnerabilidades de la cadena de suministro del cliente antes de que lo hiciera un atacante malintencionado ”, concluyeron.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *