jugando a esconderse

Nov 03, 2023

21 de octubre de 2022

En la Parte 1, explicamos qué son los enclaves Intel SGX y cómo benefician a los autores de ransomware. En la Parte 2, exploramos una implementación hipotética paso a paso y describimos las limitaciones de este método.

Mire esta demostración de ataque en vivo para ver cómo la plataforma CrowdStrike Falcon® y el equipo administrado de detección y respuesta de CrowdStrike Falcon Complete™ protegen contra el ransomware.

En esta sección, construimos un ejemplo paso a paso de un ransomware que usa enclaves para el cifrado asimétrico. El ransomware se divide en dos partes:

Los extractos del código presentado aquí provendrán del núcleo normal de la aplicación (main.c) o del enclave (enclave.c). El enclave generará un par de claves RSA, sellará la clave privada y cifrará los datos de la víctima dentro del enclave utilizando la API Intel SGX. Echemos un vistazo a cómo se hace esto y cómo interactúa el núcleo de la aplicación con el enclave.

Primero, el núcleo normal de la aplicación inicializa los recursos necesarios para la ejecución del ransomware, incluida la creación y configuración del enclave. Para cargar el enclave usamos la función sgx_create_enclave(), de sgx_urts.lib.1 El prototipo de la función es:

Los argumentos de esta función representan algunos de los atributos del enclave, como el modo de compilación o información sobre cargas anteriores. Por ejemplo, sgx_launch_token_t es una estructura opaca que representa el token de lanzamiento del enclave. La información del token contiene información sobre el enclave a lo largo de su ejecución y se puede guardar para facilitar futuras cargas del enclave.

Figura 1. Extracto de código creando el enclave (Click para agrandar)

Una vez que se carga el enclave, el núcleo normal de la aplicación puede ejecutar una ECALL para iniciar el proceso de generación de claves.

Dentro del enclave, la generación de claves se basa en el Intel SGX SDK denominado sgx_tcrypto.lib. Esta es una API documentada a la que se puede llamar directamente desde el enclave. En el fondo, la API se basa en otras bibliotecas criptográficas desarrolladas por Intel: Integrated Performance Primitives (Intel® IPP) y la biblioteca criptográfica Intel® Software Guard Extensions SSL (Intel® SGX SSL),2 ambas basadas en OpenSSL .

El primer paso en este proceso es generar componentes RSA para las claves públicas y privadas del enclave utilizando la función sgx_create_rsa_key_pair(). Esta es una llamada preliminar, realizada antes de las llamadas de función que crean claves, que se utiliza para generar componentes que cumplan con el tamaño del módulo de clave RSA predefinido y el exponente público.

Figura 2. Extracto del código que genera los componentes de las claves RSA (Haga clic para ampliar)

A partir de estos componentes de la clave RSA, utilizamos la función sgx_create_rsa_pub1_key() para generar la clave pública RSA que se utilizará para cifrar los archivos de la víctima.

Figura 3. Extracto del código que crea la clave pública RSA (Haga clic para ampliar)

El siguiente paso lógico normalmente sería generar la clave privada, como hicimos con la clave pública. En este caso, sin embargo, todavía no necesitamos la clave privada, ya que la clave privada solo se utilizará para descifrar, en caso de que la víctima cumpla con las demandas de los autores del ransomware. En este momento, solo necesitamos almacenar y ocultar de forma segura los componentes de la clave privada para permitir su futura recuperación. Con este fin, utilizamos el método de sellado de datos para garantizar que la clave privada se pueda escribir y almacenar cifrada en el disco, sin que aparezca nunca como texto sin cifrar en la memoria normal del sistema operativo.

Una forma de hacerlo es generando la clave privada y luego sellándola directamente en el disco, pero no procederemos de esta manera. Considere el prototipo de función del Intel SGX SDK3 que genera la clave privada que se muestra a continuación.

