Buenas,

Me ha parecido un proyecto interesante a tratar, la verdad que la idea de warcry no es mala y sería una buena solución, usando una raspberry si consigues conectar la rasperry al router y de ahí a tu proxy externo no será difícil traer los paquetes de vuelta, y claro para conectarte a la raspberry puedes hacer un MITM (que no siempre funciona) aunque lo mejor sería hacerlo como dice warcry haciendo que la smart TV se conecte a tu raspberry configurando su IP..., aunque eso sí parece más complejo que usar un simple arpspoofing.

Una vez que hayas conseguido conectar tu smart TV  tu raspberry simplemente activando el fordwarding de interfaces y usando iptables para desviar el tráfico de la smart TV hacia el servidor proxy de smart TV debería funcionar, iptables se encargaría de realizar el trabajo de mandar datos al proxy y traerselos de vuelta (comeback) a la smart TV, es una herramienta realmente potente.

Un saludo.

De todas maneras si es un caso en el que necesitas levantar un servidor la manera de que no te salga el aviso (suponiendo que tu programa tenga permisos de administrador) sería crearte una excepción para el firewall y luego levantar el server, supongo que en esa situación no pediría nada, los permisos de administrador casi siempre puedes escalarlos, yo tengo pensado hacerlo en C++ pero aquí tienes un comando para añadir una excepción al firewall:


Aunque bueno lo mejor es evitar hacer estas cosas así como las alertas, para ello recomiendo usar protocolos a través de los cuales mandar tus datos encapsulados (tunneling), actuar como cliente, usar TCP hole punching (preguntar a Kubox XD) que seguramente también valdría... o no complicarte mucho y directamente hacer la excepción pero claro para ello necesitas permisos de administrador, en mi caso ya los tendría así que me valdría.

Saludos.

Buenas Alberto,

Pues me parece que para windows la mejor opcion para lo que buscas es esa, dando por hecho que para procesar un cliente es mejor crear un thread que un proceso. Yo trabajo con C++ y en su lugar lo hago con std::thread que lo veo mas sencillo y maleable, din embargo para C no me viene ahora a la cabeza otra funcion para crear threads que esa,te recomendaría pasar a C++ XD.

Te dejo aquí un ejemplo de mi thread servidor sslstrip en C++:

void SSLStrip::Run(std::string serverIP, UINT serverPort)
{
	//CookieCleaner::GetInstance()->SetEnabled(TRUE);
	WSADATA wsa;
	SOCKET serverSocket;
	sockaddr_in serverAddr;
 
	WSAStartup(MAKEWORD(2, 0), &wsa);
	memset(&serverAddr, 0, sizeof(serverAddr));
 
	if ((serverSocket = socket(AF_INET, SOCK_STREAM, 0)) != INVALID_SOCKET)
	{
		serverAddr.sin_family = AF_INET;
		serverAddr.sin_port = htons(serverPort);
		serverAddr.sin_addr.s_addr = inet_addr(serverIP.c_str());
 
		if (::bind(serverSocket, (sockaddr*)&serverAddr, sizeof(serverAddr)) != SOCKET_ERROR)
		{
			if (listen(serverSocket, MAXIMUM_SNIFFER_VICTIMS) != SOCKET_ERROR)
			{
				SOCKET victimSocket;
				sockaddr_in victimAddr;
				victimAddr.sin_family = AF_INET;
				INT len = sizeof(victimAddr);
 
				while (status != DISABLE_SSLSTRIP)
				{
					victimSocket = accept(serverSocket, (sockaddr*)&victimAddr, &len);
 
					if (victimSocket != INVALID_SOCKET)
					{
						std::thread t(HTTPSession, victimSocket, inet_ntoa(victimAddr.sin_addr), status);
						t.detach();
					}
				}
			}
		}
		closesocket(serverSocket);
	}
 
	WSACleanup();
}
 

Ahora que me fijo creo que pondré un if en WSAStartup por si da error que no haga el bloque y meteré el WSACleanup al final del bloque del if.

Un saludo y animo.

¿Y como podemos evitarlo? ni que fuera algo malo XD,

Mientras el DNS se resuelva con UDP podemos estar tranquilos de que siempre se podrán acceder a esos datos XD, y sino desde una orden judicial de USA si es que hace falta eso

Saludos.

Buenas,

Necesito cambiar el timestamp, el escalado de ventana que se producen en el negociado del handshake al producirse una conexión TCP desde windows, en función de la red que nos encontremos el SO nos da unos valores u otros, ahora bien yo uso un programa que hace redirecciónes TCP y el SO no cuenta con esa latencia por lo que en redes demasiado rápidas el programa no funciona como debería ya que la capa TCP desecha los paquetes que llegan fuera de tiempo que son provenientes de mi fordward TCP (Mi programa servidor da conexiones con timestamp muy bajo y escalado de ventana muy alto en redes rápidas).

¿Que debería de cambiar en la configuración TCP para que no se produjeran problemas de este tipo?, el timestamp sino me equivoco es como un temporizador por lo que puede influir y el escalado de ventana desconozco si puede provocar el error, pero si una red es muy rápida quizás iría más rápido que lo que pueda soportar el programa y se ignoren paquetes o no sé, las posibilidades son muchas, seguiré mirando TCP, pues quizás no sea lo único que haya que tocar para que todo vaya fluido.

