En muchas ocasiones, a la hora de realizar algún test de penetración web, nos hemos encontrado con la necesidad de realizar algún tipo de ataque de fuerza bruta o de diccionario contra alguna web para poder obtener algún tipo de información, como pueden ser listas de usuarios o archivos específicos por ejemplo. En este tipo de situaciones, realizar un ataque manual (consulta por consulta) puede ser muy tedioso y largo, así que existen diferentes herramientas que nos pueden ayudar a hacerlo de una manera mucho más llevadera.

Burp Suite, como muchos de los lectores ya sabréis, es una potente herramienta que nos ayuda a realizar auditorías web, funcionando como proxy entre nuestro navegador e Internet. Pero además de esta funcionalidad tiene otras muchas, como puede ser un spider o un repetidor por ejemplo.

En este artículo, únicamente nos centraremos en intruder, el cual nos ayudará a realizar diferentes consultas a un mismo host de manera automática, modificando el payload utilizado sin necesidad de la interacción del usuario en cada una de las peticiones.

Imaginémonos la web www.xxxx.com, en la que hemos descubierto que su panel de login (/login.php) dispone de dos campos para la validación del usuario (“user” y “password”) y que al intoducir los datos, devuelve un mensaje u otro en función de si el usuario existe o no en la base de datos y de si la contraseña es válida o no. En este escenario, se podría realizar un ataque de fuerza bruta para poder obtener la lista de todos los usuarios de la aplicación, pero, cómo hacer eso de una forma automática sin necesidad de modificar a mano los parámetros “user” y “password” y obteniendo además de una manera clara las respuestas por parte del servidor?

Para ello, lo primero que deberemos hacer es ejecutar el programa desde consola con la siguiente instrucción java -jar nombre_del_archivo_.jar. Una vez abierto, nos situaremos en la pestaña “intruder” y ya lo tendremos todo listo para empezar nuestro ataque.

Una vez aquí, en la pestaña “target”, indicaremos el host sobre el cual queremos realizar el ataque, en este caso www.xxxx.com, indicando si se trata de una conexión HTTP (puerto 80) o HTTPS (puerto 443).

En la siguiente pestaña, “positions”, indicaremos la consulta a realizar, donde en nuestro caso sería algo así:

POST /login.php HTTP/1.1 
Host: www.xxxx.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 27 

username=user&password=XXXX

Y seleccionaremos aquellos parámetros que deseamos modificar, en este caso el parámetro POST “username”. Para ello, nos situaremos en el inicio del contenido “username”, le daremos al botón de “add §”, y volveremos a hacer lo mismo en el final del contenido. Indicando entre los dos § donde se deberá realizar la modificación del payload. Hay que destacar, que no debemos preocuparnos por el campo “Content-Length”, ya que Burp ofrece la posibilidad de actualizarlo automáticamente marcando la casilla correspondiente en “options”.

Una vez realizado esto, en la pestaña “payloads” indicaremos el contenido del payload que utilizaremos. Burp nos facilita diferentes opciones para la modificación de los parámetros, como puede ser una lista predefinida de opciones, el contenido de un fichero, un incrementador de números o un ataque por fuerza bruta entre otras. Todas las opciones disponibles las encontraremos en el campo de “payload set”. En la imagen mostrada, se ha decidido utilizar el contenido del fichero “nombres_usuario.txt”, el cual contiene una lista con posibles nombres de usuarios.

En la última pestaña (“options”), encontraremos diferentes opciones sobre el tratamiento de las consultas y respuestas. Dentro de ellas, la función “grep” nos ayudará a seleccionar aquellas consultas con el resultado esperado, por ejemplo haciendo “match” con una cadena deseada.

En el ejemplo dado, cuando se introducía un usuario que no existía en la base de datos, se mostraba la cadena “El usuario introducido no existe”, y en cambio, cuando el usuario sí existía pero la contraseña era inválida, se mostraba el mensaje “Password incorrecto”. De esta forma, podemos hacer que Burp compruebe si la respuesta del servidor contiene la cadena “Password incorrecto”, ya que de ser así significará que el usuario introducido es un usuario válido.

