Documentación

Situación:

.

-Un sniffer esta moritorizando la red gracias a ataques arp (cain)

*IPs afectadas:

192.168.0.1   * gateway/router

192.168.0.2 00:22:e2:fe:61:22 * víctima.

192.168.0.4 00:44:e2:fe:61:44 * local (la de nuestro host)

*IP atacante:

192.168.0.3 00:33:6d:a1:bc:33

.

*He remarcado los números en negrita para que os fijéis en que coinciden la ip con el par de cifras de inicio y fin de la dirección mac.

.

  • Narpa es iniciado:

1. Recoge la ip local, ip del router/gateway y su mac

.

2. Escribe una entrada arp estática en la tabla arp de windows.

*En la imagen podemos ver cómo ya nuestro equipo ha quedado protegido frente al atacante

.

 

3. Almacena las macs de los hosts que se encuentran online en la red:

.

  • Hacemos una parada aquí para ver como ha hecho esto a nivel de paquetes:

.

En (1) vemos como le pide la dirección mac al gateway, el cual responde, y tras responder el atacante responde con una mac falsa refiriendose al gateway para actualizar nuestra caché con su mac falseada, pero a nosotros no nos afecta porque NARPA almacena el paquete del gateway.

Dicha mac la usa para crear la entrada estática como vimos en la primera imagen la fase 2

En (3) vemos como escanea la red, a lo que el atacante responde con sus caché falsas, pero esto no nos afecta porque NARPA almacena las que le llegan de los hosts reales.

.

  • Volvemos a la interfaz con las siguientes fases:

.

.

4. Se mantiene a la espera de un paquete falso en la red con ip origen el gateway

5. Si lo encuentra, lo compara con la mac real del gateway y en caso de que sean distintos, es que esa mac pertenece a un equipo atacante.

Con lo cual almacena la mac del atacante y busca su ip en la tabla de ips del programa a traves de la mac del atacante.

-Después, espera un siguiente ataque del atacante para contraatacar.

-Cuando ese paquete lo recibe NARPA realiza la fase 5.1, 5.2 y 5.3

5.1. Realiza preguntas arp al gateway con las macs reales de los hosts para que éste se las apunte y desheche las falsas.

5.2. Realiza preguntas a los hosts de la red con la mac real del gateway.

5.3. Realiza preguntas arp al host atacante con las macs de los hosts y del gateway falsas para aislarlo de la red.

5.4. Realizamos los 3 pasos anteriores 3, pero ahora en modo respuesta(reply) de forma que actualizamos las tablas arp de los destinos.

5.5. A partir de ahora esperamos al siguiente ataque reply del atacante y le respondemos con los pasos 5.1, 5.2 y 5.3 en modo reply contrarestando los paquetes del atacante.

*El programa se quedará en el paso 5.5 continuamente, y tras pasados 10 minutos volverá a actualizar la lista de hosts por si hubieran hosts nuevos o por si algunos hubieran sido desconectados.

.

  • Ahora lo vemos en interfaz de paquetes arp:

.

(3) vemos cómo NARPA termina de escanear las macs de la red y tambien cómo el atacante manda paquetes falsos a la víctima y al host local diciendo que el gateway está en su dirección ip. (*)

(5)NARPA se mantiene a la espera de un ataque, cuando el ataque llega apunta su mac, y busca la ip perteneciente a esa mac, tras eso, vuelve a esperar a un segundo ataque. (podemos comprobar en los destinos de los paquetes de (5) que realizan 2 ataques, y en cada ataque van 2 paquetes, uno al host víctima y otro hacia nosotros)

(5.1)(5.2) ya explicados arriba.

.

  • Pasamos a otra captura de las siguientes fases:

.

.

Aquí podemos observar las siguientes fases del programa, tambien explicadas arriba.

(5.3) No aparece el contenido del paquete, pero aquí le estamos mandando las macs falsas al atacante mediante request, cuando el atacante recibió el paquete falso del gw mandó paquetes falsos (reply) a la red (*)

(5.4) Actualizamos 3 veces la cache arp de los hosts, el gw, y el atacante en modo reply,

este último con macs falsas, los tres últimos paquetes de cada tercio de la fase 5.4 se refieren a las macs falseadas hacia el atacante (lo podemos ver fijándonos en que le informamos al atacante sobre las ips de la red con mac “00:ff:aa:bb:cc:ff”

(5.5) Fase final, se mantiene en espera a (*) que el atacante ataque, y NARPA vuelve a actualizar las caches de los equipos y a aislar al atacante.

.

  • Ahora solo queda ver el resultado final:

.

*Equipo víctima:

.

Podemos observar el antes/despues de como ha pasado de ser atacada por 192.168.0.3 (00-33-6d-a1-bc-33) a que NARPA desde 192.168.0.4 le haya actualizado la caché arp a éste host víctima (192.168.0.2) dándole la mac real del gateway.

Tambien observamos que no hemos perdido la conexión de ping a google en ningún momento en la víctima.

.

*Equipo atacante:

.

.

Aquí podemos ver como el atacante sigue atacando la red ya que las macs quedan almacenadas en cain, pero al ser contrarestados sus arp reply los hosts de la red no quedan afectados por sus ataques.

Por otra parte, en su tabla arp podemos ver como se ha quedado sin acceso directo a ningún host de la red, o incluso a internet, el host atacante está totalmente aislado de la red.

.

.

_________________________________________________

.

Cambios en la última versión

.

Para ver en detalle los cambios:

*Changelog V1.5

*Changelog V1.6

.

Visualmente podemos comprobar cómo si un atacante estaba realizando un ataque antes de que NARPA fuese iniciado, ahora NARPA se altera de esto almacenando el posible gw y el posible atacante, después en el proceso de escaneo, compara esas posibles macs con las macs que le responde la red, y si alguna coincide es que esa es la atacante, y por lo tanto la otra es el gateway. (1.1.1.1 & 1.1.1.2 tienen macs coincidentes):

.

Ahora vemos como la entrada estática la escribe despues del escaneo, porque no siempre va a saber la mac del gateway de antemano:

.

.

 

*No tengo mas hosts para realizar la impresión de ejemplo, pero desde la versión 1.5, en el caso de haber hosts spoofeados tras hacer el escaneo de hosts, se activaría el modo de escaneo seguro.

Este modo escanea los hosts pero descartando las macs que surgiesen del atacante diciendo ser esos hosts, con lo cual conseguiríamos las macs reales de cada host de la red.

 

 

.

No comments yet

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: