Resultados del primer desafío forense 2010 de honeynet

Participé en el desafío forense con la intención de aprender de las soluciones ganadoras, así como de técnicas, herramientas y recursos utilizados. Los ganadores fueron; Ivan Rodriguez Almuina, Franck Guenichot y Tareq Saade sus soluciones se pueden conseguir desde el sitio del desafío forense. Mi enhorabuena por su trabajo, muy buen material para quien le guste ese campo.

Hubo 91 participantes, conseguí 18 de un total de 40 puntos lo que me dejó en el puesto 66.

Pongo a continuación las preguntas del desafío forense y hago una pequeña comparación de mis respuestas con las soluciones (a modo de auto-apunte de referencia)

1er desafío forense 2010 

1. ¿Qué sistemas estuvieron envueltos en el incidente?

Herramienta usada: Wireshark

El atacante: 98.114.205.102

El honeypot: 192.150.11.111

Conseguí 2 puntos de 2.

2. Qué puedes saber sobre el equipo atacante (¿dónde está ubicado?)

Herramienta usada: http://www.maxmind.es

Conseguí 2 puntos de 2.

3. ¿Cuantas sesiones TCP tiene el archivo de red?

Herramientas usadas: tshark y wireshark

Aquí me complique un poco, ya que inicialmente pensé en paquetes y con

#tshark -z io,phs -r attack-trace.pcap_ 

saque estadísticas de protocolo y había 348 paquetes. Luego pense en una sesión como una sesión completa del 3-way-handshake y use un filtro en wireshark para mostrarlas: (tcp.flags.syn==1) and not (tcp.ack) = 5 sesiones

Conseguí 2 puntos de 2.

4. ¿Cuánto duro el ataque?

Herramientas usadas: wireshark

De nuevo use wireshark, a través del menú:

View -> Time display format -> date and time of day to show in human time

Viendo la hora de inicio del primer paquete y la hora final del último nos daba  16 segundos.

Conseguí 2 puntos de 2.

5. ¿Qué Sistema Operativo fue atacado?, ¿qué servicio?, ¿qué vulnerabilidad?

Herramientas usadas: tshark

Con tshark -r attack-trace.pcap_ frame.number == 14 -x

mostraba ese paquete en hexadecimal revelando un Windows 2000

El servicio vulnerable escuchaba en el puerto 445 el servicio de CIFS de Microsoft. Pero la respuesta correcta era: Servicio de Windows Local Security Authority (LSA) Remote procedure Call (RPC).

La vulnerabilidad únicamente dije que era de LSASS (Local Security Authority Subsystem Service). La solución en más detalle muestra que se trata de NETBIOS SMB-DS DCERPC LSASS.

Las herramientas que usaron en la solución fueron snort, y p0f. El uso de estas herramientas para extraer esos datos ya no se me olvida. :-)

Conseguí 3 puntos de 6.

6. ¿Puedes realizar un pequeño resumen general de las acciones realizadas por el atacante?

Herramientas usadas: Wireshark + ngrep + thsark

Aquí lo que hice fue ir cogiendo paquetes y describir lo que ocurría. Por lo que ví en las soluciones con algo más general, sin entrar al detalle valía. Y por supuesto realizando una correcta descripción de los hechos. Herramientas descubiertas: scapy, dionaea.

3 de 6 puntos

7. ¿Qué vulnerabilidad específica fue atacada?

Aquí, lo que hice únicamente fue especificar la vulnerabilidad lsass. Concretamente en la dll LSARSV.DLL. En la solución usaron scapy para hacer un replay del ataque a dionaea. Mejor ver la solución.

Conseguí 1 de 2 puntos

 

8. ¿Qué acciones realizaba el shellcode?

Herramientas usadas: tshark + ghex2

En este punto, lo más que me acerque fue al comentar la función vulnerable DsRolerUpgradeDownlevelServer y donde tenía el fallo. En la solución usaron el payload detectado en el punto anterior para volcarlo a un fichero y libemu proporcionó la información.

Conseguí 1 de 8 puntos

9. ¿Crees que se uso un HoneyPot como víctima vulnerable?

Muy, pero que muy interesantes las respuestas de la solución. Algunas como; el software atacado parece un honeypot dada la elocuencia de NTLMSSPP ( a través de un volcado de thsark ), tiene la pinta de ser un honeytrap ejecutándose en linux en modo mirror en el puerto 445.

Conseguí 0 de 6 puntos.

10. ¿Hubo algún malware involucrado?, sí es así ¿cuál es su nombre?

Herramientas usadas: foremost

Extraje el binario y use servicios de terceros para ver de que se trataba. La solución era más sencilla, únicamente comentando el archivo conseguido a través del FTP (ssms.exe)

Conseguí 0 de 2 puntos

11. ¿Crees que se trató de un ataque manual o automático?

