Una filtración reciente de una "Llave de Oro" de Microsoft, junto con la presencia de un modo de depuración, ha permitido desactivar el arranque seguro en dispositivos Windows. ¡Sigue leyendo!
Los sistemas operativos basados en Windows ya no son la opción principal y predeterminada en la escena móvil. La naturaleza de código abierto de Android ha encontrado muchos seguidores en los fabricantes de equipos originales y, como resultado, cada vez menos teléfonos utilizan Windows en estos días.
Pero si usted es uno de los que todavía continúa usando un dispositivo Windows en su vida diaria, hay algunas noticias para usted. Bueno o malo, eso dependerá de su postura e interpretación de los casos de uso de esta noticia.
Según lo informado por Ars Técnica y El registro con la noticia proveniente de un sitio web que probablemente te dará dolor de cabeza (no es broma), algunos desarrolladores (@never_released y @TheWack0lian) descubrieron que una puerta trasera que Microsoft creó con fines de depuración ha abierto posibilidades para deshabilitar el arranque seguro en dispositivos Windows.
Arranque seguro y ¿qué es?
Cuando inicia por primera vez un dispositivo Windows, el procedimiento de inicio sigue este orden general: UEFI (Interfaz de firmware extensible unificada, que reemplaza al BIOS) -> Administrador de arranque -> Cargador de arranque -> Ventanas. UEFI es donde está presente la funcionalidad de arranque seguro. Como su nombre lo indica con Arranque seguro, Su objetivo es mejorar la seguridad al exigir firmas digitales. sobre los próximos pasos. Básicamente, si el gestor de arranque no está firmado con las claves que UEFI espera que esté, el procedimiento de arranque de su dispositivo no se completará.
El arranque seguro es una característica opcional, pero Microsoft ha hecho que habilitarla sea obligatorio para obtener la certificación de Windows desde Windows 8 en adelante. El razonamiento aquí fue que el arranque seguro dificultaría que los autores de malware insertaran código en el procedimiento de arranque. Sin embargo, un efecto secundario del arranque seguro fue que hacía un poco complicado el arranque dual en máquinas con Windows, ya que o el segundo sistema operativo y todos sus requisitos previos también deben estar firmados digitalmente, o el arranque seguro debería realizarse desactivado. Hay muchos otros problemas relacionados con esto, y los usuarios experimentados de arranque dual sabrían sobre ellos más de lo que podría explicar en un párrafo.
Ahora bien, hay algunos dispositivos en los que el usuario no puede desactivar el arranque seguro incluso si así lo desea. Este es el ámbito donde nuestro tema se reduce drásticamente a todos los dispositivos Windows (incluidos escritorios) a dispositivos Windows específicos como dispositivos Windows Phone, dispositivos Windows RT, algunos dispositivos Surface e incluso HoloLens. Estos dispositivos de usuario final tienen Arranque seguro bloqueado, lo que significa que un El usuario final no puede modificar ni desactivar aspectos relacionados con el arranque seguro.y, por extensión, no pueden tocar el sistema operativo de maneras no autorizadas por Microsoft para el usuario final.
Pero a los efectos del desarrollo oficial continuo, el arranque seguro necesita relajarse un poco. En los dispositivos en los que el arranque seguro está bloqueado, existen políticas de arranque seguro que pueden ayudar con el desarrollo autorizado sin necesidad de desactivar el arranque seguro. Como mencionan los usuarios investigadores, el Administrador de arranque carga este archivo de política de arranque seguro al principio del proceso de arranque de Windows. Los archivos de política también pueden contener reglas de registro que a su vez tienen la capacidad de contener configuraciones para la política misma, entre otras cosas. Nuevamente, el archivo de política debe estar firmado y existen otras disposiciones para garantizar que solo Microsoft pueda implementar estos cambios.
El elemento de firma también se basa en lo que se llama DeviceID, que se utiliza al realizar la solicitud. Dejaré que la publicación del blog explique aquí, ya que hay algunas partes que no me quedan tan claras:
Además, existe algo llamado DeviceID. Son los primeros 64 bits de un hash SHA-256 salado, de alguna salida UEFI PRNG. Se usa al aplicar políticas en Windows Phone y en Windows RT (mobilestartup lo configura en Phone y SecureBootDebug.efi cuando se inicia por primera vez en RT). En el teléfono, la política debe estar ubicada en un lugar específico de la partición EFIESP con el nombre del archivo incluyendo la forma hexadecimal del ID del dispositivo. (Con Redstone, esto se cambió a UnlockID, que lo configura bootmgr y es solo la salida UEFI PRNG sin procesar).
Básicamente, bootmgr verifica la política cuando se carga; si incluye un DeviceID que no coincide con el DeviceID del dispositivo en el que se ejecuta bootmgr, la política no se cargará. Cualquier política que permita habilitar la firma de pruebas (MS llama a estas políticas de desbloqueo de dispositivo minorista/RDU, y para instalarlos es desbloquear un dispositivo), se supone que está bloqueado en un DeviceID (UnlockID en Redstone y arriba). De hecho, tengo varias políticas (firmadas por el certificado de producción de Windows Phone) como esta, donde las únicas diferencias son el DeviceID incluido y la firma. Si no hay una política válida instalada, bootmgr recurre a una política predeterminada ubicada en sus recursos. Esta política es la que bloquea la habilitación de la firma de pruebas, etc., utilizando reglas BCD.
Esta es la parte donde las cosas se ponen interesantes. Durante el desarrollo de Windows 10 v1607, Microsoft creó un nuevo tipo de Política de arranque seguro (de ahora en adelante denominada SBP en aras de la brevedad) para fines de prueba y depuración interna. La política es de naturaleza "suplementaria" sin ningún ID de dispositivo presente y hace que su configuración se combine con una política de inicio existente. El Administrador de arranque carga los tipos más antiguos de SBP, luego verifica su firma y autenticidad y luego carga estas políticas de arranque suplementarias. El problema aquí es que no hay más verificación de la póliza complementaria en sí. Además, los administradores de arranque anteriores a Windows 10 v1511 no conocen la existencia de la naturaleza complementaria de estas políticas y, por lo tanto, reaccionar como si cargaran una póliza perfectamente válida y firmada. Nuevamente, este comportamiento probablemente se debió al desarrollo interno, por lo que los desarrolladores no deberían haber tenido que firmar todas y cada una de las versiones del sistema operativo y los cambios menores que tuvieron que hacer en el dispositivo.
A este SBP se le conoce como la "llave de oro", ya que básicamente anula el propósito de los controles de firmas. Este SBP se envió involuntariamente en dispositivos minoristas, aunque estaba desactivado. Los desarrolladores encontraron este SBP y dieron a conocer sus hallazgos. Ahora, la SBP puede ser encontrado flotando en internet, y este zip en particular se utiliza para instalar SBP en dispositivos Windows RT.
¿Qué quiere decir esto?
Si cargó un SBP complementario, puede habilitar la firma de prueba para Windows para permitirle cargar controladores no firmados. Además, dado que estas políticas entran en juego antes de la etapa del Administrador de arranque en el procedimiento de arranque, puede comprometer la seguridad de todo el pedido y ejecutar código no autorizado (leído autofirmado). Esto abre muchas posibilidades, tanto para los usuarios que desean modificar partes de Windows más allá de la autorización como para los creadores de malware.
Los autores de este hallazgo se centran en la ironía de todo el fiasco. Microsoft bloqueó el arranque seguro en ciertos dispositivos para mantener alejados los cambios no autorizados, pero luego incorporó una puerta trasera para permitirles continuar con el desarrollo y la depuración. Pero esta misma puerta trasera allana el camino para que el arranque seguro se desactive en todos los dispositivos que ejecutan Windows, lo que hace que toda la prueba sea inútil.
Los usuarios que lo deseen no sólo pueden ahora instalar distribuciones de Linux (y posiblemente Android) en tabletas y dispositivos solo con Windows. En los teléfonos, los usuarios que no lo desean también pueden tener instalados bootkits maliciosos si comprometen el acceso físico a sus dispositivo. Si bien lo primero es algo sobre lo que podemos saltar por los aires, lo segundo realmente no infunde mucha confianza. Va en ambos sentidos y nos muestra por qué la seguridad es un arma de doble filo. Además, el SBP es de naturaleza universal, lo que permite su uso en cualquier dispositivo independientemente de su arquitectura. No es particularmente útil para casos de computadoras de escritorio donde el Arranque seguro se puede desactivar fácilmente, pero tiene un alcance inmenso para dispositivos donde no se puede trastear con el Arranque seguro.
Entonces, ¿cuál es la solución?
Microsoft lanzó algunos parches, pero los desarrolladores insisten en que el problema no está completamente solucionado. Puede consultar estos parches (MS16-094 y MS16-100) y luego lea sobre el entrada en el blog sobre por qué no resuelven el problema. Si son correctas, este problema no tiene una solución o un parche a la vista, aunque eso no impedirá que Microsoft intente poner más obstáculos en el camino.
¿Qué sigue?
Hay un mundo de posibilidades y algunas de ellas se están gestando en nuestros foros de Windows. Puedes consultar nuestros foros en Desarrollo y piratería de Windows Phone 8 y nuestros foros para Windows 8, Windows RT y desarrollo y piratería de Surface. Usted además puede encontrar Hilos de instrucciones para algunos dispositivos., donde otros usuarios están discutiendo lo mismo.
La presencia de esta puerta trasera de depuración y la fuga del SBP son importantes no sólo para terceros desarrollo de dispositivos Windows bloqueados, también nos muestran un sombrío recordatorio de lo que puede suceder si Quedan puertas traseras. La reciente atención prestada a la seguridad se había centrado en las agencias de investigación que presionaban para que se utilizara la presencia de dichas puertas traseras para ayudar en sus fines de investigación legal. Pero tarde o temprano, estos métodos voluntad caer en las manos equivocadas. Lo que está destinado a ser utilizado como herramienta para combatir el crimen y ayudar en la justicia, algún día se convertirá en la herramienta para el crimen mismo.
¿Qué piensas sobre la filtración del Debug SBP? ¿Cree que deberían existir "llaves de oro" como éstas? ¡Háganos saber en los comentarios a continuación!