Hoy vamos a tocar el meollo de la cuestión sobre la seguridad en Windows. Cómo se protege el núcleo ante intentos de meterle mano. Vamos a hablar aquí de cómo Windows protege su propio núcleo y la shell.

4.- El Kelmer

El núcleo de Windows está protegido por un certificado digital (otro más) que verifica que todo está correcto en sus tripas. Ese certificado también determina qué versión de Windows es. De hecho hubo por ahí alguien que consiguió convertir un Windows 7 PRO en un 2003 Server con sólo cambiar dicho certificado.

No vamos a entrar en ese tipo de detalles. Lo que sí que vamos a comentar es que tocar ese certificado es algo bastante complejo si no imposible una vez el sistema está en ejecución, porque un cambio de certificado significa que se debe seguir toda la cadena de comprobación, y la única vía de infección sería o bien un man-in-the-middle gracias a una entidad certificadora maligna. Prácticamente imposible y que de producirse, da igual que sea un Windows, un MAC o que estemos comprando una muñeca chochona en Amazon. Estamos, como dijo qué, bien jodidos.

Fijaos cómo no hemos roto la cadena si estamos ante un sistema con EFI. Cuando encendemos el equipo, EFI comprueba que él está bien, y que el arranque del sistema operativo no está comprometido. Después de eso arranca y pasa el control a Windows, que comprueba que su núcleo tampoco ha sido tocado por nadie.

En principio estamos ante un sistema prístino y sin ningún tipo de violación del sistema. El problema puede venir cuando hemos arrancado de una BIOS clásica comprometida, o del aprovechamiento de algún tipo de fallo de seguridad dentro del propio núcleo causado por la ejecución de una aplicación de usuario maligna, lo que nos lleva a la siguiente sección.

5.- ASLR

Pero antes un poco de teoría.

Cuando decimos que un ordenador tiene x Gigas de RAM estamos diciendo que tiene esa memoria física real, pero el sistema operativo realmente no lo ve así. A él le da igual que tengamos 2 GB que 128GB, él va a ver siempre lo mismo, que es un espacio de direcciones plano, de cero hasta 2^64, y él se va a meter en unas direcciones de memoria prefijadas por los programadores.

En medio hay una capa de virtualización que hace corresponder esas direcciones virtuales a las reales y físicas de la máquina. Esto no tiene nada que ver con las máquinas virtuales, se trata de algo que se lleva haciendo desde los tiempos de Windows NT, Linux y OS X desde los orígenes. Es una forma de ajustar cualquier combinación de memoria real a la que espera el sistema operativo.

Por lo tanto, hasta Windows Vista, esas direcciones eran fijas y siempre las mismas, por lo que uno siempre esperaba que cada cosa estuviera en un mismo sitio, facilitando el meterles mano aprovechando cualquier fallo de seguridad.

Es decir, que NTOSKRNL.DLL siempre se cargaba en la misma dirección de memoria virtual, de modo que si alguien quería atacar a una función de esa DLL, tan sólo tenía que sumar la dirección base más el offset de la función.

Nada más fácil (y difícil, ojo). Pues bien, lo que hace ASLR es cambiar de forma aleatoria esas direcciones base. Hasta donde yo sé, cada vez que arranque Windows, éste se cargará en una de 8192 posibles direcciones virtuales.

En teoría, y hasta la fecha, es imposible saber desde fuera del núcleo en qué dirección se ha cargado éste, por lo que un ataque dirigido al mismo tendrá el inconveniente de que fallará una de 8192 veces porque la dirección sobre la que atacar es incorrecta.

Lo más normal es que un fallo de esos termine en una pantalla azul mostrando algún tipo de corrupción de memoria, aunque también podría terminar en un fallo de página, que el sistema mapee 4KB de RAM a la dirección en cuestión y que no pase nada más. Dependerá de dónde esté el núcleo y dónde la dirección del ataque.

No obstante, para que eso ocurra, el sistema tiene que ser vulnerable, y saltarse más salvaguardias, una de las más importantes es el DEP, sobre todo en arquitectura de 64 bits.

6.- Fírmame el docuemnto

Antes de entrar a explicar el DEP, un breve inciso para terminar con las explicaciones de la seguridad en el núcleo.

En Windows Vista Microsoft añadió la exigencia de que los drivers vinieran firmados. En Windows 7 se amplió para que vinieran firmados por Microsoft. En Windows 8.x se sigue con la tónica.

Personalmente recuerdo las críticas a todo esto.

Pues bien, un driver es otro punto importante, muy importante, de posible violación al sistema. Como tal, un driver se carga en el Anillo 0 del procesador y tiene acceso a la memoria real y virtual del sistema. Imaginaos qué puede hacer un driver malicioso. Se puede saltar el ASLR porque sabe dónde está todo o puede averiguarlo, puede inyectar código donde y cómo quiera, etc.

Por eso es por lo que primero se exigió que los drivers vinieran certificados (otra vez los certificados) por entidades de confianza que determinaran que no había nada malo en ello y finalmente por la propia Microsoft, lo que aumenta las garantías de la seguridad.

En principio un driver certificado no garantiza que esté limpio del todo, pero sí garantiza quién lo ha hecho y minimiza la posibilidad de que contenga algún tipo de malware, igual que la certificación de una actualización del EFI o de las propias de Windows.

Algunos drivers, siempre que sea posible, se ejecutan en el Anillo 3 del procesador, imposibilitando también el acceso al núcleo y manteniendo las garantías de protección gracias al ASLR y al DEP. Son los del tipo WDDM, y cada vez Microsoft está exigiendo que más y más drivers sean de ese tipo.

Hasta donde sé, Linux también tiene y recomienda este tipo de drivers. Creo que OS X todavía no los contempla, y de hecho la exigencia del firmado ha aparecido en Yosemite, y nadie se está rasgando las vestiduras como cuando lo hizo Microsoft.

Por cierto, el ASLR fue implementado al completo por Microsoft por primera vez en enero del 2007 con la salida de Windows Vista. OS X lo implementó parcialmente con Leopard (octubre de 2007), amplió en Lion (julio del 2011) y lo completó en Mountain Lion (en julio del 2012). Linux implementó algo en junio del 2005 en el Kernel 2.6.12 de forma opcional y no fue hasta el 30 de Marzo de 2014 en la versión 3.14 cuando lo implementó por completo y por defecto.

Para que critiquéis a Microsoft y su seguridad.