SANS Forensic Contest #8 (Solución)

Me encantan los retos de seguridad de todo tipo, de Hacking, de Forensics, de lo que sea, y concretamente siempre me parecen muy "reales" e interesantes los retos que pone la gente del SANS en su web ForensicContest.Com.

Hace poco pusieron su Puzzle #8, en el que nos proporcionaban una captura de red de una Wifi sobre la que ha ocurrido cosas extrañas. Concretamente, el único usuario legítimo de la red, con MAC 00:11:22:33:44:55, notifica que de repente no puede entrar a su propia red.

En el reto, te piden que contestes una serie de preguntas, pero como no tengo demasiado interés en participar en el reto yo me quedo con las preguntas que me parecen más interesantes:

1. SSID y BSSID de la Wifi
2. Clave de Citrado de la Red Wifi
3. Clave de Gestión del Punto de Acceso
4. Nueva Clave del Punto de Acceso
5. Otras acciones

Bueno, pues como dijo Jack el Destripador, "vayamos por partes":

SSID Y BSSID DE LA WIFI

Podríamos irnos a fichero PCAP y extraer de ahí esta información, pero vamos ha hacerlo de una forma mucho más sencilla con Airodump, al que le podemos pasar como parámetro que lea de una captura de red en lugar de directamente de la red:

$ airodump-ng -r evidence08.pcap

Como podeis ver, de lanzar este comando ya podemos sacar gran parte de la información, entre ella que el SSID de la red es "Ment0rNet" y que el BSSID es "00:23:69:61:00:D0" (la MAC del punto de acceso).

Algo muy interesante que tiene esta manera de ver la captura de red es que vamos viendo "en tiempo real" como se van generando los paquetes y como fuere ocurriendo todo. Entre otras cosas podemos ver como los #Data crecen de forma rapidísima, lo cual, siendo un cifrado WEP nos hace ver que casi con toda seguridad se trataban de un ataque estadístico con inyección de paquetes ARP, pero eso lo vemos ahora enseguida.

ROTURA DEL CIFRADO

Como estábamos comentando, vemos que la cantidad de paquetes crecen de forma rapidísima. Esto es típico de los ataques que hacen replay de paquetes ARP para aumentar el tráfico de red y así obtener los IVs necesarios para romper la clave WEP de forma más rápida. Para comprobarlo vamos a ver como fueron los paquetes ARP de la captura de red que tenemos, a ver si se confirma nuestra teoría.

Abrimos el fichero de captura con Wireshark y nos vamos a la opción Statistics->Conversations->WLAN y ordenamos por la columna "packets" para que se nos quede la comunicación de más tráfico arriba. Filtramos por el tráfico intercambiado entre estas dos MACs y vemos muchísimos paquetes idénticos con destino a la dirección FF:FF:FF:FF:FF:FF que tienen toda la pinta de ser replays de paquetes ARP, porque además su contenido cifrado es idéntico en todos ellos:

Bueno, pues si este tío ha generado los suficientes IVs como para romper la clave WEP y acceder a la red... nosotros tenemos la captura con los mismos datos que él ha empleado para romper la clave, así que deberíamos ser capaces de romperla nosotros también, algo que va a ser necesario para poder ver lo que ha pasado una vez que el intruso ha entrado en la red.

En realidad, en una situación real, probablemente sería más correcto pedirle a nuestro cliente que nos proporcionara la clave, pero romperla siempre es más divertido :)

$ aircrack-ng evidence08.pcap

La clave WEP es "D0:E5:9E:B9:04", así que teniendo la clave de la Wifi ahora lo que tenemos que hace es descifrar todo el tráfico para poder analizar la captura de red.

Podríamos hacerlo con las opciones de Wireshark, pero casi que prefiero tener un PCAP descifrado como si fuera tráfico ethernet, para así poder analizarlo con el programa que quiera, así que mejor vamos a seguir utilizando herramientas de la suite Aircrack:

$ airdecap-ng -e Ment0rNet -w "D0:E5:9E:B9:04" evidence08.pcap

Total number of packets read 133068

Total number of WEP data packets 56692

Total number of WPA data packets 0

Number of plaintext data packets 0

Number of decrypted WEP packets 56692

Number of corrupted WEP packets 0

Number of decrypted WPA packets 0

Esto nos ha generado un fichero "evidence08-dec.pcap" que contiene el tráfico que estaba cifrado con esa clave WEP, pero descifrado, como si lo hubiéramos capturado desde una interface ethernet.

CLAVE DE GESTIÓN DEL AP

Ahora que ya tenemos el tráfico descifrado, vamos a abrirlo con Wireshark. Como sabemos que algo raro ha pasado con el AP, es bastante probable que el intruso haya accedido a él, así que filtramos por la IP del Gateway (192.168.1.1) y vemos tráfico HTTP entre este y una IP desconocida, con una MAC diferente a la del usuario legítimo.

Observando cualquiera de las peticiones que hace y haciendo un "Follow Stream" podemos ver la clave que se ha utilizado para acceder al punto de acceso:

Como se puede ver se trata de Autenticación Basic, que por definición simplemente se trata del usuario y la contraseña separados por dos puntos y codificado todo en Base64, así que solo tenemos que decodificar esa Base64 para saber que contraseña tenía el AP:

$ echo YWRtaW46YWRtaW4= | openssl base64 -d

admin:admin

Como no... parece que la contraseña de gestión del AP era la contraseña por defecto, o al menos tiene toda la pinta, así que el intruso lo ha tenido bastante más fácil para acceder. Veamos que hizo el intruso con el AP...

NUEVA CLAVE DEL AP

Para ver todas las peticiones HTTP podemos usar el filtro de Wireshark "http.request", y veremos a la derecha todas las peticiones. Pasamos de todo lo que sea gif y similar, y buscamos peticiones GET con parámetros o peticiones POST, y al final llegamos a una petición POST.

Parámetros POST:

SecurityMode=3&CipherType=1&PassPhrase=hahp0wnedJ00&GkuInterval=3600&layout=en

Bueno, parece que la clave la tenemos, pero además de la clave vemos que ha cambiado más opciones, como "SecurityMode" y "CipherType", que podemos sospechar que son pero que mejor si nos aseguramos, así que vamos a mirar el referer de esta petición a ver si vemos el formulario que ha estado tocando el atacante:

Vale, pues vamos a mirar la petición a WSecurity.htm y vamos a salvarla en un fichero, a ver que pinta tiene. Yo personalmente para estas cosas suelo utilizar Xplico, una herramienta que me gusta bastante para hacer análisis forense de red, pero en esta ocasión no me ha sacado las cosas como yo quería (reportaré el bug), así que vamos a sacarlo un poco a mano, así que vamos a buscar en el cuerpo del HTML como se llaman los campos del formulario que el intruso ha cambiado:

SecurityMode=3 -> WPA2 Personal

CipherType=1 -> AES

PassPhrase=hahp0wnedJ00 -> WPA SKey

Parece ser que lo que ha hecho nuestro intruso es cambiar el cifrado del punto de acceso a un cifrado WPA2, y por supuesto a partir del momento del cambio de clave no vamos a ver nada en el fichero de captura que hemos sacado descifrando el cifrado WEP.

OTRAS ACCIONES

Sin embargo... tenemos la clave WPA, así que podemos descifrar el tráfico igual que hemos hecho antes. Vamos a ello!

$ airdecap-ng -e Ment0rNet -p "hahp0wnedJ00" evidence08.pcap

Total number of packets read 133068

Total number of WEP data packets 56692

Total number of WPA data packets 0

Number of plaintext data packets 0

Number of decrypted WEP packets 0

Number of corrupted WEP packets 0

Number of decrypted WPA packets 0

Joder... que aguafiestas estos del SANS... no nos han metido el tráfico WPA en la captura, con la curiosidad que tenía en saber que más había hecho el intruso... en fin...

Como digo siempre, si tenéis comentarios que hacer o formas en la que lo hubierais hecho de forma más sencilla... decídmelo!

Solución Reto Forensics: Ann Skips Bail

Como comentábamos en el anterior post, tenemos un fichero PCAP del que tenemos que extraer la máxima información posible para intentar averiguar donde se ha fugado Ann tras salir bajo fianza.

Evidentemente, la cantidad de posibilidades para resolver este reto son cuasi-infinitas, algunas más manuales, otras menos manuales, quizá algunas más eficientes que otras, pero el objetivo es conseguir el máximo de información en el mínimo tiempo posible.

Siendo un fichero PCAP pequeño, es muy factible abrirlo "a saco" con Wireshark y ver que es lo que hay, además el reto ya nos dice que lo que buscamos es un correo electrónico, por lo que nos está acotando mucho. Sin embargo, al realizar un análisis real no dispondríamos de toda esta información, así que tendríamos una captura de red mucho más grande y no sabríamos demasiado bien que tendríamos que buscar. Sería como buscar "una aguja en un pajar" pero peor aún, porque ni siquiera sabemos si lo que tenemos que encontrar es una aguja, o palillo, o cualquier otra cosa.

Para ayudarnos en este, existen programas que nos pueden sacar el tipo de tráfico que hay en el PCAP y mostrarlo clasificado. Yo concretamente, he aprovechado este reto para probar una herramienta llamada XPlico, utilizada como parte del Framework de análisis forense DEFT. Es posible que utilizar XPlico no sea la opción más elegante ni la mejor, pero desde mi punto de vista es bastante aceptable, y así aprovecho para presentar esta herramienta.

Una vez instalado Xplico, accederemos a la web de gestión a través del puerto 9876, utilizando el nombre de usuario "deft" y contraseña "xplico", como dice en la propia web de login. Una vez hecho login crearemos un "New Case" (nuevo caso) que sería nuestra investigación actual y a partir de ahí una "New Session" (nueva sesión), que sería ya la captura concreta que hemos realizado. Una vez creada la sesión tendremos que subir el fichero PCAP, para ello iremos a la zona de la derecha donde pone "pcap set" y examinaremos para buscar nuestro fichero, pulsando "Upload" para finalizar. Una vez subido el fichero nos aparecerá un mensaje "File uploaded, wait start decoding...". Es probable que tengamos que refrescar la web para ver el contenido real. Veremos algo así:

Como podemos ver, Xplico detecta 2 correos electrónicos y 1 resolución de nombres. Además de eso, debería poder detectar todas las webs visitadas, FTPs accedidos y un largo etcétera. Sin embargo, es cierto que Xplico no detecta todos los tipos de tráfico del mundo, por eso no está de más que realicemos una pequeña comprobación. Para ello, podriamos utilizar Wireshark para ver las llamadas "conversaciones" presentes en la captura, pero partiendo de la base de que podría tratarse de un fichero razonablemente grande y para evitarnos el desespero de manejarlo con una herramienta gráfica como Wireshark, vamos a utilizar a su hermano de la linea de comandos, el TShark. Veamos entonces las conversaciones ip, tcp y udp:

# tshark -r evidence02.pcap -n -z conv,ip
[...]
| <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.1.159 <-> 64.12.102.142 255 14792 235 299979 490 314771
192.168.1.30 <-> 192.168.1.10 26 6500 2 180 28 6680
192.168.1.255 <-> 192.168.1.159 16 2007 0 0 16 2007
192.168.1.255 <-> 192.168.1.10 4 360 0 0 4 360
192.168.1.159 <-> 192.168.1.30 0 0 2 519 2 519
192.168.1.159 <-> 10.1.1.20 1 299 1 72 2 371

# tshark -r evidence02.pcap -n -z conv,tcp
[...]
| <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.1.159:1038 <-> 64.12.102.142:587 233 13093 221 297720 454 310813
192.168.1.159:1036 <-> 64.12.102.142:587 22 1699 14 2259 36 3958

# tshark -r evidence02.pcap -n -z conv,udp
[...]
| <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.1.10:52111 <-> 192.168.1.30:514 0 0 24 6320 24 6320
192.168.1.255:137 <-> 192.168.1.159:137 12 1104 0 0 12 1104
192.168.1.30:123 <-> 192.168.1.10:123 2 180 2 180 4 360
192.168.1.255:138 <-> 192.168.1.159:138 4 903 0 0 4 903
192.168.1.255:123 <-> 192.168.1.10:123 4 360 0 0 4 360
192.168.1.159:1025 <-> 192.168.1.30:514 0 0 2 519 2 519
192.168.1.159:1026 <-> 10.1.1.20:53 1 299 1 72 2 371

