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:
- El atacante conoce la existencia de una vulnerabilidad crítica, como es un Command Injection, en un servidor de la empresa target.
- 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.
Hace unos meses un investigador descubrió una vulnerabilidad no parcheada en el navegador web de Safari. La vulnerabilidad en cuestión permitiría a un atacante controlar el contenido mostrado en la barra de direcciones. Este bug si es explotado correctamente podría permitir la construcción de un buen ataque phishing que resultaría muy difícil de identificar por cualquier usuario. Esta brecha de seguridad ha sido generada por un fallo en la actualización de la barra de búsqueda. El navegador de Apple permite a javascript actualizar la información de la barra de direcciones antes de que la página buscada acabe de cargar por completo.