Mi principal argumento para pensar que se trataba de algo automático es que el ataque fue muy rápido, y algunos patrones ( sin detallar ) así lo demostraban.

2 de 2 puntos

Cosas aprendidas: La parte más floja la relacionada con el shellcode y su análisis así como argumentar porque se trataba de un honeypot. Las pistas de cómo se comporta un honeypot ya las se para otra vez, ahora queda trastear con scapy y dionaea. Además descubrí unas cuantas herramientas que no conocía: rumint, PEiD, TrID.

A ver si me da tiempo a participar en el segundo desafío forense. Lo dicho, una muy buena oportunidad para aprender y descubrir herramientas.

Lo siguiente; la búsqueda social

Hace 12 años, en la conferencia WWW se presentó el paper "Anatomy of a largue-scale hypertextual web search engine"  en el cual Sergey Brin y Larry Page presentaron los algoritmos y arquitectura de Google. En abril de este año, Aardvark va a presentar en la misma conferencia el paper "Anatomy of a Largue-Scale Social Search Engine."  

El paper bien merece una lectura detenida para comprender el contexto actual de las redes sociales y el potencial de información qué hay en ellas y no en modo texto cómo hasta ahora, sino en la capacidad de extraer e interpretar información de cada post de un blog, tweet, facebook, IM, pérfiles, etc. Todo ese contenido Aardvark no lo usa cómo fuente de respuestas que ya existen sobre algún tema, sino como indicador de los temas y expertise que un sujeto sea capaz de dar a preguntas bajo demanda.

El desafío en el motor de búsqueda social de Aardvark es encontrar a la persona adecuada que pueda conocer las respuestas que necesitamos, hasta ahora el desafío era encontrar la página o documento que satisfacía nuestras preguntas. Aardvark se basa en el modelo de conocimiento de pueblo, o algo así, donde la información pasa de persona en persona hasta encontrar a la persona adecuada que pueda responderte. Además, como en los pueblos, se usa un lenguaje natural para realizar las preguntas.

No se trata de algo que pueda desplazar a Google, -de hecho, mientras escribía esto me enteré que Google lo había comprado- ambos sistemas de búsqueda son muy complementarios. Lo interesante en mi opinión es la utilidad que se puede sacar a todo el contenido que se está generando actualmente en las redes sociales y la capacidad de extraer respuestas y conocimiento de él. 

 

Lo llevo probando unos días. Por ahora sólo está en inglés y las preguntas tienes que formularlas, no basta con introducir algunos términos aleatorios. Hay que preguntar de manera natural. Sí, cómo algunos hacen en Google. :-)

Desafío forense: analizando una traza de red

El proyecto "The honeynet project" tiene como finalidad estudiar las herramientas, tácticas, y motivos de los ataques de red y ordenadores, y compartir las lecciones aprendidas. Para ello, suelen fomentar concursos de análisis de ataques para descubrir técnicas usadas por los diferentes participantes y así enriquecernos todos. Hacía años que no organizaban concursos de este tipo, pero a raíz de un twiter de @lostinsecurity, me entero de que este mes empieza uno de ellos.

First Challenge of the forensic challenge 2010.

Se trata de analizar una traza de red que proporcionan, y responder a una serie de preguntas. Hay tiempo hasta el 1 de febrero. Se trata de una gran oportunidad de aprender, ya que después de invertir tiempo intentando descubrir que ocurrió y teorizando, tienes acceso a las soluciones ganadoras para comprobar cuan equivocado estabas en tus especulaciones.

Empezando

Lo primero que hago es descargarme la traza de red y comprobar el checksum.

ecasbas@laptop:~/proyectos/honey-forensics$ sha1sum attack-trace.pcap_.gz
0f5ddab19034b2656ec316875b527d9bff1f035f  attack-trace.pcap_.gz

OK, es correcta. La descomprimo y la abro con wireshark para echar un vistazo general.

Algunos detalles llaman inmediatamente mi atención.

1. Sólo hay dos ips involucradas.

2. Observo algunas cadenas con intercambios de paquetes NTLMSPP. NTLMSPP es un protocolo de autenticación de Microsoft por lo que ya podemos intuir que el servidor objetivo es un Windows.

3. Hay algún paquete duplicado y otros con RST. Esto es extraño en TCP porque si falla, intentará retransmitir de nuevo. Algo no le ha gustado al servidor y ha finalizado la conexión, ¿o se trata de algún tipo de fingerprinting?

4. Lo siguiente que veo son múltiples conexiones con destino y origen protocolo SOCKS en el servidor.

5. En las últimas líneas, algo ocurre porque también vemos paquetes RST y un simpático mensaje de despedida.

Estos datos simplemente con un primer vistazo, en próximas entradas los veremos en detalle.

Cualquier otra interpretación de los paquetes es más que bienvenida.