9 de noviembre de 2009

reCAPTCHA

Creo que la medida de seguridad que hoy voy a presentar a pesar de ser bien conocida -a la par que odidada en algunas ocasiones- añadirá un puntito adicional a su favor que otras soluciones parecidas no disponen: bajo coste y robustez. Hablábamos hace un par de entradas de “encuestas seguras”, su cada vez mayor presencia y relevancia en los medios de comunicación que pueden (y no es erróneo decirlo) engañar a la opinión pública. Pues bien, una aplicación práctica de reCAPTCHA es la protección contra ataques por repetición en las encuestas. Claro está a alguno le puede parecer exagerado para una encuesta, es solo un ejemplo, seguro que se os ocurren otras muchas aplicaciones.
Entrando en detalle, reCAPTCHA es un servicio que puede incrustarse de forma gratuita en cualquier aplicación web, incluye 2 palabras distintas que deben escribirse separadas, lo cual añade un puntito más de robustez. Además incluye compatibilidad para discapacitados permitiendo la emisión de CAPTCHAs en forma de sonido. Para instalarlo es necesario darse de alta en el sistema con el dominio que se vaya a utilizar, con esto se nos proporcionarán dos claves, una pública y una privada. Al incrustar el siguiente código javascript en nuestro frontal web:

Se hará una llamada a los servidores de recaptcha y se incrustará el desafío en el frontal, lo que vayamos a hacer con él ya es nuestra decisión. Ahora bien dependiendo del lenguaje de nuestra aplicación web deberemos acudir aquí para obtener los recursos que analicen y verifiquen el CAPTCHA, por ejemplo en ASP deberemos añadir una librería a nuestro proyecto que contiene una serie de llamadas para verificar el CAPTCHA, este proceso se realiza nuevamente contra servidores externos, para mayor claridad:

Es decir, en 1) el usuario carga la página web que tiene incrustado el CAPTCHA, en 2) el browser solicita a los servidores de reCAPTCHA el reto, esta petición la hace con la clave publica del servidor. Después en 3) el usuario soluciona el reto y esa solución es enviada al servidor de aplicaciones (o el frontal web dependiendo de la arquitectura), en 4) este servidor contacta con el API Server, aquí es cuando se utiliza la clave privada para verificar que efectivamente la petición no ha sido manipulada en su recorrido, el API server devuelve el resultado del desafio, esto lo recogerá el servidor de aplicaciones proporcionando una respuesta dependiendo de si se ha superado el desafió o no.


¿Sencillo? A mi me parece que sí, como detalle final añadir que el API Server detecta las IP de los clientes que solucionan “muchos” CAPTCHA en pocos minutos, evitando así que en caso de que el desafío se haya visto comprometido se realicen ataques por repetición bloqueando la IP origen temporalmente.


Bueno, bonito y barato, lo ideal para comenzar la semana :)

Salu2


PD: Entrada relacionada de Breaking CAPTCHAS.

6 de noviembre de 2009

Data Carving Challenger

Al hilo de nuestra anterior entrada sobre zombies, en otra de esas maniobras de parecidos razonables hoy vamos a coger la pala y cavar, cavar y cavar hasta que saquemos los cuerpos del delito, aunque los ingleses tienen un verbo algo más extraño para estas tareas, se llama carving (trinchar), Data Carving.

En el reto forense de hoy nos han proporcionado un raw de aproximadamente 41 MB, esto es un archivo binario cuyo contenido es desconocido, podemos imaginar que ha sido extraído de un disco corrompido o formateado, nuestra labor es extraer el contenido del disco y descubrir de forma inequívoca lo que en el había. Antes de ponernos los guantes de manipular cadáveres, vamos a repasar algunos conceptos necesarios:

La magia de los números

Como es sabido, los ficheros no son más que un conjunto binario que, agrupado por ciertos patrones diferencia a unos de otros. Por ejemplo, si esos números en binario forman la combinación 25 50 44 46 al comienzo de un archivo sabremos que estamos delante de un PDF (además que la traducción a hexadecimal es %PDF). Bien, los sistemas operativos se basan en los conocidos como “magic numbers” para identificar los archivos y saber que acciones puede ejecutar con ellos. En Linux el comando file es el encargado de identificar los magic numbers al principio y final de un archivo para saber qué es, si hacemos un man file:

