En 2012, una coalición de fabricantes de hardware y software de todo el sector adoptó el Secure Boot para protegerse contra una amenaza de seguridad que se venía gestando desde hacía tiempo. La amenaza era el espectro de un malware que podía infectar el BIOS, el firmware que cargaba el sistema operativo cada vez que se iniciaba una computadora. A partir de ahí, podría permanecer inmune a la detección y eliminación y podría cargarse incluso antes que el sistema operativo y las aplicaciones de seguridad.

• Dispositivos vendidos por Acer, Dell, Gigabyte, Intel y Supermicro. La causa: una clave criptográfica en la que se basa se vio comprometida en 2022

La amenaza de este malware alojado en el BIOS era en gran medida teórica y se alimentó en gran parte por la creación de ICLord Bioskit por un investigador chino en 2007. ICLord era un rootkit, una clase de malware que obtiene y mantiene un acceso oculto subvirtiendo las protecciones clave integradas en el sistema operativo. La prueba de concepto demostró que estos rootkits de BIOS no solo eran factibles, sino que también eran poderosos. En 2011, la amenaza se convirtió en realidad con el descubrimiento de Mebromi, el primer rootkit de BIOS (ahora denominados Bootkit) conocido que se utilizó en la práctica.

Los arquitectos de Secure Boot, muy conscientes de Mebromi y de su potencial para una nueva clase de ataque devastador, idearon una nueva y compleja forma de reforzar la seguridad en el entorno previo al arranque. Integrado en UEFI (Unified Extensible Firmware Interface), que se convertiría en la sucesora de BIOS, Secure Boot utiliza criptografía de clave pública para bloquear la carga de cualquier código que esté firmado con una firma digital aprobada previamente. Hasta el día de hoy, los actores clave en seguridad (entre ellos Microsoft y la Agencia de Seguridad Nacional de los EE.UU.) consideran que Secure Boot es una base importante, si no esencial, de confianza para proteger los dispositivos en algunos de los entornos más críticos, incluidos los de control industrial y redes empresariales. 

Una evasión ilimitada de Secure Boot

El jueves, los investigadores de la empresa de seguridad Binarly revelaron que Secure Boot está completamente comprometido en más de 200 modelos de dispositivos vendidos por Acer, Dell, Gigabyte, Intel y Supermicro.

La causa: una clave criptográfica que sustentaba el arranque seguro en esos modelos que se vio comprometida en 2022. En un repositorio público de GitHub publicado en diciembre de ese año, alguien que trabajaba para varios fabricantes de dispositivos con sede en EE.UU. publicó lo que se conoce como "clave de plataforma PK", la clave criptográfica que forma el ancla de raíz de confianza entre el dispositivo de hardware y el firmware que se ejecuta en él. El repositorio estaba ubicado en https://github.com/raywu-aaeon/Ryzen2000_4000.git, y no está claro cuándo fue eliminado.

El repositorio incluía la parte privada de la clave de la plataforma en forma cifrada. Sin embargo, el archivo cifrado estaba protegido por una contraseña de cuatro caracteres, una decisión que hizo que fuera trivial para Binarly, y cualquier otra persona con una mínima curiosidad, descifrar el código de acceso y recuperar el texto sin formato correspondiente.

La divulgación de la clave pasó en gran medida desapercibida hasta enero de 2023, cuando los investigadores de Binarly la encontraron mientras investigaban un incidente en la cadena de suministro. Ahora que la filtración ha salido a la luz, los expertos en seguridad afirman que torpedea de manera efectiva las garantías de seguridad ofrecidas por Secure Boot.

"Es un gran problema", dijo Martin Smolár, un analista de malware especializado en rootkits que revisó la investigación de Binarly. "Básicamente, se trata de una evasión ilimitada de Secure Boot para estos dispositivos que utilizan esta clave de plataforma. Por lo tanto, hasta que los fabricantes de dispositivos o los OEM proporcionen actualizaciones de firmware, cualquiera puede básicamente… ejecutar cualquier malware o código no confiable durante el arranque del sistema. Por supuesto, se requiere acceso privilegiado, pero eso no es un problema en muchos casos".

Los investigadores de Binarly dijeron que sus escaneos de imágenes de firmware descubrieron 215 dispositivos que utilizan la clave comprometida, que se puede identificar por el número de serie del certificado 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. Una tabla de afectados aparece en este artículo.

Los investigadores pronto descubrieron que el compromiso de la clave era solo el comienzo de una falla mucho mayor en la cadena de suministro que plantea serias dudas sobre la integridad del arranque seguro en más de 300 modelos de dispositivos adicionales de prácticamente todos los principales fabricantes de dispositivos. Como es el caso de la clave de plataforma comprometida en la filtración de GitHub de 2022, otras 21 claves de plataforma contienen las cadenas "DO NOT SHIP" o "DO NO TRUST".

 Estas claves fueron creadas por AMI, uno de los tres principales proveedores de kits de desarrollo de software que los fabricantes de dispositivos utilizan para personalizar su firmware UEFI para que funcione en sus configuraciones de hardware específicas. Como sugieren las cadenas, las claves nunca estuvieron pensadas para ser utilizadas en sistemas de producción. En cambio, AMI las proporcionó a los clientes o posibles clientes para que las probaran. Por razones que no están claras, las claves de prueba llegaron a los dispositivos de una lista casi inagotable de fabricantes. Además de los cinco fabricantes mencionados anteriormente, se incluyen Aopen, Foremelife, Fujitsu, HP, Lenovo y Supermicro.

PKfail

Binarly ha llamado a su descubrimiento PKfail en reconocimiento al enorme error en la cadena de suministro resultante de la falla en toda la industria para administrar adecuadamente las claves de la plataforma. El informe está disponible aquí. Los videos de prueba de concepto están aquí y aquí. Binarly ha proporcionado una herramienta de escaneo aquí.

Los cuatro recursos clave para que funcione el Arranque seguro son:

• La clave de plataforma o PK: proporciona el ancla root-of-trust en forma de una clave criptográfica integrada en el firmware del sistema. Establece la confianza entre el hardware de la plataforma y todo el firmware que se ejecuta en él.
• La clave de intercambio de claves o KEK: es la clave que establece la confianza entre el sistema operativo y el firmware de la plataforma.
• La base de datos de firmas o DB: una base de datos que contiene firmas y certificados de confianza para los componentes UEFI de terceros y los cargadores de arranque aprobados por el fabricante del hardware.
• La base de datos de firmas prohibidas o DBX: una base de datos de firmas y certificados que se utiliza para revocar los componentes de arranque que antes eran de confianza para que ya no puedan ejecutarse durante el arranque. Las actualizaciones tanto de la base de datos como de la DBX deben estar firmadas por una KEK en la base de datos KEK de Arranque seguro.

El informe de Binarly señaló un incidente ocurrido en 2016, identificado como CVE-2016-5247, en el que los investigadores de seguridad descubrieron varios dispositivos Lenovo que compartían la misma clave de prueba AMI. En ese momento, el problema se describió como un problema que permitía a "usuarios locales o atacantes físicamente próximos eludir el mecanismo de protección de arranque seguro aprovechando una clave de prueba AMI".

"Es un problema enorme", afirma Matrosov. "Si pensamos en un complejo de apartamentos en el que todas las cerraduras de las puertas tienen la misma llave, si se pierde una de ellas, puede crear problemas para todos".

Fuente: Arstechnica

Vía:
https://blog.segu-info.com.ar/2024/07/pkfail-secure-boot-roto-en-mas-de-200.html