PKfail, el fallo que deja fuera de combate el Arranque Seguro

Los investigadores de seguridad advierten que algunos fabricantes de PC y servidores están utilizando claves criptográficas no seguras como base de confianza para el Arranque Seguro, una importante característica de seguridad en los ordenadores modernos que impide que el malware se active en las primeras fases del proceso de arranque. Una de esas claves se ha filtrado accidentalmente, lo que podría romper las garantías de Arranque Seguro de cientos de modelos de ordenadores de siete fabricantes. Sin embargo, casi 900 modelos en los últimos 12 años están utilizando claves que probablemente se generaron con fines de prueba y que nunca deberían haberse utilizado en producción. según un informe de la empresa de seguridad Binarly, que denominó el problema PKfail. A principios de este año, nos dimos cuenta de que la clave privada de American Megatrends International (AMI) vinculada a la "clave maestra" de Secure Boot, llamada Platform Key (PK), había quedado expuesta públicamente en una filtración de datos", escriben los investigadores. "El incidente ocurrió en un ODM [original design manufacturer] Responsable del desarrollo de firmware para muchos proveedores de terminales, incluido uno con sede en Estados Unidos. Estos dispositivos que coinciden con esta clave todavía se utilizan en el campo y la clave también se utiliza en terminales empresariales lanzados recientemente.

El arranque seguro es una característica de la Interfaz de firmware extensible unificada (UEFI), que es la sucesora del BIOS (sistema básico de entrada/salida) tradicional que se encuentra en las computadoras más antiguas. En principio, el arranque seguro garantiza que el sistema solo se inicie con software y firmware confiables. Garantizar la integridad del proceso de arranque es fundamental, ya que el código malicioso que se ejecuta en esta etapa temprana toma el control total del sistema operativo, deshabilitando o eludiendo sus características de seguridad. Antes de que el arranque seguro fuera ampliamente adoptado, muchos programas maliciosos inyectaban código en el cargador de arranque de las computadoras comprometidas o en el propio BIOS/UEFI. Estos bootkits (rootkits de nivel de arranque) brindan a los atacantes una persistencia de alto nivel en los sistemas comprometidos y la capacidad de ocultar archivos y procesos de cualquier producto de seguridad de puntos finales que se ejecute en esos sistemas. El arranque seguro utiliza cifrado de clave pública, con cifrado de clave pública almacenado en la UEFI que se usa para validar los componentes firmados con las claves privadas correspondientes. En el corazón del sistema se encuentra una clave pública llamada “Platform Key”: se supone que la genera el fabricante del ordenador y, según los investigadores de Binarly, debería renovarse periódicamente y, idealmente, no reutilizarse en otras líneas de productos para limitar el impacto de una vulneración. Además, la clave privada debería almacenarse de forma segura en módulos de seguridad de hardware (HSM), desde donde no pueda ser robada o divulgada fácilmente.

Una clave privada raíz que no tiene lugar en un repositorio público de GitHub

Bajo ninguna circunstancia la clave privada raíz para una característica de seguridad tan importante debería terminar en un repositorio público en GitHub, como sucedió con la clave de plataforma AMI encontrada por Binarly. Ese no es el único problema. AMI es uno de los tres proveedores independientes de BIOS (IBV) que producen implementaciones UEFI de referencia para fabricantes de PC y OEM, quienes luego personalizan esas implementaciones para sus productos. Binarly cree que generar nuevas claves de plataforma debería ser parte de este proceso de personalización, porque los fabricantes de PC deberían ser responsables de sus "plataformas", no un tercero. El certificado de clave pública de la clave privada filtrada tiene un campo de nombre común que dice "NO CONFÍE - AMI Test PK". Sin embargo, se ha utilizado en cientos de modelos de siete proveedores diferentes.

“Es probable que esta clave se incluyera en su implementación de referencia con la expectativa de que fuera reemplazada por otra clave generada de forma segura por entidades más abajo en la cadena de suministro”, escriben los investigadores. “Las claves de prueba se comparten con socios comerciales y proveedores con la expectativa de que serán tratadas como claves no confiables. Además, la clave AMI filtrada se utilizó en muchas líneas de productos, desde computadoras portátiles para juegos hasta placas base para servidores, lo que aumentó enormemente el impacto de la filtración en todas las industrias y para todos los tipos de usuarios”.

¿Cómo pueden los atacantes abusar de la clave filtrada?