Tenga en cuenta que el valor de la clave privada se escribe en un vacío** pero, en el fondo, la estructura real utilizada es una estructura EVP_PKEY, una estructura compleja que se origina en la biblioteca OpenSSL.

Figura 4. Extracto de código que define la estructura EVP_PKEY, de la biblioteca openssl (Haga clic para ampliar)

Por lo tanto, si quisiéramos sellar la clave privada, necesitaríamos usar la estructura EVP_PKEY. No obstante, la arquitectura de desarrollo de enclave no está diseñada para importar fácilmente bibliotecas externas, por lo que usar la biblioteca Open SSL directamente sería engorroso. De lo contrario, podríamos intentar recrear la estructura desde cero, pero esto requeriría varias operaciones de análisis. Dada la complejidad de almacenar la clave privada en la estructura adecuada, es mucho más fácil guardar los componentes de la clave privada y construir la clave privada en una etapa posterior. Para respaldar este proceso, creamos una estructura para recopilar los componentes de la clave privada.

Figura 5. Extracto de código que define la estructura PrivateKey (Haga clic para ampliar)

Ahora tenemos los medios para sellar los componentes de la clave privada para un posible descifrado futuro. Usaremos los mismos valores producidos cuando generamos los componentes clave y los asignaremos a los campos apropiados en nuestra estructura PrivKeyComp personalizada. Una vez configurada correctamente la estructura, podemos sellar los componentes de la clave privada con sgx_seal_data_ex(), desde sgx_tservice.lib.4

Figura 6. Extracto del código que sella los componentes de la clave privada RSA (Haga clic para ampliar)

Aquí usamos sgx_seal_data_ex(), la versión extendida de sgx_seal_data(), que nos permite usar la política MRENCLAVE. Elegimos esta política porque garantiza que otros enclaves firmados por los mismos autores del enclave no podrán acceder a los datos sellados. Si se roba la firma del enclave del atacante, podría usarse para desbloquear los datos.

Una vez sellados, los componentes de la clave privada pueden devolverse al núcleo normal de la aplicación y escribirse en el disco.

A partir de este punto, tenemos dos opciones para cifrar los datos de la víctima. La primera opción es devolver la clave pública al núcleo normal de la aplicación y cifrar los archivos de la víctima fuera del enclave. La otra opción es mantener la clave pública dentro del enclave y usar funciones de la API Intel SGX para cifrar los datos de la víctima. Este último es más complejo que un proceso de encriptación clásico fuera del enclave, pero usaremos este método para demostrar las posibilidades de la programación SGX.

La parte no confiable de la aplicación se encarga de abrir y leer el expediente de la víctima. Para obtener los datos cifrados que se generarán dentro del enclave, debemos inicializar el búfer de salida en el núcleo normal de la aplicación. De lo contrario, el búfer generado dentro de la memoria protegida no podrá enviarse al espacio no confiable.

El cifrado se realiza con la función sgx_rsa_pub_encrypt_sha256(), que realiza un esquema de cifrado RSA-OAEP con SHA-256. Esto calcula una operación de cifrado y codificación para los búferes, que está limitada al tamaño del módulo n de RSA, y da como resultado un búfer de la misma longitud. En este caso, dado un módulo RSA n de 256 bytes, el búfer de salida de sgx_rsa_pub_encrypt_sha256() tendrá una longitud de 256 bytes.5 Como tal, asignamos un búfer de 256 bytes para el búfer de salida que contendrá los datos cifrados.

A continuación, enviaremos este búfer de salida con el búfer que contiene los datos para cifrar.

Figura 7. Extracto de código que encripta el contenido de un archivo, desde la página principal (Haga clic para ampliar)