Por último, solo nos queda lanzar el ataque y esperar los resultados. Para ello, seleccionaremos “intruder” y “start attack”.

Como se puede observar en la imagen, se muestran todas las consultas realizadas, y marcadas con un check aquellas en que la respuesta por parte del servidor contiene la cadena “Password incorrecto”, lo cual significa que el usuario sí existe.

Este escenario únicamente ha sido utilizado para realizar una pequeña introducción de la funcionalidad de Burp, pero no hay que quedarse únicamente en este ejemplo, ya que “intruder” puede utilizarse para realizar ataques SQLi, XSS o cualquier otra técnica en la que se necesite automatización y que pueda ocurrirsele al pentester ;) Para ello, se recomienda analizar las diferentes opciones de las que esta herramienta dispone

En este nuevo reto, partíamos de la siguiente imagen:

Analizando el campo “alt” de la imagen, vemos que se corresponde a una cadena codificada en base64:

NmQ3OTc5NzUyYTM4NDYzNDM0MjUzNzQzMjUzNzQzMjUzNzQzMzM3ODZhNjg3YTc3NmU3OTI1Mzc0NTY2Nzc3OT
I1Mzc0Mzc0Nzc3MDMzNmE3ODM0MjUzNzQzNzUzMjY4NzQ3Mzc5NmE3Mzc5MzQ3YTc1NzE3NDY2Njk3ODM0MjUz
NzQ1NjY2NDcxNzE2YTZjNjY3MzY0NzE2Njc4NjQyNTM3NDI2NjY4NjY2ODZlNzQ3MzZhNzgzNDI1Mzc0MzY2Nz
E3MTcxMjUzNzQ1MzM2YzZlNmIzNQ==

Así que al decodificarla obtenemos lo siguiente:

6d7979752a3846343425374325374325374333786a687a776e79253745667779253743747770336a78342
537437532687473796a7379347a75717466697834253745666471716a6c66736471667864253742666866
686e74736a783425374366717171253745336c6e6b35

Si nos fijamos en el resultado obtenido vemos que únicamente contiene números y algunas letras del abecedario (concretamente las primeras), así que podemos pensar que se encuentra en hexadecimal. Por lo que si lo convertimos a caracteres ASCII obtenemos:

myyu*8F44%7C%7C%7C3xjhzwny%7Efwy%7Ctwp3jx4%7Cu2htsyjsy4zuqtfix4%7Efdqqjlfsdqfxd%7Bfh
fhntsjx4%7Cfqqq%7E3lnk5

Llegados aquí, no es tan fácil continuar decodificando el enlace, ya que no se trata de un codificado “básico”. Pero teniendo en cuenta la primera pista que se dio, seguramente se trata de un enlace web, lo más lógico es que empiece por “http://”, así que podemos pensar que los primeros caracteres de la cadena se corresponden con ese inicio. Por lo tanto, si “myyu” se corresponde a “http”, esto nos dice que se está utilizando un cifrado Cesar con desplazamiento de 5 hacia la derecha. El problema viene con el abecedario utilizado, ya que no sabemos que serie de número y/o símbolos se han utilizado para realizar la codificación.

Si observamos bien el enlace e intentamos descifrar algo más, obtenemos algunas cadenas nuevas como “xjhzwny” que pasa a ser “securit”, “fwy” que pasa a ser “art”, y “twp” que se convierte en “ork”. Esto forma “securit?art?ork”, lo que parece demostrar que sí que se ha utilizado un desplazamiento de 5 para codificar el enlace.

Analizando más detalladamente el enlace codificado y sabiendo como está formada una URL, podemos llegar a la conclusión de que se han utilizado los valores unicode de los caracteres, y se les ha aplicado el desplazamiento al valor de los mismos.

Utilizando un script como por ejemplo el siguiente: “codifica_decodifica.txt” (renombrar a html y ejecutarlo en el navegador) y sabiendo que el último carácter de la cadena cifrada indica el desplazamiento utilizado, obtendremos el resultado final:

https://www.securityartwork.es/wp-content/uploads/ya_llegan_las_vacaciones/wallly.gif

Para aquellos que tengan curiosidad por el método utilizado, podréis encontrar una explicación más detallada en el siguiente enlace: http://scriptasylum.com/tutorials/encode-decode.html.

