Este post en una introducción a ‘shatter attacks’, un tipo de ataque ya veterano (del 2002) que se basa en el uso del API de Windows, y que como veréis más adelante todavía sigue siendo muy delicado.
Una aplicación que se ejecuta en Windows básicamente lo que hace es procesar los mensajes que va recibiendo. Cualquier programa tiene la capacidad de enviar mensajes a otros programas y no existe ningún sistema de autenticación, lo que abre la posibilidad a un nuevo mundo de vulnerabilidades de seguridad.
"Exploiting design flaws in the Win32 API for privilege escalation - or Shatter Attacks - How to break Windows" es un artículo de Foon (Chris Paget) que presentaba un nuevo método para atacar los sistemas basados en Win32 (y con la posibilidad que otros entornos basados en el proceso de mensajes se ven igualmente afectados).
Lo más importante de esta vulnerabilidad es que no tiene una solución fácil. Al menos no mediante la aplicación de un simple parche, ya que se trata de un problema en el propio diseño del entorno.
La estructura de un programa Windows se puede simplificar, muy superficialmente, de la siguiente forma: el programa está constantemente recibiendo mensajes que son enviados por el núcleo y los otros programas en ejecución. Su misión consiste en procesar todos aquellos para los que el programador ha incluido alguna acción. Por ejemplo, cada vez que se pulsa una tecla, Windows envía el mensaje WM-KEYDOWN a la aplicación que está en primer plano. Todos los mensajes generados se sitúan en una cola y son procesados de forma secuencial por cada aplicación.
El problema de seguridad se encuentra en el hecho que Windows permite a una aplicación en ejecución enviar un mensaje a cualquier ventana abierta en el mismo ordenador (o escritorio, para ser más exactos), con independencia de si la ventana receptora tiene alguna relación con la aplicación que emite el mensaje o de sí el receptor de mensajes desea recibir los mensajes que le son enviados.
Adicionalmente, Windows no facilita a las aplicaciones ningún mecanismo para determinar la autenticación del emisor del mensaje.
Es justamente esta falta de funciones de autenticación la que puede ser aprovechada en este tipo de ataques.
Una aplicación maliciosa puede enviar un mensaje a un programa que se está ejecutando con el que puede manipular las ventanas y los procesos del programa receptor del mensaje.
Este tipo de ataques, hoy por hoy, todavía sólo pueden realizarse en local.
Parece que Microsoft ha solventado estos problemas a partir de Windows Vista y a través de la asignación de niveles de integridad a cada proceso a través de UIPI (User Interface Privilege Isolation) e impediendo que los usuarios por defecto se logeen con Sesión 0.
Aunque recordemos que todavía el rey de los puestos cliente sigue siendo XP…
Extraído de http://unlugarsinfin.blogspot.es
Una aplicación que se ejecuta en Windows básicamente lo que hace es procesar los mensajes que va recibiendo. Cualquier programa tiene la capacidad de enviar mensajes a otros programas y no existe ningún sistema de autenticación, lo que abre la posibilidad a un nuevo mundo de vulnerabilidades de seguridad.
"Exploiting design flaws in the Win32 API for privilege escalation - or Shatter Attacks - How to break Windows" es un artículo de Foon (Chris Paget) que presentaba un nuevo método para atacar los sistemas basados en Win32 (y con la posibilidad que otros entornos basados en el proceso de mensajes se ven igualmente afectados).
Lo más importante de esta vulnerabilidad es que no tiene una solución fácil. Al menos no mediante la aplicación de un simple parche, ya que se trata de un problema en el propio diseño del entorno.
La estructura de un programa Windows se puede simplificar, muy superficialmente, de la siguiente forma: el programa está constantemente recibiendo mensajes que son enviados por el núcleo y los otros programas en ejecución. Su misión consiste en procesar todos aquellos para los que el programador ha incluido alguna acción. Por ejemplo, cada vez que se pulsa una tecla, Windows envía el mensaje WM-KEYDOWN a la aplicación que está en primer plano. Todos los mensajes generados se sitúan en una cola y son procesados de forma secuencial por cada aplicación.
El problema de seguridad se encuentra en el hecho que Windows permite a una aplicación en ejecución enviar un mensaje a cualquier ventana abierta en el mismo ordenador (o escritorio, para ser más exactos), con independencia de si la ventana receptora tiene alguna relación con la aplicación que emite el mensaje o de sí el receptor de mensajes desea recibir los mensajes que le son enviados.
Adicionalmente, Windows no facilita a las aplicaciones ningún mecanismo para determinar la autenticación del emisor del mensaje.
Es justamente esta falta de funciones de autenticación la que puede ser aprovechada en este tipo de ataques.
Una aplicación maliciosa puede enviar un mensaje a un programa que se está ejecutando con el que puede manipular las ventanas y los procesos del programa receptor del mensaje.
Este tipo de ataques, hoy por hoy, todavía sólo pueden realizarse en local.
Parece que Microsoft ha solventado estos problemas a partir de Windows Vista y a través de la asignación de niveles de integridad a cada proceso a través de UIPI (User Interface Privilege Isolation) e impediendo que los usuarios por defecto se logeen con Sesión 0.
Aunque recordemos que todavía el rey de los puestos cliente sigue siendo XP…
Extraído de http://unlugarsinfin.blogspot.es
Comentarios
Publicar un comentario