El enclave recibe los búferes y utiliza la clave pública que se ha generado previamente para realizar el cifrado. Esto se hace en tres pasos. El primer paso es llamar a sgx_rsa_pub_encrypt_sha256() para obtener el tamaño del búfer cifrado resultante. Una vez que se devuelve el tamaño, comprobamos que corresponde a 256 bytes (el tamaño que asignamos al búfer de salida). Si coincide, realizamos una segunda llamada a sgx_rsa_pub_encrypt_sha256() para obtener los datos cifrados en el búfer de salida.

Figura 8. Extracto de código cifrando el contenido de un archivo, del enclave (Click para ampliar)

Finalmente, el núcleo regular de la aplicación anula el contenido del archivo original con el contenido encriptado, devuelto desde el enclave.

La misma lógica se aplica al proceso de descifrado. Los datos sellados se envían al enclave, que los abre con sgx_unseal_data() y almacena los componentes de la clave privada en la variable global PrivKeyComp. Los datos cifrados se envían al enclave, construye la clave privada utilizando la variable global PrivKeyComp como parámetros para sgx_create_rsa_priv2_key() y luego descifra los datos con la función sgx_rsa_priv_decrypt_sha256(). Luego, los datos descifrados se devuelven al núcleo normal de la aplicación, que anula los archivos cifrados con el texto claro original.

Como hemos establecido, el uso de enclaves tiene beneficios considerables, como garantizar que los objetivos del ransomware no puedan recuperar sus claves de descifrado. Sin embargo, esta táctica también tiene limitaciones considerables, que explican su prevalencia limitada en los ataques de ransomware.

Primero, los enclaves tienen especificaciones de hardware estrictas. Dado que SGX es una tecnología propietaria, requiere una CPU Intel. Aunque AMD tiene una tecnología equivalente llamada ARM TrustZone, el código compilado basado en bibliotecas Intel SGX no funcionará en CPU que no sean de Intel. Además, solo ciertos modelos de CPU Intel son compatibles con SGX, ya que Intel ha desaprobado la función para las generaciones de escritorio de procesador de núcleo 11 y 12.6 Como requisito final de hardware, la función Intel SGX debe habilitarse desde el BIOS, lo cual no se hace por defecto.

Teniendo en cuenta todos estos requisitos, la probabilidad de que un sistema de destino pueda ejecutar un binario utilizando enclaves es muy baja. Además, dado que es posible que el uso de la tecnología SGX no esté habilitado en todos los sistemas infectados, las posibilidades de infectar con éxito un objetivo son considerablemente bajas, especialmente en comparación con los métodos de ransomware más comunes.

Anteriormente en este blog, explicamos que los enclaves deben completar un proceso de verificación para compilarse en modo de lanzamiento. No obstante, un enclave compilado en modo de depuración aún se puede ejecutar en una máquina habilitada para Intel SGX si las bibliotecas requeridas se importan con el binario malicioso. El tamaño de los binarios necesarios para el ataque sería mucho mayor que el de un binario de ransomware clásico, pero tal escenario es plausible.

Además, si los atacantes tienen la intención de utilizar un enclave en modo de lanzamiento, es posible que el proceso de verificación de Intel no los detecte si el enclave solo parece generar un par de claves RSA y recibe búferes para cifrar y sellar datos. En tal situación, ¿cómo determinaría Intel si el enclave tiene fines maliciosos?

Investigadores de la Universidad Tecnológica de Graz afirman que "Intel no inspecciona ni firma enclaves individuales, sino que incluye claves de firma en listas blancas que se utilizarán a discreción de los desarrolladores de enclaves para firmar enclaves arbitrarios".7 Citan el ejemplo de un estudiante independiente que ha completó con éxito el proceso de Intel para obtener una clave de firma. Esto plantea la cuestión de si los autores de malware podrían usar enclaves pasando por el proceso de lista de permitidos de Intel.

