Yuzi download

Las técnicas de esteganografía nos permiten ocultar elementos (mensaje, objetos, etc…) dentro de otros elementos de modo que el primero sea imperceptible a primera vista. Por ejemplo, se puede ocultar información dentro de una imagen utilizando los bits menos significativos para componer el mensaje oculto. Pues bien, en la siguiente prueba de concepto, vamos a realizar algo parecido ocultando archivos “dentro del sonido” de un fichero WAV.

Figura 1: Esteganografía con ficheros de audito

Para entender mejor esta prueba, vamos a explicar un poco algunos conceptos básicos necesarios. Todos nosotros cuando éramos pequeños, seguro que hemos cogido plantillas de dibujo en las cuales habían unos puntos numerados, los cuales teníamos que seguir con el lápiz para formar la silueta del dibujo. Pues bien, con el sonido digital ocurre algo parecido. Cuando estamos grabando una sesión de sonido, nosotros elegimos el samplerate (muestras de valores de sonido tomadas en un segundo) y la resolución de dicha muestra (cantidad de bits con los que se miden dichos valores). De esta manera, cuando el reproductor, procese el audio grabado, lo hará como si escribiera una figura de puntos numerados, creando así las ondas sonoras que se reproducirán en nuestros altavoces.

Figura 2: Los puntos indican en qué momento del eje X (tiempo) se ha tomado una muestra de sonido,  y en eje Y se dibuja la resolución captada en ese momento (negativo o positivo)

Vale, pero entonces, ¿cómo podemos ocultar la información “dentro del sonido”? Pues la verdad, es que es bastante sencillo de realizar. Teniendo en cuenta, que la resolución de cada muestra puede ser de por ejemplo 16 bits, vamos a coger los 8 bits menos significativos (valores comprendidos entre 0-255, lo cual hace que la modificación de onda de sonido sea imperceptible) de la muestra para almacenar cada byte del fichero que queremos ocultar, además, éstos se van a intercalar entre el canal derecho e izquierdo (stereo) y en un intervalo de X muestras (para evitar posible deterioro en el audio).

Figura 3: Valores de los bits de audio en 16bits

Figura 4: Valores máximos por profundidad de bits:

Además, para poder tener una estructura la cual podamos desenglosar y recuperar, añadiremos las siguientes funcionalidades:

- Generaremos una cabecera dentro del audio modificado para poder identificar que ahí se está escondiendo “algo” (con un tamaño que determinaremos nosotros). 

- Un byte para indicar si el fichero está cifrado con GPG (Añadir una capa de cifrado al documento oculto nos dará más garantía) 

- Una trama de 4 bytes para identificar el tamaño del fichero a extraer (número de 32bits, además, nunca llegará a ser tar alto por las limitaciones de un fichero wav, pero 24 bits podrían quedarse cortos). 

- Y finalmente la trama de bytes del fichero oculto.

Figura 5: Estructura de la trama de datos ocultos

Para poder visualizar mejor lo que se pretende hacer, he creado un script en Python que utiliza la librería wave y gnupg para este fin, del cual explicaremos los bloques más importantes (recalcar que el script está diseñado para ser funcional a sabiendas de los errores que puede causar por no estar diseñado para un uso constante). El script y demás material lo podéis descargar del siguiente repositorio de github: Estewav y en este vídeo tenéis un ejemplo de su funcionamiento:

Analizando el script para ocultar documentos en ficheros wav

Sólo vamos a repasar los apartados clave del mismo y para seguirlo es muy recomendable tener el script a mano. Vamos a ver el codificador - encargado de codificar y cifrar el archivo que queremos ocultar en el archivo wav - y luego el decodificador podéis ver en el script como es exactamente la función inversa.

codificador.py 

jumpsData = 10
#Espacio de muestras del framerate para la toma de datos válidos, al hacer esto, hacemos que los cambios en el audio se noten menos aun si se puede...

numFraSize = 4
# numero de bytes con el que se compondrá el número decimal final que indica la cantidad de bytes que ocupa el fichero oculto

cipher = CIPHER_ON
# establecemos si se va a cifrar o no

header = ["S", "Y", "L", "M"]
# 1 byte por cada caracter (contra menos caracteres, más posibilidades de error por accidente), pasaremos el valor de cada string a su valor ascii para poder manipularlo como bytes.

…

# Obtenemos los datos del fichero de audio original para que sean iguales en el audio wav destino:

channels = fileWav.getnchannels() # canales de audio (1 mono, 2 stereo)
sampleWidth = fileWav.getsampwidth() # número de bytes para las muestras del samplerate
frameRate = fileWav.getframerate() # obtenemos el número de muestras (frames) por segundo que realiza

