Facebook Forensics Paper y algo más...

Ayer me encontré este divertido paper, y digo divertido por que realmente me pareció que muestra cosas curiosas acerca de esta popular red social. Incluye también bastantes datos que por el hecho de conectar nuestro iPhone o teléfono con Android podemos obtener (siempre y cuando tengamos la aplicación instalada claro).

Merece la pena echarle un vistazo.

Dicho esto una breve aclaración para mis tres o cuatro lectoras, allá por el mes de Enero inicié una maravillosa aventura, la escritura de mi primer libro (no tecnológico, se entiende). Desde entonces y gracias a los consejos de algún compañero bloguero (ejem, lobosoft) he consumido mi tiempo libre en tan gran reto, mi escasa pericia en el arte de las letras acompañada de mi perseverancia ha conseguido que esté prácticamente a punto de terminarlo, con lo que este gran proyecto (que espero publicar aquí) llegará a su fin. Aunque solo para poder adentrarme en otro nuevo, mucho más grande y que no tiene nada que ver. ¿Significa esto que "Todo es seguro" muere?, bueno, digamos que ya llevaba meses criogenizado y así va a seguir una buena temporada.

Por supuesto sigo dedicándome a la Seguridad a diario por lo que no descarto que un día... :)

Muchas gracias a todos.

Warcraft DiscHack (y el Falso Positivo) I/II

El por qué de la idea

Todo comenzó a finales de Agosto, un poco cansado de que mi viejo K8 3000+ no diera mucho rendimiento con juegos relativamente viejos (Bioshock, Alone In the Dark 4, etc.) volví a instalarme el Warcraft III: The Frozen Throne. Hacía ya bastantes meses que no me ponía a “ownear” así que no sabía como estaba el percal en Battle.net, cual fue mi sorpresa cuando me di cuenta que estas batallas cibernéticas ya no son lo que eran, era muy habitual cruzarse con “hackers” que se valían de cheats como desactivar la niebla de guerra (que te permite ver las unidades enemigas) o simplemente desconectarlo, el llamado disc Hack:

Aunque a mi siempre me gustó más el video del guiry flipao que, tras padecer los sufrimientos de un demon hunter y su “Mana Burn”, lo desconecta:

El caso es que, desanimado como estaba por la ausencia de fair play decidí investigar en que consistía el dischack, que era el que más me preocupaba, por lo que podía ver el proceso del juego “war3.exe” crecía exponencialmente desde que se lanzaba el ataque, la desconexión no era instantanea, más bien el juego se ralentizaba en lo que parecía un envío de paquetes con un TTL incrementando al máximo (o al menos eso es lo 1º que pensé).

Investigación

Ni corto ni perezoso me dispuse a descargar un par de herramientas muy útiles en estos casos, el WinSock y el CheatEngine, esta última está especialmente diseñada para alterar parámetros de las partidas. Winsock es muy útil para analizar la actividad de los procesos y sus flujos de comunicaciones TCP/IP. También permite establecer filtros para parar determinados tipos de paquetes, lo que puede ser útil si queremos detener el dischack ;-)

Entonces ocurrió algo que personalmente odio, ante la descarga de Winsock el Avast saltó como loco y borró el .rar que lo contenía, dando una alerta por troyano, pensando que esto suele ocurrir con las herramientas de hacking lo subí a virustotal para conocer terceras opiniones, con este resultado : 37/43 positivos con muchos Generic.WinTrojan de por medio o W32/Trojan, etc. (deberían hacer un chiste con estas alertas: Tienes menos personalidad que un Generic.WinTrojan), en mi espíritu paranoico cesé mis actividades de investigación en Warcraft y las sustituía por otras, ¿Qué hacíar realmente WinSock?, ¿me podía fiar?

Lo que realmente investigué

Como laboratorio personal tengo una pequeña máquina virtual con Windows XP SP2 , ideal para hacer un destrozo y luego volver a la normalidad como si nada, en estos casos la función de snapshot de VMWare Workstation viene de perlas. Utilizaré solo dos herramientas para averiguar que hace WinSock:

- Regshot

- Process Monitor

Con regshot obtendré rápidamente una instantánea del registro de sistema, después instalaré y ejecutaré WinSock, tomando una nueva instánea. Regshot comparará ambas imágenes y me dirá los cambios. El programa es muy sencillo e intuitivo de utilizar así que no tiene pérdida:

Tras todo ello vemos bastantes cambios en el registro, aunque muchos están relacionados con cosas que no son WinSock, las únicas entradas relevantes son las siguientes:

HKU\S-1-5-21-1935655697-764733703-839522115-1003\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Documents and Settings\GigA\Escritorio\WPE PRO.exe: "WPE PRO"

HKU\S-1-5-21-1935655697-764733703-839522115-1003\Software\WinRAR\ArcHistory\0: "C:\Documents and Settings\GigA\Escritorio\wpepro09x.zip"

La primera parece que ha incluido en el listado de software de Windows la aplicación WPE PRO, con la ruta que tiene en el sistema, y la ha cacheado para futuras llamadas. La segunda cambia el histórico de WinRar para que figure el zip de Winsock. Nada extraño por ahora.

Tras esto lanzamos process monitor, esta herramienta de Microsoft combina las bondades de Filemon y Regmon, que formaban parte de SysInternals y han sido combinadas en este nuevo producto. Es perfecto para monitorizar la actividad de un proceso, las librerías de las que depende, las llamadas que realiza, el tráfico de red que genera, los archivos que crea, etc. etc. En este caso vemos que WinSock genera bastante actividad en el sistema, que además mezclada con el resto de procesos puede generar bastante confusión, por suerte con un botón derecho “Hightlight WPE-PRO” nos resaltará en verde lo que nos interesa.

Hay bastantes líneas, muchas de ellas son sencillamente utilización de fuentes de Windows (para lo cual tiene que leer muchos archivos), hay otras en las que llama a la librería que adjunta, WpeSpy.dll.

El programa comienza como es obvio cargándose en memoria, después pasa a añadir a la carpeta prefetch de Windows varios un archivo con la aplicación, en el mismo se han encontrado referencias a entradas de registro del mismo WPE, por lo cual entendemos que quiere que Windows tenga cacheada la aplicación para próximas sesiones. Después realizar varias consultas al sistema, mapeando la unidad raiz “C:\” así como otras de Windows, System32, etc. Después pasa a generar varios archivos en la carpeta fantasma de Windows, la odiada, enigmática y poco comprendida desde el punto de vista de los usuarios WinSxS, así que podemos suponer correctamente que tenemos varios hard-links nuevos para la posteridad.

Tras perdernos durante varios minutos por el registro de actividades de WinSock comenzamos a sospechar que todo es terriblemente normal, no hay conexiones a Internet, no hay creación de ficheros extraños, vemos múltiples llamadas a principalmente dos archivos del core de Windows, kernel32.dll y ntdlm.dll, uno para realizar llamadas al sistema (recordemos que este software sirve para monitorizar procesos) y otro para el gestor de archivos. También hay llamadas a otras librerías y drivers (como wsock32.dll) que entiendo muy necesarios para su ejecución:

Conclusión

Si, ha sido una falsa alarma, lo cual puede dejar a uno más perplejo que anteriormente, ¿37 antivirus dando un falso positivo?, al menos podrían limar un poquito las alertas y que solo fuese un Warning: Hacking Tool, pero no veo el Trojano por ningún lado, e imagino que ellos tampoco. Mi teoría es la que todos estaréis pensado, alguien lo clasifica así una vez por alguna razón y los demás copian la firma. Recuerdo el caso de una casa de antivirus que generó un falso positivo “adrede” solo para comprobar que 24 horas después todas las demás habían hecho lo mismo, sin pararse a investigar claro qué era aquel positivo.

Bueno, y ahora que tenemos una cierta confianza en nuestras herramientas vamos a analizar el famoso, “dischack” de Warcraft, pero será en otra entrada ;-)

