¿Entradas ARP Estáticas contra ataques Man in the Middle?

Un poco de teoría sobre MitM y ARP

El protocolo ARP es el encargado de traducir de direcciones IP a MAC (y el inverso, traduce de MAC a IP lógicamente). Cuando estamos conectados a internet desde un portátil a traves de una red wireless, usamos este protocolo para saber a dónde tenemos que enviar nuestros paquetes (al router claramente) para que puedan ir a través de Internet y demás.

El envenenamiento de las tablas ARP consiste en decirle al ordenador víctima desde el ordenador atacante “el router se encuentra en esta otra dirección (la del atacante)”. De esta manera, la víctima piensa que le está enviando los paquetes al router, y realmente se los envía al atacante. Así, éste puede ver todo el tráfico de la víctima, que luego redirige al router, y realiza el camino inverso.

En la siguiente imagen, vemos una tabla ARP normal. Subrayado y en primer lugar, tenemos la dirección del router. Luego, dos direcciones de un par de equipos, broadcast, etc. Aquí no hay nada raro, está todo en orden.

Ahora, vamos a envenenar la tabla ARP desde un ordenador atacante.
Como podemos ver, aparece otro ordenador con IP 192.168.2.103 (el atacante), y la MAC del router ha cambiado. Si os dais cuenta, es la misma que la del atacante.

Nota: para ver la tabla ARP desde Windows se hace mediante arp -a

Solución: ¿Poner entradas ARP estáticas?

Teóricamente, si ponemos entradas estáticas estamos seguros, ya que de esta forma ningún atacante puede cambiarlas para hacer pensar al ordenador víctima que el router está en otra dirección distinta. ¿Es lógico no? Si no se puede cambiar esto, se enviará siempre hacia el router.

Pues bien, vamos allá. Poner entradas ARP estáticas en Windows es más complicado que usar simplemente el comando ARP. Nuestra primera intención es hacerle caso a lo que nos dice la ayuda de ARP de la consola, y es usar:

arp -s IP MAC

Pero no funciona. Como he dicho, es algo más complicado. De hecho, uno de los motivos de crear esta entrada es para guardar cómo se hace, y así no tener que buscarlo si en un futuro es requerido hacerlo.

Primero de todo, necesitamos saber el nombre de la conexión. Para ello lo hacemos mediante:

netsh interface ip show config

Como podemos ver, el nombre de mi conexión es “Conexión de red inalámbrica”.
Después, ejecutamos el siguiente comando:

netsh interface ipv4 add neighbors “NOMBRE_CONEXIÓN” IP MAC

Importante: daros cuenta que la MAC está separada por guiones y no por dos puntos.

Volvemos a reproducir el ataque

¿Qué sucede si reproducimos de nuevo el ataque? ¿Seremos completamente invulnerables? La respuesta es no, no estamos seguros. Y ahora viene el porqué: el envenenamiento de la tabla ARP consiste en enviar paquetes hacia la víctima y el router para que le envien los paquetes al atacante. De esta forma ve todo lo que va de la víctima al router (y por tanto hacia Internet) y viceversa. Si le decimos al ordenador víctima que el router está en una dirección (con entradas estáticas), el router todavía seguirá pensando que el ordenador atacante es en realidad el de la víctima.

Paquetes ARP que envía el atacante. Como podemos ver, le dice al router “la dirección del ordenador (víctima) está en mi MAC” y le dice a la víctima “la dirección del router está en mi MAC”.

Un dibujo de cómo quedaría ahora el envío de paquetes:

Conclusiones

Principalmente de este asunto saco dos conclusiones importantes.
La primera de todas es, que para que sea realmente seguro, habría que poner estática también la entrada ARP del router que vaya dirigida hacia el ordenador. De esta forma no se alteraría nada de nada, y todo iría por su camino correspondiente.

La segunda conclusión es la siguiente: ¿realmente nos merece la pena poner entradas estáticas en nuestro ordenador en caso de no poder hacerlo en el router? Me explico: si no lo hacemos en el router, el atacante podrá obtener los paquetes que vienen del router (e Internet) hacia la victima y no los otros vale, pero es interesante tener las entradas dinámicas, para que si un atacante nos envenena nuestra tabla, nos demos cuentas (hay programas que detectan cuando una tabla ARP es cambiada y nos avisan, como Marmita).

Conclusión de las conclusiones: si podemos poner estáticas las entradas del ordenador y el router perfecto. Si no, es interesante dejarlas dinámicas y tener un programa que nos avise cuando sean cambiadas.

Algunos comandos de nmap

Lejos de ser una entrada dedicada al intenso estudio sobre esta herramienta de escaneo de puertos, simplemente queria poner algunas opciones que me son útiles y que alguna vez se me olvidan, y como a mi, seguro que a muchos otros igual, por lo que simplemente quería apuntarlas en un post.

