Buenas, en este artículo voy a escribir acerca de vulnerabilidades propias del modelo TCP/IP.
Recordemos que el modelo TCP/IP es un modelo de 5 capas: Capa de Aplicación, Capa de Transporte, Capa de Red, Capa de Enlace y la Capa Física.
La capa de aplicación utiliza los servicios de la capa de transporte, la capa de transporte los servicios de la capa de red, la de red los de la capa de enlace, y la capa de enlace los de la capa física.
Empezaré por vulnerabilidades propias de la capa de transporte, capa cuya función es lograr comunicar procesos de distintos hosts. En esta capa funcionan, principalmente, dos protocolos: TCP y UDP. A los mensajes enviados en esta capa se les denomina segmentos.
TCP, a diferencia de UDP, fue diseñado orientado a conexíón, esto significa que previo al envío de mensajes se debe establecer una conexión entre los dos procesos que se comunicarán. Para ello, cuando un proceso corriendo en una IP y en un puerto, se quiere conectar con otro proceso en otra IP y puerto, le envía un segmento con una flag conocida como SYN, la cual se utiliza para iniciar una conexión. En ese momento, el proceso servidor (el que recibe el intento de conexión), almacena la información necesaria para establecer una conexión con el proceso cliente (principalmente IP del cliente, puerto y el número de secuencia inicial) y le envía al cliente un segmento con la flag SYN ACK. Cuando el cliente recibe dicho segmento, almacena la información del servidor (principalmente el número de secuencia del proceso servidor) y responde con un segmento ACK.
Con estos tres segmentos (dos desde el cliente al servidor, y uno del servidor al cliente) queda establecida la conexión TCP. El problema es, ¿qué pasa si el cliente no envía el último ACK? En ese caso el servidor no "crea" la conexión, pero aún así tiene en su memoria la IP, el puerto y el número de secuencia del cliente. Un ataque que se aprovecha de esto se conoce como SYN flooding.
Los ataques de SYN flooding se basan en que el atacante le envía muchos segmentos SYN a un servidor, pero nunca un ACK, logrando que el servidor dé un error de memoria y, por lo tanto, quede fuera de servicio.
Una contramedida muy simple es que el servidor no guarde en memoria mas de una cierta cantidad de SYN's de una misma IP. Esto funcionaría si el atacante enviara segmentos con una misma IP pero, como vamos a ver más adelante, el atacante puede enviar segmentos TCP con otra IP que no sea la suya.
Pero, si el atacante puede enviar segmentos TCP con otra IP, ¿qué le impide hacerse pasar por mi en una conexión que tengo establecida?
Esto es una pregunta interesante, imaginemos que me estoy comunicando con otro proceso enviando segmentos TCP, ¿el atacante podría enviarle también segmentos TCP a ese proceso haciéndose pasar por mi?
Esto no es tan así, debido al ya mencionado número de secuencia. Para hacerse pasar por un cliente en una conexión establecida, el atacante debe enviar segmentos TCP al proceso servidor con la IP del cliente, el puerto del cliente (no son dificiles de obtener) pero también el número de secuencia del cliente, el cual no es sencillo de obtener si el cliente utiliza un número de secuencia aleatorio cada vez que comienza una conexión.
Ahora, ¿si UDP no utiliza números de secuencia, me puedo hacer pasar por otro proceso enviando segmentos UDP? La respuesta es sí.
Esto de hacerse pasar por otro (en este caso, otro proceso), se conoce como spoofing. El tema es que hacerse pasar por otro proceso no sirve de mucho, a no ser que dicho proceso y el servidor tengan una conexión abierta (el proceso servidor podría pedirle al proceso cliente que se identifique con alguna password, pero en una conexión abierta el cliente ya dió la password por lo tanto si me hago pasar por él, cuando esa conexión está abierta, sí puedo sacar ventaja), para lo cual necesitaría predecir el número de secuencia, que normalmente no es sencillo.
Ahora, ¿cómo es eso que puedo enviar segmentos utilizando la IP de otra pc?
Esto es un problema de diseño del protocolo IP, el cuál funciona en la capa de red, que es la capa encargada de lograr comunicar distintos hosts. Observemos que cada host puede tener mas de un proceso corriendo, no es lo mismo comunicar hosts que comunicar procesos. Los mensajes intercambiados en la capa de red son llamados datagramas.
Es importante entender bien el concepto de capas, y como cada una utiliza los servicios de la capa inferior. La capa de transporte asume que la capa de red sabe comunicar hosts, entonces para enviar un mensaje de un proceso a otro, crea un segmento con el puerto de origen, el puerto de destino y dicho mensaje. Luego, le dice a la capa de red: "Envía este segmento desde esta IP hasta esta otra IP" (comunicación entre hosts). Entonces la capa de red crea un datagrama, con la IP de origen, la IP de destino y en su payload lleva el segmento creado por la capa de transporte.
Volviendo al problema original, el protocolo IP no fue pensado para evitar spoofing. Cada host simplemente puede enviar un datagrama hacia otra dirección IP, y en el "campo" que indica la dirección de origen, poner otra IP que no sea la suya. Esto es muy importante, no se puede garantizar una relación IP <-> máquina, ni siquiera una relación IP <-> empresa.
IPSec soluciona este problema (hablaré de esto en próximas publicaciones) pero, aunque es obligatorio de implementar en IPv6, NO es obligatorio utilizarlo (una lástima).
Siguiendo la lógica anterior, la capa de red recibe un segmento y entonces crea un datagrama con la IP de origen, IP de destino y el segmento en su payload.
¿Qué hace con dicho datagrama?, en nuestras casas normalmente se lo enviamos al gateway (ese router que nos conecta con Internet), pero básicamente se lo enviamos a un dispositivo de capa 3 (router o host) al cual estamos conectados directamente (en la misma LAN). ¿Cómo sabemos a cual dispositivo de capa 3? utilizando tablas de ruteo, que nos indican a qué dispositivo enviarle el datagrama para que pueda llegar a su destino.
Las tablas de ruteo nos dicen a qué IP le tenemos que enviar el datagrama que tenemos, esa IP no es la misma que la IP de destino, es la IP de lo que se llama el next-hop: un dispositivo al cual estamos conectados físicamente (por un cable, o por wifi), y que sabe cómo llegar a la IP destino del datagrama.
Resumiendo, tenemos un datagrama con la IP de origen, IP de destino, y se lo tenemos que enviar a otra dirección IP, ¿cómo hacemos?. La capa inferior (capa de enlace), provee los servicios para comunicar dos equipos en la misma LAN utilizando las direcciones MAC en lugar de las direcciones IP. Por lo tanto, sólo nos falta la dirección MAC que corresponde a la dirección IP a la cual le vamos a enviar el datagrama, para eso es que se utiliza ARP (En IPv4). ARP es un protocolo que actualiza la tabla ARP local (tabla que asocia IP's con MAC's).
Básicamente ARP funciona de la siguiente manera:
1) Tengo una IP de la cual no conozco su MAC, envío una ARP QUERY de dicha IP a todos los dispositivos de la LAN (la precondición es que dicha IP sea de algún dispositivo de la red local)
2) Si me llega una ARP QUERY preguntando por una IP que es mia, le envío un ARP REPLY al dispositivo que preguntó, con mi MAC y mi IP
3) Cuando me llega el ARP REPLY actualizo mi tabla ARP
El problema es que históricamente se ha implementado de la siguiente manera:
1) Tengo una IP de la cual no conozco su MAC, envío una ARP QUERY de dicha IP a todos los dispositivos de la LAN (la precondición es que dicha IP sea de algún dispositivo de la red local)
2) Si me llega una ARP QUERY preguntando por una IP que es la mia, le envío un ARP REPLY a TODOS los dispositivos de la LAN, con mi MAC y mi IP
3) Si me llega un ARP REPLY, aunque no haya hecho yo el ARP QUERY, aprovecho y actualizo mi tabla ARP
Otra vez hay problemas de spoofing, cualquier atacante puede enviar continuamente ARP REPLIES, con la IP de otro y su MAC, logrando que los dispositivos de su LAN contengan en sus tablas ARP la asociación (IP - MAC) incorrecta.
Observación: Las entradas de las tablas ARP tienen un tiempo de validez, cada tanto se "olvidan", por eso el atacante tiene que realizar continuamente ARP REPLIES.
¿Consecuenicas?
Algo tan obvio como Man-In-The-Middle o incluso denegación de servicio. ¿Denegación de servicio? Sí, observemos que todo datagrama IP que fuera para el dispositivo victima (el que tiene en realidad dicha IP), me va a llegar a mí, por lo tanto pierde conexión a internet.
¿Soluciones?
1) Configurar las tablas ARP estáticas en la LAN
2) Cifrar las capas superiores: Si se cifran las capas superiores todo lo que el atacante reciba (que en realidad era para mi), no lo va a poder entender porque está cifrado. No soluciona la denegación de servicio.
3) Algunos dispositivos, al recibir un ARP REPLY, si tenían en su tabla ARP otra MAC asociada a dicha IP, le envían una consulta a la MAC vieja
Cualquier pregunta a las órdenes
He intentado no entrar en detalles muy técnicos propios del modelo TCP/IP, pero cualquier duda no tengo problemas en responder
Saludos