Otra posibilidad para los autores de ransomware sería robar una firma legítima. Esto agrega otro nivel de complejidad al ataque, pero ya se ha hecho en el pasado. En este caso, tan pronto como se detecta el ataque y se informa a Intel, Intel revoca la firma de enclave utilizada de la lista de permitidos, evitando que se cargue el enclave malicioso. Ya sea que la firma sea robada o adquirida legítimamente, el riesgo de descubrimiento crece rápidamente tan pronto como la campaña de ransomware está en marcha, lo que plantea la cuestión de la vigencia de la validez de la firma.

Para brindar más flexibilidad en el uso de enclaves, en 2018 Intel lanzó la alternativa de control de lanzamiento flexible.8 Esta característica permite que terceros controlen qué enclaves se pueden cargar en máquinas configuradas apropiadamente, sin pasar por el proceso de verificación de Intel. Requiere que las máquinas de destino admitan y habiliten la función de control de inicio flexible, configurada en el BIOS de cada máquina. Este enfoque requiere tener acceso al BIOS antes de la infección y tener derechos de administrador para configurar el entorno, los cuales agregan complejidad al ataque.

Dentro del enclave, el código se ejecuta en un contexto específico, lo que da como resultado una ejecución más lenta que en un entorno de sistema operativo normal. Cuanto más tarde en ejecutarse el ransomware, más probable es que el usuario sea alertado de una actividad sospechosa y tenga tiempo de reaccionar ante ella, lo que pone en peligro aún más las posibilidades de realizar un ataque exitoso.

Intel no considera los ataques de canal lateral como parte del modelo de amenazas SGX. La Guía para desarrolladores de Intel® Software Guard Extensions9 establece: "Intel SGX no brinda protección explícita contra ataques de canal lateral. Es responsabilidad del desarrollador del enclave abordar las inquietudes de los ataques de canal lateral".

Esto implica que hay formas de observar lo que sucede dentro de un enclave y, por lo tanto, potencialmente interceptar la clave de descifrado, lo que subraya aún más que el uso de enclaves está lejos de ser infalible y se filtró con éxito en el pasado, que se analiza en el artículo "SGAxe: How SGX falla en la práctica". 10

También hay límites a la seguridad de la clave sellada escrita en el disco.

La guía para desarrolladores de Intel establece: "Los enclaves, independientemente de la cantidad de subprocesos de confianza definidos, no deben diseñarse con la suposición de que la aplicación que no es de confianza invocará las funciones de la interfaz ISV siguiendo un orden específico. Una vez que se inicializa el enclave, un atacante puede invocar cualquier función de interfaz ISV, organice las llamadas en cualquier orden y proporcione cualquier parámetro de entrada. Tenga en cuenta estas tácticas para evitar abrir un enclave a los ataques". 11

Una pregunta reciente en el foro de la comunidad de Intel planteó si diferentes aplicaciones utilizan el mismo enclave, a lo que Intel respondió: "No existe una forma integrada de evitar que una aplicación que no es de confianza cargue el enclave de otra".12 Como tal, ¿los investigadores forenses deberían recuperar el enclave? binario utilizado en un ataque de ransomware y la clave privada sellada, podrían recrear una aplicación que interactúe con el enclave para que revele la clave privada, al menos en modo de depuración.

En la práctica, la creación de una aplicación de este tipo requiere importar el archivo .edl del enclave, que contiene la definición de ECALL. Dado que es poco probable que este archivo se importe en los binarios del ataque, la única opción sería reconstituir el archivo .edl, lo que podría complicarse aún más si los atacantes ofuscan los binarios del enclave.

En un escenario en el que la clave privada ha sido sellada mediante la política MRSIGNER, la seguridad de la clave sellada se cuestiona aún más. Si los investigadores forenses pueden recuperar la firma del autor del enclave, podrían recrear un enclave firmado de manera similar con el apoyo de Intel y hacer que este nuevo enclave revele los datos. De hecho, dado que los datos se sellaron con la firma del autor del enclave, otro enclave con la misma firma podría abrirlos.

