Microsoft filtra por accidente las claves maestras para saltarse Secure Boot

Microsoft ha filtrado accidentalmente las claves maestras que permitirán a los hackers desbloquear los dispositivos protegidos con la característica Secure Boot de UEFI, y lo que es peor, la compañía no puede dar marcha atrás a su error.

Secure Boot es una característica de seguridad que protege un dispositivo, impidiendo que se pueda iniciar sistemas operativos no verificados. Dicho así puede sonar una gran idea, sin embargo, sectores afines a Linux se han mostrado muy críticos porque en la forma en que se ha gestionado todo se restringía la ejecución de sistemas operativos que no fuesen Windows. Actualmente, si Secure Boot está habilitado, solo se puede iniciar los sistemas operativos que incorporen una clave aprobada por Microsoft.

Sin embargo, la situación ha dado un giro radical al filtrar los investigadores MY123 y Slipstream las claves maestras (Golden Keys) de Secure Boot, pudiendo así ejecutar cualquier otro sistema operativo que no sea Windows (pudiéndose destacar Linux, Android y FreeBSD) en dispositivos protegidos por Secure Boot. Este hecho es bastante grave para Microsoft, ya que la compañía nunca podrá revocar totalmente las claves filtradas, dando a agencias como la NSA y el FBI puertas traseras que pueden ser usadas para desbloquear dispositivos Windows en casos que estén resolviendo.

El problema reside en la política de cargado del sistema de Secure Boot, donde una política especialmente firmada carga de forma rápida y desactiva la comprobación de firmas para el sistema operativo. Esta política fue creada y firmada por desarrolladores, programadores y testers de Microsoft para propósitos de depuración.

En una entrada publicada con formato bastante particular, los investigadores comentan lo siguiente sobre la filtración.

Durante el desarrollo de Windows 10 v1607 ‘Redstone’, Microsoft ha añadido un nuevo tipo de política a Secure Boot. Estas políticas complementarias están ubicadas en la partición EFIESP (en lugar de una variable de UEFI) y sus configuraciones están fusionadas dependiendo de las condiciones (es decir, que cierta política de activación también es residente y ha sido cargada).

La política complementaria no tiene un DeviceID. Y, debido a que fueron diseñadas para ser fusionadas dentro de la política base, no contienen ninguna de las normas BCD, lo que significa que si son cargadas tú puedes habilitar las pruebas de firmas, no solo para Windows, sino también el elemento {bootmgr} que permite ejecutar un fichero .efi sin firmar (como por ejemplo un bootkit). En la práctica el fichero .efi tiene que estar firmado, aunque también firmarse a sí mismo. Como puedes ver, esto es muy malo, es una puerta trasera que Microsoft ha puesto en Secure Boot debido que ha decidido no permitir a los usuarios desactivarlo en algunos dispositivos, permitiendo a Secure Boot ser desactivado en todas partes.

Recientemente Microsoft ha publicado el boletín de seguridad correspondiente a agosto, en el cual se ha publicado un parche para corregir una vulnerabilidad hallada en Secure Boot, pero que no soluciona el problema que se ha presentado.

Fuente | The Hacker News