Una vez llegados hasta aquí, si seguimos el enlace ahora decodificado, encontramos una imagen prácticamente igual a la inicial, pero con la pequeña diferencia de que parece que ésta se encuentre un poco desplazada respecto a la anterior.

Abriendo las imágenes con un editor hexadecimal no apreciamos ninguna diferencia entre ellas a simple vista, pero si realizamos una comparación carácter a carácter de ambas imágenes y obtenemos los bytes que diferencian cada una de ellas (con el siguiente código por ejemplo: “comparador.c”), conseguimos dos resultados diferentes. Los cuales resultan ser un cadena con caracteres no imprimibles y la cadena “_721_PaS5Gu0rD_208_”.

Utilizando la segunda cadena obtenida, abrimos el archivo comprimido correspondiente a la segunda parte del reto. El cual contiene un único archivo, que a pesar de tener la extensión “jpeg”, se corresponde a una imagen PGM.

Si abrimos la imagen, vemos que contiene el logo del blog de SecurityArtWork pero no se observa nada más a simple vista.

Estudiando como funciona el formato PGM, vemos que posee una cabecera la cual indica el tipo de fichero (P5 en este caso), un posible comentario seguido de una almohadilla (#), el tamaño de la imagen (721 x 71) y el número de tonalidades de gris utilizado (155). Si observamos los comentarios, a parte de ver “created by fikih888”, podemos encontrar la cadena “– check_the_PaS5Gu0rD – ” un poco más para abajo, la cual podría ser la contraseña que estábamos buscando. Pero si la probamos, vemos que no podemos abrir el archivo comprimido, así que toca seguir buscando ;)

Si entendemos esta pista, nos está diciendo que debemos comprobar “PaS5Gu0rD”, cadena la cual coincide con el resultado de la prueba anterior. Así que si la analizamos, vemos que contiene los números “721” y “208”, los cuales nos indican el tamaño de la imagen del logo de SecurityArtWork. Así que poniendo estos valores como tamaño de la imagen (cambiando el valor “71” por “208” con el editor hexadecimal) obtenemos una imagen más grande que la anterior, pero aun y así no somos capaces de conseguir nada. Por lo tanto, lo último que queda por probar es ampliando el rango de tonalidades de gris al máximo (cambiando el “155” por el “255”) y de esta manera obtenemos la siguiente imagen:

Donde en la esquina inferior derecha podemos ver “Congratulations! You’ve got the “SeCR3t” ”, donde “SeCR3t” se corresponde al token que estábamos buscando, ya que con él podemos abrir el archivo comprimido que servía como validador :)

Y hasta aquí la solución del reto ^^ Espero que hayáis disfrutado con él y aquellos que no habéis logrado pasarlo hayáis aprendido nuevas técnicas de ocultación de información en imágenes ;)

Después de un tiempo sin poner ningún reto en el blog, aquí os traemos uno nuevo :)

Este reto esta compuesto por dos partes. La primera está formada por la siguiente imagen, y la segunda se corresponde al archivo “parte2.rar”. Pese a que el archivo de la segunda parte es un .rar, el reto no consiste en hacer fuerza bruta ni nada por el estilo sobre el mismo, simplemente es para poder continuar con el reto a partir del token de la primera parte.

En esta ocasión se ha facilitado un validador para que podáis comprobar si efectivamente habéis llegado a la solución deseada. Como en el caso anterior, no se trata de hacer ningún tipo de ataque contra el mismo, simplemente es para que podáis comprobar si lo que creéis que es el token final (i.e., la solución del reto), lo es verdaderamente ;)

Parte 2: parte2.
Validador: validador

Como siempre, se dejarán unos días antes de publicar la solución del mismo, así que los que no lo consigáis estad atentos al blog. Si vemos que existen problemas para dar con la solución del reto se publicará alguna pista durante el transcurso del mismo.

(Para evitar confusiones que pueda haber creado la anterior entrada, comentar que este post no trata de ser una guía paso a paso de un análisis forense, sino que consiste en proporcionar información que el auditor debe conocer a la hora de realizarlo e información que deberá utilizar según las necesidades del caso. Tanto vierito5 como Román Ramírez hacen apreciaciones muy interesantes en los comentarios de la primera parte de esta serie, que recomiendo encarecidamente leer.)

