Hacking con imágenes 2

  • 0

Hacking con imágenes 2

En un post anterior se describió un posible ataque a través de imágenes bmp, esta vez vamos a hablar de otro tipo de ataque pero también a través de imágenes. La diferencia es que, esta vez, el ataque es del lado del cliente y/o servidor que funciona con imágenes de tipo jpg.

El peligro puede venir de parte del lado del servidor, siempre que en una web exista algún método de subir una imagen jpg. Este problema es muy típico que en foros y otros sitios web donde el usuario tiene permitido subir imágenes y compartirlas con los demás usuarios.

A grandes rasgos el problema se produce al no comprobar el servidor si la “supuesta” imagen que sube el usuario es en realidad una imagen.

Vamos a ver como se puede aprovechar las medidas que se usan para comprobar el código fuente del lado de un servidor, en el siguiente codigo vemos que el servidor comprueba si el tipo del fichero subido es “image/jpg”. Veamos un ejemplo:

<input name="fileToUpload" type="file" onchange="check_file()" >
if($_FILES['userfile']['type'] != "image/jpg")

Muchas veces los programadores utilizarán un código similar que  hace lo que se supone debe hacer, checkea el archivo para comprobar la extensión de lo subido. Lo malo es que si solo hace la comprobación del tipo de archivo al que se refiere se puede truncar esta medida de comprobación cambiando por ejemplo la extensión del archivo.

Por ejemplo, en programación esto definiría los tipos de extensiones permitidas.

$valid_file_extensions = array(".jpg", ".jpeg", ".gif", ".png");

Hay que tener muy en cuenta la hora de filtrar las entradas de usuario que pueden reportar un comportamiento distinto al esperado e implementarlo a través de la programación.

Funciones como strrchr dan mucho juego pues puede ser utilizado para que se consiga baypassear esta comprobación.

$file_extension = strrchr($_FILES["file"]["name"], ".");

Ejemplo de posibles intentos que en muchos casos pueden llegar a funcionar, al subir una imagen a una web que solo comprueba alguna función del tipo strrchr. Con imaginación , alguien maliciosamente podría testear funciones e intentar subir una webshell como c99. Tenemos un ejemplo de este tipo en la siguiente URL http://www.php.net/manual/en/function.strrchr.php

c99.jpg.php – Es posible que llegue a satisfacer la subida del jpg

c99.jpg.PhP – Ofuscación.

c99.php;.jpg – A veces puede ignorar lo que hay detrás de un ;

c99.php.test – Puede ser que se ignore .test

c99.php.xxxjpg – Es posible que invalide el final xxxjpg por invalido

De nuevo, para explotar este tipo de vulnerabilidad, necesitaremos de algo que convierta una imagen esta vez jpg, en una webshell con código malicioso. Esta herramienta nos permite utilizar el espacio de de los metadatos que contiene un jpg para insertar ese código. Simplemente genial.

http://kaoticcreations.blogspot.co.uk/2013/10/ohno-evil-image-builder-meta-manipulator.html

Desde el punto de vista de la programación cada vez más, se están estableciendo unos patrones de metodología de control del desarrollo de la aplicación a nivel de la seguridad. Existen una serie de metodologías que ayudan a realizar ese tipo de comprobaciones. Entendemos que esto es algo que no debe estar resumido en una API de control de usuarios, sino como parte de una rutina que el programador debe asumir además como llevar un control de excepciones (exceptions, errors, etc) que pueda reportarle la aplicación. Se puede resumir en no dejar cabos sueltos, ya que el no tratarlos correctamente puede terminar por convertirse en una vulnerabilidad y ser explotada.

Por todo ello es recomendable que para cualquier proyecto existan una serie de protocolos, metodologías, asesores que guíen en todas las fases de vida de dicho proyecto desde el punto de vista de la seguridad. Cuanto antes se introduzcan expertos o metodologías de seguridad en un proyecto ayudara a que los costes de los cambios sean mínimos si lo comparamos con los costes que se pueden dar en, por ejemplo, reestructurar una herramienta para implementar contramedidas para que los “usuarios” no suban ficheros que no debieran.

Recordar que la seguridad es una lucha de todos, tanto de los que prestan los servicios (web, programas, etc) como del usuario. La seguridad debe de ser proactiva por ambas partes.

Nuestra empresa estará encantada de ayudarles en sus proyectos de seguridad con un grupo de profesionales altamente cualificados que darán soluciones a sus problemas y necesidades