1 votos

¿Por qué se ignoran los paquetes de DNS falsificados?

Primero, permítanme aclarar que esta pregunta se refiere a un proyecto privado, que está diseñado para fines educativos solamente.

Traté de escribir mi propio DNS con el simulador". No te preocupes, esta pregunta no está relacionada con ningún prácticas de codificación.

La configuración actual

El funcionamiento de la máquina es un MacBook (con OSX) en una red local (por lo que existen algunos otros de importancia de los dispositivos). Hay un router que utiliza otra máquina (también en la red local), como servidor DNS local. Aunque esta configuración es un poco inusual, no debe ser la causa del problema (descrito a continuación).

El objetivo

DNS Spoofing - cuando el MacBook envía una petición DNS, enviar una respuesta con una falsificación de la dirección IP.

Mi enfoque actual

Yo uso BPF (Berkeley Packet Filter) para tener acceso raw a la capa de enlace de datos.

Ahora, yo estoy escuchando/capturar cualquier consulta sobre la interfaz de red Ethernet de la MacBook (que se refiere como "MB" en la siguiente parte).

He desactivado el protocolo IPv6 en el MB.

Voy a borrar la caché de DNS en el MB con los siguientes comandos:

sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache

Procedimiento

  1. MB envía una petición DNS con algunas consultas
  2. Puedo crear una respuesta DNS con las mismas consultas y respuestas a todo Tipo a (IPv4) consultas y enviarle esta respuesta
  3. El MB recibe a las respuestas: mi falso respuesta de la primera, entonces la real enviado por el real servidor DNS local

Cada falso paquete de respuesta DNS incluyen:

  • la dirección MAC de Ethernet de la solicitud de DNS del servidor de Ethernet de la dirección de origen
  • la dirección IP para la que solicita el servidor DNS de la dirección de origen
  • el puerto 53 como puerto de origen
  • el puerto como puerto de destino que el DNS se originó la petición de
  • una IP correcta de la suma de comprobación del encabezado
  • una correcta UDP checksum
  • una correcta Secuencia de Verificación de Trama Ethernet/la suma de comprobación.

Cada respuesta DNS se envían a través de la misma interfaz de red que estoy escuchando.

Cada vez que una consulta se envía, habrá dos respuestas:

  1. la primera, que envió inmediatamente por el "DNS spoofer", el "falso" paquete/respuesta DNS, llega antes de la segunda
  2. el segundo, el 'real' de respuesta DNS, enviado por el servidor DNS local.

Yo también supone (aunque no estoy seguro acerca de esto) que OSX siempre toma la primera respuesta DNS que resuelve un nombre de dominio a su dirección IP.

Para resumir; ambas respuestas de DNS son iguales salvo que las sumas de comprobación y la respuesta DNS, las direcciones IP son diferentes. También, el 'real' servidor DNS no enviar (por qué razón nunca) un FCS (Secuencia de Verificación de Trama). Yo, aunque no se calcula y acaba de establecer a cero (cero).

Problema

OSX parece ignorar el falso respuestas de DNS. También podría ser que el sistema operativo es forzada al máximo; el comportamiento a la hora de usar Safari para abrir una página Web es la siguiente:

Cuando se utiliza Safari y escribir "http://some-url.com" en la barra de direcciones, no pasa nada. No se conecta al sitio real, ni conectarse a la página falsa. La página parece cargar para siempre. A veces, después de una década, se conecta a la página real.

Ejemplo (captura con Wireshark)

Un ejemplo al azar.

Request: 
0000   b8 27 eb b9 a0 0f a0 ce c8 10 75 8c 08 00 45 00   
0010   00 33 74 2c 00 00 ff 11 62 06 c0 a8 b2 1f c0 a8   .3t,..ÿ.b.À¨².À¨
0020   b2 16 f2 7e 00 35 00 1f 49 71 67 00 01 00 00 01   ².ò~.5..Iqg.....
0030   00 00 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01                                                .



Fake Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 43 12 34 00 00 40 11 82 ef c0 a8 b2 16 c0 a8   .C.4..@..ïÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 2f 46 44 67 00 81 80 00 01   ²..5ò~./FDg.....
0030   00 01 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0c 00 01 00 01 00 00 07 08 00 04 ac d9 17   .À...........¬Ù.
0050   8e 22 4f 80 1c                                    ."O..



Real Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 7c 9c 19 40 00 40 11 b8 d0 c0 a8 b2 16 c0 a8   .|..@.@.¸ÐÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 68 83 00 67 00 81 83 00 01   ²..5ò~.h..g.....
0030   00 00 00 01 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0e 00 06 00 01 00 00 03 84 00 3d 01 61 0c   .À..........=.a.
0050   67 74 6c 64 2d 73 65 72 76 65 72 73 03 6e 65 74   gtld-servers.net
0060   00 05 6e 73 74 6c 64 0c 76 65 72 69 73 69 67 6e   ..nstld.verisign
0070   2d 67 72 73 c0 0e 5c 83 f7 73 00 00 07 08 00 00   -grsÀ.\.÷s......
0080   03 84 00 09 3a 80 00 01 51 80                     ....:...Q.

1]2]

Cualquier ayuda es muy apreciada. Si necesita más detalles, que me haga saber. Si quieres una recompensa, hágamelo saber.

1voto

Simon Puntos 165

En primer lugar, las tramas Ethernet siempre han FCSes en el cable, pero no todos los Nic de Ethernet mantener la FCS se adjunta al pasar de la trama recibida hasta el host, lo que significa que su sniffer, no siempre se puede ver la FCS o saber si era válido o no.

Así que usted necesita para obtener su FCSes derecho.

Si usted no sabe que es un hecho que la versión de BPF en el inyector/simulador del dispositivo de la plataforma, o su controlador de NIC o de hardware, se va a calcular el correcto FCS para usted si se omite o pad con ceros, entonces usted probablemente tendrá que averiguar eso en primer lugar. Mi conjetura es que NO va a arreglar para usted si se intenta inyectar un paquete sin que se establezca correctamente, entonces usted probablemente tendrá que calcular usted mismo y introduzca el valor correcto al final de su búfer de paquetes antes de hacer su bpf_write().

Segundo, estoy echando un vistazo a su hex volcados, pero si estoy mentalmente decodificación correctamente, su campo DiffServ se ve falso. De forma predeterminada, a 0x00 en lugar de 0xff si usted no sabe qué hacer con él.

Tercero, la IP de la longitud total del campo se ve falso (cero). Es probable que necesite para calcular y establecer correctamente. Asegúrese de que antes de calcular las sumas de comprobación de su.

Nada más salta a mí. Así que si yo fuera usted, me gustaría solucionar los tres problemas e intente de nuevo.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: