Windows 10 NDIS me bloquea paquetes de ARP spoofing

[Kaxperday]

Bueno, pues ha pasado esta última semana. Resulta que todo funcionaba bien excepto el ARP poisoning. Utilizo C++ y winpcap para hacer el spoofing, todo estaba bien, todo era correcto y era la misma red. Abría wireshark y no detectaba errores, era todo correcto como las otras veces. Al ver que no me funcionaba el programa probé con mis propios backups que si funcionaban anteriormente sin éxito tampoco. Entonces me descargué programas que hacían ARP spoofing (mejor dicho ya los tenía descargados), me refiero al nighthawk que es de código abierto y en numerosas ocasiones lo he probado con éxito, pero esta vez no funcionaba.

No era posible los paquetes estaban bien, la misma red, siempre me habían funcionado... algo pasaba pero creo que no tenía que ver ni con los programas ni con winpcap ni nada.
Entonces instalé wireshark en una víctima para comprobar que le llegaban mis paquetes ARP poisonning, y SORPRESA no le llegaban, pero todos los demás paquetes si llegaban como preguntas de broadcast etc, solo no llegaban los ARP response falsos.

En mi wireshark diciendo que los estaba mandando, en mi programa diciendo que los estaba mandando, pero sin embargo a las víctima no le llegaban. Creo que puede ser debido a una actualización de un driver de windows que detecta si el ARP es falso o no.

El caso una putada, porque siempre me ha funcionado esto y parece que windows lo ha capado o el antivirus, que de alguna manera detecta los paquetes falsos y no los envía.

Saludos.

Edito: Bueno aunque si de verdad lo han capado, no hay problema pasaré al MITM con DHCP u otros métodos, no me pararán XD.

Os invito a probar nighthawk y comentarme si os funciona para win10, podréis encontrarlo por github.

[kub0x]

Veo que has dado con la solución pero a nivel técnico lo que ha implementado Microsoft (tampoco tengo info oficial) es lo que hizo antiguamente con los RAW_SOCKETS, y es limitar el tráfico ARP a su driver TCP/IP, así que cualquier paquete ARP que envíes desde sockets en Usermode será denegado.

La alternativa sería crear un kernel driver o un firewall filter, cito de la msdn:

Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for creating network filtering applications. The WFP API allows developers to write code that interacts with the packet processing that takes place at several layers in the networking stack of the operating system. Network data can be filtered and also modified before it reaches its destination.

Básicamente te deja escribir código que interactua con el procesamiento de paquetes en las distintas capas de red de la pila TCP/IP del SO.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366510%28v=vs.85%29.aspx

Saludos.

[Kaxperday]

Buenas bro, gracias por la respuesta.

Veo que has dado con la solución pero a nivel técnico lo que ha implementado Microsoft (tampoco tengo info oficial) es lo que hizo antiguamente con los RAW_SOCKETS, y es limitar el tráfico ARP a su driver TCP/IP, así que cualquier paquete ARP que envíes desde sockets en Usermode será denegado.

¿Usermode? XD, para usar winpcap necesitas permisos de administrador, la aplicación está corriendo con permisos y me capa los ARP responses falsos por igual. LLegan todos los paquetes menos esos, todo lo que mando con pcap_sendpacket() llega a la victima menos solo exclusivamente ese tipo de paquete el que envenea la tabla ARP a la victima, ¿casualidad?, no lo creo XD.

XD no se si un kernel driver o firewall filter serían solución a este problema, de todas maneras desconozco como programarlos.. que tendría que hacer.. puede hacer mas enredoso el proyecto, quizás sea más fácil optar por DHCP spoofing. De todas maneras, estudiaré tus alternativas.

Un saludo y gracias.

Edito: Habrá que probar también esto:

http://www.win10pcap.org/
http://www.winpcap.org/pipermail/winpcap-users/2015-March/004935.html

[Kaxperday]

Bueno leyendo un buen rato por microsoft me voy enterando un poco más del asunto.