User Assist en Windows 7

Un rápido vistazo al registro de Windows 7 nos muestra que hay algunas cosas que dentro del sistema operativo de Microsoft no han cambiado mucho desde el Windows 2000 y sucesores. El menu contextual y las herramientas del registro son prácticamente las mismas, sin embargo el contenido del registro va cambiando poco a poco. En la entrada de hoy vamos a presentar una clave del registro que suele pasar desapercibida, el UserAssist:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

Este registro es el encargado de almacenar estadísticas y datos del principal proceso de todo Windows. El explorer.exe, si echamos un rápido vistazo a su contenido:

El "nuevo" registro de Windows

Vemos que no entendemos nada, ¿por qué? Bueno, la respuesta es obvia: está cifrado. Microsoft utiliza el algoritmo rotativo ROT13, que lo único que hace es rotar 13 posiciones (podían ser 12 o 14, pero no), un cifrado débil que permite a cualquiera descifrar fácilmente esa clave. Con Windows 7 esto no ha cambiado, se sigue utilizando ROT13 aunque si hubo algún cambio, concretamente en el formato. Por suerte hay gente como el belga Didier Stevens que ya se ha puesto a hacer Ingeniería Inversa para averiguar qué clave ROT13 hay que utilizar y en qué formato se guardan los registros, podeis encontrar más información aquí, y no solo eso, también se han currado una herramienta para descifrar vuestras claves y saber qué programas son lanzados por el explorador, cuando fue la última vez que se lanzó, etc. Por tanto viene muy bien no solo para satisfacer vuestra curiosidad, sino como herramienta de apoyo de análisis forense en Windows:

Interfaz del User Assist: Ultimo programa ejecutado, User Assist

Incluye datos sobre el tiempo que una aplicación tiene el foco, ultima vez que se ejecutó, número de veces ejecutadas y ,,,, la habilidad de con un click deshacer este registro de vuestras actividades (pone a 1 el valor de no logging en el la entrada UserAssist).

Los secretos de W7 van saliendo a la luz,,, ¡Salu2!

Sandboxie

Hoy presentamos una sencilla aplicación que hará las delicias de los muchas veces sufridos usuarios de máquinas virtuales. Una de las aplicaciones de estas últimas es disponer de un entorno “basura” en el que realizar nuestros experimentos, bajarnos esos archivos sospechosos o directamente analizar malware. Es probable que os pase como a mí, juntando fácilmente 4 o 5 de estas máquinas nuestro disco duro baja vertiginosamente, además se necesita mucha memoria RAM para que vayan decentemente ligeras.

Con SandBoxie se puede ahorrar bastante tiempo y recursos en maquinas virtuales, esta aplicación genera un entorno de virtual donde todo lo que se ejecute estará aislado del sistema operativo. Se integra en Windows perfectamente como una opción más del “botón derecho – click” y su complejidad es mínima:

Podemos trabajar con ficheros en un entorno virtual, darle los permisos que queramos sobre el entorno real, ubicar un espacio para almacenar aquellos archivos que querramos extraer de la cajita de arena, disponer de más de una sandbox, etc. Y todo esto de forma gratuita :)

Un detalle que me ha gustado es que no es trivial "salirse" de la sandbox, a pesar de que los procesos nuevos te aparezcan si haces un pslist lo que ellos generan está controlado y sus permisos restringidos. Por ejemplo, probad a ejecutar un cmd.exe en la sandbox y desde ahí un notepad, word, etc. No podréis grabarlos en la unidad física, casi casi como un appliance vmware. En la página de los autores hay un buen tutorial que os dejo por aquí , espero que os guste.

Happy Week!

El café está servido,,,

Microsoft’s Computer Online Forensic Evidence Extractor , COFEE () para los amigos, está circulando por Internet, o eso dicen multitud de blogs desde hace unos días. Y tiene que ser verdad aunque haya investigadores como Robert Graham que anuncien en su blog que la versión disponible solo aloja 45 utilidades / comandos, en lugar de los 150 que Microsoft anunció.