Como podemos observar, además de los dos correos enviados y de la resolución de nombres encontrada por Xplico, tenemos algunas otras conexiones UDP que no han aparecido en el análisis de esta herramienta, y que podriamos estraer de la captura para un análisis más manual.

De momento, puesto que lo más sencillo es mirar lo que sí ha detectado Xplico, vamos a pegarle un vistazo a esos dos correos, así que vamos a volver al interface gráfico de Xplico a ver que información nos ofrece:

Como se puede ver en las capturas, Xplico nos muestra el origen, destinatario, mensaje y archivos adjuntos, lo cual nos proporciona una manera cómoda de obtener dicha información sin tener que deshacer la codificación base64 del adjunto ni nada similar.

En este caso, vemos como Ann escribe a su amante, con correo mistersecretx@aol.com diciendole que quedan en el lugar indicado en el adjunto, y que lleve su pasaporte y su bolsa de aseo. Si descargamos el adjunto y lo abrimos veremos que tiene la siguiente imagen:

Como se puede observar, la ciudad de Playa del Carmen en México ha sido el lugar elegido por Ann para encontrarse con su amante. Además, en el mismo cuerpo del documento podemos leer "Meet me at the fountain near the rendezvous point. Address bellow. I'm bringing all the cash", que traducido al español quiere decir: "Nos encontraremos en la fuente junto al punto de encuentro. La dirección está debajo (la de la imagen). Llevo todo el dinero".

De momento la cosa va bien, así sin complicarnos mucho la vida sabemos donde se van a encontrar Ann y su amante y sabemos que ella va a llevar todo el dinero, así que si les pillamos lo haremos con las manos en la masa.

Sin embargo, hay cosas que aún no sabemos, y es por ejemplo CUÁNDO van a verse, ya que en la información no se puede ver una fecha para quedar en ningún momento, y aunque se sale de las preguntas que hace el reto de SANS, es algo que si se tratase de un reto real yo sí me preguntaría. Para ello, vamos a intentar obtener algo más de información de la que nos proporciona Xplico, empezando por los correos electrónicos.

El envío de correo electrónico por SMTP es posible hacerlo con autenticación o sin autenticación, y dado que el correo que hemos analizado ha sido enviado sin cifrar, en el caso de que haya utilizado autenticación, podremos ver la contraseña utilizada en claro, pudiendo de esta manera acceder a la cuenta de correo de Ann, donde es posible que podamos obtener mucha más información anterior a la monitorización de su linea. Para ello vamos a quedarnos solo con la comunicación de alguno de los correos y vamos a observar las primeras lineas, con el fin de extraer el proceso de autenticación:

# tcpdump -r evidence02.pcap -s 0 -w correo.pcap port 1038 and port 587
# tshark -r correo.pcap -n | head -20
1 0.000000 192.168.1.159 -> 64.12.102.142 TCP 1038 > 587 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2 0.111116 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
3 0.111462 192.168.1.159 -> 64.12.102.142 TCP 1038 > 587 [ACK] Seq=1 Ack=1 Win=64240 Len=0
4 0.282720 64.12.102.142 -> 192.168.1.159 SMTP Response: 220 cia-mc07.mx.aol.com ESMTP mail_cia-mc07.1; Sat, 10 Oct 2009 15:37:56 -0400
5 0.283746 192.168.1.159 -> 64.12.102.142 SMTP Command: EHLO annlaptop
6 0.284189 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=81 Ack=17 Win=64240 Len=0
7 0.396057 64.12.102.142 -> 192.168.1.159 SMTP Response: 250-cia-mc07.mx.aol.com host-69-140-19-190.static.comcast.net
8 0.397784 192.168.1.159 -> 64.12.102.142 SMTP Command: AUTH LOGIN
9 0.398285 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=332 Ack=29 Win=64240 Len=0
10 0.506142 64.12.102.142 -> 192.168.1.159 SMTP Response: 334 VXNlcm5hbWU6
11 0.507100 192.168.1.159 -> 64.12.102.142 SMTP Command: c25lYWt5ZzMza0Bhb2wuY29t
12 0.507551 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=350 Ack=55 Win=64240 Len=0
13 0.618061 64.12.102.142 -> 192.168.1.159 SMTP Response: 334 UGFzc3dvcmQ6
14 0.618922 192.168.1.159 -> 64.12.102.142 SMTP Command: NTU4cjAwbHo=
15 0.619472 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=368 Ack=69 Win=64240 Len=0
16 0.741622 64.12.102.142 -> 192.168.1.159 SMTP Response: 235 AUTHENTICATION SUCCESSFUL
17 0.745296 192.168.1.159 -> 64.12.102.142 SMTP Command: MAIL FROM:
18 0.745789 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=399 Ack=102 Win=64240 Len=0
19 0.862648 64.12.102.142 -> 192.168.1.159 SMTP Response: 250 OK
20 0.863473 192.168.1.159 -> 64.12.102.142 SMTP Command: RCPT TO:

Hemos tenido suerte, el correo ha sido mandado utilizando autenticación, por lo que ahora mismo tenemos el siguiente tráfico "petición -> respuesta":

VXNlcm5hbWU6 -> c25lYWt5ZzMza0Bhb2wuY29t
UGFzc3dvcmQ6 -> NTU4cjAwbHo=

Como podemos observar, las cadenas se encuentran codificadas en Base64. Decodificándolas mediante cualquier web, Burp o comando "base64" de unix, obtenemos lo siguiente:

Username: -> sneakyg33k@aol.com
Password: -> 558r00lz

Un ejemplo de las maneras de obtenerlo por linea de comandos en un linux:

# echo "c25lYWt5ZzMza0Bhb2wuY29t" | base64 -d
sneakyg33k@aol.com

Bueno, pues ya tenemos algo más, ahora además sabemos que usa una cuenta de AOL con usuario sneakyg33k@aol.com y con contraseña 558roolz (menuda auto-propaganda que se hacen los de SANS :P) donde podriamos entrar a buscar más información.

Por último, nos quedaría algo más de información que, sin ser tan relevante como esta, nunca se sabe si podría resultar útil, como por ejemplo la que podemos extraer del tráfico UDP que mencionamos antes, como versión del Windows utilizado, por ejemplo.

Para acabar, me gustaría referenciar a uno de los dos ganadores del reto de SANS, que tras leer su solución es la que más me ha gustado, ya que ha creado un par de herramientas muy muy completas para ayudarle a resolver el reto que nos pueden resultar muy útiles a todos nosotros en el futuro.

Reto Forensics: Ann Skips Bail

De entre la cantidad de cursos que tiene el SANS Institute, uno de ellos, el SEC558 Network Forensics, es el destinado a la realización de Análisis Forense de Red. Además del curso, SANS tiene una web llamada Network Forensics Puzzle Contest en la que de vez en cuando plantea retos forenses.

Por el momento los retos son sencillos de sacar, pero la dificultad radica en que el ganador es aquel que plantea la solución más elegante, generalmente desarrollando alguna pequeña herramienta que le ayude a resolver el reto. Sin embargo, aunque no aspiremos a ganar el reto, es muy útil probar con estos retos sencillos.

Hace unas semanas se publicó en esa misma web el segundo reto, y aquí es donde entramos al trapo... Dice tal que así:

Después de haber sido soltada bajo fianza, Ann Dercover desaparece! Afortunadamente su conexión de red estaba siendo monitorizada antes de que saliera de la ciudad.

"Creemos que Ann se podría haber comunicado con su amante secreto, Mr. X, antes de irse", dijo el jefe de policía. La captura de red puede contener pistas sobre su paradero.

Tú eres el investigador forense. Tu misión es averiguar donde se ha ido Ann y la máxima información posible contenida en la captura de red que pueda ayudar a la investigación.

En el reto original hay una serie de preguntas que hay que contestar, pero no las he puesto porque me parece que dan muchas pistas y lo ponen muy fácil, así que el que quiera puede hacer trampas y mirar la versión original del reto o incluso la solución, pero lo interesante es aprender a hacer el camino necesario para obtener esa información :)