Quien quiera una documentación completa, muy buena por cierto, que vaya a la página oficial en donde incluso se encuentra en español una guia bastante interesante: Guía de referencia de Nmap.

-Escaneando todas las direcciones de red (desde 192.168.1.0 hasta 192.168.1.255)
-Escaneando puertos (3 formas distintas)
-Adivinar el sistema operativo de un dispositivo

Escaneando todas las direcciones de la red (desde 192.168.1.0 hasta 192.168.1.255)

nmap -sP 192.168.1.0/24
Resultado:

Starting Nmap 5.21 ( http://nmap.org ) at 2011-06-11 22:17 CEST
Nmap scan report for www.brntech.com.tw (192.168.1.1)
Host is up (0.0032s latency).
MAC Address: xX:XX:XX:XX:XX:XX (Unknown)
Nmap scan report for 192.168.1.100
Host is up (0.012s latency).
MAC Address: 00:XX:XX:XX:XX:XX (Intel Corporate)
Nmap scan report for 192.168.1.102
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 4.50 seconds

Como podemos ver, nos devuelve la dirección del router, de otro dispositivo conectado a la red, y por último, el nuestro.

Escaneando puertos

Podemos escanear uno o varios puertos (separados por comas) de una dirección específica:
nmap -p 135,155 192.168.1.100

Starting Nmap 5.21 ( http://nmap.org ) at 2011-06-11 22:28 CEST
Nmap scan report for 192.168.1.100
Host is up (0.0063s latency).
PORT STATE SERVICE
135/tcp open msrpc
155/tcp filtered unknown
MAC Address: 00:XX:XX:XX:XX:XX (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 1.37 seconds

O incluso buscar si está abierto un puerto específico (o los que sean) en cualquier dispositivo de toda la red:
nmap -p 135,155 192.168.1.1/24

Starting Nmap 5.21 ( http://nmap.org ) at 2011-06-11 22:29 CEST
Nmap scan report for www.brntech.com.tw (192.168.1.1)
Host is up (0.0089s latency).
PORT STATE SERVICE
135/tcp open msrpc
155/tcp closed unknown
MAC Address: 00:XX:XX:XX:XX:XX (Unknown)

Nmap scan report for 192.168.2.100
Host is up (0.017s latency).
PORT STATE SERVICE
135/tcp open msrpc
155/tcp filtered unknown
MAC Address: 00:XX:XX:XX:XX:XX (Intel Corporate)

Nmap scan report for 192.168.2.102
Host is up (0.000076s latency).
PORT STATE SERVICE
135/tcp closed msrpc
155/tcp closed unknown

Nmap done: 256 IP addresses (3 hosts up) scanned in 5.66 seconds

O si no, directamente buscar todos los puertos que tenga abierto una dirección:
nmap 192.168.2.100

Starting Nmap 5.21 ( http://nmap.org ) at 2011-06-11 22:50 CEST
Nmap scan report for 192.168.2.100
Host is up (0.040s latency).
Not shown: 993 filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
554/tcp open rtsp
2869/tcp open unknown
5357/tcp open unknown
10243/tcp open unknown
MAC Address: 00:XX:XX:XX:XX:XX (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 19.53 seconds

Adivinar el sistema operativo de un dispositivo

El funcionamiento de esto se basa en que, nmpa envía a la máquina objetivo una serie de paquetes. Posteriormente analiza los bits de las respuestas recibidas y este resultado lo compara con una base de datos.

nmap -O 192.168.1.100

Starting Nmap 5.21 ( http://nmap.org ) at 2011-06-11 22:32 CEST
Nmap scan report for 192.168.1.100
Host is up (0.031s latency).
Not shown: 993 filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
554/tcp open rtsp
2869/tcp open unknown
5357/tcp open unknown
10243/tcp open unknown
MAC Address: 00:XX:XX:XX:XX:XX (Intel Corporate)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING) : Microsoft Windows Vista|2008|7 (93%)
Aggressive OS guesses: Microsoft Windows Vista Home Premium SP1 (93%), Microsoft Windows Vista SP0 or SP1, Server 2008 SP1, or Windows 7 (93%), Microsoft Windows Server 2008 Beta 3 (88%), Microsoft Windows Vista Business SP1 (88%), Microsoft Windows Vista Home Premium SP1 or Windows 7 (87%), Microsoft Windows 7 (85%), Microsoft Windows Vista SP1 (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.98 seconds

Saludos, lipman

[Script] Tratar cookies esnifadas con Wireshark en PHP

Un sitio web puede tener más de una cookie en el ordenador del usuario que navega, pero las cookies críticas son las que nos permiten la identificación del usuario en la página web. De esta manera, mediante técnicas como los conocidos XSS o los MITM seriamos capaces de obtener cookies críticas que nos permitan falsificar y hacer creer al sistema que nosotros somos el usuario objetivo.

El problema viene cuando el objetivo de un esnifado de red es únicamente saber las cookies críticas del que navega. Con todos los paquetes de datos que recibimos, incluso filtrándolos por HTTP en Wireshark, tendriamos mucho trabajo por delante.

De este problema me surgió la necesidad de crear un script en PHP, el cual quiero compartir en el blog, que nos permite, no solo ordenar y obtener las cookies de manera agradable para la vista, sino que, incluyo una función en la que a partir de un array cuyo índice sea el domino y el valor sea el nombre de la cookie crítica de ese sitio, nos lo colorea de rojo, permitiéndonos así localizarlas más fácilmente. De la misma manera, nos quita las cookies de los hosts repetidos.

El código está completamente comentado y dividio en dos funciones que nos hacen el entendimiento más fácil. El archivo que tenemos que pasarle al script, ha de ser el fichero pcap guardado del wireshark una vez esté filtrado usando el siguiente filtro:
http contains "Cookie: "
Esto nos permite obtener los paquetes que contenga “Cookie:” que son los que nos interesan.

Este es un ejemplo del resultado. Sabemos que la cookie crítica de twitter es auth_token:

Script:





Documento sin título





0)
    $final[] = $valor;
}

//La matriz "final" contiene por cada valor, un paquete con host y cookie
//"resultado" es una matriz vacia en la que se almacenará el resultado devuelto
parsear_matriz($final,$resultado);


//Printeamos el resultado
foreach($resultado as $clave => $valor){

  echo $clave;
  unset($final);
		$nuevo = explode(";",$valor);
		foreach($nuevo as $valor2)
			$final .= "" . $valor2 . "
"; echo $final . "
"; } //FUNCIONES function parsear_matriz($matriz,&$resultado) { foreach($matriz as $valor) { $host = explode("Host: ",$valor); $host = explode("\r\nUser",$host[1]); //Host[0] tiene cada host $cookie = explode("Cookie: ",$valor); //Cookie[1] tiene el valor de la cookie en cada host detectar_cookies_criticas($host[0],$cookie[1]); $host[0] = "" . $host[0] . ":
"; $resultado[$host[0]] = $cookie[1]; //Devolvemos el resultado } } function detectar_cookies_criticas($host,&$cookie){ $buscar = array("twitter.com" => "auth_token"); //Esta matriz contiene el host y la cookie crítica que destacará en el caso de que la encuentre if(array_key_exists($host,$buscar)){ $nuevo = explode($buscar[$host],$cookie); $cookie = $nuevo[0] . "" . $buscar[$host]; $nuevo = explode(";",$nuevo[1]); $cookie .= $nuevo[0] . ";" . $nuevo[1]; } } ?>

[NetworkMiner] Una alternativa bonita para visualizar paquetes de red

De todos es bien conocido Wireshark, un analizador de paquetes de red multiplataforma cuya característica más destacabla, al menos para mi, es la gran flexibilidad que tiene a la hora de filtrar y analizar todo de una forma bastante gustosa.

Sin embargo… a la hora de comodidad para llevar a cabo algunas tareas como puede ser la visualización de todas las imágenes capturadas, de las cookies obtenidas, de los hosts, etc.. puede resultarnos un poco incómodo. Por ello, recomiendo a todo el uso de NetworkMiner, otro analizador de paquetes que, aunque tristemente solo esté disponible para Windows, es portable, lo cual es atractivo.

Como podemos ver en la imagen superior, una de las cosas más interesantes que trae, es la funcionalidad que nos permite ver los Hosts de manera tan clara y los DNS en la ventana correspondiente.

Otra de las grandes funcionalidades que tiene NetworkMiner es la de poder visualizar y abrir todos los archivos que al capturar paquetes son descargados, archivos del tipo json (peticiones de los servidores), archivos html, y básicamente, cualquier archivo con los que linda nuestro navegador.

La finalidad, al menos para mi, más interesante y cómoda que tiene, es la posibilidad de visualizar todas las imagenes capturadas correctamente. A diferencia de Wireshark, en donde para poder ver una imagen completa teniamos que, primero localizar el archivo de imagen, luego seleccionar la parte que queremos exportar y finalmente, darle a Export Selected Packet Bytes, aquí simplemente las visualizamos en miniaturas, y la que queremos abrir, simplemente seleccionamos y pinchamos con el botón derecho, y le damos a abrir imagen.

Por otra parte, otro de sus atractivos es la facilidad de ver las cookies recogidas respecto al host que pertenecen, junto con datos como su caducidad y la IP del cliente al que hace referencia.

Por último, mencionar que NetworkMiner no solo sirve para visualizar paquetes, sino que tambien nos permite capturarlos como podemos ver a continuación:

Como conclusión diré que para los que quieran visualizar rasgos como imágenes, cookies y hosts capturados de forma fácil y sin profundizar demasiado, esta herramienta es imprescindible (ya que además es portable). Si queremos ojear paquetes con profundidad, siempre recomendaría usar Wireshark.

Un saludo, lipman