Resulta que ayer probé mi programa que hace ARP poissoning en otro ordenador windows 10 y el resultado fue el mismo que el mio.

Windows 10 y no se si otras versiones no permiten enviar mensajes ARP request o responses suplantando mi IP por la del router, es decir, que paquetes ARP que envíe asociando mi MAC con la IP del router serán rechazados por windows, y aunque mi winpcap los detecte, no salen del adaptador.

Ejemplo: Este código manda un ARP poissoning response diciendo a las victimas de la red que tengo la IP del router para que envenenen su tabla y me hagan llegar sus paquetes:

Código (cpp) [Seleccionar] Expandir


memcpy(paquete, mensaje_arp(true, true, ip_gateway, mac_atacante, ip_destino, NULL), sizeof(u_char)* 42);
pcap_sendpacket(capturador, paquete, 42);


Y bien ese paquete a pesar de decir que es enviado es rechazado, no sale nada del ordenador, sin embargo sin en vez de poner la IP del router, pongo cualquier otra IP el paquete sale y es recibido por los demás dispositivos.

Todos los windows NDIS "network driver interface specification" de version 6 en adelante utilizan "filtros" como pone aqui:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff565492%28v=vs.85%29.aspx

Ahora bien cuando mandamos un paquete desde una NIC esa NIC pasa por el NDIS antes de salir, luego nuestros paquetes son monitoreados por el NDIS. El NDIS utiliza filtros, que filtran nuestros paquetes que envíamos.

El NDIS provee a nuestro NIC de drivers intermedios que ofrecen a nuestras aplicaciones protocolos TCP/IP, es decir todos los paquetes que mandamos de nuestra aplicación de tipo TCP/IP automaticamente son construidos en este paso gracias a estos drivers intermedios.

Pero con programas como winpcap lo que se hace es saltar ese paso a través del protocolo NFC:

https://www.winpcap.org/docs/docs_412/html/group__NPF.html

Que salta directamente a la NIC pasando por encima de estos drivers intermedios que construyen la capa ethernet, tcp, ip... a partir de los datos de nuestro paquete, esto nos permite poder enviar a la NIC directamente los datos de la capa ethernet que queramos, poner lo que queramos en el paquete para que pase a la NIC y de la NIC pasando por los filtros de la NDIS hasta llegar
a la tarjeta de red y salir el paquete de esta a la red.

Hay antivirus como kaxpersky que instalan su propia NDIS para interceptar conexiones TCP/IP y bloquearlas si detectan un uso irregular de las mismas.
Parece que windows también se ha apuntado a la fiesta con sus ultimas versiones de NDIS
que parecen detectar y bloquear la salida a ciertos paquetes de red, como en mi caso ocurre
con los paquetes ARP poisonning, causante de los problemas actuales de mi sniffer.

Ahora bien, ¿que soluciones puedo tomar para poder desarrollar estas hacktools en windows con estas restricciones?.

1) Utilizar otros métodos para lograr el MITM (usar DHCP MITM mucho menos eficaz que el ARP MITM pues debería esperar a que la victima se reconectara en la red para que accediera a nuestro servidor DHCP).

2) Utilizar nuestro propio driver NDIS (o buscar uno sin restricciones e instalarlo), pero desconozco si eso sería posible hacerlo, tendríamos que instalar nuestro NDIS restricciones ¿y desinsntalar el de windows?, entonces con winpcap accederiamos a la NIC y nuestro driver enlazaría la NIC con el minipuerto de red dando salida el paquete. Pero me pregunto si se podría instalar un driver para nuestro sniffer solo que al usar nosotros nuestro propio NDIS no usariamos el NDIS de windows que restringe nuestros paquetes. Necesitaría el SDK de NDIS, y ayudarme con esto supongo: https://github.com/Microsoft/Windows-driver-samples/tree/master/network (no quiero verme en esa mier** XD). #modefreakon.

¿Cuál sería mejor opción para vosotros?. ¿la segunda sería posible?.

PD: ¿Como sería eso del firewall filter kub0x?.

Saludos, y ahí vamos XD