Bl0ckch41nnews#PKFail: Secure Boot roto en más de 200 modelos de 5 grandes fabricantes de dispositivos

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.

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

Source link