¿Por qué no puedo conectarme a una dirección falsificada con arpspoof?

3

Quería ver cuántas combinaciones de sitios web y navegadores siguen siendo vulnerables a un ataque de eliminación de tls (como, al implementar HSTS o deshabilitar el uso de HTTP de texto simple). Para hacerlo, quería verlo de primera mano utilizando la herramienta sslstrip, pero no pude hacerlo funcionar (siguiendo las instrucciones en la página del proyecto): la suplantación de ARP aparentemente funciona bien, ya que la PC de destino ya no puede navegar. , pero sslstrip no recibe nada.

Intenté escuchar con un socket TCP en el puerto redirigido por iptables, pero no recibí nada, por lo que también excluí iptables, y ahora solo estoy tratando de recibir conexiones directamente en el puerto utilizado por el cliente víctima. Lo intenté habilitando y deshabilitando el reenvío de IP (con /proc/sys/net/ipv4/ip_forward ) y usando wifi o Ethernet como la interfaz del host atacante, pero nada cambia:

Este es el comando que estoy usando desde el host atacante (dirección 192.168.1.33 hostname macbook , una caja de Linux 3.11):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

( 192.168.1.1 es la puerta de enlace) y luego

sudo socat TCP4-LISTEN:80 STDOUT

en el host de la víctima ( 192.168.1.31 ):

socat - TCP4:192.168.1.1:80

Puedo abrir la conexión, pero si intento algo, no recibo nada en el host atacante (el hecho de señalar socat a la dirección IP del atacante obviamente funciona)

traceroute muestra que, aparentemente, la falsificación ARP es exitosa:

> traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1 macbook.local (192.168.1.30) 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 [snip]
28 * * *
29 * * *
30 * * *

arp -n de salida desde el host víctima

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.33             ether   00:1d:4f:fc:af:fc   C                     wlan0
192.168.1.1              ether   00:1d:4f:fc:af:fc   C                     wlan0
    
pregunta berdario 21.11.2013 - 14:16
fuente

1 respuesta

1

Se está produciendo una colisión de IP. Aunque has convencido a 192.168.1.31 de que eres 192.168.1.1 con el siguiente comando (lo que significa que has influido en su tabla de enrutamiento):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... el 192.168.1.1 aún piensa que es 192.168.1.1, por lo que cuando vea las solicitudes de arp para su propia IP, tanto su máquina como el enrutador responderán con una dirección MAC. La primera dirección MAC recibida será la que reciba el paquete (no creas que debido a que ves una entrada para tu IP envenenada en arp -n, las solicitudes de arp para esa IP necesariamente cesarán). Además, no sabe NO enviar paquetes a la máquina víctima o responder a otros paquetes que parecen provenir de esa máquina.

Por lo general, man-in-the middle es solo eso, "en el medio", por lo que debes intentar lo siguiente:

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

El segundo le dice a su enrutador que le envíe paquetes dirigidos a IP 192.168.1.31 (en lugar de a la máquina víctima original). Si su máquina víctima recibe un paquete del 192.168.1.1 real con la dirección MAC real de esa máquina, ¿sabe cuál será su comportamiento? Por lo tanto, es mejor evitar esta posibilidad redirigiendo cualquier paquete de 192.168.1.1 real destinado a 192.168.1.31, ya que se supone que estás en el medio.

    
respondido por el user34445 29.11.2013 - 06:49
fuente

Lea otras preguntas en las etiquetas