Programas maliciosos en metadatos

Uno de los sistemas que he estado ejecutando recopila todas nuestras detecciones de programas maliciosos en la web con dominios .ES. Suelo revisarlo todas las mañanas para ver si hay algo de especial interés o relevancia. Y cuando encuentro algo, me gusta elaborar estadísticas para tener una visión global.

Cada vez que reviso mis estadísticas encuentro algunas cosas, como URLs que han estado infectadas por más de 200 días, incluso después de que se les notifica. Esto dice mucho de la falta de una conciencia sobre seguridad en algunas compañías, y sobre cómo alguno sitios web quedan abandonados y se convierten en un nido de programas maliciosos.

Sin embargo, algo que llamó mi atención fue la detección de muchos troyanos puerta trasera PHP con extensiones poco comunes, como JPG o MP3. ¿Quizás se trate de un falso positivo? ¡Vale la pena echarle un vistazo!

Algunos no son más que típicos JavaScripts ofuscados que implementan el famoso C99Shell usando una extensión diferente, en este caso, JPG o MP3:

También pude encontrar códigos e iframes JavaScript adjuntos al final de archivos JPG legítimos:

Obviamente, si el servidor web está apropiadamente configurado, estos archivos nunca llegarán a ejecutarse. En el primer caso, ni siquiera las imágenes se interpretarán correctamente, lo cual debería ser una obvia señal para cualquier administrador de que algo anda mal.

En el caso de los iframes adjuntos, las imágenes se muestran correctamente (JPEG es un formato muy flexible), pero el iframe no se ejecuta. Entonces, ¿por qué esta ahí? No hay ninguna razón, son sólo scripts automáticos y ruidosos adjuntos a este iframe al final de cualquier archivo que se encuentra en el servidor web una vez que un atacante lo penetra, probablemente utilizando herramientas automáticas.

Sin embargo, había algo realmente interesante en algunos archivos JPG.

Estos hilos se corresponden con los datos EXIF de la imagen.

Observemos cuidadosamente los datos EXIF JavaScript que aparecen en la  información de Modelo, y en el hilo “/.*/e” en Marca. Este código JavaScript se traduce en:

Básicamente, evalúa si va a través del parámetro POST zz1. Pero si se trata de una imagen, ¿cómo llega a ejecutarse este código? Lo hace gracias a la función PHP exif_read_data.

La función PHP function preg_replace interpreta el contenido como un código PHP gracias al hilo “/e” (el campo Marca en los datos EXIF). Esto ejecuta el código eval en el segundo campo EXIF (Modelo). Entonces, básicamente se trata de un troyano puerta trasera que ejecuta cualquier comando dentro del parámetro zz1 POST. El modificador de patrón “/e”se ya no se usa desde PHP 5.5.0, lo que es una buena noticia.

Entonces, en esencia se trata de un troyano puerta trasera con dos componentes: un archivo JPEG con datos EXIF maliciosos, y un código PHP que lo ejecuta. Este código PHP puede insertarse fácilmente en cualquier otro archivo PHP que se encuentre en el servidor, que quizás un análisis rápido no logre identificar como malicioso.

La imagen se interpreta correctamente, ya que este código JavaScript no afecta la visualización, pues sólo se trata de datos EXIF:

Cuando uno descubre algo así, inmediatamente se pone a explorar en Internet. Por desgracia, no sabía que algunos colegas ya habían descubierto esta técnica en junio:

Malware Hidden Inside JPG EXIF Headers

El código malicioso EXIF es el mismo en todos los análisis, y en todas las imágenes que encontré. Ya sé que se ha detectado este código en algunos ataques dirigidos, aunque al parecer no había una relación directa.

La explicación más probable es que esta técnica se haya usado en una sola campaña que infectó automáticamente a cientos de sitios web. Al revisar el perfil de estos sitios infectados se ve que tal vez hayan explotado una vulnerabilidad Joomla. Sin embargo, esto aún no se ha confirmado. Asimismo, una vez que esta técnica se dio a conocer pudo haberse reutilizado.

Gracias a KSN podemos consultar nuestras propias estadísticas la distribución geográfica de nuestras detecciones:

Esto no significa que los servidores infectados se encuentren necesariamente en estos países, aunque es lo más probable. Al buscar en Google este hilo encontramos más de 1.300 sitios.

Esta campaña nos enseña una lección: nunca debemos subestimar ningún vector de ataque. Por lo general, 9 de cada 10 administradores web subestimarán los archivos de imágenes como peligrosos. Ahora sabemos que no es así.

Siempre se ha considerado los metadatos como un problema que afecta la privacidad; sin embargo, ahora se han convertido en un canal encubierto para los ciberdelincuentes. Jugando con algunas ideas, no he encontrado una forma sencilla de reproducir este ataque con metadatos en otros formatos de archivos, como PDF, pero esto no significa que no sea posible.