Yuzi download

Ha salido a la luz un conjunto de vulnerabilidades que afectan a ImageMagick. Dicho así, puede no decirnos mucho, pero ImageMagick es una de las aplicaciones más utilizadas para la conversión y recorte de imágenes en los servidores de Internet. ImageMagick permite la manipulación y procesado de imágenes en cualquier sitio web. Por defecto, viene instalado en sistemas como Ubuntu, o incluso Kali Linux 2.0.

Figura 1: Command Injection en ImageMagick.

Múltiples vulnerabilidades han afectado al software. Una de las descubiertas puede hacer que se pueda ejecutar código remoto. ¿Cómo? Al enviar una imagen al servidor, y éste vaya a procesarla o convertirla, un error en dicho proceso provoca que se ejecute el código embebido en el fichero. De este modo, se estima que miles de servidores expuestos en Internet son vulnerables a día de hoy.

Además, según se ha explicado el exploit para esta vulnerabilidad está siendo utilizado por algunos usuarios de manera pública, por lo que el riesgo es muy grande. El CVSS de dicha vulnerabilidad es de 10, ya que permite la ejecución de código remoto, sin necesidad de ninguna condición más. A continuación se enumeran todas las vulnerabilidades publicadas:

• CVE-2016-3714. No se filtran caracteres correctamente y potencialmente se puede ejecutar código remoto.
• CVE-2016-3715. Permite borrar archivos en el contexto del servidor.
• CVE-2016-3716. Permite mover archivos.
• CVE-2016-3717. Permite la lectura de ficheros locales.
• CVE-2016-3718. Este es un SSRF, con el que se pueden realizar peticiones HTTP o FTP.

El peligro real

¿Es realmente peligroso? ImageMagick dispone de diversos forks y una serie de plugins, por lo que a priori no se puede saber el número exactos de servidores en Internet que pueden ser vulnerables a esto. Se estima que el número es bastante alto, ya que el software es muy utilizado por los desarrolladores y administradores. La recomendación es clara: hay que actualizar en cuanto se pueda y no esperar más, ya que el nivel de exposición es muy alto.

Para que la ejecución remota tenga éxito se necesita, en primer lugar, subir un archivo a un servidor. Éste solicitará dicha imagen y al procesarla con una versión vulnerable de ImageMagick podría ocurrir algo no deseado por parte del propietario del servidor. Una ejecución de código remoto es la vulnerabilidad más crítica que se puede tener, ya que afecta a confidencialidad, integridad y disponibilidad. Es cierto, que la criticidad dependerá de los permisos del usuario con los que ImageMagick se ejecute.

Sea como sea, en el mejor caso desde el punto de vista del hardening de servidores Linux, solo se podría ejecutar acciones no privilegiadas, que no es poco. En el peor de los casos, se puede disponer de un usuario con el mayor privilegio. Además, siempre está la opción de encadenar una escalada de privilegios con algún otro exploit para GNU/Linux una vez conseguida la ejecución de comandos, así que el nivel de criticidad está bien justificado.

PoC: Ejemplificando la vulnerabilidad

En esta prueba de concepto vamos a utilizar el software ImageMagick disponible, entre otros, en Kali Linux 2.0. En primer lugar, crearemos un archivo denominado poc.jpg y en su interior meteremos el código del payload malicioso, que será del tipo:

push graphic-context
viewbox 0 0 640 480
fill url(https://example.com/image.jpg"|ls "-la)
pop graphic-context

Si nos fijamos en la línea fill ‘url(https://example.com/image.jpg”|ls “-la)’ encontramos la inyección del comando y su potencial ejecución. Cuando ImageMagick procesa el fichero creado, en este caso p.jpg se provoca la ejecución de comandos, en este caso se ejecuta la instrucción ls –la. Al igual que se ejecuta un listado de directorios se podría ejecutar código arbitrario, o no tan arbitrario, como por ejemplo una shell o una Meterpreter de Metasploit.

Figura 2: Ejecución de comandos al usar el comando convert que utiliza ImageMagick

Con el módulo generate_payload_base64 se genera un texto en base64 que representa un binario encodeado. En este ejemplo utilizaremos una Meterpreter en base64. El módulo se queda a la espera con el handler preparado para recibir las conexiones. Es una de las formas similares a la explotación de un Command Injection.

Figura 3: Generando el payload en Metasploit

El fichero JPG tendrá el campo fill con este estilo. El esquema es el siguiente:

• En primer lugar se vuelca en base64 a un fichero dentro del contexto del servidor, echo [shellcode base64] > /tmp/text
• Después, se debe volcar a binario utilizando el base64 –d, cat /tmp/text | base64 –d > /tmp/binary2.
• Ejecutar, revisar permisos y si no hay utilizar chmod.

Figura 4: Fichero malicioso con payload generado

Al ejecutar el fichero en el servidor dónde está ImageMagick se produce la “magia”. Obtenemos una sesión de Meterpreter.

Figura 5: Obtenida sesión remota en la máquina de la víctima

El peligro está ahí fuera. Los administradores se enfrentan a una amenaza, la cual debe ser parcheada rápidamente. Ya hay exploits públicos que, como está prueba de concepto, se aprovechan de lo que esté expuesto y sea vulnerable.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

Así se llama el dispositivo que Andrew ‘bunnie’ Huang y Edward Snowden han presentado al mundo. Introspection. Un dispositivo de seguridad que se acopla a tu terminal móvil para monitorizar si en cualquier momento está emitiendo señales de comunicación a bajo nivel que no deberían estar realizándose. Es decir, para ver si tu terminal móvil está enviando información en contra de tu voluntad, y para evitar capas de software que pudieran estar controladas, y software corriendo en los chips que pudiera estar controlado - recordad el escándalo con los chips Intel que está bajo estudio ahora mismo - directamente monitoriza las señales en los buses a nivel físico.

Figura 1: Introspection. Edward Snowden diseña un dispositivo de seguridad para saber si te espían el terminal móvil.

Como digo, el dispositivo se acopla a nivel físico para poder medir las señales de los buses de comunicación del hardware que son utilizados por los elementos de comunicación de un terminal, como son las conexiones WiFi, BlueTooth, las comunicaciones GSM, 2G, 3G, 4G, las conexiones RF o el mismo GPS. En esta imagen se ve cómo se conecta físicamente a la circuitería del terminal iPhone para monitorizar los buses con unos cables que salen debajo de la zona de la SIM.

Figura 2: Conexión cableada de Introspection en un iPhone

En cada terminal hay que hacer una serie de conexiones y debería hacerse por gente especializada. Monitorizar los buses es la única forma que es 100% de fiar, según explican, para poderse fiar de un terminal que ha sido puesto en modo avión y del que no se espera ninguna conexión. Para ello, miran los buses utilizados de todos los elementos de comunicación. La siguiente tabla recoge la lista de sistemas de comunicación y buses monitorizados por su sistema. Como curiosidad, la tabla publicada tiene las típicas marcas del corrector ortográfico de Microsoft Word (una de "metadata leakage" en el post).

Figura 3: Lista de señales monitorizadas

A partir de ese momento, Introspection auditará todas las señales para detectar tráfico en los buses de estas señales que se produzcan cuando no deberían producirse porque el terminal está en modo avión. Esto garantizaría que durante los instantes que el usuario quiera, el terminal no emite ninguna señal lo que evitaría que se pudiera localizar por medio de los múltiples caminos que existen: GPS, trilateración de antenas de comunicación, trilateración de redes WiFi, etcétera.

Figura 4: Señales de bus FE1 en modo avión y en modo comunicación.

En la figura superior se puede ver cómo los buses de comunicación dejan de emitir señales cuando están en modo avión, así que si están emitiendo significaría que no está en modo avión de verdad y alguien podría estar recibiendo la información del terminal, y por tanto la ubicación del mismo en el mundo.

Figura 5: Diseño de cómo sería el funcionamiento de Introspection

El objetivo es que fabricantes, operadores, o personal cualificado pueda inspeccionar el software que corre en Introspection, que puedan analizar el hardware con que se construye y que puedan instalarlo ellos sin necesidad de contar con los fabricantes que proveen los teléfonos. Para ello, el diseño se presenta como un recargador de batería extra, tal y como se ve en la fotografía.

Figura 6: Conexión externa e interna en un iPhone

La conexión se podrá hacer a través de un nexo entre las conexiones físicas que se hacen internamente en el dispositivo y los circuitos de Introspection. Aquí la conexión que es necesaria en un iPhone, que es uno de los dispositivos de los que Edward Snowden no se fía por haber aparecido también en el programa PRISM. Al final la propuesta que hace Introspection es meterse en las capas más bajas posibles para saber si te están monitorizando e ir a por las señales físicas parece que es lo más fiable a día de hoy, porque lo demás todo se puede troyanizar por una capa inferior.  Eso sí, esto no protegerá de todo el hacking de comunicaciones móviles que se produzca desde fuera.

Saludos Malignos!