Ataques de TPM Sniffing contra objetivos que no son Bitlocker

Fecha:
10 junio 2022 |
Author(s):

Jos Wetzels - Consultor principal de seguridad

El año pasado, durante un repunte de la atención mediática sobre la seguridad de los módulos de plataforma de confianza (TPM) provocado por una publicación en el blog de Dolos Group en la que se describía un ataque de sniffing a Windows Bitlocker basado en un TPM, un cliente nos pidió que investigáramos su configuración de cifrado de disco completo (FDE) basada en TPM a la luz de este tipo de ataque. La investigación relacionada y los comentarios que siguieron, como el post de Dolos Group, parecen haberse centrado en los TPM tal y como los utiliza Windows Bitlocker [1], [2], [3], [4]. Como tal, pensamos que sería interesante profundizar en este escenario aplicado a otros casos de uso de TPM.

En esta entrada de blog, aprenderá sobre:

Los antecedentes del módulo de plataforma de confianza (TPM)
Nuestro modelo de amenazas
Investigación
IoT y los TPM
Consideraciones para los Red Teaming
Recomendaciones defensivas

Antecedentes

Un módulo de plataforma fiable (TPM) suele referirse a un criptoprocesador seguro dedicado conforme a la norma ISO/IEC 11889 del Trusted Computing Group (TCG). Los TPM pueden utilizarse para diversos fines, que van desde la integridad de la plataforma y el soporte FDE hasta el almacenamiento de material clave y credenciales (como para la autenticación SSH). Los TPM pueden utilizarse en diversas plataformas, desde servidores y ordenadores portátiles hasta dispositivos IoT conectados a la nube.

Existen dos versiones principales de la norma, la TPM 1.2 y la TPM 2.0, y la segunda no es compatible con la primera. Los TPM pueden implementarse de diversas maneras (siendo los dTPM y los fTPM los más comunes):

TPMs discretos (dTPM): que se presentan en forma de un chip dedicado y a prueba de manipulaciones.
TPM integrados: que se implementan como un subsistema de hardware dentro de un chip diferente.
TPMs de firmware (fTPMs): que están basados en firmware y suelen ejecutarse en el Entorno de Ejecución de Confianza (TEE) de una CPU.
TPMs de hipervisor (vTPMs): que se segmentan lejos de una máquina virtual ejecutándose encima de un hipervisor.
TPMs de software: que están basados puramente en software y son la implementación menos segura.

Para la integridad de la plataforma, los TPM proporcionan mecanismos para soportar el arranque medido. Partiendo de un núcleo raíz de confianza para la medición (CRTM) (por ejemplo, la ROM de arranque de algún SoC), se calculan hashes de varios componentes de la plataforma (por ejemplo, BIOS/UEFI, cargador de arranque, firmware del controlador integrado, etc.) y se almacenan en ranuras del registro de configuración de la plataforma (PCR). Esta información puede incorporarse al proceso de arranque seguro (posiblemente como parte de FDE) para garantizar que estos diversos componentes no han sido manipulados.

Los TPM también proporcionan mecanismos de apoyo a las soluciones de cifrado para ofrecer garantías de confidencialidad y autenticación de la integridad. Estos mecanismos incluyen la generación de claves, la capacidad de cifrar el material clave con una clave específica del TPM y características resistentes a la manipulación para que el TPM funcione como un almacenamiento seguro de secretos. El uso de una clave protegida por el TPM por sí sola se denomina normalmente vinculación, mientras que la adición de valores PCR de arranque medidos a la mezcla criptográfica se denomina normalmente sellado.

En los escenarios de cifrado, los TPM pueden configurarse normalmente en uno de varios modos:

Sólo TPM: aquí, el TPM suministra automáticamente la clave a la solución de cifrado cuando se le solicita (por ejemplo, en el arranque).
TPM + PIN: aquí, el TPM necesita un secreto suministrado por el sistema (normalmente un PIN introducido por el usuario) antes de desvelar la clave.
TPM + PIN + MFA: aquí, se requiere un factor adicional, como una llave USB con un secreto o TOTP.

En el caso de FDE, hay que proporcionar secretos adicionales antes del arranque. Las características resistentes a la manipulación en el TPM (deberían) impedir el forzamiento bruto de los PIN, la extracción de claves privadas y el glitching para eludir estas características.

Aunque en el pasado se han producido sondeos invasivos, diversos ataques de canal lateral, de interposición y de diseño e implementación contra los TPM, en este post sólo nos centraremos en los ataques de sniffing contra los dTPM en escenarios de soporte FDE, ya que este tipo de ataques son inherentes al diseño de los dTPM.