…

# Si el cifrado está activo, lo ciframos (nos guardamos también el fichero cifrado original)

if cipher == CIPHER_ON:

gpg_home = "gnupg"
gpg = gnupg.GPG(gnupghome=gpg_home)
encrypted_ascii_data = gpg.encrypt_file(fileToHide, None, passphrase=passphrase_cipher, symmetric=True, output=pathFileToHideCipher)
fileToHide.close()

fileToHideEncripted = open(pathFileToHideCipher, rb)
bytesFileToHide = bytearray(fileToHideEncripted.read()) # guardamos todos los bytes del archivo en un array
fileToHideEncripted.close()
else:
bytesFileToHide = bytearray(fileToHide.read()) # guardamos todos los bytes del archivo en un array
fileToHide.close()

…

startIn = 0 # índice del byte del sample de audio donde se empieza a contar

# A tener en cuenta:
#
# bytem = byte menos significativo
# byteM = byte más significativo
#
# si se un sistema estereo el muestreo comienza así -> bytem_ch1 - byteM_ch1 - bytem_ch2 - byteM_ch2 .....
# si se un sistema mono el muestreo comienza así -> bytem_ch1 - byteM_ch1 - bytem_ch1 - byteM_ch1 .....
#
# ----------------

…

# Este será el espaciado (saltos) con el que intercalemos cada uno de los bytes de toda la trama (cabecera, etc...)
jump = (sampleWidth * jumpsData) # salto para grabar en los bytes correctos

…

# Al tratarse de bytes no podemos poner un número entero muy alto en cada valor, para ello separamos el número total de bytes que se tienen que guardar en 4 octetos (32bits), mediante desplazamiento binario:
# grabamos el tamaño bytes que ocupa el fichero oculto en los bytes asignados para ello
# utilizamos desplazamiento de bits para guardarlo en bloques de un octeto (byte) y luego poder recomponerlo
desplazamiento = 0
for i in range(numFraSize):

#print bytes(len(bytesFileToHide)>>24 & 0xFF) , bytes(len(bytesFileToHide)>>16 & 0xFF) , bytes(len(bytesFileToHide)>>8 & 0xFF) , bytes(len(bytesFileToHide)>>0 & 0xFF)
bytesfileWav[indexSampleWav] = len(bytesFileToHide)>>desplazamiento & 0xFF
desplazamiento += 8
indexSampleWav += jump

Tal y como están diseñados los scripts, podéis clonaros el repositorio y ejecutarlo cambiando los valores de los ficheros de origen y destino o simplemente ejecutarlo y ver los resultados. Al ejecutar el script codificador.py veremos lo siguiente en la salida:

Figura 7: Salida del codificador

Nos proporciona datos sobre el audio de origen como el número de canales, el ancho de muestra en bytes y el número total de frames que tiene el ficheros. Además, nos calcula en base a esos datos y en base a los saltos que tenemos configurados, cuantos bytes podemos ocultar dentro de él. A parte, nos analiza si el tamaño del fichero que queremos ocultar es inferior a la capacidad máxima y de ser así nos lo oculta, tiendo en cuenta, que si hemos activado el cifrado GPG nos lo ocultará cifrado con el passphrase que hayamos configurado en el script.

A continuación escucháis el fichero .wav original (por defecto audioBase3.wav) y a continuación escucharéis el fichero estego.wav el cual lleva oculto el fichero (por defecto oculta el archivo calico.jpg cifrado). Es muy probable que no notéis ninguna diferencia entre los dos archivos de sonido. Para hacernos una idea de la viabilidad de esta técnica de esteganografía, vamos a realizar la visualización gráfica del sonido, y para ello nos ayudaremos de la herramienta audacity. A continuación mostraré una imagen de dos tomas de tiempo de un audio musical (audioBase3.wav) y el mismo aplicándole la esteganografía (estego.wav).

Figura 8: Audio de fichero original y con esteganografía

Como podéis ver, ni si quiera aumentando hasta ver los puntos de muestreo podemos detectar una diferencia visual apreciable (menos aún nuestro oído). Para acercarnos más y poder ver algo con más claridad, en las siguientes dos imágenes pondré un captura de audio con una frecuencia constante de 1Hz y otra imagen de audio nulo (plano), para que podamos ver que aunque la diferencia de valores es minúscula, estos, claramente existen.

Figura 9: Imagen de toma con 1Hz con un ciclo completo.