Después de haber obtenido todas las características principales del sistema a analizar, debemos averiguar qué ha podido pasar o qué acciones se han podido llevar a cabo. Para esto, Linux dispone de una serie de registros (logs) que nos facilitarán el obtener este tipo de información. Con la siguiente lista, se pretende hacer una breve introducción a algunos de los más importantes:

• /var/log/boot.log: En este registro podremos encontrar información que se almacena durante el arranque del sistema.
• /var/log/dmesg: Guarda los mensajes que lanza el kernel. Entre otros datos, almacena los mensajes sobre dispositivos hardware que el kernel detecta durante el arranque del sistema.
• /var/log/cron: En este registro se guardarán las acciones realizadas por “cron” (automatizador de tareas en sistemas Unix). Aunque en algunos sistemas este log viene desactivado por defecto, podemos obtener la información del mismo de /var/log/syslog con la siguiente instrucción: zgrep -i cron /var/log/syslog”.



• /var/log/apache2 (o /var/log/httpd): En este directorio encontraremos el registro de logs del servicio apache a través de los archivos access.log y error.log.



• /var/log/lastlog y /var/log/wmtp: El primero muestra cuando fue el último acceso de cada usuario al sistema, y el segundo un registro de los accesos del usuario al sistema. Para poder visualizarlos es necesario hacerlo a través de los comandos lastlog (para el primero) y last (para el segundo), ya que no se tratan de archivos de texto ASCII.



• /var/log/btmp: En este archivo podemos encontrar la lista de accesos fallidos al sistema. Como en el caso anterior, el archivo no se encuentra en ASCII, por lo que para visualizarlos utilizaremos el comando lastb.
• /var/log/mail.log, /var/log/mail.err, /var/log/mail.warn y /var/log/mail.info: Contienen los registros del servidor de correo que haya en el sistema. Entre otros datos, podremos encontrar información sobre los e-mails enviados.
• /var/log/messages: Este registro almacena los principales mensajes del sistema.
• /var/log/auth.log: Guarda información sobre el sistema de autorización de usuarios y permisos del mismo.



• /var/log/samba/: En este directorio se almacenan los logs relacionados con el servicio samba, el cual permite conectar equipos Windows con Linux.
• .bash_history: El archivo lo podemos encontrar en el directorio home de cada usuario. En él encontraremos el historial de comandos realizados por el usuario en cuestión. Además de accediendo al propio fichero, también puede accederse a su contenido a través de la instrucción history.

Para concluir el artículo, comentar que existen muchos más logs que podrían ser de interés dependiendo de los hallazgos realizados o de las acciones realizadas por el atacante. Por este motivo es muy importante prestar atención a cada uno de ellos y saber hacía donde dirigir el análisis forense para obtener el mejor resultado posible a medida que éste se va realizando.

Con esta serie de dos artículos se pretende hacer una pequeña descripción sobre algunos comandos y registros de logs que deben analizarse cuando nos encontramos ante un análisis forense en un sistema Linux.

(Añadido 29.05, 16h)

Para realizar esta serie de posts, se ha cargado la imagen del sistema afectado en una máquina virtual, por lo que ante cualquier modificación realizada, siempre se puede volver al sistema “original”.

[Read more…]

Para este nuevo reto de esteganografía, partíamos de la siguiente imagen la cual sabíamos que contenía el color del cable que conseguía desactivar la detonación de la bomba en caso de una emergencia. Color que era la solución al reto:

Al abrir la imagen, no observamos nada fuera de lo normal, así que procedemos a realizar un pequeño análisis de la imagen abriéndola con un editor hexadecimal y analizamos su cabecera para ver si efectivamente se trata de una imagen PNG.

Una vez comprobado que efectivamente se trata de una imagen PNG, podemos comprobar si se ha ocultado alguna información mediante la técnica de EOF (End Of File) por ejemplo, que es una de las más sencillas, ya que consiste en añadir la información a ocultar después de la marca de finalización del fichero. Esto se puede realizar con aquellos tipos de archivos cuya estructura utiliza una cadena o conjunto de bytes concretos para indicar el final del mismo, posición a partir de la que ya no existirán más datos referentes al archivo.