Dado que los dTPM son chips dedicados separados de la CPU principal y de otros controladores de un dispositivo, necesitan alguna forma de comunicarse con ellos. El estándar especifica los buses LPC, I2C y SPI para este propósito, y el dTPM tendrá que colocarse en un bus junto con cualquier dispositivo que pueda necesitar hablar con él (dependiendo de si hay roles mono o multimaestro).

Para simplificarlo un poco, durante la configuración del cifrado, la CPU se apropia del TPM, lo configura y envía una clave al TPM para su vinculación o sellado. El TPM cifra esta clave utilizando datos de autenticación, su propia clave secreta y medidas PCR opcionales y envía de vuelta el blob de clave cifrada. Este blob se almacena entonces en algún lugar (normalmente como parte de una cabecera de volumen encriptada). Durante el descifrado, la CPU envía el blob de clave cifrado al TPM, y los datos de autenticación y las mediciones opcionales son obtenidos por el TPM y utilizados junto con su clave secreta para descifrar el blob. La clave en texto plano se envía de nuevo a la CPU para su uso.

Por lo tanto, en algún momento del proceso de descifrado, la clave en texto plano puede enviarse por el bus a la CPU en texto plano por diseño. Aunque el estándar TPM 2.0 permite la llamada"encriptación de parámetros", esta característica rara vez es implementada por las soluciones de encriptación y, como señala Trammell Hudson, viene con el problema del huevo y la gallina del establecimiento de la confianza sin la capacidad de almacenar secretos en la CPU principal.

Modelado de amenazas

Nuestro modelo de amenaza operaba bajo el supuesto de un atacante con acceso físico durante un tiempo limitado a un dispositivo que utilizaba una solución FDE compatible con dTPM. Esto suponía que se había realizado el aprovisionamiento/la puesta en marcha y que los datos en cuestión estaban cifrados. Aunque toda una serie de otras amenazas entran dentro de este ámbito, nos centramos específicamente en husmear el bus TPM, ya que las mediciones PCR son irrelevantes en este escenario.

Investigación

Durante nuestra investigación, comparamos Windows 10 Bitlocker con TPM contra varias implementaciones FDE basadas en Linux, siendo éstas: systemd-cryptsetup, clevis, luks-tpm2, safeboot y coreboot. El TPM en cuestión era un módulo Infineon OPTIGA SLB 9670 TPM 2.0 con una interfaz SPI (aunque obviamente, este escenario funciona contra I2C y LPC, como se ha demostrado anteriormente).

Como podemos ver, el cifrado de parámetros simplemente no se utiliza en la práctica, y salvo safeboot ninguna de las soluciones aplica PIN/MFA por defecto. Aunque no examinamos en detalle pureboot, U-Boot, tboot y TrustedGRUB2, sospechamos que se aplican conclusiones similares en estos casos.

Para ayudar a otros a evaluar y demostrar la viabilidad de los ataques de sniffing TPM contra las implementaciones FDE basadas en Linux, desarrollé dos plugins Saleae Logic 2, como se muestra a continuación. Están disponibles en Github.

Todas las soluciones que investigamos se basan en el Linux Unified Key Setup (LUKS). Los volúmenes LUKS2 tienen una cabecera con un área de keyslot que contiene diferentes keyslots para diferentes contraseñas o archivos de claves que pueden utilizarse para descifrar el volumen. Estas entradas de ranura para claves especifican información sobre la derivación de claves como la prioridad, la función de derivación de claves, los parámetros, la sal y el algoritmo de cifrado. A continuación, se descifra una clave maestra (MK) cifrada, almacenada en franjas antiforense (AF), utilizando la clave derivada.

Para utilizar LUKS junto con un TPM, la mayoría de las soluciones (system-cryptsetup, safeboot, luks_tpm2) hacen uso de tpm2-tools, una especie de kit de herramientas similar a BusyBox para interactuar con la pila de software (TSS) TPM2 del Trusted Computing Group (TCG).

En systemd-cryptsetup, se registra un token TPM y se vincula a una ranura LUKS2. Con un comando `cryptsetup luksDump /dev/sda1 --debug-json`, podemos ver que el token contiene una entrada tpm2-blob codificada en base64 que se envía al TPM para su desprecintado. El tráfico de desprecintado es bastante fácil de detectar en un bus SPI y consiste en una operación TPM_READ sobre TPM_DATA_FIFO_0 (d40024) con una estructura de datos consistente en un DWORD con valor 00000022 seguido de un campo de longitud de tamaño WORD (normalmente con valor 0020) y la posterior clave de 256 bits.

Mi plugin Saleae Logic formatea la clave para la salida del fichero de claves LUKS:

El montaje de un volumen puede hacerse con `cryptsetup open ./sda1-luks myvolumename --key-slot 1 --key-file ./mykey --keyfile-size 44`.

Aunque luks-tpm2 funciona de forma un poco diferente, puede almacenar claves en un archivo sellado en el disco o en la NVRAM del TPM y tiene soporte de frase de contraseña para el desprecintado. Su operación de desprecintado parece la misma a través del bus SPI, y el complemento también funciona aquí. Safeboot parece la más robusta de las soluciones investigadas, ya que obliga a los usuarios a utilizar el PIN por defecto, y funciona de forma un poco diferente bajo el capó, pero el plugin tpm2-tools también funciona para ésta.

Clevis es un marco de descifrado automatizado enchufable con una serie de 'pines' (no confundir con un PIN), donde cada pin implementa el soporte criptográfico utilizando un backend diferente. Para el cifrado, Clevis toma algunos datos y una configuración JSON para producir un objeto JSON Web Encryption (JWE) que contiene los datos cifrados mediante una JSON Web KEY (JWK) y algunos metadatos. Al descifrar, Clevis obtiene la clave de la JWK y los metadatos y descifra el texto cifrado del JWE.

El "pin" tpm2 de Clevis genera una JWK, crea un objeto en el TPM con la JWK como dato secreto y lo vincula o sella al TPM. El JWE resultante (asociado a una ranura de clave LUKS2) contiene tanto las partes sensibles públicas y selladas del objeto creado como los metadatos relacionados con el desprecintado. En el momento del descifrado, el "pin" tpm2 toma el JWE, lo carga en el TPM, desprecinta el JWK y descifra el texto cifrado en el JWE.

Como resultado de este enfoque, el tráfico SPI del TPM parece un poco diferente. Lo que estamos buscando es una operación TPM_READ sobre TPM_DATA_FIFO_0 (d40024) con una estructura de datos consistente en un DWORD con valor 00000072, seguido de un campo de longitud variable de tamaño WORD, seguido de un montón de datos JSON.

Mi plugin Saleae Logic valida el JSON y extrae la clave y los metadatos relevantes:

IoT y los TPM

Los dispositivos IoT suelen caer bajo el típico modelo de amenaza de "acceso físico por parte de un adversario", especialmente para aquellos dispositivos desplegados en lugares públicos o en los que el usuario es un adversario potencial. Varios casos de uso relacionados requieren algún tipo de funcionalidad del subsistema de seguridad de confianza, como la autenticación del dispositivo, la identificación, el mantenimiento seguro, la atestación remota y la protección de los datos en reposo y en tránsito.

Aunque muchos dispositivos IoT utilizan coprocesadores seguros que no se ajustan al estándar TPM, tanto las plataformas AWS como Azure pueden utilizarse para el aprovisionamiento seguro de dispositivos y la protección de tokens/credenciales.

Como se ilustra a continuación, el enfoque de Azure para Windows 10 IoT Core es bastante típico para este caso de uso. Aquí se establece una clave de acceso compartida (SAK) entre el dispositivo IoT y la nube durante el proceso de aprovisionamiento, suministrando a la nube las partes públicas de la clave de endoso (EK) y la clave raíz de almacenamiento (SRK) del TPM. La SAK se imprime en el TPM en el extremo del dispositivo, mientras que en el extremo de la nube, el dispositivo físico se asocia a un ID de dispositivo en el concentrador de dispositivos de la nube. Siguiente, se genera un token de Firma de Acceso Compartido (SAS ), que especifica una solicitud de acceso asociada a determinadas políticas. Este token es firmado por el TPM utilizando una clave HMAC con el SAK.

La implementación del TPM del Núcleo IoT de Windows 10 tampoco utiliza el cifrado de parámetros. Como tal, el SAK podría ser olfateado durante el aprovisionamiento (que no es un escenario muy preocupante), y los tokens SAS podrían ser olfateados durante las operaciones. Dependiendo del modelo de amenazas del dispositivo, esta última cuestión podría ser un problema. Además, un atacante con acceso físico al dispositivo IoT podría simplemente solicitar al TPM la firma de datos arbitrarios, ya sea interponiéndose en el bus o eliminando el TPM por completo.

La defensa contra este tipo de amenazas en los dispositivos IoT se complica por el hecho de que el control de acceso al TPM, en forma de PIN, se complica por la necesidad típica de una interacción nula del usuario durante las operaciones (o de usuarios en los que no se confía en absoluto). Y el simple almacenamiento del PIN para su introducción automática por la CPU principal produce un problema del huevo y la gallina. Por ello, se me ocurren dos líneas de defensa complementarias para los dispositivos IoT protegidos con TPM en los que el acceso físico es una preocupación:

Diversificación y revocabilidad. Para limitar el impacto de los secretos comprometidos, deben diversificarse para cada dispositivo durante el aprovisionamiento, de modo que el compromiso de un solo dispositivo no se extienda a toda la flota al estilo "pwn-once, exploit everywhere". Además, los secretos de autenticación deberían ser revocables, para que la telemetría defensiva sea procesable.

