¿Cuáles son las posibles consecuencias del ataque de la "llave de oro" de Windows 10 a los usuarios finales, en términos simples?

8

Hoy en día, los medios tecnológicos están discutiendo el descubrimiento de un backdoor integrado oculto dentro de la función SecureBoot de los sistemas operativos móviles con Windows 10. Parece que, a partir de una lectura superficial de la naturaleza de la vulnerabilidad, esa explotación requiere acceso físico. Es decir, no parece ser un ataque que se pueda realizar de forma remota; un atacante tendría que robar el dispositivo para utilizarlo.

¿Qué tipo de uso podría tener esta vulnerabilidad para un atacante con respecto a los usuarios finales (qué tipo de escenarios se abre a un atacante), y qué pasos (si los hay) atenúan el usuario final?

    
pregunta Bradley Evans 12.08.2016 - 06:50
fuente

1 respuesta

3

SecureBoot es una parte de UEFI y de otros firmwares que se pueden usar para verificar firmas en el software que se cargará en el arranque. Normalmente, este es un gestor de arranque, pero también puede ser el propio sistema operativo.

En algunas implementaciones, el usuario puede "grabar" un certificado personalizado para que el firmware lo utilice para la validación. En otros casos, los certificados son precargados por el fabricante y solo el software firmado por ellos puede usarse en el dispositivo.

Los dispositivos integrados, como teléfonos y tabletas, generalmente se encuentran en la segunda categoría, donde el usuario no puede cambiar el software instalado, excepto cuando el fabricante lo permita (es decir, una actualización del sistema operativo).

Al romper este bloqueo, los usuarios podrían instalar lo que quieran. Esto suele denominarse "jailbreaking" al dispositivo.

El problema con el jailbreaking es que también permite a los malos actores comprometer el dispositivo a un nivel bajo, lo que hace que las amenazas sean más persistentes y difíciles de detectar.

Los diferentes dispositivos han tenido diferentes métodos para hacer jailbreak a través de los años. En este caso, fue un error de Microsoft el que lo permitió. De el escrito original (quizás NSFW) :

  

[la política de arranque seguro es] un archivo en formato binario que está incrustado   dentro de un blob ASN.1, que está firmado. Se carga por bootmgr REALMENTE   temprano en el proceso de arranque de Windows. Debe estar firmado por un   certificado en db. Se carga desde una variable UEFI en el   espacio de nombres de secureboot (por lo tanto, solo puede ser tocado por boot   servicios). Hay un par .efis firmado por MS que puede proveer tales   una política, es decir, establecer la variable UEFI con su contenido como el   política.

Este es un esquema muy inteligente y extensible que se rompió por una omisión durante el desarrollo:

  

Durante el desarrollo de Windows 10 v1607 'Redstone', MS agregó un nuevo   Tipo de política de arranque seguro. A saber, las políticas "suplementarias" que son   ubicado en la partición EFIESP (en lugar de en una variable UEFI), y   fusionar sus configuraciones, dependiendo de las condiciones (a saber, que un   cierta política de "activación" también existe, y se ha cargado   en).   [...] La política "suplementaria" contiene nuevos elementos, para la fusión   condiciones Estas condiciones son (bueno, a la vez) no marcadas por   bootmgr al cargar una política heredada. Y bootmgr de win10 v1511 y   Anteriormente, ciertamente no sabe acerca de ellos. Para aquellos bootmgrs, tiene   acaba de cargar una política firmada y perfectamente válida.

En otras palabras, tienen una política firmada que les permite cargar archivos binarios sin firmar, presumiblemente para permitir probar versiones de desarrollo sin tener que firmar cada una.

Ellos enviaron accidentalmente esta política en algunos dispositivos, alguien la descubrió y la publicó, y ahora se puede cargar en cualquier dispositivo.

El artículo incluye muchos más detalles sobre cómo funciona. El punto es que este es un exploit de jailbreak. Para algunos son buenas noticias, para otros no tanto.

La explotación exitosa requiere derechos de administrador o acceso físico.

@Bradley mencionó en los comentarios que "hace que sea más fácil para el malware que ya está en tu PC controlar el progreso del arranque y superar completamente a tu PC". Si bien es cierto, significa que el malware ya tenía derechos de administrador en el dispositivo, por lo que el compromiso de arranque es el menor de tus problemas.

Microsoft ha declarado:

  

La técnica de jailbreak descrita en el informe de los investigadores de agosto   10 no se aplica a sistemas de PC de escritorio o empresariales. Requiere   Acceso físico y derechos de administrador a dispositivos ARM y RT y   no compromete las protecciones de cifrado.

Pero eso puede haber sido un eufemismo. Lanzaron dos parches: MS16-094 y MS16-100. El primero dice:

  

Un atacante debe tener privilegios administrativos o físicos   acceso para instalar una política y omitir el arranque seguro.

     

Esta actualización de seguridad se considera importante para todas las ediciones compatibles de   Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012   R2, y Windows 10.   [...]   La actualización de seguridad corrige la vulnerabilidad mediante la inclusión en listas negras   Políticas afectadas.

Por lo tanto, es cualquiera de acceso raíz o físico, como se mencionó anteriormente.

Y afecta a los escritorios y servidores (consulte la discusión de comentarios para especular sobre por qué podrían haber dicho que no).

Además, la lista negra de políticas se consideró insuficiente: revertir a un bootmgr anterior aún podría permitir que se cargue la política (esto se menciona en el informe). El segundo parche también enlista a los administradores de arranque antiguos para solucionarlo.

TL; DR : parchea tus sistemas de Windows y no te preocupes demasiado por esto. Hay problemas mucho peores.

    
respondido por el GnP 29.08.2016 - 18:33
fuente

Lea otras preguntas en las etiquetas