Problema redirigiendo paquete TCP

[Kaxperday]

Hola, buscando errores me he dado cuenta que no llegan o el servidor HTTP proxy no quiere responder los paquetes y rechaza su conexión, no entiendo:

LLegan paquetes TCP con destino puesto 80, lo que hago es redirigirlos a mi servidor local, pero este no los debe de recibir, los paquetes están mal, o no se que pasa pero no se produce conexión:

Código:

Código (cpp) [Seleccionar] Expandir


else if (content[36] == 0x00 && content[37] == 0x50)//de host hacia localserver
{//les pongo la mac del otro en ambos sentidos.
// lo manda a 127.0.0.1:10000 y pone la mac del host de src y dest y ip src del server
//le respondera como 127.0.0.1:10000 -> 202.123.123.123.34
//ip red ordenador origen hacia 127.0.0.1:10000 -> 202.20.20.12:80
UCHAR localhost[5] = "\x7f\x00\x00\x01";
memcpy(const_cast<UCHAR*>(content), content + 6, 6);
memcpy(const_cast<UCHAR*>(content + 26), content + 30, 4);//origen IP pongo la del server
memcpy(const_cast<UCHAR*>(content + 30), localhost, 4);//dst IP to localhost
const_cast<UCHAR*>(content)[36] = 0x27;//puerto destino 10000
const_cast<UCHAR*>(content)[37] = 0x10;

memcpy(const_cast<UCHAR*>(content + 24), GetIPChecksum(const_cast<UCHAR*>(content), header->caplen), 2);
memcpy(const_cast<UCHAR*>(content + 50), GetTCPChecksum(content, header->caplen), 2);//si puerto 80 no hace falta modificarlo.
pcap_sendpacket(sniffer, content, header->caplen);
printf("sended to localserver");
continue;
}


[AlbertoBSD]

Por que pruebas inyectando los paquetes?

ya tratase con una petición GET Manual usando Telenet o netcat?

Los paquetes van especificamente DST (MAC,IP,PUERTO)  a la maquin que tiene tu programa servidor?

Como los otros hosts saben que tienen que mandar las peticiones a tu maquina?

He visto varios de tus temas y todo apunta a que estas haciendo un proxy transparente al estilo squid o algo similar.

Saludos

[Kaxperday]

Buenas gracias por la respuesta!, pensé que el tema no le había posteado porque pensaba que igual era problema de la MAC que al poner la del host victima en ambos lados al mandarlo al servidor local podría fallar pero no, parece que no tiene que ver.

Ya sabía yo que en el foro C++ me ibais a ayudar

Por partes alberto:

Por que pruebas inyectando los paquetes?

Inyecto los paquetes con pcap_sendpacket para que el paquete vuelva a ser recibido por el SO con los nuevos datos y entre en el servidor, usando la mac/ip/puerto, pero no llega a pesar de lanzar el paquete con mi mac destino, mi ip local en la red e ip de localhost, y puerto destino el de la aplicación, quizás llegue pero no se conecta porque creo que debe de salir el ACK del servidor para que se produzca la conexión y comiencen a llegar los datos. Y ese paquete de ACK no veo que salga del servidor con wireshark (poniendo el tcp port src 1000 para verlo claro), luego lo más normal es que no llegue o que sea rechazado.

ya tratase con una petición GET Manual usando Telenet o netcat?

Hice con el navegador, simplemente pongo la IP del servidor y el puerto y conecta sin problemas. El servidor no es problema, o los paquetes no  le llegan o no salen de el por lo que no se produce la conexión.

Como los otros hosts saben que tienen que mandar las peticiones a tu maquina?

Les hago ARP poisoning XD

He visto varios de tus temas y todo apunta a que estas haciendo un proxy transparente al estilo squid o algo similar.

Te lo agradezco que los hayas leído , el squid he estado leyendo ahora y apunta a un servidor proxy HTTP que utiliza una cache, bueno quizás sea algo así.

En definitiva yo hago IP fordward a las máquinas de la red, tienen acceso a todo tipo de servicios IP (y de otros protocolos si me interesa), internet y demás, pero interesado en manipular el tráfico HTTP a través de SSLStrip pues creé este servidor, pero tratando de redirigirle los paquetes TCP que me llegan de los host (con el código que puse) parece que no llegan o algo pongo mal, también he tenido dudas sobre si mandar el paquete al router y que el router me lo mande a mi para que lo trate el SO (poniendo mac del router y la mia), en vez de los que estoy haciendo que es enviarmelo a mi propia mac el paquete que no llega no se porque, aunque dudo que esa sea una solución.

Al volver el paquete atrás he pensado en crear un vector que cada peticion que desvíe al server local guarde IP del servidor con la ip de origen y su puerto en plan (para luego poder recuperar la IP del server con la IP del host y su puerto) de esa manera la recupero y la quito del vector: 192.168.1.43:15673 -> 202.123.12.3

Aunque eso aun no lo he hecho, aún así creo que no funcionaría porque falta algo, quizás el firewall bloquee conexiones entrantes, no sé es complejo, pueden ser muchas cosas, seguiré en ello conforme pueda y tenga tiempo, cualquier ayuda es bienvenida, pues estoy deseando probar el server.

Saludos!.

[AlbertoBSD]

Les hago ARP poisoning XD

Y en la maquina donde tienes tu programa ya viste que si lleguen directament los paquetes a la interfaz de red mediane snort/wireshark/tcpdump ???

Podria ser que los paquetes lleguen mal y la tarjeta de red simplemente los dropee eso o el sistema operativo..

Es complejo y mas cuando estas haciendo ARP poisoning, muchos SO ya no son tan vulnerables a estos ataques.

