Mucho se ha hablado ya sobre UEFI y Secure Boot, perso sigue siendo una de las cosas que más llama la atención cuando se habla de las novedades de Windows 8, como ya sucediera en el pasado con la necesidad de contar con un certificado digital especial para poder meter un driver en Windows Vista. Todas ellas son tecnologías pensadas para luchar contra el malware, pero que evidentemente tienen sus efectos colaterales.

Firmado de drivers a partir de Windows Vista

En el caso de Windows Vista y el firmado de drivers con un certificado emitido por Microsoft el objetivo era acabar con todo el malware que se paseaba por ring0 en Windows XP. Rootkits y botnets hacían del modo kernel su particular palacete de verano para hacer la vida un poco más incómoda a los usuarios que los sufrían.

A partir de Windows Vista, cada driver que se va a meter en modo kernel necesita venir firmado por una entidad con un certificado especial emitido por Microsoft, lo que hizo que muchas universidades y/o investigadores particulares vieran como tenían que cambiar sus procesos para poder seguir haciendo drivers para Windows Vista.


Esta medida, aunque sí dificultó y acabó con muchos de los canales de explotación tradicionales siendo una buena medida de fortificación, no fue una medida definitiva para siempre, ya aparecieron formas de saltarse esas protecciones.

Entre las técnicas para saltarse la protección del kernel para meter drivers firmados, una primera aproximación evidente eviente fue hacerse con certificados de fabricantes de drivers autorizados y utilizarlos para firmar malware, algo que pasó y que llegó hasta el propio servicio de Windows Update, con lo que la propia Microsoft distribuyó malware.

Bootkits

La segunda aproximación, mucho más efectiva, es similar a la que se hace en el mundo del jailbreak de dispositivos iPhone, iPod o iPad de Apple, es decir, parchear el propio kernel para quitar esa comprobación. Por supuesto, para conseguir quitar esa comprobación con el sistema arrancado hace falta encontrar un fallo en el kernel que permita parchearlo - algo bastante complejo, pero que puede llegar a pasar aprovechando una ventana de tiempo -. La otra opción es quitarla antes de que el sistema arranque.

Para quitar la protección contra la inclusión de drivers no firmados en modo kernel, se utiliza un tipo de malware especial que infecta el sector de arranque para, en el siguiente reinicio del equipo arrancar con un programa que parchee el kernel antes de arrancarlo, y ya poder meter cualquier driver en modo kernel. Este tipo de malware se llama Bootkit.

Así, con un bootkit y un poco de ingenio se atacan también los sistemas protegidos con TrueCrypt o BitLocker, detectando si el disco está cifrado en arranque, e infectando el proceso de solicitud de contraseña, para robarla de manera definitiva, y que solo podría ser protegido en aquellos equipos en los que el disco cifrado tuviera protegidas las claves por el chip TPM [Trusted Platform Module].

Uno de este tipo de malware que más famoso se hizo fue Stoned Bootkit, una solución presentada en un paper de 46 páginas de Peter Kleissner, más que interesante de leer, y en que no sólo explica cómo está desarrollado, sino sus usos:

It [Stoned Bootkit] can also be used for malware developers to get full access to the system. It should be the most used bootkit in the wild for 2010.

Stoned Bootkit es una solución completa, que viene con un API y una completa guía de cómo adaptar el sistema para las necesidades de cualquiera que lo quiera implementar, enseñando desde cómo se ha hecho el debugging a cómo crear los ficheros para que arranque cualquier bootkit creado con él.


UEFI y Secure Boot

Debido a esto, la industria trabajó en un sistema de protección contra este tipo de actividades maliciosas, y generó lo que hoy en día se conoce como Secure Boot, una protección que viene implementada y basada en el propio firmware del equipo, que vendrá de serie en todos los que vengan con UEFI, la evolución de las antiguas BIOS.

Esta protección que viene de serie en la UEFI del equipo, lo que hace es evitar que se cargue un MBR de un sistema no conocido, por lo que el arranque de los sistemas operativos vendrán firmados digitalmente, y el equipo comprobará la firma del MBR antes de lanzar el arranque del sistema o liberar las claves de cifrado desde el chip TPM para que se descifren los discos con Bitlocker.


Lo que generó alarma de esta tecnología, y de lo que se quejaron algunas organizaciones tras conocer que Windows 8 soportará Secure Boot, es de que los fabricantes de software como Microsoft podrían llegar a acuerdos con integradores de hardware para que no permitan arrancar sistemas que no sean Windows - o que los equipos con Apple solo puedan ejecutar Mac OS X -.

Secure Boot como Opt-in u Opt-out

Aunque esto podría llegar a suceder, y los que quieran instalar otro sistema en el equipo puedan verse incapacitados, parece que muchos fabricantes están dispuesto a dejar Secure Boot como una opción activable desde la UEFI o que venga con un selector, para que sea el propio usuario el que decida si lo quiere utilizar o no, pero que por defecto lo pondrán activo.

En mi opinión, tras haber visto como funciona el mundo del fraude online en el libro de Mikel Gastesi y Dani Creus, si el usuario tiene la posibilidad de desactivarlo fácilmente, ya se encargará la industria del malware convencer al usuario para que lo deshabilite.

Donde no hay que apostar mucho en contra, porque sí que parece que vendrán estas protecciones puestas de serie, será en consolas de vídeo juegos o plataformas empotradas, y algunos equipos puede que la traigan también cerrada, incluso con Windows - yo así, sin conocimiento de causa y haciendo mera especulación apuesto una cerveza a que en Apple la tendrá en sus equipos portátiles sin poder deshabilitarla -. Por otro lado, hay que decir, que muchos equipos portátiles, especialmente los ultraligeros, no cuentan con chip TPM, por lo que se debilita un poco toda esta arquitectura.

Veremos qué pasa en el futuro, pero i quieres aprender de todo esto, te recomiendo el libro de Sergio de los Santos "Máxima Seguridad en Windows" que habla de temas que tienen que ver con todo esto y de mucho más en la plataforma Windows.

Publicado en: http://www.elladodelmal.com/2012/01/...re-boot-y.html

Interesante... este Chema Alonso con su toque simpático...

Allá por el 2007, la gente de linchpinlabs sacó una herramienta que permitía instalar un driver sin firmar a través de un driver certificado por Microsoft... las consecuencias, tal y como se dice en el link anterior, es que Microsoft catalogó ese driver como malware, impidiendo así la instalación. Esto nos lo puso difícil a los que "cacharreamos" en nuestro tiempo libre...

Si el objetivo era el de instalar un driver no firmado, (que no "sin certificado"), hay otras vias:

¿Qué ocurriría si en vez del usuario administrador o usuario sin privilegios, es el usuario SYSTEM quien intenta instalar el driver no firmado sobre una plataforma de 64 bits?.

¿Qué pasaría si se utilizara un driver de filtro en vez de un driver de clase o específico de vendedor? Esta alternativa es muy atractiva para un malware... pero insuficiente para un desarrollador hardware... Un malware podría hacer uso de lo que el WDM define como "FDO" (Filter Driver Object), para conseguir sus propósitos, interceptando los IRP's que desea para su cometido, siendo el driver de clase o específico de vendedor (por ejemplo el driver de una webcam) quien lleva la firma original del fabricante.

Un saludo.