Pero, ¿Qué es Cofee? Bueno, en la primavera del año pasado surgieron comentarios y especulaciones como setas cuando Microsoft informaba al mundo de que entregaba COFEE a los cuerpos de policía y seguridad del mundo como herramienta de análisis forense, esto es, no había nada más que llegar con un pen drive a la escena del crimen, enchufarla y ella sola obtenía todos los datos de auditoría del equipo, se rumoreaba que aprovechaba puertas traseras desconocidas, que utilizaba algoritmos criptográficos avanzados para obtener las contraseñas de los usuarios (¿?¿?¿?), etc. Teoría conspiratoria al poder vamos.

Pues haciendo unas cuentas búsquedas en los corrillos de seguridad, descargando algún que otro torrent, etc. Efectivamente, damos con la herramienta en su versión 1.12. La misma incluye un completo manual de uso, instalación, configuración, generación de informes, etc. Su funcionamiento es sencillo, se instala en el equipo del investigador, generas un pen-drive personalizado con las herramientas asociadas a la investigación que se pretende realizar (puedes meter las 150, aunque se requerirá un USB de 2 GB para recolectar tanta evidencia), te vas al ordenador de la víctima y descarga todos los registros de auditoría y salida de los principales comandos de Windows y Sysinternals, también hace volcados de memoria por lo que está principalmente pensada para análisis forense en caliente. Una vez hecho esto se extrae el pen drive, el investigador vuelve a su “laboratorio” feliz y contento. Lo introduce en su equipo y,,, Cofee te genera un informe XML con todo lo que ha encontrado. Es decir, análisis forense for dummys.

A priori no hay “comandos secretos”, utilidades desconocidas, puertas traseras, etc. Solo una aplicación amigable que hace todo el trabajo de obtención de evidencias por nosotros, si esto es así, ¿Por qué Microsoft no la libera? Parece no tener mucho sentido por lo que dejo la pregunta en el aire. Ahora bien, no os emocionéis de sobremanera, tras bajar COFEE de distintas fuentes puedo constatar que la versión que se ha fugado es una 1.12 que, lamentablemente no he conseguido instalar y correr en un Windows 7, en un Windows Vista o en un XP. Parece que el instalador está corrupto (¿?), lo que sí se he podido ojear es el manual de la aplicación que confirma datos como, solo funciona en Windows XP con Framework 3.5 (es decir, que tiene que ser XP SP2), los comandos disponibles son conocidos y su principal beneficio es que proporciona la confianza de que las herramientas utilizadas no han sido comprometidas por un rootkit o similares, ya que cada una de ellas tiene su checksum una vez instalada en el dispositivo, si es alterada COFEE lo detectará.

Os dejo algunos pantallazos y la desilusión de no haber encontrado una versión que funcionase correctamente, será cuestión de tiempo supongo:

Interfaz de COFEE

Las herramientas secretas :-p

Recolectando evidencias...

Y nuestro informe XML.

Ahora copa y puro ;-)

Salu2!

Nota 26/11/2009 --> Por fin he conseguido solucionar el problema del instalador, si os lo bajáis y os ocurre lo que a mí probad con esta herramienta. Por cierto, ahora sí puedo corroborar todo lo contado :-D

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.

Forensic Analysis of a Network Scan

¡Hola! Volvemos a la carga con una vieja asignatura que teníamos aparcada desde hace tiempo: Análisis Forense. En el día de hoy hemos cogido un sencillo reto “for beginners” de los muchos existentes en los “scan of the month” del honeynet Project. En el mismo nos proporcionan un fichero binario con un tcpdump de varios megas que incluye una serie de tráfico TCP/IP que deberemos analizar para averiguar que ocurrió, el reto incluye la respuesta a varias preguntas de creciente dificultad. En este “mini-reto” utilizaremos herramientas tan comunes como Wireshark (también vale Ethereal o el sniffer que a vosotros os guste) y nmap. Vamos para allá:

1.- What is a binary log file and how is one created?

Una teórica para empezar, un fichero binario no es más que un archivo generado por el NIDS (Network Intrussion Detection System) Snort que, apoyándose en las habituales librerías Libpcap / Winpcap es capaz de depositar el tráfico exactamente igual que circula por la red en un fichero. La presencia de copias exactas de los paquetes nos garantiza que nada es modificado, ¡el requisito más importante en cualquier investigación! Esto nos lleva a la siguiente cuestión.

2.- What is MD5 and what value does it provide?

Bueno, creo que esto lo sabéis todos ya, lo vimos en esta entrada. El MD5 no es más que un algoritmo de un solo camino que calcula un valor hash, ese valor es único para cada entrada, o eso se supone. Existe un verdadero debate (el cual me está dando una idea para una futura entrada) acerca de la validez de un hash como mecanismo que garantiza que una evidencia no ha sido comprometida, debate acrecentado a medida que se descubren colisiones en los principales algoritmos: MD5 y SHA1. Cuando nos descargamos los archivos del reto nos piden que confirmemos el hash, en este caso lo hemos hecho:

3.- What is the attacker’s IP address?

Se acabó la literature, tenemos que averiguar la dirección IP del atacante, para ello (y dado que no es un fichero grande) examinaremos todas las IP origen y destino con Wireshark. Rápidamente podemos observar que aparecen las siguientes IP source:

192.168.0.9, 192.168.09.9, 192.168.0.254, 192.168.0.199, 192.168.0.1

Y las siguientes IP de destino (IP.dst):

192.168.0.9, 192.168.0.99

En la siguiente captura hacemos filtrado para asegurarnos que no hay otras IP.dst:

De forma curiosa, la regla no filtra aquellos destinos inalcanzables (¡pero eso es una pista!), ahora bien, ¿Cómo sabemos la IP del atacante a partir de esta información? Deberemos examinar los paquetes, no obstante algo huele a chamusquina cuando el 99% del tráfico procede de 192.168.0.9 y tiene de destino 192.168.0.99. No obstante nos aseguramos comprobando el tráfico que sale de 192.168.0.99 y eliminando el que tiene de destino 192.168.0.9 (genera demasiado ruido), obteniendo que no hay tráfico de estas características. Lo cual quiere decir que no hay respuesta de 192.168.0.99 hacia otros destinos distintos de 192.168.0.9, en este caso la ausencia de evidencia es la evidencia de que el atacante (¿supuesto atacante?) proviene de 192.168.0.9, probablemente por que el resto de destinos no existían (¿IP spoofing?).

4.- What is the destination IP address?

Como hemos hecho nuestro trabajo bien en la anterior cuestión, sabemos que la IP que estaba respondiendo a todas las peticiones era la 192.168.0.9. Parece que vamos bien ;-)

5.- We scanned de honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of five works?

Comienza a subir la dificultad del análisis, nos piden averiguar las distintas tácticas de escaneo utilizadas. Vayamos por partes, nada más comenzar la captura se observa un ping hacia 192.168.0.99, justo después (Time 10.346091) comienzan a hacerse peticiones de tipo SYN desde el puerto origen 52198 hacia puertos fuera del rango reservado, el host escaneado responde con trazas [RST, ACK], lo que significa que se ha llegado al puerto pero no hay nadie escuchando, este podría ser nuestro primer tipo de escaneo:

Correspondiente a un nmap –sS (TCP SYN Scan) 192.168.0.99, el cliente debería responder con un ACK pero no lo hace, se queda a medio camino (half-open scanning).

En el Time 148007 se vuelve a producir un ping hacia 192.168.0.99, en ese momento se arranca otro tipo de escaneo, el wireshark nos cambia los colores, lo que ayuda ya que es muy llamativo:

Parece que se están tratando de hacer fingerprinting del sistema operativo, es decir, detectar que tipo de máquina hay detrás, en este caso el escaneo se concentra en los puertos habituales de servicios Windows. Por ahora parece que no tiene suerte nuestro atacante :) sin embargo poco tiempo después, línea de tiempo 150563 comienzan a aparecer paquetes ACK duplicados (el Wireshark los pinta de un negro terrorífico), que tienen su cumbre en el 150626, donde se comienza a recibir [SYN-ACK] en servicios habituales de Windows, lo que parece un nmap –sX (Xmas scan) bastante exitoso:

Ahora bien, justo después (se puede apreciar en la imagen anterior) el atacante trata de establecer conexiones al puerto SSH, pero con todos los flags TCP sin determinar, esto significa que estamos delante de un “Null Scan”, también llamado nmap –sN, si pinchamos en cualquier paquete veremos esta información dentro de los flags del protocolo de control de transmisiones:

Terminamos con un último ataque, se llama decoy scanning y sirve para que el host remoto no sepa identificar (a priori) quien es el host destino, decoy significa señuelo en inglés y lo que hace es realizar la misma petición desde varias IP inexistentes como las que vimos en 3), está muy bien para pasar desapercibidos aunque obviamente no tiene sentido en un entorno como el que estamos viendo:

Puede reproducirse con nmap y la opción –D. Y con esto hemos repasado los escaneos que se han realizado, como vemos es importante conocer los tipos de escáneres que permiten las herramientas, para ello podemos acudir por ejemplo a las técnicas que explican en la página del escáner más famoso.

6) Which scanning tool was used to scan our honeypot? How were you able to determine this?

Bien, en el punto anterior vimos que opciones de nmap había que habilitar para cada ataque, pero eso no significa ni mucho menos que haya sido esta herramienta, ¿verdad? Necesitaremos utilizar un NIDS para analiza las trazas y verificar si detecta algún ataque y por parte de qué, para ello no hay nada como Snort, que nos devolverá algo parecido a esto:

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539

[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996

[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9

[**] [1:628:1] SCAN nmap TCP [**] - 9

Luego ahí tenemos a nuestro principal sospechoso.

7) What is the purpose of port scanning?

Bueno, la razón de realizar un escáner de puertos es bastante sencilla. Identificar todos los servicios y puertos abiertos que el host “víctima” está ofreciendo. O dicho de otro modo, identificar los posibles puntos de entrada a su sistema. Es una definición algo tosca pero nos vale :)

8) What ports are open on our honeypot?

Tal y como vimos en 5) los mecanismos para establecer una conexión TCP/IP incluyen el famoso saludo “a 3 bandas” o 3-way handshake, de tal forma que cuando hay un puerto abierto y dependiendo del ataque lo podemos identificar de varias formas. A grandes rasgos para no extender la entrada en demasiado he recolectado todos los paquetes emitidos por 192.168.0.99 con [SYN,ACK], es decir donde hay servicios, con ello he identificado los puertos:

- 22 / SSH

- 53 / DNS

- 80 / HTTP

- 443 /HTTPS

- 111 / SUNRPC

- 32768 / FILENET

9) Bonus Question: What operating system was the attacker using?

Esta cuestión puede parecer a priori la más difícil de responder, obtener el sistema operativo origen a partir de unas trazas TCP/IP podría ser un problema si no fuese por herramientas como p0f, Ettercap o Network Miner, las mismas utilizan técnicas de fingerprinting pasivo a raíz de los valores TTL, el tamaño de la ventana, type of service, (TOS) etc. Se puede profundizar en estas técnicas aquí. Yo he escogido Network Miner, la cual nos podría haber facilitado el trabajo desde el principio (pero entonces no habría sido tan divertido ;-) ) ya que es una herramienta de análisis forense en red. Ella nos muestra que tanto host atacante como host atacado eran Linux:

Y esto es todo por hoy, el análisis forense es magnífico para repasar y profundizar en los habituales conocimientos de redes, sistemas operativos, etc.

Buen fin de semana :)

NdA: Estoy teniendo bastantes problemas para escalar las imágenes sin perder detalle, así que se ven bastante pequeñas, siento el inconveniente.