En lugar de hacer este hack xD

Podrias tratar (Si es que tienes acceso al DHCPD...) en hacer que este mande tambien la informacion del Proxy en la respuesta del Protocolo DHCP para que los hosts se conecten directamente a tu maquina, eso mientras resuelves el problema de Conexión

http://artica-proxy.com/proxy-transparent-mode/
http://smallbusiness.chron.com/set-up-dhcp-provide-proxy-server-50621.html

Saludos

[Kaxperday]

Sí se a lo que te refieres, no es ese el problema, claro que me llegan los paquetes con el poisoning, y les hago ip fordward, incluso tengo una función para ver si la red es vulnerable al poisoning pues por desgracia/fortuna, hay redes que no lo son XD.

En una que no era vulnerable, hice lo que dijistes del DHCP para hacer las pruebas, pero no es el caso, los paquetes llegan correctamente, pero claro, llegan pensando que soy el router, conectandose a google, y la IP de mi servidor local (127.0.0.1) no es la de google así que debo de coger el paquete cambiarle la IP de destino y puerto por el de mi servidor local y mandarmelo a mi mismo con pcap_sendpacket (triste pero no hay otro remedio) para que mi SO lo reciba a través de mi server proxy.

Y luego mismo proceso de vuelta, cuando el proxy responda, responderá con IP origen 127.0.0.1 y puerto de server, y tendré que cambiarlo por la IP del servidor de google (o la que solicitó el host) y puerto 80.

Pero el caso es que algo pasa que no llegan al servidor o no salen de este, con wireshark parece que el servidor no responde cuando me reenvio los paquetes, algo les falla a esos paquetes, ojo pues son SYN al server google o que apunta el host, y los estoy usando para conectar a mi server HTTP debería funcionar no?, es igual para todas las conexiones TCP.

No sé el caso es que no reponde el server, y culpa del server no es porque como digo va bien, basta con probarlo con el navegador y ver como hace el strip (además de suplantar exes)   hehehe

Saludos!!

Edito: No hay manera, he probado a mandar el paquete al router y que del router vuelva a mi y trate de entrar en el servidor, pues nada no funciona no sale respuesta del servidor luego no llega.

La cosa es que no entiendo, para que se produzca conexión con el server tiene que pasar esto:

https://wiki.wireshark.org/TCP_3_way_handshaking

Cuando redirecciono el paquete normalmente es un SYN correcto, pero al redirigirlo algo pasa que no es respondido pues hay varios paquetes destino puerto 10000 (el puerto del server) pero ninguno con source puerto 10000, no está ese SYN/ACK.

¿Porque?, en el firewall tengo permitido el programa, juraría que todo bien, incluido checksums. ¿que pasa? XD.

JEJEJE, "incluido checksums", cuando he puesto esto lo decía un poco como a regañadientes y me he puesto a comprobar el que no se si lo había solucionado.. ¡EL TCP CHECKSUM! y sorpresa persiste con su error de unos pocos bits, así que tendré que areglarlo, sin embargo puedo probar a dejarlo normal y poner el puerto 80 el checksum debería ser correcto a ver si así responde... sigue sin funcionar con el 80 tampoco, probaré a calcular bien el checksum que me sale igual que el normal solo que 16 uds por encima, y veré que tal.

Perfecto he puesto "checksum -= 20;" y acierta la mitad de los tcp checksums Y SI SE HA PRODUCIDO EL SYN/ACK que estaba buscando sin embargo no encamina bien para el host pues falla lo de poner la IP del server, pero eso ya son problemas menores CORRECTO, en unos días lo solucionare, ahora lo tengo que dejar.. XD.

[AlbertoBSD]

En que sistema estas haciendo esto?

Hay que descartar que sea problema del sistema.

Mira este tema tal vez te interese

https://foro.elhacker.net/redes/duda_servidor_ws2012-t453241.0.html

Y soluciones libres esta:
https://www.freebsd.org/doc/handbook/network-routing.html

http://eatingsecurity.blogspot.mx/2013/05/more-ettercap-and-arp-poisoning.html?m=1


https://forums.freebsd.org/threads/54518/

Suerte!!

[Kaxperday]

Traigo una buena noticia, ayer me llevé grata sorpresa al ver que conseguí conectar un host al server!!!!, tras miles de TCP checksums fallidos debieron de alinearse los planetas y conseguir lanzar el handshake y una petición GET, no se volvió a saber nada más (el server la respondió pero no volvieron a llegar del host) primero hay que arreglar el checksum y luego se podrá volver a entrar al tema de la redirección para hacerla más eficiente y e mejor. Sin el TCP checksum bien se fallan mil paquetes y es imposible que haya conexión y más si no es persistente.

Pues uso windows 10 en concreto, si fueran linux serían easy con el iptables XD, primero a ver si soluciono el TCP checksum, ya veo que tu eres linuxero, gracias por las aportaciones y la respuesta, veré a ver si puedo solucionar el checksum XD.

Saludos!!

[Kaxperday]

Problema también solucionado, flipáis como funciona mi sslstrip para windows!!! que bestia, tocan mejorar bastantes cosas porque va lento y a veces saltan errores, pero... la redirección HTTP funciona a la perfección con la idea que usé en mi segundo comentario sobre usar un vector para sacar la dirección de los servidores web en los paquetes de vuelta del servidor local.

Bueno aun así buscaré hacerlo lo más eficiente posible, ahorrando código pero ante todo hacerlo rápido y eficaz, el intercepter-ng una mierd*!! al lado de esto

Como me lo voy a pasar con esto jajaja