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:
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.aspxAhora 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.htmlQue 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
Mostrar Mensajes