Secure Boot tiene cuatro ubicaciones de claves y bases de datos en UEFI. La clave de plataforma, que se utiliza para validar todos los componentes del firmware, y otra clave, llamada clave de intercambio de claves (KEK), son el núcleo de este sistema. La KEK se puede utilizar para actualizar una base de datos llamada db, que contiene las firmas de los cargadores de arranque y otros componentes EFI de terceros que pueden ejecutarse, como el cargador de arranque de Windows o el cargador de arranque de Linux. También puede actualizar dbx, una base de datos que contiene una lista negra de firmas, como las de los cargadores de arranque vulnerables. Un atacante con acceso privilegiado al sistema operativo de una computadora que explote la fuga de PK puede generar otra KEK, firmarla e insertarla en la ubicación de la KEK utilizando herramientas como efi-updatevar. Luego puede utilizar su nueva clave para modificar la base de datos de firmas db para agregar la firma de un módulo .efi malicioso que creó y colocó en la partición EFI del disco. Este módulo se ejecutará en el momento del arranque, lo que le permitirá controlar el arranque de Windows y el kernel.

Los atacantes ya están explotando vulnerabilidades conocidas en Secure Boot para implementar bootkits. El año pasado, los investigadores de ESET Han advertido sobre un nuevo bootkit UEFI llamado BlackLotus que explota una vulnerabilidad de Windows conocida como Baton Drop (CVE-2022-21894) para eludir la función a través de componentes vulnerables del cargador de arranque. Por lo tanto, no sería sorprendente que los atacantes comenzaran a explotar una fuga de la clave de la plataforma. Hace dos años, los investigadores de Eclypsium descubrieron vulnerabilidades que podrían usarse para eludir el arranque seguro, mientras que Binarly expuso otros 12 fallos que podrían conducir a la ejecución remota de código antes del arranque en implementaciones UEFI. No se puede descartar la posibilidad de que la PK de prueba AMI cayera en manos equivocadas. Según los investigadores de Binarly, el repositorio que contenía la clave se eliminó después de cuatro meses, pero se necesitaron cinco meses para eliminar todas las bifurcaciones. La clave privada no se almacenó en texto sin formato y estaba cifrada, pero protegida solo por una contraseña de cuatro caracteres que se podía descifrar en segundos utilizando herramientas básicas de reconocimiento de contraseñas.

El uso de claves de plataforma AMI de prueba en binarios de firmware es común.

Después de encontrar la clave filtrada, los expertos descubrieron informes de 2016 de que algunas claves de la plataforma contenían palabras como "NO CONFÍE" y "clave de prueba". Incluso había un identificador de vulnerabilidad (CVE-2016-5247) generada en ese momento para varios modelos de Lenovo utilizando claves de prueba AMI. Pero la clave filtrada se encontró en el firmware lanzado ya en 2018 y más recientemente este año. Para averiguar si la práctica sigue siendo común, los investigadores de Binarly analizaron su base de datos de decenas de miles de binarios de firmware recopilados a lo largo de los años e identificaron 22 PK de prueba AMI diferentes con advertencias de "NO CONFÍE" o "NO ENVÍE". Estas claves se encontraron en binarios de firmware UEFI para casi 900 placas base de computadoras y servidores diferentes de más de 10 proveedores, incluidos Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo y Supermicro. Juntos, representaron más del 10% de las imágenes de firmware en toda la base de datos.

Estas claves no son fiables, ya que probablemente se han compartido con muchos proveedores, OEM, ODM y desarrolladores, y es posible que se hayan almacenado de forma insegura. Es posible que algunas de ellas ya se hayan filtrado o robado en incidentes no descubiertos. El año pasado, una banda cibernética relacionada con el fabricante de placas base y ordenadores Micro-Star International (MSI) publicó un volcado de datos Incluye una clave privada OEM de Intel y, un año antes, una filtración de datos de Lenovo incluía el código fuente del firmware y claves de firma de Intel Boot Guard.

Binarly ha creado una escáner en línea permitiendo a los usuarios enviar copias del firmware de su placa base para verificar si utiliza una clave de prueba, y se incluye una lista de los modelos de placa base afectados. El boletín Desafortunadamente, los usuarios no pueden hacer mucho hasta que los proveedores proporcionen actualizaciones de firmware con nuevas claves de prueba generadas de forma segura, suponiendo que sus modelos de placa base aún sean compatibles. El primer uso de estas claves de prueba que encontró Binarly se remonta a 2012.