Después de esta pequeña introducción a la técnica EOF y volviendo al reto, podemos decir que las imágenes PNG poseen la cabecera descrita anteriormente, y la cadena que indica el final de la imagen es “IEND”, más concretamente el conjunto de bytes “00 00 00 00 49 45 4E 44 AE 42 60 82”. Así que si procedemos a analizar el conjunto hexadecimal, observamos que efectivamente el fichero acaba con “IEND” y no hay información extra después de la misma. Pero si buscamos esta cadena, podemos comprobar que se repite una vez más, y justo después de ésta, existe otra cabecera PNG (como se puede ver en la siguiente imagen), lo cual quiere decir que muy probablemente hayan dos imágenes PNG concatenadas. Siendo la segunda la información oculta de la primera.

Como nota hay que destacar que al abrirla con el visor de imágenes, no hemos notado nada raro porque los editores están preparados para leer hasta el punto donde se indica el final de la imagen y omitir toda la información que exista después.

Si separamos los dos archivos, obtenemos la siguiente imagen de otra bomba distinta, la cual también se corresponde a un archivo PNG como hemos visto anteriormente.

Llegados a este punto tenemos dos imágenes totalmente distintas, y a simple vista ninguna nos aporta ningún dato que nos ayude a descubrir cual es el color del cable que hay que cortar para desactivar la bomba…

Hace unos días, hablamos en el blog sobre la técnica LSB (ver I y II), que nos permitía ocultar información en imágenes PNG. ¿Coincidencia? Vamos a comprobarlo :)

Si usamos el segundo script facilitado en el anterior post, podremos ver si se ha utilizado esta técnica para ocultar algún archivo más en alguna de las imágenes, y obtendremos el resultado siguiente para cada una de las imágenes:

En la primera imagen podemos ver claramente que se esconde algo, ya que a partir de cierto instante no aparece ningún bit menos significativo a 1 (todos los píxeles son blancos), y además vemos que se ha ocultado el archivo recorriendo la imagen por columnas. En la segunda imagen no vemos nada que indique a simple vista que se ha utilizado LSB, pero si nos fijamos más detalladamente, a partir de cierto instante la imagen resultante parece que sea más “clara”, existen menos puntos negros. ¿Será debido a algo o es simplemente que la imagen es así realmente?

Como en la primera imagen parece que tenemos claro lo que hay que hacer vamos a ello.

Ejecutamos el script para obtener el archivo oculto dentro de una imagen en formato PNG especificando el recorrido por columnas: php obtener.php columnas bomba.png archivo_oculto

Con la anterior instrucción, nos aparecerá en nuestro directorio un nuevo fichero del cual desconocemos la extensión, así que haciendo un file del mismo vemos que se trata de un documento de texto de OpenOffice.

Dependiendo del editor que utilicemos al abrirlo, es posible que nos diga que el archivo esta corrupto y pregunte si lo queremos reparar. Si el programa lo repara automáticamente perfecto, pero en el caso de que no lo haga, deberemos hacerlo nosotros manualmente. Para esto, basta con abrir el archivo con un editor hexadecimal y eliminar todos los 0s que existan después de los bytes que indican el final del mismo (0x00 0x00 0x00). Esto es debido a que al extraer los bits menos significativos de la imagen y crear el archivo nuevo, también se han añadido los 0s que indicaban que se había acabado el fichero oculto.

Una vez abierto el documento, vemos que lo único que aparece es la frase “Las instrucciones las puedes encontrar aquí:” y cuatro hojas más sin “nada” escrito. Pero si seleccionamos todo el contenido del documento y cambiamos el color de la letra a negro (por ejemplo), vemos que aparece un texto que antes no veíamos, el cual se corresponde a un texto cifrado en base64.

El texto codificado es:

“QV92M2NFc19MNHNfYzBzQTVfcEVxVTNuNHNfU29uX0xBc19NNHNfMW1QMHJUYW4zc19QZVJvX24wX1MxM21wUmVf
bDBfczBOX1QwZDRzX0VsbEFz”

