banner

[Solved] Christmas Hacking Challenge - Part III

| INDICE: 

En los capítulos anteriores el Sr. Anderson, nuestro experto en Seguridad, conseguía averiguar al Plan Secreto que la Abuela del Pequeño Timmy tenía preparado para la mañana del 25 de Diciembre (Navidad), proporcionando así la respuesta a la primera de las cuestiones que planteaba el inspector Martinez.

En el ultimo capitulo el Sr. Anderson, una vez más, deberá poner en practica todos sus conocimiento para conseguir averiguar toda la verdad que rodea al extraño caso, y proporcionar las pruebas (evidencias) suficientes ante el jurado en caso de que sea necesario.

Capitulo IV: El desenlace final

Los resultados de los que dispone hasta el momento el inspector Martinez y que puede presentar ante el Jurado en día de la celebración del Juicio, son inconclusas y/o bien, conducen hacia la "duda razonable". Debido a, si recordáis, que el móvil de Rudolph (el reno), lo sitúa en la escena del crimen en la misma fecha y hora.

Recapitulando, los resultados, pruebas y evidencias obtenidas hasta el momento son:

1. Fichero PCAP de la Captura de datos del tráfico de Red del ordenador personal de la Abuela, alias Grandma.
El experto en Seguridad, tras analizar el fichero, averigua la existencia de un correo electrónico que envía la Abuela a Mel, contando los detalles del Plan Secreto (Part II). El plan se encontraba como un documento MSWord adjunto codificado en BASE64.
2. El Plan secreto de Abuela que consiste en:
Simular su muerte a manos del Rudolph el Reno de Santa Claus, mientras tanto Mel (su cómplice) proporcionará a la acusación un testigo ocular de la escena del crimen. Además, la abuela habría hecho heredero de la póliza del seguro de vida a Mel, para que una vez, que Mel hubiera recibido la indemnización del seguro se reunirá con ella, y escapar juntos al Caribe.

En el capitulo anterior el Sr. Anderon había averiguado el Plan Secreto de la Abuela, pero todavía no ha demostrado cómo la Abuela había ejecutado dicho plan y conseguido incriminar a Rudolph. ¿Será capaz el Sr. Anderson de conseguir demostrar con evidencias la ejecución del Plan Secreto y responder así a las cuestiones pendientes?

  1. Why did the geo-location information on Rudolph's computer, synced from his cell phone, show that Rudolph was in Central Park during the attack? Please describe each technical step that lead to this "evidence" presented in court.
  2. Where should the authorities look for Grandma?
  3. Based on the evidence in the packet capture file, who is guilty in this story?
----
Eran las 6:15 de la madrugada cuando el Sr. Anderson consiguió por fin echarse en el sofá de casa, había acabado su colaboración en el caso del "Reno Killer", pero de repente, un sobresalto lo levanto del sofá como si de un resorte se tratase.
/(RING .. RING ..)/ 8:15 ...
- Si, diga.- Sr. Anderson, al habla el inspector Martinez, espero que haya dormido bien y repuesto lo suficiente, en 10 mintuos un coche patrulla lo recogerá en su domicilio, este preparado.
La investigación continua en los laboratorios de la BIT, en calle esperanza, ...
- Buenos, días Sr. Anderson. Necesitamos averiguar qué hay de cierto en el Plan de la Abuela, y si realmente Rudolph ha sido victima de un malvado plan.- ¿Estas preparado?- Si, si, tan solo necesito un café doble y ...
Detalles técnicos:

- [Steps 1] - Networkminer, analizando el flujo de información, así como el intercambio de parámetros entre  las conexiones establecidas, y registradas en el ordenador de la Abuela (Grandma).