Aquí ya podemos ver pequeños cambios en el alisado de la onda, pero tenemos que tener en cuenta que la onda de arriba es una onda perfecta generada por código y en la grabación de audio real no es tan perfecto.

Figura 10: Imagen de toma nula (silencio completo)

En este último ejemplo, al ser un audio totalmente nulo, podemos ver sin problemas la dimensión que tiene un byte de datos dentro del audio, el cual es insignificante, ya que hay que tener en cuenta que todo el audio es nulo excepto el dato oculto. Y esto es todo. Espero que os haya gustado y hasta la próxima.

Saludos!

Autor: Christian Prieto Bustamante

No, no os alarméis que Facebook no se lee vuestros mensajes que enviáis en vuestras conversaciones de WhatsApp, aunque si vigila con quién tienes las conversaciones. Esto se nota porque poco a poco Facebook va haciendo la integración entre los datos que tiene de los usuarios y los datos que de por sí tiene en la red social, con el objetivo de mejorar el funcionamiento de sus sistemas de inteligencia. Y se puede palpa en varios aspectos de la red social, como por ejemplo en la sugerencia de amigos que a día de hoy se hace ya en Facebook para lo que parece más que claro que utiliza también como referencia con quién tienes conversaciones en WhtasApp. Para contaros eso os traigo la historia que me describió un lector (¡gracias Avelino Domínguez!) que le había pasado con WhatsApp y Facebook.

La anécdota comienza con un descuido que alguna vez seguro que os ha sucedido. Consiste en que envíes por error un mensaje de WhatsApp a un número equivocado o antiguo o, en su defecto, que lo recibas. Esto es algo que entra dentro de lo posible cuando estamos hablando de teclear un nuevo número dentro del terminal por primera vez o dar de alta un contacto. En este caso nuestro amigo recibió un mensaje de una desconocida en su WhatsApp, y que, como se puede ver en la imagen, no estaba en su lista de contactos.

Si nos fijamos en la captura de la imagen se puede inferir información de la configuración de WhatsApp de la persona que envía el mensaje, que está lejos de tener configurado WhatsApp a prueba de balas, especialmente en cuanto a las opciones de privacidad de WhatsApp.

Como se puede ver, es posible acceder a la fotografía del remitente del mensaje sin que el destinatario lo tenga en sus contactos, lo que significa que la opción de compartir foto la tiene habilitada para todo el mundo o que la opción de visualizar la foto la tiene solo para sus contactos y ha agregado a nuestro protagonista como contacto - algo probable -.

Por supuesto, nuestro protagonista, como se puede ver en la captura de la Figura 2, no le contestó en ningún momento, pero más tarde, cuando se conectó a Facebook pudo ver que la red social le estaba recomendando como amigo a la misma persona que se había equivocado a la hora de enviar el mensaje. 

Es fácil darse cuenta de que es la misma persona porque, casualidades de la vida, no solo la persona que le envió el mensaje de WhatsApp tenía configuradas sus opciones de privacidad para que le mostrara su foto de perfil, sino que además había utilizado la misma foto en su perfil de Facebook.

Pues según cuenta nuestro amigo, parece evidente que mediante los datos de WhatsApp. Sabía que había una conversación en WhatsApp así que posiblemente se conocían por que buscaría su conexión de usuarios a nivel de Facebook y el motor descubrió que los usuarios de Facebook no eran amigos, así que se lo recomendó.  La pregunta es, ¿cómo conectó los usuarios de WhtasApp - números de teléfono -, con los usuarios de Facebook? Las respuestas pueden ser dos distintas, y probablemente Facebook utiliza las dos aproximaciones.

Como ya hemos visto en varios artículos, tu puedes asociar tu número de teléfono en tu cuenta de Facebook para tener un segundo factor de autenticación o para hacer uso de Facebook Messenger, esto, como vimos, puede utilizarse para desenmascarar cuentas de Facebook o para hacer una base de datos inversa de números de teléfono asociados a cuentas de Facebook. Esto le permite a Facebook tener la relación Facebook User -> Número de Teléfono.

Este es el caso del protagonista de esta historia, que tiene el número de teléfono asociado a su cuenta de Facebook, así que el 50% de la conexión ya la tiene hecha el motor de inteligencia de la red social.

Facebook es una platform App, es decir, es de las que más permisos requiere en el mundo de los dispositivos móviles. Esta es la lista de permisos que pide en Android, vista en nuestra plataforma Tacyt. Con estos permisos puede extraer información del dispositivo suficiente como para identificar un mismo dispositivo desde la app de WhatsApp y desde la app de Facebook, con lo que si el usuario tiene de Facebook tiene la app del móvil instalada en el mismo móvil desde el que usa WhatsApp puede tener la base de datos del cliente con la relación Número de Teléfono  -> ID Device o número de Telefónono -> Facebook User.