“file tests each argument in an attempt to classify it. There are three sets of tests, performed in this order: filesystem tests, magic number tests, and language tests. The first test that succeeds causes the file type to be printed. The type printed will usually contain one of the words text (the file contains only printing characters and a few common control characters and is probably safe to read on an ASCII terminal), executable (the file contains the result of compiling a program in a form understandable to some UNIX kernel or another), or data meaning anything else (data is usually `binary’ or non-printable). Exceptions are well-known file formats (core files, tar archives) that are known to contain binary data. When adding local definitions to /etc/magic, preserve these keywords. People depend on knowing that all the readable files in a directory have the word “text” printed. Don’t do as Berkeley did and change “shell commands text” to “shell script”. Note that the file /usr/share/file/magic is built mechanically from a large number of small files in the subdirectory Magdir in the source distribution of this program.”

Comprobamos que “file” hace 3 test, 1º pregunta al filesystem para saber como lo identifica, 2º comprueba los números mágicos, 3º hace comprobaciones de lenguaje. Es sencillo engañar al comando file. Podemos manipular el directorio /usr/share/file/magic y dejar el file con cara de poker ya que en ese archivo está el repositorio que asocia números y formatos de archivo:

O podemos cogernos un editor hexadecimal, hacer unos cambios aquí y allá y encontrarnos con que un script es realmente,,, ¡un ejecutable MS-DOS!:

File System

Ahora que sabemos cómo identificar a los archivos tenemos que saber que no todos los sistemas operativos los guardan de igual forma, dependerá exactamente del formato que tenga el file system, FAT 16/32, NTFS o UFS /JFS son algunos de los formatos que rigen la arquitectura de los file sytem. Desde una perspectiva forense debemos saber que dependiendo de varios factores nuestros archivos se pueden encontrar fragmentados (es decir, divididos en regiones de memoria distintas), además esa fragmentación no tiene por qué ser consecutiva, puede haber trozos que han sido sobrescritos por otros (por ejemplo, tras un borrado y escritura) y se han perdido o incluso el archivo puede estar comprimido (compresión NTFS), esto puede complicar mucho las cosas,,, a priori.

Manos a la obra

Ahora que tenemos conocimientos básicos sobre los archivos y su estructura de almacenamiento es momento de abordar el “DFRWS Forensic Challenge Images”. Para este reto aconsejo bajar una distribución forense, la que he utilizado yo es Helix 2008 RC1, disponible aquí como appliance de máquina virtual. Dentro de esta distribución descargamos y descomprimimos el raw y ejecutamos foremost . Esta herramienta es la llave inglesa del Data Carving, si hacemos un foremost –h vemos todas las opciones:

foremost version 1.5 by Jesse Kornblum, Kris Kendall, and Nick Mikus.

$ foremost [-v|-V|-h|-T|-Q|-q|-a|-w-d] [-t ] [-s ] [-k]

[-b ] [-c ] [-o] [-i]

-V - display copyright information and exit

-t - specify file type. (-t jpeg,pdf ...)

-d - turn on indirect block detection (for UNIX file-systems)

-i - specify input file (default is stdin)

-a - Write all headers, perform no error detection (corrupted files)

-w - Only write the audit file, do not write any detected files to the disk

-o - set output directory (defaults to output)

-c - set configuration file to use (defaults to foremost.conf)

-q - enables quick mode. Search are performed on 512 byte boundaries.

-Q - enables quiet mode. Suppress output messages.

-v - verbose mode. Logs all messages to screen

Con el archive de configuración por defectoy y sin habilitar la opción de detección de indirección de bloques es capaz de recuperarnos 25 archivos:

Foremost started at Wed Oct 28 11:22:24 2009

Invocation: foremost dfrws-2006-challenge.raw -o forensic.txt

Output directory: /home/bagside/Desktop/forensic.txt

Configuration file: /etc/foremost.conf

------------------------------------------------------------------

File: dfrws-2006-challenge.raw

Start: Wed Oct 28 11:22:24 2009

Length: 47 MB (49999872 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00003868.jpg 280 KB 1980416

1: 00008285.jpg 594 KB 4241920

2: 00011619.jpg 199 KB 5948928

3: 00012222.jpg 6 MB 6257664

4: 00027607.jpg 185 KB 14134784

5: 00031475.jpg 206 KB 16115200

6: 00036292.jpg 174 KB 18581504

7: 00040638.jpg 292 KB 20806656

8: 00041611.jpg 1 MB 21304832

9: 00045566.jpg 630 KB 23329792

10: 00094846.jpg 391 KB 48561152

11: 00000009.htm 17 KB 4691

12: 00004456.htm 22 KB 2281535

13: 00027496.htm 349 KB 14078061

14: 00028244.htm 50 KB 14460928

15: 00029529.htm 183 KB 15118957

16: 00032837.doc 282 KB 16812544

17: 00045964.doc 71 KB 23533568

18: 00028439.zip 157 KB 14560768

19: 00030050.zip 697 KB 15385752

20: 00045015.zip 274 KB 23047680

21: 00007982.png 6 KB 4086865 (1408 x 1800)

22: 00033012.png 69 KB 16902215 (1052 x 360)

23: 00035391.png 19 KB 18120696 (879 x 499)

24: 00035431.png 72 KB 18140936 (1140 x 540)

Finish: Wed Oct 28 11:23:19 2009

25 FILES EXTRACTED

jpg:= 11

htm:= 5

ole:= 2

zip:= 3

png:= 4

Sin embargo el resultado no es satisfactorio siempre, por ejemplo en algunas imágenes nos encontramos:

Existen herramientas alternativas como photorec y testdisk capaces de detectar más archivos, el problema es que el número de falsos positivos es altísimo (a mí me ha detectado unos 3000 archivos, 20950 de ellos falsos xd). Si habilitamos las opciones de búsqueda avanzada de foremost, o buscamos algunas extensiones en concreto encuentra exactamente lo mismo, tampoco es capaz de recomponer las imágenes fragementadas, ¿qué podemos hacer en este caso?

Vamos a centrarnos por ejemplo en nuestro amigüito el puercoespín, archivo 5 de los listados anteriormente. Si lo abrimos veremos que sale partido, se reconoce el tamaño de la imagen correctamente pero hay algunos bits que están en otro sector así que no puede formarla completamente. Sabemos que el tamaño del archivo son 206 KB, sin embargo descubrimos (esta imagen la obtiene photorec, mientras que foremost no la detecta) que existe un archivo con una foto de Marte en la posición 31532, es decir, 57 Kb después, ¿Dónde están los demás? La foto de Marte comienza cuando la anterior todavía no ha finalizado, quedando ambas corrompidas. Aquí debemos fijarnos en qué posición comienza cada fotografía y el Offset, esto es 31475-31532 para el puercoespín y 31533-32836 para marte. En primer lugar extraemos esos 57 KB del puercoespín a un archivo con el comando dd:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31475 count=`expr 31532 - 31475 + 1` > hedgehog1.jpg

58+0 records in

58+0 records out

29696 bytes (30 kB) copied, 0.0176145 s, 1.7 MB/s

Luego añadimos el trozo que falta a partir del trozo que sí que conocemos de marte:

bagside@bagvapp:~/Desktop$ dd if=dfrws-2006-challenge.raw skip=31753 count=`expr 32836 - 31753 + 1` > hedgehog1.jpg

1084+0 records in

1084+0 records out

Y podemos ver a Rizo:

Una vez que la foto ha sido reconstruida podemos utilizar photorec para obtener los datos exactos del archivo, a partir de ellos recomponer la foto de marte y el resto de fotos detectadas es trivial. Claro está, ese proceso puede ser largo y arduo, además puede diferir según el tipo de archivo.

En el post de hoy hemos visto técnicas de Data Carving y la forma en que trabajan estas herramientas, también hemos visto como el componente humano sigue siendo fundamental, os animo a que practiquéis por ejemplo, con una carpeta en la que habéis borrado todo (sin borrado seguro, obviamente) o un pendrive formateado y reescrito.

Salu2.