| Formulario de acceso |
|---|
| Anuncios |
|---|
|
|
| Violaciones de sistemas (II - Ataques de red) |
|
|
| jueves, 14 de septiembre de 2006 | ||
|
Decimos que se produce un ataque de red cuando éste se lleva a cabo aprovechando vulnerabilidades en los protocolos o descuidos en la seguridad de los servicios relacionados con dichos protocolos. Cinco son los ataques principales que vamos a tratar en este capítulo, pues se entiende que el resto suelen ser variantes más o menos complejas de los primeros. IP Spoofing Veíamos en el capítulo anterior como una usrpación de la IP de una máquina concreta llevaba a crear un ataque de denegación de servicio conocido como SYN Flooding. Cuando dicho ataque tiene como última finalidad, no la saturación o quiebra del sistema atacado, si no el control del mismo, hablamos de un ataque conocido como IP Spoofing o Blind Spoofing. El ataque suele llevarse a cabo mediante el uso de herramientas destinadas exclusivamente a ese fin (como el programa nemesis) que, desde una IP falsificada, tratarán de recibir todos los paquetes de respuesta de la máquina atacada. Como los paquetes enviados desde la máquina objetivo tendrán como destino la IP falsa, deberá existir alguna técnica que haga que los paquetes se redireccionen hacia el lugar correcto. A continuación vamos a ver las dos más usadas:
Como vimos en el capítulo anterior, el método seguido en el ataque se aprovecha de la negociación en tres pasos del protocolo TCP/IP. Pero veamos de forma más detallada cómo se formaría un ataque Blind Spoofing:
Paquete 1: Cliente -> Servidor
Paquete 1: T -> X (Sería A -> X) Obsérvese el ACK del paquete tres (guessed_servernr+1). El host A es incapaz de ver el paquete dos, por lo que no se prodrá usar la secuencia de serie (servernr) para calcular el ACK siguiente (servernr+1) en el tercer paquete, así que tendrá que predecirse de alguna forma (guessed_servernr+1). El problema es que desde la máquina atacante no se sabe si la secuencia creada es la correcta, ya que el paquete no se puede ver, así que se tendrá que predecir el número a partir de algún algoritmo mientras se evita que desde el host T (que no sabe nada a cerca de una conexión desde X) se acabe con la conexión. Para evitar esto ultimo, suele esperarse a que el host T esté off-line, se ataca con un SYN Flood o se idea algo que deshabilite el puerto "hackeado" desde A hasta T.
La única forma de evitar un ataque de estas características es filtrando todo lo que provenga del exterior y quiera hacerse pasar por algo que corresponda con alguna dirección local: -A INPUT -i ppp0 -s 192.168.0.0/16 -j SPOOFED Y tampoco deberíamos olvidar que nuestra máquina puede ser usada como anfitrión en un ataque, así que no sería mala idea filtrar igualmente los paquetes dirigidos al exterior: -A OUTPUT -o ppp0 -s 0.0.0.0/0 -d 192.168.0.0/16 -j REJECT Ataques de fragmentos Los ataques de fragmentos son ataques bastante antiguos que los cortafuegos actuales resuelven sin mayor problema, aunque no por ello vamos a dejar de referenciarlos. En principio hay dos métodos a seguir para formar un ataque de fragmentos: fragmentos cortos y superposición de fragmentos.
El campo que identifica la cabecera IP (ID) tiene un tamaño de 16 bits, por lo que no es dificil que en un momento dado se mezclen varios fragmentos con el mismo IP ID en la red, corrspondiendo cada uno de ellos a un paquete diferente. Según el estándar RFC 791, cuando dos fragmentos IP quedan superpuestos, el segundo ha de sobreescribir al primero. Esto deja las puertas abiertas a una planificación de ataque. Como en el punto anterior, el paquete IP será dividido en dos fragmentos: el primero de 68 bytes que será aceptado por el filtro IP y el segundo, que recogerá la regla principal y que contiene los datos reales de la conexión. El sistema no es capaz de distinguir entre los fragmentos legítimos y los que forman parte del ataque, así que, cuando se produce la unión de los dos fragmentos, el segundo sobreescribirá al primero y formará la figura de una conexión válida para la máquina destino. La conexión queda estabilizada habiéndose saltado el filtro IP. Como hemos explicado al comienzo del apartado, los ataques de fragmentos deberían filtrarse sin muchos problemas desde cualquier cortafuegos medianamente decente y bien configurado. Con iptables podemos definir una regla que descarte cualquier fragmento menor de 40 bytes: -A INPUT -i eth0 -f -m length --length 0:40 -j DROP Se establece el filtro en 40 bytes porque el tamaño mínimo de un paquete TCP serán los 20 bytes de la cabecera IP más los 20 bytes mínimos que tiene el resto del paquete si no se especifican opciones. Se descartan los 8 bytes de fragmento mínimo para evitar la división de la cabecera IP en dos fragmentos, no los datos. Suponemos que el sistema operativo será capaz de tratar cualquier carga del fragmento IP. Secuestro de sesión (Session Hijacking) Aunque una buena política de contraseñas y unos mecanismos de autenticación bien diseñados resistirán adecuadamente un ataque de diccionario, un atacante podría capturar una sesión determinada una vez producida la autenticación y su correspondiente autorización. En principio, el ataque debería quedar restringido a la red física de la máquina atacada, pues es necesario capturar el tráfico entre el atacante y el atacado para llevar a buen fin el secuestro de sesión. Ya hemos visto en varios puntos anteriores cómo una conexión TCP/IP se inicia a través de una negociación en tres pasos (Three Way Handshake). Una vez establecida la conexión, la tranferencia de datos entre dos máquinas quedaría de la siguiente manera (el número de secuencia (SEQ) cambia en función de los datos que se envían (número entre paréntesis) ): Paquete 1: Cliente -> Servidor Para llevar a cabo el ataque, es necesario desincronizar los dos lados de la conexión TCP. Esto se consigue cuando el número de secuencia enviado por el cliente es distinto al esperado por la máquina servidor y viceversa. En el ejemplo anterior, el cliente espera recibir en el paquete número dos la secuencia clientnr + 60. Si esto no sucede así, la secuencia estará desincronizada. Si un atacante desea secuestrar la sesión ya iniciada entre dos máquinas "escuchará" primeramente el tráfico sobre un puerto concreto hasta que se considere que las dos máquinas han iniciado una sesión, momento en el que se procederá a la desincronización de la sesión. Para hacer esto, la tercera máquina (la atacante) crea un paquete tomando la IP de origen de la máquina cliente y el número de secuencia esperado por el servidor. Como el paquete contiene los datos correctos, el servidor lo aceptará y la máquina atacante habrá conseguido el objetivo. Además, como la sesión ya está establecida en un paso anterior, el paquete falso puede contener datos (PSH), así que no será difícil mandar un comenado determinado y ejecutarlo sobre la sesión del servidor. Si la sesión capturada es una sesión, por ejemplo, de telnet, el control sobre la máquina atacada sería casi absoluto. Observemos a continuación cómo se produciría este ataque: Paquete 1: Cliente -> Servidor El paquete falso número cinco es aceptado por el servidor y éste devuelve al cliente los datos esperados, siendo rechazado el paquete original al no cumplir con la secuencia esperada. Sin embargo, el cliente original recibirá un paquete del servidor con el flag ACK activado y un requerimiento de la secuencia correcta. El cliente hará lo propio con el servidor, pues la secuencia recibida esta vez tampoco coincide, y así de forma permanente. Es lo que se conoce como tormenta ACK, un problema que el atacante deberá resolver mediante el uso del ataque con ARP Spoofing. En los apartados anteriores hemos ofrecido ejemplos de reglas basadas en iptables para la prevención de los ataques. En esta ocasión hemos de significar que la mejor forma de prevenir el ataque de este apartado es evitando que el atacante pueda "escuchar" la negociación entre el servidor y el cliente. Para evitar esto, procuraremos que todas nuestras conexiones sean realizadas mediante servidores que permitan la comunicación encriptada entre máquinas. Por ejemplo, si es inevitable tener que usar una consola remota, optaremos por el uso de ssh en vez de telnet, si nuestros datos de sesión va a viajar por un servidor web, cifraremos la conexión mediante SSL, etc. ARP Spoofing La finalidad del ataque consiste en redireccionar el tráfico de una o varias máquinas hacia una máquina controlada por el atacante. El ataque, igual que el anterior, ha de ser relizado sobre la red física de las víctimas. Mediante el ataque a la caché escrita por medio del protocolo ARP (Address Resolution Protocol), que es el encargado de resolver y guardar los vínculos entre una dirección IP y una MAC Ethernet, se tratará de envenenar la información contenida y guardada en la máquina objetivo. Por ejemplo, un atacante puede empezar a enviar paquetes a un servidor con respuestas de negociación que informarán al servidor de que la nueva dirección MAC asociada a la IP de su gateway es la dirección IP del atacante. De esta forma, todo el tráfico enviado a través de esa gateway pasará sin mayor problema por la máquina impostora. Los paquetes seguirán su camino real una vez hayan sido manipulados u observados de forma conveniente. Veamos un ataque de este tipo de forma más detallada. Para ello, vamos a suponer una máquina con la dirección 192.168.1.15, con una gateway en 192.168.1.1 (router.machinex.net) y una máquina atacante con la dirección 192.168.1.35. Hagamos un traceroute hacia la gateway: [~]# traceroute 192.168.1.1 Observemos también la caché ARP: [~]# arp Mediante el programa arpspoof, el atacante generará paquetes ARP que dirigirá hacia la víctima: [~]$ arpspoof -t 192.168.1.15 192.168.1.1 Mediante este comando se confundirá a la máquina atacada y se le suministrará una dirección de gateway que se corresponde con la máquina del atacante. Así, si ahora ejecutaramos el comando arp, quedaría como sigue: [~]# arp Y el comando traceroute nos devolvería lo siguiente: [~]# traceroute 192.168.1.1 Como se puede observar, todo el tráfico correrá ahora por una máquina intermedia antes de pasar por la gateway. Al igual que en el caso anterior, la mejor forma de evitar ataques de este tipo es mediante el cifrado de conexiones. Aunque no hay una técnica infalible que permita evitar la "escucha", el objetivo es tratar de evitar que las conexiones sean facilmente escaneadas y comprometidas. DNS Spoofing El funcionamiento de este ataque es similar al ataque del apartado anterior, solo que esta vez se utilizarán respuestas falsas a peticiones hechas mediante el protocolo de resolución de nombre DNS. El ataque se puede llevar a cabo siguiendo dos patrones bien diferenciados: DNS Spoofing y DNS Cache Poisoning.
Cuando se manda un paquete DNS, éste tiene una cabecera que identifica la relación existente entre las preguntas y las respuestas. La teoría del ataque dice que se habrá de devolver una respuesta falsa a la máquina objetivo antes de que el servidor DNS real alcance a responder. Como ya pasaba en ataques anteriores, alguno de los campos de la cabecera ha de ser predecido. En este caso, se trata del campo ID del usuario solicitante. En una red local, se puede predecirde una manera más o menos sencilla dicho ID "escuchando" el tráfico. Fuera de la red local, la tarea es algo más complicada, aunque no imposible. El atacante puede probar a mandar contra la máquina atacada varios paquetes que comprenden en sus cabeceras todas las posibilidades del campo ID (65535 posibilidades, ya que hablamos de un campo de 16 bits), también podrá mandar unas cientos de peticiones DNS siguiendo un patrón controlado o, como tercera posibilidad, podrá buscar una vulnerabilidad en el propio servidor DNS que haga de la predicción un juego de niños (es común encontrarse servidores DNS que generan IDs predecibles en sistemas basados en versiones de Windows 9x). Se haga como se haga, la respuesta falsa ha de llegar a la máquina de la víctima antes de la respuesta real, por lo que el servidor tendrá que ser bloqueado mediante un ataque, por ejemplo, de denegación de servicio, que le impida responder a las peticiones. Supongamos a continuación un ataque de este tipo suponiendo que el servidor DNS objetivo genera números de secuencia predecibles en incrementos de una unidad:
El envenenamiento de la caché de un servidor DNS tiene como finalidad llenar la memoria del servidor de datos incorrectos que serán usados en beneficio de un atacante concreto. Si el servidor DNS está configurado para usar la caché, la información de las últimas peticiones será guardada en esta memoria durante un tiempo determinado durante el cual no se refrescará la información. El ataque se lleva a cabo de forma similar al anterior, pero esta vez el atacante no necesita "escuchar" tráfico ni mardar paquetes alterados para descubrir el ID de las cabeceras. Sencillamente se limitará a enviar un registro alterado como respuesta a una petición concreta, que redirigirá el nombre de la máquina afectada hacia la dirección de la máquina atacante durante todo el tiempo que dure la información en la caché. Las técnicas habituales para evitar un ataque aprovechando alguna vulnerabilidad del servidor DNS consisten, a parte de una buena configuración del cortafuegos, en una política de restricción de consultas externas al servidor, en la limitación del uso de la caché del servidor, el aislamiento (o enjaulado con chroot) del servidor DNS y el control sobre las actualizaciones y los tiempos de refresco del servidor. Ni que decir tiene que las versiones del software del servidor han de estar totalmente actualizadas a las últimas versiones. Por poner un ejemplo, podemos filtrar las peticiones externas a un servidor DNS local mediante la modificación del fichero de configuración de BIND: acl mired { 10.104.48/24; } // este sería la red de la entidad
Sólo los usuarios registrados pueden escribir comentarios. Powered by AkoComment 2.0! |
||
Todos los nodos de internet deben transmitir, sin que haya fragmentación, paquetes de 68 bytes (cabecera IP con opciones más un fragmento de datos). Esto queda definido en el estándar RFC 791. El protocolo IP brinda un mecanismo que permite fragmentar los paquetes, así que el ataque consistirá en solicitar una conexión fragmentada en dos paquetes IP (Cabecera y petición con | < Anterior | Siguiente > |
|---|
