TCP Split Handshake

Que mejor forma de retomar el blog que mandando un afectuoso salud a mis apreciados lectores, si los tuviera delante haríamos algo tal que así:

GigA --------->Hola:Lector

GigA:Hola + Mano<----------Lector

GigA:Mano<---------------->Mano:Lector

Etc.

Esto por si no lo habéis entendido es un saludo normal y corriente, que da paso a una conversación. Los humanos, fieles copiadores de lo que vemos en el mundo real decidimos trasladar esta forma de saludo a la informática, para que dos ordenadores pudieran iniciar su conversación lo harán de la misma forma. Es lo que conocemos como ThreeWay-Handsake , que originales somos:

Lo gracioso es que en el mundo virtual, al igual que en el real, pasamos del saludo a 3 bandas y pillamos a alguien desprevenido y le damos una colleja diciéndole: ¡ay maestro agujas!, ¡como vá capataz! (resto de saludos José Mota©), sin dejarle hablar ni nada. Esto entre colegas e incluso desconocidos puede ser gracioso, pero entre frías máquinas sin corazón es desastroso, tanto como que pueden reaccionar de formas raras, reiniciándose, parándose, ignorándote o accediendo a un nivel superior de funcionalidad (muchas veces esto también puede ocurrir con las mujeres), así una máquina se queda algo confusa cuando se le intenta abrir una conexión por ejemplo un SYN SEQ 1000, te responde con un SYN ACK 1000+1 SEQ 1500, y tu ignoras completamente su respuesta y vuelves a hacer otro SYN, y otro, y otro, y vas cambiando puerto, o le saturas un servicio a intentos de conexión, etc. Son muchas de las variedades de handshake que se pueden hacer en un escaner de puertos (para lo que vendría bien recordar esta entrada).

Sin embargo parecía que estaba todo inventado en lo que a saludos se refiere, cual es mi sorpresa cuando ayer me encontré esta interesante investigación de la gente de Macrothink, el TCP Split Handshake. Trasladado al lenguaje humano sería como realizar el saludo de forma normal, pero definir y recalcar cada una de las fases sin hacer nunca 2 cosas a la vez (¿?¿?), vale. Os pongo la imagen y me explico:

¿Qué es lo que se ha hecho?, separar el SYN, ACK que hace el servidor en dos pasos bien diferenciados, en dos paquetes distintos, algo que recoge perfectamente la RFC 793 en su página 27. Algo tan inocente como esto se ha probado con IDS/ IPS, routers, servidores, etc. con resultados más que soprendentes, y es que un servidor que tenga el protocolo de establecimiento de conexiones TCP alterado puede comprometer a sus clientes en una infinidad de casos. Veamos como reacciona el cliente cuando el servidor hace el split:

Lo que era un ThreeWay Handshake acaba convirtiéndose un FiveWay,,, de esto no decía nada la RFC 793. Otras curiosidades de esta particular forma de saludarse son que algunos IPS (lo probaron con un Juniper) no detectaron el ataque, sirviendo el splits tcp como técnica de evasión ya que, al no detectar la conexión como establecida no detectaba ataque alguno. En caso de NAT se encuentra de todo, desde un PIX-515 que era incapaz de hacer NAT y salir hacia otras redes con el splits TCP a un Cisco 2631 que se metía hasta Internet, luego parece que dependiendo del caso el NAT a priori no nos protegerá de este tipo de intentos de conexión. Finalmente, si estás ofreciendo un servicio en un puerto cualquiera, digamos el 22, y tu máquina es sometida a un escáner de red con un NMAP o similares no reaccionará tampoco de la forma habitual, pudiendo quedar oculto ese servicio o mal identificado:

Efectivamente esto para un atacante persistente no es un problema pero por ejemplo, para un barrido de un virus puede ser una “medida de seguridad”.

En resumen, este comportamiento anómalo en el establecimiento de conexiones por Split Handshake va a obligar a todo tipo de proveedores de equipos de comunicaciones, servidores, appliances de seguridad, etc. a añadir una excepción más o a contemplar que el ThreeWay Handshake no es la única forma de establecer una conexión TCP. Parece mentira que algo que lleva tantos años usándose no haya sido evaluado por muchos fabricantes en el 2010.

Ah, si queréis jugar tenéis scripts de ejemplo y capturas de Wireshark aquí, está hecho en Ruby y necesitareis las librerías libpcap para poder ejecutarlo.

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.