Figura 6: Permisos de Facebook en Android

Entre los permisos, se puede ver que tiene acceso a GET_ACCOUNTS, que puede permitirle acceder a las cuentas configuradas - incluso sacar el número de teléfono de otras apps que lo hayan usado como identificador - y READ_PHONE_STATE, que también puede ser utilizado para obtener ese número de teléfono.

Figura 7: PoC de acceso a número de teléfono con permiso READ_PHONE_STATE

Una vez que Facebook tiene asociado el número de teléfono en las dos cuentas en su base de datos de usuarios de Facebook y descubre que hay un mensaje - cifrado o no extremo a extremo - sabe que hay una conexión, así que aunque no "espíe" tus mensajes al estilo que la gente entiende que es espiar los mensajes de WhtasApp, pero sí que "espía" con quién tienes conversaciones. Hay que tener cuidado, porque esto abre muchas posibilidades para el doxing, sobre todo si resulta que utilizas tu número de teléfono en anuncios de contactos para adultos en los que preferirías cierto anonimato, ya que con dar tu número de teléfono a alguien o que alguien lo conozca, existen posibilidades de que Facebook le ofrezca tu perfil en la red social, así que configura bien la privacidad y seguridad de tu cuenta de Facebook. Y para completar esta noticia, lee esta otra que explica cómo evitar que Facebook oiga tus conversaciones delante de tu smartphone... que ahora lo hace.

Saludos Malignos!

Hace una semana hablábamos en el artículo dedicado a OSINT Framework de la importancia que pueden tener las fuentes de información abierta en distintos ámbitos de la ciberseguridad. Footprinting en etapas tempranas de una auditoría, vigilancia digital, descubrimiento de amenazas o fugas de información son solo unos ejemplos de lo que se puede hacer con OSINT.  Y aprovechando que esta semana nuestro compañero da una charla gratuita el jueves por la tarde dedicada a la disciplina OSINT, vamos a profundizar un poco más en el tema.

Figura 1: Censys, un buscador con los scans de tus servers

En el artículo de hoy quería hablar de Censys, una plataforma que nos ofrece un buscador, una API y la información en crudo para lo que necesitemos.

¿Qué ofrece Censys?

Censys es una plataforma de la gente de scans.io, de los que ya os he hablado en la charla de “Cómo los malos pueden conquistar el mundo”. Censys es un motor que permite realizar búsquedas que proporciona respuestas a los investigadores sobre los hosts y la red que compone Internet.


Figura 2: Cómo los malos pueden conquistar el mundo
Vamos a ver por separado qué tipo de información proporciona Censys y cómo podemos interactuar con ella. Censys recopila datos de equipos y sitios web a través de escaneos diarios con ZMap y ZGran sobre el espacio de direccionamiento de IPv4. Al final con Censys tenemos instantáneas con periodicidad de cómo los equipos y sitios web están configurados. Como he comentado anteriormente, se puede interactuar a través de:

- Buscador en la página web. 

- API para integraciones de plugins. 

- Descargándose en modo “Raw data” las bases de datos

Estas últimas son ficheros JSON bastante grandes y, por ejemplo, en el caso de mi charla descargaba un fichero de más de 4,3 GB,  que representaba todas las máquinas de IPv4 con el puerto 21 abierto y con banner grabbing realizado sobre la máquina.

Figura 3: Paper sobre Censys

Se puede encontrar mucha más información sobre la arquitectura sobre la que Censys se encuentra montado y sus funcionalidades en el paper que sus autores publicaron. Desde el frontend web y la API se accede a diferentes elementos, Google Datastore, Elastic Search y Google BigQuery. Otra opción, comentada anteriormente, es la descarga de información en crudo a través de ficheros comprimidos que albergan un JSON.

Figura 4: Arquitectura de Censys

Como se puede ver en la imagen, la arquitectura de Censys es compleja y tiene el concepto de Worker, similar al que nosotros tenemos en nuestro servicio de pentesting persistente Faast. En el caso de Censys, el Worker realiza operaciones de fingerprinting a través de la ejecución de ZMap y ZGrab, reportando los resultados al elemento de almacenamiento denominado Google Cloud Storage.

Figura 5: Arquitectura del planificador de tareas en Censys

Si hacemos zoom en el Scheduler, conceptualmente es el elemento de repartir el trabajo, podemos observar como los Workers se convierten en procesos de ZMap y ZGrab que realizan diferentes operaciones. En la imagen anterior se puede ver como ZMap devuelve direcciones IP con puertos abiertos, y ZGrab puede obtener el Handshake completo. Una vez se “normalizan” los datos se almacenan en base de datos.

Opciones del buscador

Desde el propio buscador que hay en el sitio web, si queremos hacer un poco de hacking con buscadores, podemos elegir qué tipo de búsqueda realizar, por ejemplo, si queremos realizar búsqueda sobre los resultados de los escaneos sobre sitios web podemos elegir la opción “Websites”.  Las tres posibilidades son:

Figura 6: Opciones de búsqueda en Censys

- IPv4 Hosts: Esta opción permite realizar búsquedas sobre los hosts descubiertos con anterioridad. Tenemos la posibilidad de filtrar la búsqueda con los “fields”. Estos campos permiten realizar filtros al más puro estilo “Wireshark” o “TCPDump”.

- Websites: Esta opción permite realizar búsquedas sobre los equipos que se han catalogado como websites. De ellos se puede sacar información como: puertos abiertos, subdominios, visibilidad según el ranking de Alexa, etcétera.

Figura 7: Búsqueda en Censys sobre servicios FTP

- Certificates: Al igual que el proyecto de SSL Observatory realizaba un dumpeo de todos los certificados en IPv4, Censys proporciona dicha información. Como veremos más adelante se puede juntar esta información con tools proporcionadas por Censys con el fin de generar informes o reportes de interés.

Tools en Censys

Al igual que Shodan dispone de diversas herramientas que aportan inteligencia a los datos recopilados como, por ejemplo, la posibilidad de descubrir exploits públicos para ciertos hosts con ciertas condiciones. Censys presenta varias herramientas para analizar la información que se ha recopilado previamente.

En el apartado de IPv4 Hosts podemos hacer la búsqueda “*”, por lo que obtendremos un volcado paginado de toda la información. Vemos una pestaña denominada Tools, en la que podemos elegir 3. Tenemos la posibilidad de consultar metadatos encontrados en los hosts, como por ejemplo el sistema operativo que corre en la máquina, la posibilidad de situar hosts en un mapa y verificar en qué zona se encuentran y la de construir un reporte.

Figura 8: Tools en Censys

En el caso del reporte podemos construir en base a unos parámetros históricos almacenados. A modo de ejemplo se selecciona el puerto 21, con servicio ftp y banner. Le indicamos el número máximo de buckets que queremos, indicando en este caso 25.

Figura 9: Construcción de un informe

Podemos ver en la imagen cómo se construye el reporte en base a palabras que aparecen en el banner. Más de 15 millones de hosts respondieron en su banner con un “220” código de conexión con dicho servicio.

Figura 10: Informe generado en Censys

Esto es un ejemplo sencillo, pero podemos ver la potencia que Censys puede otorgar en un análisis de los datos almacenados en la base de datos.

More Censys: API & Raw Data

Que una plataforma como Censys proporcione una API es algo fundamental. La posibilidad de crear plugins y aprovecharse del consumo de la información que Censys genera es de gran utilidad. A través de su API este servicio proporciona una serie de opciones o endpoints. Además, existe una librería en Python para acceder a la API.

Figura 11: Información sobre la API

Por último, para mostrar la opción de “Raw Data” podemos descargar un fichero comprimido que alberga un JSON. Este JSON tiene que ser parseado y le aplicaremos la lógica que nosotros queramos o necesitemos. Podemos fácilmente crearnos un script en Ruby o Python con el que parsear el fichero JSON e ir quedándonos con la información que necesitamos. En el siguiente script se puede ver cómo se va analizando y parseando el JSON.

Figura 12: Ejemplo de procesado del JSON de Censys

Se escoge el campo [‘log’][‘data’][‘response’] que corresponde con el campo dónde se almacena el banner de los FTP en este fichero. Se pasa una expresión regular para filtrar por ese tipo de software “matcheado” con banner grabbing. En el caso de que se matchee se almacena en un fichero.

Pensamientos finales

Al final Censys nos proporciona diferentes formas de procesar y analizar la información que va capturando con sus escaneos periódicos lo que lo hace de gran utilidad. Censys es una fuente de información interesante que, como hemos visto, proporciona diferentes mecanismos para “jugar” con la información y construir cosas interesantes, como aplicar inteligencia sobre los datos y cruzarla con exploits públicos para conseguir "conquistar el mundo". Por supuesto, si eres responsable de seguridad de una empresa, es una fuente útil para ver qué puede estar recopilando de tu infraestructura cualquier posible atacante.

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

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”