Resistencia a la manipulación. Dado que los TPM no tienen la capacidad de conectarse directamente a interruptores antimanipulación externos, deberían integrarse en un subsistema protegido en el que la activación del interruptor antimanipulación desencadene inmediatamente el borrado del secreto del TPM. En el mejor de los casos, la activación del interruptor antimanipulación también genera alertas en el backend para que puedan iniciarse los procesos de revocación.

Consideraciones para los equipos rojos

Llevar a cabo un ataque de sniffing de TPM en la práctica no es exactamente lo mismo que hacerlo en condiciones de laboratorio. Los ataques de rastreo de TPM contra soluciones FDE pueden ser una herramienta poderosa en el arsenal de un equipo rojo y encajan en una amplia gama de modelos de amenazas, como atacantes físicos con acceso en las instalaciones, portátiles desatendidos/robados, personas con información privilegiada no autorizadas e interceptación de la cadena de suministro. Sin embargo, todos estos escenarios tienen en común que la ventana dentro de la cual los operadores de los equipos rojos pueden ejecutar su ataque es limitada. Se requiere cierto grado de sigilo, por lo que entrar completamente a ciegas y andar a tientas durante media hora mientras se planifican los minutos y se deja atrás un portátil montado a toda prisa puede hacer que todo esto sea más difícil de llevar a cabo en la práctica que por motivos puramente técnicos.

En primer lugar, la accesibilidad de las comunicaciones del bus TPM puede variar enormemente. En la mayoría de los trabajos anteriores, los investigadores optaron por acoplar pinzas de prueba SOIC8 o sondas grabadoras a algún chip que casualmente se encontraba en el mismo bus que el TPM. Sin embargo, puede encontrarse con diseños de placas base en los que ninguno de los chips del bus TPM tenga un tipo de encapsulado de fácil acceso. Roscar los pines del bus en un chip TQFP, QFN o BGA es bastante más complicado que en los bonitos y fáciles chips SOIC. A veces tendrá suerte y habrá almohadillas grandes o puntos de prueba cercanos, pero en otros casos, necesitará utilizar sondas de aguja o algunas habilidades de soldadura de alambre muy fino. Y entonces podría resultar que usted esperaba comunicaciones SPI mientras que en esta revisión de placa base, el TPM todavía utilizaba LPC...

En otros casos, los chips y/o los puntos de prueba son simplemente de difícil acceso. Pueden estar ocultos bajo capas de plástico y revestimiento, encajados bajo los brazos de los ventiladores o en el otro lado de la placa base, lo que requiere un desmontaje y volteo completo. Y todo eso tendrá que volver a montarse de forma discreta y en condiciones de funcionamiento antes de que le pillen.

Para evitar sorpresas y tanteos innecesarios, los operadores del equipo rojo deben realizar los siguientes preparativos cuando ejecuten un ataque de sniffing TPM:

Recopilar inteligencia sobre la solución FDE desplegada y su configuración (¿se utiliza PIN?), y asegurarse de que se dispone de herramientas de análisis para ella.
Recopile inteligencia sobre los modelos de portátiles en uso, obtenga los esquemas, asegúrese de que el utillaje puede manejar el tipo de bus en cuestión y, al menos, practique unas cuantas veces con el modelo en cuestión.
Recopile información sobre las medidas antimanipulación (etiquetas de seguridad, interruptores, etc.) que se utilicen y prepárese en consecuencia.
Asegúrese de llevar una solución rápida de clonación de discos para copiar el texto cifrado de la unidad para su posterior descifrado, no querrá hacerlo sobre la marcha, ni esperar horas.

Derrotar un factor adicional en la práctica no será trivial. Aún así, dos posibles vías podrían ser los ataques de manipulación y reversión basados en bootkits y dejar un diminuto implante de hardware con capacidades de bus-sniffing en la placa base. Al introducir el factor adicional y desprecintar el secreto TPM, el implante podría almacenarlo para su posterior recuperación física o, posiblemente, exfiltrarlo a través de una capacidad de comunicación integrada (RF, 4G, etc.) en función del espacio disponible y las capacidades de miniaturización. Trammell Hudson presentó una gran charla sobre este tema para un caso de uso relacionado en el 35C3.

Recomendaciones defensivas

Existen muchos consejos defensivos sólidos sobre este tema, incluidos los de Microsoft[1],[2], pero en términos generales, el endurecimiento de las soluciones FDE basadas en TPM se reduce a los siguientes principios:

Implemente un factor adicional como un PIN, una contraseña o un TOTP para regular el desprecintado del TPM.
Utilice un fTPM en lugar de un dTPM si es posible.
Configure el TPM para la integración de arranque medido en la configuración FDE para protegerlo contra amenazas de firmware.
Implemente precintos de seguridad a prueba de manipulaciones en los dispositivos sensibles (aunque el grado de ayuda varía mucho).