Cómo participaron los certificados X.509 en el ataque a SolarWinds

Por un momento, estuvimos dispuestos a dejar atrás 2020, hasta esta semana.

Todo empezó con el robo de las herramientas del Red Team de FireEye, y luego llegaron las noticias más importantes. FireEye y los departamentos del Tesoro y Comercio de Estados Unidos habían sido infiltrados a través de las actualizaciones de SolarWinds Orion software , que incluían código malicioso inyectado por el grupo de hacking Cozy Bear (APT 29), respaldado por Rusia.

Esta noticia no sólo afecta a SolarWinds, FireEye y las agencias gubernamentales estadounidenses, nos afecta a todos. Cuando una nación-estado ataca a uno de nosotros, nos ataca a todos, y todos sentimos el aguijón. Es un recordatorio aleccionador de nuestra realidad cotidiana: cualquiera puede ser víctima de un ataque.

Aunque aún no se han revelado todos los detalles del ataque, ahora conocido como SUNBURST, hemos aprendido mucho más sobre nuestros adversarios y sobre cómo consiguieron burlar las defensas.

Desglosemos lo que sabemos hasta ahora:

• El⁸ de diciembre, FireEye reveló el robo de sus herramientas de evaluación Red Team de un repositorio de GitHub. A pesar del revuelo, la mayoría de estas herramientas y exploits ya eran conocidos.
• El¹³ de diciembre, FireEye descubrió en su propia investigación que el ataque implicaba código malicioso que se insertaba en actualizaciones legítimas de software de SolarWinds Orion Platform que databan de entre marzo de 2020 y mayo de 2020.
• El mismo día, los departamentos del Tesoro y de Comercio de Estados Unidos anunciaron que sus sistemas habían sido vulnerados por un grupo de piratas informáticos respaldado por Rusia y conocido como CozyBear (APT 29). CISA publicó entonces la Directiva de Emergencia 21-01, "Mitigar el compromiso del código de SolarWinds Orion".
• El ¹⁵ de diciembre, Microsoft requisó el nombre de dominio malicioso utilizado para controlar los sistemas afectados con el fin de prevenir e incluso mitigar el ataque con un "interruptor de desactivación".

Averiguar el alcance y la escala de este incidente llevará probablemente un tiempo, pero durante la semana pasada hemos aprendido mucho sobre las herramientas y técnicas utilizadas por los atacantes.

A medida que se asienta el polvo y surgen más detalles, una cosa ha quedado clara: los atacantes utilizaron indebidamente certificados y claves X.509 como parte de su conjunto de herramientas para suplantar la confianza y evitar ser detectados. Empezó con SolarWinds, pero no acaba ahí.

Un artículo publicado recientemente por el Centro de Respuesta de Seguridad de Microsoft repasa algunos de los detalles técnicos del ataque a la cadena de suministro. He aquí algunas claves sobre cómo los atacantes utilizaron los certificados X.509 para falsificarlos y socavar la confianza:

Un rastro de migas de pan nos lleva de vuelta a SolarWinds, donde los atacantes modificaron el código fuente para incluir una puerta trasera maliciosa, que luego fue compilada, firmada y entregada sin saberlo por SolarWinds a casi 18.000 clientes a través de sus sistemas de actualización y firma de código software .

La brecha inicial no fue el resultado de un certificado de firma de código robado, sino que la biblioteca manipulada fue firmada por SolarWinds, haciendo que pareciera legítima para los sistemas de los usuarios finales. Aunque no hay pruebas de que el certificado de firma o el proceso en sí estuvieran comprometidos, el proceso de creación y revisión previo a la firma sí lo estaba, lo que permitió que el código malicioso se colara.

Tampoco es la primera vez. Los ciberdelincuentes utilizan cada vez más la confianza en la que confiamos. Ataques similares a la cadena de suministro implicaron el robo de certificados de firma de código, como los ataques llevados a cabo por APT41 y Kimsuky, o la introducción de código manipulado a través del proceso de firma, como el ataque a ASUS del año pasado.

Según Microsoft, "una vez en la red, el intruso utiliza los permisos administrativos adquiridos a través del compromiso en las instalaciones para obtener acceso a la cuenta de administrador global de la organización y/o al certificado de firma de token SAML de confianza."

En este caso, los atacantes falsificaban tokens SAML y los firmaban con certificados legítimos comprometidos para hacerse pasar por usuarios y cuentas de confianza, lo que les permitía moverse lateralmente sin ser detectados.

En algunos casos, el actor malicioso realizó modificaciones en la configuración de Azure Active Directory para obtener acceso a largo plazo, incluyendo "añadir credenciales (claves X.509 o credenciales de contraseña) a una o más aplicaciones OAuth legítimas..."

Una vez que han conseguido un punto de apoyo, la siguiente prioridad de los atacantes suele ser encontrar la forma de permanecer dentro. En este caso, utilizaron certificados X.509 para crear un acceso OAuth legítimo a la red.

Como he mencionado antes, no existe una solución milagrosa para prevenir estos sofisticados ataques. Se trataba de un ataque muy sofisticado en el que intervenían muchas herramientas y técnicas diferentes.

No estamos aquí para especular, sino para concienciar sobre un problema creciente que vemos en el sector: el aumento del uso indebido y el robo de claves y certificados digitales. No se trata de esta brecha, ni de la siguiente, sino de la necesidad de rastrear y supervisar eficazmente el uso de certificados en las aplicaciones, la nube y la infraestructura de red.

Estas son algunas de las mejores prácticas recomendadas para mitigar el uso indebido de claves y certificados:

• Mantenga un inventario activo de todos los certificados, dónde están instalados, quién los emitió y quién es su propietario (y de sus dominios).
• Controle la emisión de certificados y los flujos de trabajo de aprobación para garantizar que todos los certificados son de confianza, cumplen la política y están actualizados.
• Pruebe regularmente sus capacidades de reemisión y revocación de certificados para asegurarse de que puede responder eficazmente a un compromiso.
• Nunca almacene claves de firma de código en estaciones de trabajo de desarrolladores o servidores de compilación. Las claves privadas deben guardarse en un HSM validado por FIPS 140-2 y nunca deben salir de hardware.
• Separe las funciones entre quién está autorizado a firmar código, quién puede aprobar la solicitud y quién puede supervisar y hacer cumplir las políticas de firma.
• Defina políticas para limitar el acceso a las claves de firma de código por usuario, máquina, ubicación, duración, hora del día, método de firma u otros parámetros que tengan sentido para su organización.

Si desea obtener más información sobre las tendencias que estamos observando en lo que respecta al uso (y mal uso) de la criptografía, consulte nuestro Informe de tendencias en criptografía 2021.