Dos investigadores han publicado recientemente como Microsoft proporcionó sin querer la “llave maestra” para permitir deshabilitar el Secure Boot una de las medidas de seguridad más importantes dentro del firmware UEFI y es que mantener en secreto un backdoor incluido en el código es misión casi imposible con una comunidad de investigadores tan activa.
El añadir un backdoor universal en nuestro software, en un primer momento puede parecer tener algo de lógica para permitirnos un acceso permanente a diversas funciones en principio cerradas en el mismo pero realmente es un grave error de seguridad. Microsoft está sufriendo en sus carnes esta práctica ya que, obviamente, de manera no intencionada distribuyó la llamada “llave dorada” que permite desbloquear cualquier dispositivo protegido por Secure Boot.
Secure Boot, parte del firmware de la UEFI, es cargado por el bootmgr en un estadio muy temprano del arranque. Al ser activado impide que se ejecute un sistema operativo u otro software no firmado por Microsoft. Secure Boot está presente y activado por defecto en dispositivos que incluyen Windows 8.1 en adelante y en estos el usuario final no tiene posibilidad de desactivarlo. Almenos no tenía hasta que Microsoft publicó por error esta llave maestra para desactivar a Secure Boot.
Esta llave maestra no se trata de una clave privada PKI que permita firmar binarios para que los cargue el bootmgr sino una técnica que permite alterar las tareas ejecutadas por la UEFI en el arranque. En principio esta llave maestra se supone que fue introducida para llevar a cabo procesos internos de depuración y para permitir a los programadores probar nuevas versiones del sistema operativo pero se ha convertido en una via de entrada que supone un grave peligro para todos estos tipos de dispositivos ya que esta revelación permitiría instalar sistemas operativos alternativos pero también ejecutar malware y/o instalar bootkits y rootkits.
Microsoft cometió el error en el desarrollo de Windows 10 v1607, en esta versión se añadieron políticas adicionales a Secure Boot almacenadas en la partición EFIESP en vez de en una variable UEFI y que se debían incluir en las políticas ya existentes en la UEFI. El bootmgr de esa versión carga primero las políticas previas de las variables UEFI pero luego deja de realizar todas las comprobaciones a las políticas adicionales. Entre estas se incluyen cambios para las condiciones de inclusión con las políticas previas, condiciones que no eran comprobadas por bootmgr al cargar una política antigua (de una versión previa de Windows 10) ya que el bootmgr de esta versión previa no contenía estas nuevas políticas y por tanto no podía comprobarlas. Para estos bootmgrs antiguos se cargaba una política firmada y valida. Esto en la práctica permite cargar .efi no firmadas (o autofirmadas), por ejemplo un bootkit y drivers no firmados para Windows, por ejemplo un rootkit.
En un primer momento según explican los investigadores, Microsoft consideró su descubrimiento como algo menor y sin mucha importancia, aunque poco más tarde se reconsideró el asunto se pagó a los investigadores una recompensa y desde entonces se han lanzado ya 2 actualizaciones (MS16-094 y MS16-100) con una tercera en camino. Aunque se supone que será imposible cerrar del todo este backdoor ya que si se invalidaran todos los bootmgr anteriores a esa posible actualización, se inutilizarian todos los medios de instalación (dvds..), copias de seguridad y particiones de recuperación anteriores a ese momento... algo totalmente inadmisible.
Los investigadores aprovechan en su curiosa web para dirigirse en modo de mofa al FBI a modo de recordatorio sobre los graves peligros e inconvenientes de las llaves maestras. Recordemos que desde el FBI se ha demandado en diversas ocasiones que las grandes empresas tecnológicas incluyan un backdoor universal para poderlo utilizar en sus investigaciones y no encontrarse con problemas para acceder a dispositivos y datos encriptados.
Fuente my123 y slipstream
