Menú principal

martes, 5 de mayo de 2015

[PoC] Explotar un bug de Command Injection a través del cliente Mail de iOS

Hace ya años hablamos de una debilidad en el gestor de correo electrónico que por defecto trae iOS, el cliente Mail. Este cliente permitía al abrir un correo electrónico cargar automáticamente las imágenes, por lo que las etiquetas img en html son ejecutadas por el cliente intentando buscar el origen de la imagen. Ya se mostró en el artículo como era sencillo obtener la versión del sistema operativo de un target, incluso jugando con el ISP podríamos cercar una ubicación.

En el año 2012, un año después del artículo dónde se mostraba la debilidad, Apple decidió quitar esta funcionalidad por defecto, lo cual supuso una mejora de seguridad en el cliente de correo, la cual se introdujo en la versión 6 de iOS.

Carga de imágenes en mensajes de correo electrónico

En muchas ocasiones, hay usuarios que prefieren tener habilitado la carga de imágenes por defecto, y lo ven como una costumbre. ¿Qué se puede llegar a hacer con esta debilidad? Lo que se muestra en este artículo es una combinación fatal en la que gracias a un tercero, en este caso el usuario que abre un email con el cliente de correo de iOS, se puede llevar a cabo un ataque con consecuencias devastadoras para una empresa que tiene alguna que otra vulnerabilidad web, como ya vimos en el ejemplo de explotar un CSRF en el panel de administración de un router, o un ataque SQL Injection en la intranet de la empresa, o un bug en los sistemas de votaciones, así como que te hagan tracking de tu ubicación en todo momento. Hoy veremos un ejemplo con la explotación de un Command Injection

El esquema del ataque es el siguiente:
  1. El atacante conoce la existencia de una vulnerabilidad crítica, como es un Command Injection, en un servidor de la empresa target
  2. El atacante prepara un email para un usuario que utiliza el cliente mail de iOS. Dentro del cuerpo del mensaje existirá una etiqueta img que solicitará una imagen a una fuente, la cual es el servidor vulnerable.
Figura 1: Preparación HTML del correo electrónico

Existe una vulnerabilidad de Command Injection en el parámetro domain de la aplicación web. Aprovechando esto y sabiendo que el atacante quiere la dirección IP que quede registrada en el ataque no sea la suya, y sí la de un dispositivo iOS, se ejecutan 4 instrucciones en la petición al parámetro vulnerable. La primera vuelca un contenido en un fichero en /tmp denominado pay.txt. Este fichero contiene nuestro payload. La segunda instrucción decodifica el contenido del fichero y lo vuelva en un fichero. Este fichero ya es código binario. La tercera instrucción cambia los permisos del fichero binario que acabamos de crear, mientras que la cuarta instrucción ejecuta el código en el servidor remoto. Cuando el binario se ejecute, devolverá el control de la máquina a dónde el usuario que lo generó con el módulo que se verá a continuación haya indicado.

¿Qué es el "chorro" de números y letras que se muestra después del echo y que acaba en un signo "="? Es una Meterpreter en base64. Para generar este tipo de soluciones en ataques web, nuestro compañero Pablo González realizó un pequeño módulo para generar payloads ya encodeados en base64. En su libro de Metasploit para Pentesters podéis encontrar ejemplos como éste en la introducción al desarrollo de módulos para el framework. En la imagen se puede visualizar una prueba de cómo utilizar este módulo, y es realmente interesante utilizar estos códigos en ataques web de tipo CI.

Figura 2: Creación de un payload en base64 con generator_payload_base64

Antes de suponer el envío del email reflejemos el escenario final del ataque. En la siguiente imagen se puede comprobar los pasos a seguir por el atacante y el resultado del mismo si todo va bien. Como se dijo anteriormente hay una serie de condiciones que se deben cumplir, pero el resultado del ataque es crítico.

Figura 3: Esquema global del ataque

Una vez el email se envía, el usuario con iOS lo abrirá. Cuando el e-mail es abierto, y siempre y cuando la opción de carga de imágenes se encuentre activa se realizará una petición al servidor que se indique en el atributo src de la etiqueta img. Si la carga automática no se encuentra activa, el usuario puede decidir cargar las imágenes también, aunque ya requiere acción por parte del usuario.

Figura 4: Obtención de un Meterpreter en un sistema Linux

En definitiva, tenemos que tener cuidado con la carga de fuentes externas, ya que es común que ejecutemos contenido externo de otros sitios web, por ejemplo archivos Javascript que ejecutan código en nuestro navegador.

No hay comentarios:

Publicar un comentario

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares