El fallo se encuentra en el soporte heredado que da Windows a las aplicaciones de 16 bits. Como bien nos explican en una-al-dia Windows comete algunos errores y asume que:
- Se requiere el privilegio SeTcbPrivilege para configurar un contexto VDM (Virtual DOS Machine) .
- Código en ring3 no puede instalar selectores de segmento de código arbitrarios. Usando el modo Virtual-8086, es posible.
- Código alojado en el ring3 (espacio de usuario) no puede falsificar un "trap frame".
Para eludir el tercer punto, se necesita acceder a una dirección de
memoria, que es siempre la misma en todos los Windows menos Vista y
Windows 7 que realizan una "aleatorización" de la carga en memoria. Se
supone que esto protege de este tipo de ataques. Sin embargo, usando
NtQuerySystemInformation(), se puede llegar a calcular dónde está esa
dirección aunque sea diferente en cada inicio, con lo que la protección
ASLR (Address space layout randomization) también se ve eludida.
Ormandy avisó a Microsoft en junio de 2009, y poco después confirmaron
el problema. Harto de que no publicasen una solución (que considera no
muy compleja), ha decidido hacer público el fallo. Él mismo entiende que
esta vulnerabilidad afecta de forma más seria a empresas y corporaciones
que mantienen a sus usuarios con privilegios limitados. Por desgracia,
la mayoría de usuarios caseros utilizan ya la cuenta de administrador
en su Windows (no tan poderosa como SYSTEM, pero equivalente a efectos
prácticos) para tareas cotidianas, con lo que la elevación de
privilegios no suele ser un requisito en los ataques.
En el siguiente ejemplo podemos ver como se ejecuta el exploit y la nueva ventana de cmd se ejecuta con el usuario SYSTEM:
memoria, que es siempre la misma en todos los Windows menos Vista y
Windows 7 que realizan una "aleatorización" de la carga en memoria. Se
supone que esto protege de este tipo de ataques. Sin embargo, usando
NtQuerySystemInformation(), se puede llegar a calcular dónde está esa
dirección aunque sea diferente en cada inicio, con lo que la protección
ASLR (Address space layout randomization) también se ve eludida.
Ormandy avisó a Microsoft en junio de 2009, y poco después confirmaron
el problema. Harto de que no publicasen una solución (que considera no
muy compleja), ha decidido hacer público el fallo. Él mismo entiende que
esta vulnerabilidad afecta de forma más seria a empresas y corporaciones
que mantienen a sus usuarios con privilegios limitados. Por desgracia,
la mayoría de usuarios caseros utilizan ya la cuenta de administrador
en su Windows (no tan poderosa como SYSTEM, pero equivalente a efectos
prácticos) para tareas cotidianas, con lo que la elevación de
privilegios no suele ser un requisito en los ataques.
En el siguiente ejemplo podemos ver como se ejecuta el exploit y la nueva ventana de cmd se ejecuta con el usuario SYSTEM:
Nos encontramos por lo tanto ante una vulnerabilidad grave que todos los administradores de sistemas deben remediar en sus servidores, aunque no hay parche oficial la vulnerabilidad es muy fácil de solucionar. Solo necesitamos abrir nuestra consola de políticas (gpedit.msc) y vamos a Configuración de Equipo -> Plantillas Administrativas -> Componentes de Windows -> Compatibilidad de Aplicación y habilitamos la política "Impedir el acceso a aplicaciones de 16 bits".
Una vez aplicada la política comprobamos que la nueva ventana de comandos se ejecuta con el mismo usuario que la crea:
Colleja a Microsoft por seguir teniendo compatibilidad con aplicaciones de 16 bits incluso en versiones como Windows 7 y otra colleja por no haber sacado el parche en su debido momento ya que hubo un aviso previo por parte de los responsables del exploit.
El exploit lo podeis descargar de aquí
El exploit lo podeis descargar de aquí
Un saludo
1 comentarios:
mola mil el bug!!
xD
Publicar un comentario en la entrada