Si bien cada una de estas limitaciones agrega restricciones al ataque, todas pueden mitigarse. Tener la función SGX habilitada se puede omitir con unos pocos pasos previos a la infección. Para facilitar el uso de enclaves, Intel lanzó una aplicación de activación13 que permite a los usuarios habilitar Intel SGX en plataformas basadas en procesadores Intel Core compatibles, simplemente haciendo clic en el botón "Activar", como se muestra en la Figura 9. La aplicación debe ser se ejecuta con privilegios de administrador, pero un enfoque de ingeniería social podría hacer que una víctima haga clic fácilmente en un botón desde una aplicación legítima.

Figura 9. Captura de pantalla de la aplicación de activación de Intel® Software Guard Extensions (haga clic para ampliar)

Una vez que el sistema de destino tiene habilitada la función Intel SGX, un atacante podría eludir los requisitos de firma mediante el uso de un binario de enclave compilado en modo de depuración para incorporar dependencias en el ataque. Para acelerar la ejecución de su código, podrían usar una implementación de subprocesos múltiples o un proceso de cifrado externalizado dentro del núcleo normal de la aplicación. Además, si el binario del enclave se elimina por completo del sistema infectado después del ataque, el atacante puede estar seguro de que la clave privada sellada no se abrirá hasta que lo permita. Finalmente, es muy poco probable que los ataques de canal lateral se configuren antes de la infección, lo que hace que sea muy poco probable que estos puedan frustrar con éxito un ataque de ransomware utilizando enclaves.

La tecnología Intel SGX ofrece a los desarrolladores una oportunidad única para proteger su código. Revisamos cómo la arquitectura de los enclaves proporciona un entorno propicio para proteger los datos confidenciales e incorpora diferentes mecanismos para manipularlos de forma segura, como el sellado.

Aunque esto puede ser beneficioso en las operaciones del día a día, también puede ser explotado con fines maliciosos, como vimos en el caso de la gestión de claves criptográficas por parte de los autores de ransomware. Los enclaves permiten a los autores de ransomware generar claves criptográficas de forma segura y segura, lo que evita que las víctimas de ataques aprovechen dos de los escenarios más comunes que los autores de ransomware quieren evitar: recuperar claves de descifrado y prevenir infecciones con objetivos fuera de línea.

La baja prevalencia del uso de enclaves por ransomware se debe en gran medida a las limitaciones técnicas impuestas por Intel SGX. Sus requisitos de hardware y la obsolescencia para futuras generaciones de CPU reducen las posibilidades de que los sistemas de destino puedan cumplir con todas las condiciones requeridas para la ejecución del enclave. Además, liberar un enclave en modo de producción requiere pasar por el proceso de firma de Intel que, si se completa con éxito, da como resultado una firma que se puede revocar rápidamente de la noche a la mañana, lo que reduce aún más las posibilidades de ejecución exitosa del ransomware.

Como hemos demostrado, los autores de ransomware no pueden depender exclusivamente de enclaves para orquestar ataques, pero pueden beneficiarse de su uso para la gestión de claves criptográficas. Dado que existen usos legítimos para los enclaves, un enfoque preventivo de estos ataques de ransomware no debe basarse exclusivamente en la detección de la carga de un enclave.

Como parte de nuestro compromiso de permitir que los clientes tengan visibilidad continua en toda su organización, el sensor CrowdStrike Falcon tiene visibilidad sobre el uso de enclaves y utiliza estos datos junto con la telemetría de eventos para determinar si un proceso es malicioso y para responder a las amenazas detectadas. Al final, un enclave es solo una pista, nada más y nada menos.

Vea usted mismo cómo la plataforma CrowdStrike Falcon líder en la industria protege contra amenazas modernas como el ransomware. Comience su prueba gratuita de 15 días hoy.

Regístrese ahora para recibir las últimas notificaciones y actualizaciones de CrowdStrike.

Detecte, prevenga y responda a los ataques, incluso a las intrusiones libres de malware, en cualquier etapa, con la protección de punto final de última generación.