En 2012, una coalición de fabricantes de hardware y software 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.
La amenaza del malware en el BIOS
La amenaza de este malware alojado en el BIOS era en gran medida teórica, pero se alimentó con 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.
Secure Boot como solución
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.
PKfail: una falla crítica
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».