Se realiza la carga en la herramienta del "caso 0092918772663563", dependerá del nombre que se le asigne en el momento de guardar el "caso" del análisis. 
Prueba_01: Identificación del PC-Grandma
IP: 192.168.1.10
Hecho_01: Intercambios de Email From 192.168.1.10 to 192.168.1.3 (Servidor Correo).
Hecho_02: Puerto 25 SMTP abierto en el equipo 192.168.1.3, recepción de conexión de email.
Analizando, el flujo de conexión que se ha producido con origen IP:192.168.1.10, el Sr. Anderson, sospecha sobre un parámetro que ha sido detectado por la herramienta, en concreto se trata del campo "NAME" perteneciente al dominio www.santaslist.northpole. La experiencia del analista le hace sospechar que ese parámetro suele ser habitual en los formulario de registro en las páginas web, hecho, confirmado por la herramienta, que asocia el parámetro NAME a una petición HTTP Post (envió de información desde una página web al servidor).

Step 1 - HTTP Post Field NAME

Esta pista, conduce a nuestro analista hasta la empresa dueña del dominio www.santaslist.northpole, que se corresponde con Santa Polo Norte S.A. Esta empresa dispone de un servicio Web público accesible desde Internet para consultar si tu nombre se encuentra en la lista de los "niños" que ha sido traviesos durante el año. Precisamente el parámetro "NAME" se corresponde con el nombre que tiene la variable del  formulario de la página WEB, que guarda el "nombre" introducido para su consulta en la lista de SantaClaus.

Step1 - Santa List Form chek.

- [Step 2] - Uniendo los hilos.

Si nos fijamos en el número de trama (FRAME Number) correspondiente a la primera vez que aparece el parámetro NAME, se observa que se trata del numero 108 (ver la imagen de abajo). Para confirma la suposición que asocia el parámetro NAME con el formulario de SANTA, se accederá a la pestaña de  "ficheros (FILES)" para buscar una coincidencia con el número de trama (108). 

En la imagen siguiente se observa que se corresponde con una pagina WEB resultado de una consulta con el valor del parámetro NAME=Grandma.

Step 2 - Parameter NAME value and Frame number.
Step 2 - Confirm  Web form HTTP Post in Santa website.

Si nos damos cuenta, en la pestaña de FILES, la trama numero 74, se corresponde con la consulta a la página principal (raíz) del servidor de SantaClaus (index.html), que confirma y demuestra la existencia de campo NAME en el formulario de consulta.

Step 2 - Confirm HTTP Post form in web (index.html) source code.

- [Step 3] - Vector de ataque SQL Inyection