Y me gustaría saber si es posible hacerlo para un solo socket (el del servidor) haciendo que las conexiones que produzca ese socket tengan esa configuración TCP pero sin afectar a los demás programas.

Saludos y gracias.

Edito: He comparado con wireshark los SYNs de una red muy rápida y una normal o lenta, y la diferencia es que el de la rápida lleva el en un FLAG de SYN timestamps que son temporizadores TCP, creo que son los responsables de que en redes rápidas se colapse mi sslstrip, así pues he probado con "netsh int tcp set global timestamps=disabled" y claro funciona PERO solo en la comunicación de el equipo donde se ejecuta con el server, es decir las víctimas que se conectan a mi llevan en el SYN el timestamp al ser una red de gran velocidad, lo que quiero es mandarlas un SYN/ACK desactivando el timestamp, y con este comando parece que no se puede, espero que haya otra forma porque sino mal vamos.

En fín necesito que mi servidor de windows al aceptar conexiónes SYN con timestamp reponda con timestamp nulo desactivando así el timestamp durante todo el proceso de conexión TCP, hasta ahora solo he visto desactivarlo como cliente es decir que windows mande SYNs sin timestamp, pero lo que quiero es que al recibirlos como servidor los desactive en el SYN/ACK, y eso no he encontrado como, si alguien sabe estaría bien que lo pusiera, gracias.

Edicion delicatesse: Al final tuve una ingeniosa idea de modificar los SYN entrantes de las víctimas que tuvieran el campo del timestamp y eliminarlo, la respuesta fue satisfactoria la conexión servidor cliente se producía sin timestamps y se podían mandar todos los datos sin problemas de corte de conexión, funcionaba de la manera que el cliente mandaba un SYN con timestamp y yo le mando al server un SYN sin timestamp el server responde sin timestamp y la víctima lo acata, gg.

Eso sí el server tiene un serio problema con la velocidad y con al carga de algunas páginas que va a costar corregirlo.

Saludos.

Buenas,

Según veo quieres validar solo la request line y solo para el caso de GET, entonces me parece que la validación puede considerarse correcta, aquí los límites los pones tu si quieres un server de calidad asegurate de hacer un buen control de errores, sino me equivoco todos los HTTP request (incluido el GET por supuesto) tienen en su request line 3 partes: el método, la uri, y la versión de protocolo HTTP empleado, si tienen más o menos de 3 deberías considerar la request como errónea.

Para un GET no veo necesario validar más, ahora deberías de pensar en validar los headers también, e implementar los métodos que deeses y que debes de mostrar cuando te envíen un HTTP OPTIONS.

También cuidado al programar el GET pues por lo general sirve archivos, y pueden hacer algo como "GET ../../passwords.txt HTTP 1.1" y puedan acceder a directorios anteriores que el de la carpeta root del servidor, para ello debes controlar que la uri no empiece con "..", pero eso ya sería más adelante cuando vayas a servir el archivo.

Ánimo con el proyecto, me parece interesante.

Un saludo.

No es que no envíe bien los datos, es que estás mandando los datos que te pide de manera incompleta, como dije te falta enviar parametros al post que son explícitamente "lt", "execution", "_eventId", y "submit" además de "username" y "password".

Además debes enviarlos con el contenido que tienen en su campo value como "lt", "execution" y "_eventId", que en el caso de los 2 primeros el valor no es siempre el mismo por lo que deberás de cargar la página recoger el valor y las cookies que te envía (aunque puede que no sean necesarias pero lo más probable es que sí) y ya con todo eso lanzarte a iniciar sesión con el POST una vez tengas todos esos datos de los que te hablo listos.

Saludos y suerte.

Hola mester, pues verás te faltan más variables a enviar en el FORM aparte de username y password, en la url te recomiendo usar https://autentica.cpd.ua.es/cas/login que vale por igual y quizás evites futuros errores.

Respecto a que no consigues que envie los datos por el POST ¿a qué te refieres? ¿a que no recibes respuesta? ¿que te da error al enviar los datos al server? ¿o que la respuesta que recibes no es la esperada (que no consigues iniciar sesión vaya)?.

Saludos

Bueno desconozco esa aplicación, sin embargo hay más ataques MITM aparte del ARP spoofing, si no mal creo hay hasta 6 tipos de ataques MITM, y el ARP spoofing es solo uno de ellos aunque es el más usado y eficaz.

Tu mismo decidirás, al final me da a mi que le acabas sniffando el tráfico tu a él antes que el a ti XD.

Saludos.

Buenas,

Hay routers que bloquean los ataques MITM mediante filtrado de los protocolos que propician el ataque, sin embargo la mayoría son vulnerables y aún así los que están protegidos estoy casi seguro que son vulnerables a otros ataques MITM más allá de los comunes.

Mal rollo vas a tener en el piso si crees que tu compañero te sniffa el tráfico XD, te recomiendo cargar las paginas siempre con https y bueno si tienes que cargar una http y loguearte quizás te venga bien saber si estás siendo víctima o no, para ello toma la dirección MAC del router de vuestro piso, cuando tu compañero esté desconectado (en windows abre la CMD y escribe "ARP -A") la primera dirección MAC que te aparece es la del router apuntala en un papel, esa dirección es única.

Ahora bien cada vez que te conectes a internet y tengas sospechas de que tu amigo está sniffandote el tráfico abres la CMD y lo vuelves a escribir, si la MAC es la misma no hay problema si es diferente está sniffandote el tráfico.

Saludos y suerte.