Inyectar un paquete TCP en una conexión existente

El escenario "todas las probabilidades en atacantes favorecen"

El atacante está en la misma red que la víctima, puede monitorear la red y no solo puede escuchar la conexión, sino también interferir con ella. Este es el caso cuando el atacante puede ejecutar un ataque de ARP Spoofing contra la víctima.

En este caso, el ataque es posible y trivial contra un protocolo no cifrado como HTTP. El atacante puede leer cada paquete de la víctima y el servidor, y puede alterar las cosas cuando lo desee. Puede decirle a H que es la puerta de enlace y modificar los paquetes que van al servidor. Como tiene todo el paquete en sus manos, conoce los Números de secuencia de TCP, todas las banderas, opciones y todo lo demás. Esto se llama El hombre en el ataque medio .

Atacante en otra red

Es más difícil que adivinar un número de 32 bits. En este caso, MH debe adivinar el número de secuencia correcto (un número de 32 bits) Y crear el paquete inyectado con las marcas correctas Y las opciones correctas Y haga que su paquete llegue al servidor antes que el paquete de H . Como H y MH no están en la misma red, MH tendrá que emplear IP spoofing , y eso es casi imposible de ejecutar. Como muchos enrutadores tienen Filtrado de egreso , descartarán los paquetes con una dirección de origen falsificada.

Protocolos cifrados

Las mismas restricciones que los otros escenarios, pero con una complicación: el atacante debe falsificar un paquete encriptado, adivinar el conjunto de códigos cifrados, todos los parámetros de encriptación, el relleno, IV, la suma de comprobación, y hacer que se combine sin problemas con el próximo paquete que viene de el cliente ... No, no es posible inyectar datos en un protocolo cifrado y esperar que el servidor o el cliente lo acepte.

  

El servidor puede descubrir que un paquete es malicioso porque el contenido no se descifra para corregir el formulario.

No, el servidor encuentra el paquete malintencionado porque el número de secuencia de TCP es incorrecto, o es correcto pero está atrasado (el paquete más nuevo ya llegó), o muy por encima del número esperado más la ventana de transmisión. Si todos esos valores casi imposibles de falsificar son correctos, y se emplea el cifrado, el servidor descartará el paquete porque ni siquiera se parece remotamente a uno válido.

TCP es un protocolo complejo, por lo que es realmente difícil de omitir. Además, agregue un protocolo aún más complejo (TLS / SSL) y tendrá una tarea imposible al intentar inyectar paquetes falsificados en la comunicación.