Una vez que se ha confirmado la utilización y el acceso de Grandma al servidor Web de SantaClaus. La sospecha, la abuela (alias Grandma), maestra en el arte de la "ciberseguridad", detecta una vulnerabilidad en la página WEB [OWASP -# SQL Inyection] al introducir la comilla (') simple como valor en el formulario:

Step 3 - SQL Inyection vulnerability.

Descubierta la vulnerabilidad, la Abuela comenzó con el asalto del sistema (pentesting)  utilizando como vector de ataque la vulnerabilidad en el formulario Web. El objetivo era introducirse en el equipo de Rudolph e incriminarlo en el falso homicidio

Para  llevar a cabo su elaborado Plan necesita conocer en detalle la estructura, tipo y numero de columnas que tiene la BD a la que tiene acceso a través de la vulnerabilidad en el formulario web. Datos requeridos para poder manipular la información correctamente. 

Step 3 - SQL Inyection Attack step by step.

Como se observa en la imagen superior, el analista demuestra los pasos seguidos por la Abuela para averiguar la estructura de la BD. En el transcurso de ataque, Grandma se da cuenta de la existencia de una base de datos "mydns", que se corresponde con el registro de los DNS de la empresa de Santa.
- Inspector, creo que lo tengo! Según parece Grandma, ha elaborado una estrategia cuyo plan de ataque consiste según el registro del tráfico de red de su ordenador, en aprovechar una vulnerabilidad en el servidor Web de Santa, para realizar un "envenenamiento / spoofing" de los registros DNS internos, falseando algunos dominios de Apple e iTunes. Imagino que su intención debe ser aprovechar la consulta al dominio Apple de los usuarios para explotar alguna vulnerabilidad o .....
Los resultados y pruebas que demuestran el atraque de inyección SQL realizado desde el PC de Grandma,  se puede ver en la siguiente imagen:

Step 3 - SQL Attack results.


- [Step 4] - Manipulación / Spoofing de los registros del servidor DNS de la empresa SantaPoloNorte SA.

En particular introduce una serie de registros (dns records) en la base de datos mydns, para redirigir todo el tráfico de las consultas realizadas, desde la red interna de SANTAPOLONORTE SA, a los nombres de dominios de Apple e iTunes hacia la IP de la Abuela (192.168.1.10).

Step 4 - DNS Record Insert by SQL Inyection.

- [Step 5] - El ataque: Update process (nueva versión de iTunes)

La IP 172.16.79.6 perteneciente a la red de SANTAPOLONORTE SA, realiza una actualización de software consultando a Apple.com, descargando una nueva versión de iTunes. Sin embargo, el usuario cuya IP es 172.16.79.6 desconoce que la versión descargada se la ha proporcionado el "fake" Server, montado por la abuela.

Las pruebas de la existencia de este proceso son:

Step 5 - HTTP Get update to apple.com
Step 5 - iTunes update process
Step 5 - iTunes update files details.

- [Step 6] - La nueva versión de iTunes, que se descarga la IP 172.16.79.6 es una versión modificada de la original que instala un backdoors en el equipo de la victima.
- Inspector, todavía no tengo claro que es lo que hace la versión iTunes descargada por el equipo 172.16.79.6, tampoco he averiguado si esta IP se corresponde con el equipo de Rudolph ...

- Espere, Hay un flujo de tráfico "extraño", voy a analizarlo .... 
Se observa una conexión FTP con origen IP:172.16.79.6 y destino IP:192.168.1.10, ¿Extraño? verdad!. Consultando los detalles de ese flujo se sospecha de la existencia de un troyano o backdoor. ¿Porqué?

Step 6 - FTP conection to Grandma IP.
Step 6 - FTP Details.

Según parece, Networkminer, no es suficiente para esclarecer los detalles y motivos de la conexión FTP. A continuación nuestro analista utilizará "wireshark" para profundizar sobre el tráfico anómalo detectado. Se detecta un tipo de tráfico que realiza una conexión TCP por el puerto 1228 en la IP 192.168.1.10, justo unos segundos antes de establecerse la conexión FTP con la misma IP (véase imagen siguiente).

Step 6 - Wireshark Traffic Analysis.

Utilizando la opción "Follow de TCP Stream" en wireshark, se consigue obtener los datos intercambiados para el flujo de tráfico, exclusivamente, TCP:1228 entre las IP's: 172.16.79.6 y 192.168.1.10.

Step 6 - TCP conversation between 172.16.79.6 and 192.168.1.10.

Tal y como se observa en la imagen, se corresponde con un tipo de tráfico característico de ejecución remota de comando del Sistema, comúnmente conocido shell remota (remote-tcp-inverse-shell). Lo que ha ocurrido, es que se ha inyectado una dll en el ejecutable iTunes.exe, de forma que al ejecutar iTunes instala   y establece una shell remota sin que el usuario tenga conocimiento ninguno al respecto. [Nota: existen técnicas de paquetización del ejecutable  para evitar los sistemas antivirus - suponemos que este ha sido el caso-]


En la imagen superior, se observa la ejecución del comando "ftp -A 192.168.1.10", demostrando de ese modo el significado de la conexión FTP. Además se observa, que es un equipo Windows XP perteneciente al usuario Rudolph, por lo que es de suponer que se trata del "Reno Rudolph". Por tanto, se puede afirmar que la IP 172.16.79.6 se corresponde con el ordenador de Rudolph el "reno" victima de un complejo ataque.

- [Step 7] - Culminación del ataque, y finalización de la investigación.

Para incriminar a Rudolph en la escena del crimen, Grandma necesitaba, modificar los registros de geolocalización GPS que guarda el teléfono móvil iPhone de la victima. Para lograr su objetivo, se le ocurrió modificar esos datos a través de la copia de seguridad que guarda la victima en su equipo, de modo que al sincronizar los datos entre PC-iPhone, los datos GPS añadidos serían copiados al teléfono. !Un plan brillante¡ Menos mal que esta el Sr. Anderson.

La shell remota proporciona a Grandma la capacidad de controlar por completo el PC de Rudolph, a continuación se explican los pasos que realizó para lograr su propósito.
[7.1] Con ayuda de la conexión FTP, sube (upload) una herramienta sqlite3.exe que permite la modificación del fichero que contiene los datos de GPS que guarda automáticamente los móviles iPhone. (véase Step 6 - FTP conection to Grandma IP)
[7.2] Localización del fichero (DB) y inserción de la localización GPS incriminatoria.

Demostración de este proceso:

Examinando la conversación TCP filtrada mediante wireshark (tal y como se ha visto en el paso anterior), se observa:

Step 7 - SQLite3 commands and GPS.

Las coordenadas introducidas en la copia de backup perteneciente al móvil de Rudolph, son (40.7715, -73.978833), que si comprobamos en cualquier mapa se corresponde con "Central Park" de NY:

Step 7 - GPS location maps.

Para confirmar este dato, se ha realizado un "mapeado" entre la estructura de la base de datos (DB) que almacena la información en el móvil iPhone y el comando ejecutado por el hacker (Grandma):
>sqlite3 4096c9ec676f2847dc283405900e284a7c815836 "insert into CellLocation values(310,410,11250,116541837,346471200.820172,40.7715,-73.978833,1414,0,-1,-1,-1,50)
Step 7 - iPhone DB structure.

Pero además, se ha cotejado la información de localización GPS del móvil, con la fotografía tomada en la escena del crimen:

Step 7 - GPS Details.

Por si no fuera suficiente, la Abuela, también se guardo de situar a Rudolph en la escena del crimen, no solo en Central Park, sino en el día y hora señalados, siguiendo el mapeado entre la estructura de la DB y el comando introducido por el hacker (véase imagen Step 7 - iPhoen DB structure), se extrae el valor 346413600.207493, que se corresponde con la fecha y hora expresadas en el formato Cocoa NSDate, se necesitará realizar una conversión al formato que todos utilizamos:

Steps 7 - Cocoa NSDate Time

Situando a Rudolph en la escena del crimen (Central Park, New York) el 25 de Diciembre de 2011 a las 02:00. Con el suficiente margen de tiempo que sirva para justificar ante el jurado la intención y planificación del homicidio.

CONCLUSIONES FINALES

Tras analizar todos los datos, y detalles presentados por el Sr. Anderson, protagonista de esta historia, (Especialista en Seguridad de la Información), se puede decir:

Que a la vista de las pruebas presentadas por la defensa del acusado, se declara "inocente", a Rudolph el reno, de todos los cargos. Y se emite una orden de captura sobre Grandma y Mel.


RESPUESTAS

Respuestas a las preguntas planteadas por el inspector Martinez, y necesarias para resolver el Reto Hacking:

Why did the geo-location information on Rudolph's computer, synced from his cell phone, show that Rudolph was in Central Park during the attack? Please describe each technical step that lead to this "evidence" presented in court.
Rudolph fue victima de un elaborado y sofisticado ataque informático, que manipulados los datos de tu teléfono móvil para su incriminación, tal y como se ha demostrado anteriormente.
Where should the authorities look for Grandma?
Grandma se esconde en el Hotel Plaza (http://www.theplaza.com/) cerca de Central Park, en NewYork.
Based on the evidence in the packet capture file, who is guilty in this story?
Después de todo lo expuesto, durante estos tres capitulos, Rudolph es inocente, y los culpables son la Abuela por la autora material de los hechos, y Mel por su colaboración, y falso testimonio.
[Referencia para la estructura de la BD Iphone - http://foro.infiernohacker.com/index.php?topic=22406.0]

2012 - Solución al Reto Hacking planteado por Ed Skoudis & Tom Hessman (SANS Institute) a través del Blog sobre Pentesting (pen-testing.sans.org). Autor: Julián J. González Caracuel.

No hay comentarios :

Publicar un comentario