En un par de días pondré mi solución al reto, explicando las herramientas que utilicé y todo el proceso.

Recursos: LiveCDs y Máquinas Virtuales

En el trabajo tanto de un pentester como de un incident handler es habitual que tengamos que tirar mano de LiveCDs y Máquinas Virtuales, tanto para utilizarlas como herramientas como para utilizarlas como sistemas sobre los que realizar pruebas.

Hay montones y montones de webs que albergan su livecd propia o su máquina virtual, pero también existen otras webs que lo que hacen es recopilar toda esta información, lo cual nos va a ahorrar mucho tiempo. Algunas de las que más me gustan a mi son las siguientes:

• SecurityDistro: Es una web que contiene referencias a las LiveCD de seguridad más conocidas, aunque hecho a faltar alguna, pero también he descubierto alguna otra muy interesante.
  

• BagVapp: Web que recopila un montón de máquinas virtuales preinstaladas de un montón de sistemas operativos diferentes, incluso Windows 7 (por estar en estado beta, supongo, luego con las licencias...). Algunas de ellas de seguridad que incluso no están en el enlace anterior, como Caine, y otras que sí que están pero que resulta más cómodo tenerlas en una máquina virtual, como Samurai (aunque ahora mismo no están actualizados a la última versión).
  

• VMWare Appliances: Muchos fabricantes de productos, incluso de pago, dejan preparadas máquinas virtuales con el producto preinstalado para que lo pruebes a modo de demostración. Puede ser muy interesante para probar este tipo de software antes de decidirnos a comprarlo.

De entre todas ellas, las que yo he probado o las que me parece que tienen buena pinta y que tengo pensado probar, son las siguientes:

• BackTrack: Por supuesto, la distro de seguridad por excelencia, yo uso la versión en máquina virtual porque me resulta más cómoda cuando trabajo desde mi equipo, pero tengo también una distribución en el USB que utilizo de llavero (aún pendiente de actualizar de la versión 3 a la 4), para que no me encuentre en algún sitio sin el portátil y se requieran mis habilidades y tenga que decir aquello de "es que me pillas sin herramientas" ;)

• Helix: Distribución para realizar respuesta ante incidentes y análisis forense. Extremadamente conocida y utilizada, de hecho como en su propia web indican, es utilizada por entidades de mucho prestigio como herramienta para sus cursos de formación sobre Forensics.

• Samurai: Esta no la he probado todavía pero la tengo apuntada en la agenda. El ser un producto de la empresa InGuardians, fundada por los gurús de SANS Ed Skoudis y Mike Poor, es una garantía de su calidad.

• Sumo: Esta es una de las distros que hecho en falta en los enlaces anteriores. Se trata de una distro en DVD que contiene varias LiveCD, y que te muestra un menú en el arranque para que elijas con cual la quieres arrancar. Ahora mismo las versiones no están excesivamente actualizadas, e incluso yo cambiaría las que vienen, pero lo bueno de las distros Linux es que te las puedes tunear a tu gusto :)

• Caine: Otra de las que hecho en falta en la web de SecurityDistro pero que también es de las que tengo pendientes por probar y que le voy a hacer un seguimiento muy de cerca. Este proyecto se inición como Tesis de un estudiante Italiano que tenía como objetivo desarrollar una herramienta para análisis forense que no fuera únicamente un compendio de herramientas, sino que fuera una integración total de dichas herramientas.

• SANS SIFT: Ahora mismo estoy ojeando esta, es una máquina virtual creada por SANS para Forensics, lo cual ya es toda una garantía. Está muy bien, contiene un montón de herramientas de las que se suelen utilizar y es muy completa.

• Otras de las que tengo pendientes por probar a ver que tal son porque me parece que pueden tener buena pinta son DEFT y FCCU para Forensics, que son muy nombrados en los foros y listas que frecuento. En cuanto a Pentesting, OWASP Labrat es otra de las que tengo ganas de probar, sobretodo por lo excepcional que son las guias de OWASP, aunque dudo que aporte más que distribuciones como BackTrack o Samurai.

Por supuesto, hay muchas más distros y cada uno tendrá sus favoritas, así que estais invitados a sugerirnos vuestras distros favoritas y hacer una buena recolección entre todos.

Busca, Busca... Busca Malware bonito...

Hace unos pocos días una muy buena amiga me hizo la pregunta que se nos hace muchas veces a los que nos dedicamos a esto de la seguridad: Mi ordenador/servidor hace cosas raras, ¿Estaré infectado por algún virus o habré sufrido alguna intrusión?

Sin duda es la pregunta del millón, pues aunque tengas un anvirus actualizado, todas las medidas de seguridad y todos los parches aplicados al siguiente instante de ser publicados, nadie puede garantizarte que un error humano al aplicarlos, o en la administración del sistema, o un exploit zero-day no haya tirado por tierra todos tus esfuerzos.

Una de las cosas que me gusta hacer a mi para contestar a esta pregunta es buscar herramientas, puesto que los intrusos generalmente no buscan "entrar y salir" (y si lo hubieran hecho probablemente no se estarían notando ya esas "cosas raras"), sino que buscan mantener el control de la máquina. Por ello, suelen dejar algún tipo de software que realice las acciones que deseen, puertas traseras o algún otro tipo de Malware. También podrían crearse cuentas de usuario, pero eso suele cantar mucho, vamos a centrarnos en el caso en que hemos revisado ya el sistema (apagado, para evitar que un rootkit nos de gato por liebre) y no vemos nada raro en cuanto a la configuración de usuarios, y temas similares.

Vamos al lio, esto es lo que haría yo en un caso como este, para un sistema Windows, después de haber observado la máquina y no ver cuentas raras ni ningún tipo de punto de entrada que pueda no implicar el uso de malware:

1. Apagado de la máquina: Con la máquina encendida corremos el riesgo de que la información que nos devuelva la máquina esté siendo alterada por algún tipo de rootkit. Existen varias vertientes de como hacer el apagado de la máquina, yo suelo optar por tirón del cable, no sin antes tener backup de todo, especialmente si tenemos servicios que manejan una gran cantidad de datos en memoria, como las bases de datos.
2. Escaneo antivirus: Lo primero de nada es ver si existen virus conocidos, igual la cosa es tan fácil como que un virus ha inutilizado el antivirus local, y simplemente con arrancar desde CD y pasar un antivirus es suficiente.
   
3. Busqueda de ejecutables: Al final, no importa si el código del virus está realmente cifrado, o si se lo baja de Internet, o lo que sea, pero lo que es seguro es que tiene que haber algo en la máquina que lo llame y que no sea original de un fabricante de software, esto nos dará algunos candidatos. Para ello, vamos a partir de la suposición que la mayoría de ejecutables de un sistema Microsoft son de Microsoft (o al menos si conseguimos descartar todos los originales de Microsoft esto nos va a quitar un montón de trabajo). ¿Como sabemos que binarios del sistema son realmente de Microsoft? Pues por ejemplo con una herramienta de Mark Russinovich Sigcheck, que nos permite detectar ficheros ejecutables (independientemente de su extensión) y comprobar si están firmados por Microsoft o no, esto nos dará una buena lista de candidatos con tan solo lanzar el siguiente comando: sigcheck -e -s "c:\\"
4. Criba de candidatos: De esta lista, donde más es posible que haya ejecutables legítimos no firmados es en Archivos de programa, así que en una primera aproximación podriamos obviar ese directorio por el momento y quedarnos con el resto, que deberían ser ya pocos.
5. Análisis de Malware: A partir de ahí, realizariamos un pequeño análisis de malware sobre los ficheros encontrados, en los que iremos cribando sucesivamente hasta encontrar el bichito en cuestión o hasta determinar que no ha existido infección.

A partir de ahí... se pueden hacer muchas más cosas, tanto si hemos encontrado el malware como sino, quizá se encuentre en algún datastream... una cosa que no he probado todavía es si sigcheck detectaría un ejecutable en un stream alternativo, quizá un intruso podría ocultar un ejecutable en uno de estos streams alternativos de un binario legítimo del sistema.

Si alguien lo prueba que lo diga :)