Y al decodificarlo obtenemos:

“A_v3cEs_L4s_c0sA5_pEqU3n4s_Son_LAs_M4s_1mP0rTan3s_PeRo_n0_S13mpRe_l0_s0N_T0d4s_EllAs”

Si logramos interpretar el texto como se espera, nos da una pista para poder obtener un archivo oculto en la siguiente imagen, ya que nos dice que las cosas pequeñas son importantes, refiriéndose a los bits menos significativos de la imagen, pero que no todas ellas, es decir, no todos los colores ;)

Sabiendo esto, podemos dar sentido a la parte más clara de la imagen obtenida de comprobar_lsb.php de la imagen oculta. Ya que esto es debido a que se han rellenado de 0s uno o dos colores de los tres disponibles (RGB), y por lo tanto el hecho de que los 3 bits menos significativos de cada píxel coincidan en 0 es más probable.

Dicho esto, lo que tenemos que hacer es modificar el script de obtener el archivo oculto mediante LSB para que no obtenga los bits de los tres colores, y comprobar si nos devuelve un fichero válido.

Una vez realizadas las pruebas pertinentes, descubriamos que la única combinación que devolvía un fichero válido era obteniendo únicamente los valores del color verde (G), la cual nos devolvía una bonita imagen JPG de una playa en una puesta de sol. El script utilizado podría ser algo como obtener_versionReto.php, proporcionado en este enlace.

Llegado este punto alguien podrían pensar que la solución del reto era el color verde por el hecho de que la información estuviese oculta ahí, pero como se dijo en la presentación del reto, cuando se descubriera la respuesta se sabría claramente. Así que si ahora tenemos una nueva imagen, querrá decir que deberemos descubrir algo más ¿no? En este caso la solución la encontramos utilizando las funcionalidades que nos aportan algunos programas de edición de imagen como por ejemplo GIMP (aunque también se pueden desarrollar herramientas propias) para la detección de bordes de las imágenes.

Si seleccionamos el filtro de detección de bordes mediante aristas y seleccionamos el algoritmo Prewitt (por ejemplo) con una cantidad de 10 …

Obtendremos la siguiente imagen, en la que podremos leer “RED”, nuestro color tan buscado :)

Espero que hayáis disfrutado una vez más con este tipo de retos y que hayáis practicado y aprendido mucho durante la solución del mismo. Mención especial para Kachakil, que unas horas después de la publicación ya había resuelto el reto y Hecky, que estuvieron cerca de resolver el reto.

(N.d.E. A partir de ahora gracias al volumen y calidad de las colaboraciones de Rafa, pueden encontrar todas sus entradas, futuras y pasadas, en el menú de autores ubicado en el lateral de la derecha.)

Gracias a la detención y análisis de los sistemas informáticos de uno de los implicados en el último atentado, hemos podido obtener a través de un correo electrónico la imagen del nuevo prototipo de bombas que la banda tiene planeado utilizar. Según creen nuestros analistas, este tipo de mensajes entre terroristas suele contener información extra, como pueden ser datos sobre su fabricación o desactivación.

Sabiendo esto, nuestro equipo de investigación está completamente convencido de que la forma de desactivar el nuevo prototipo de bombas se puede encontrar en la imagen capturada, así que… ¿cuál es el color del cable que deberán cortar los expertos en desarticulación de explosivos para poder evitar la detonación?

Enlace a la imagen: bomba.png
MD5: 021928d0966a189d26fe3e9499d4243a

Nota (que no pista) sobre el reto: Debido a que no tenemos un validador de respuestas, comentar que cuando se obtenga la solución del reto, se sabrá claramente que es la solución ;)

Para comprender mejor la técnica de esteganografía comentada en la entrada del viernes, he realizado una serie de scripts en PHP que nos permiten realizar todo este procedimiento de manera automática, simplemente indicando los archivos a utilizar.

El primero de ellos es ocultar.php (en todos los scripts es necesario quitar la extensión .txt para probarlo) que utilizaremos para ocultar el archivo deseado en la imagen y nos devolverá una imagen en formato PNG, que será igual a simple vista que la imagen de entrada pero que contendrá el archivo oculto. Para utilizarlo, debemos ejecutarlo de la siguiente forma:

php ocultar.php formato_entrada[jpeg/png] recorrido[filas/columnas] \
            imagen_portadora fichero_a_ocultar imagen_resultante

Como podemos ver, tenemos la opción de elegir el tipo de imagen de entrada entre “jpeg” y “png”, y la forma en que se recorrerá la imagen para ir introduciendo los bits del archivo a ocultar. Esto último sirve para saber en qué orden tendremos que recorrer la imagen resultante para poder obtener el archivo oculto, ya que debemos saber el orden en el que se han introducido los bits en la imagen para después ordenarlos correctamente.

El segundo script, comprobar_lsb.php, nos sirve precisamente para conocer en qué orden debemos recorrer la imagen portadora para obtener el archivo oculto, ya que crea una imagen de igual tamaño que la portadora, pintando de color negro si el píxel contiene algún 1 en los bits menos significativos o de color blanco si tiene todo 0s. Esto es debido a que para poder detectar el final del archivo oculto, los siguiente bits menos significativos de los píxeles se rellenan con 0s.

Para ejecutarlo lo haremos de la siguiente manera, donde en formato_salida indicaremos si queremos obtener una imagen jpeg o png con el resultado.

php comprobar_lsb.php formato_salida[jpeg/png] imagen_portadora imagen_salida

En las siguientes imágenes, podemos ver un ejemplo de una misma imagen en la que se ha utilizado el método LSB para ocultar un archivo recorriendo la imagen por columnas y por filas:

Una vez hemos comprobado que en la imagen hay información oculta y la forma en la que se ha ocultado, podemos utilizar el tercer script, obtener.php, para obtener el archivo oculto.

Para ejecutarlo, lo haremos de la siguiente forma:

php obtener.php recorrido[filas/columnas] imagen_portadora archivo_salida

En este caso, los scripts se han utilizado para hacer una demostración del método, pero pueden ser utilizados para ocultar cualquier tipo de archivo en una imagen usando el método LSB, siempre y cuando se cumpla el requisito del tamaño :)

Para aquellos que quieran probar y comprobar la técnica, os dejo dos imágenes completamente “iguales”, pero una de ellas tiene algo oculto. ¿Sabríais decir cual es? :P

En esta ocasión vamos a seguir hablando sobre esteganografía, concretamente sobre una de las técnicas que se pueden utilizar para ocultar cualquier tipo de información dentro de ciertos tipos de archivo, como por ejemplo imágenes o audio.

El método en cuestión es conocido como LSB (Least Significant Bit) y como su nombre indica consiste en aprovechar el bit menos significativo de cada byte para guardar información en él. En la introducción que se hizo en este mismo blog sobre esteganografía ya se comentó esta técnica, pero esta vez vamos a entrar un poco más en detalle y para hacer más comprensible la técnica vamos utilizar un ejemplo basándonos en una imagen en formato png (llamada “A”) en la que queremos ocultar un documento de texto (llamado “B”), creando la imagen “A+B”.

[Read more…]

Hace unos días os propusimos un reto sobre esteganografía, en el cual debíais encontrar cual era el videojuego del cual se había realizado una nueva versión. Para esto se proporcionaba un archivo comprimido el cual se creía que tenía información privilegiada sobre este juego.

Al intentar abrir el archivo, se nos pedía una contraseña, la cual sabíamos (gracias a la pista proporcionada en un comentario del reto) que sólo era de caracteres numéricos y de no más de cuatro caracteres, así que necesitábamos obtener esa contraseña.

Para este paso, como sabemos que es una contraseña sencilla, podemos utilizar algún software de recuperación de contraseñas como por ejemplo rarcrack.

Después de un ratito (este ratito depende de la máquina utilizada y el programa elegido, todo hay que decirlo, aunque en este caso se acotaron mucho los caracteres posibles y la longitud para que se obtuviese más rápido) obtendríamos nuestro password, el cual era “4567”, y podríamos abrir el archivo.

Una vez extraemos el contenido del rar, nos encontramos con dos fichero más. Uno con el nombre “juego.txt” y otro con el nombre “final_challenge”.

[Read more…]