ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.


Analizadores de Paquetes (“Sniffers”)

Los protocolos se especifican sobre papel para dar una serie de descripciones sobre como deben de funcionar, como deben de ser implementados, sus propósitos… pero es evidente que su uso no solo posee el ámbito de lo teórico. Teorizar sobre el papel o crear implementaciones de los protocolos es fácilen comparación de las implementaciones prácticas, pero sobre todo a la hora de verificar su correcto funcionamiento. Al igual que en programación disponemos de depuradores paso a paso para ir comprobando el correcto comportamiento de un algoritmo, los protocolos de red necesitan de una herramienta similar que puedan comprobarlos, verificarlos… a fin de cuenta observarlos. De esta necesidad nacen los Analizadores de Paquetes. ¿Qué son? Software que son capaces generalmente de capturar desde paquetes (nivel 3 en modelo OSI) hasta frames (nivel 1 y 2 del modelo OSI), y posteriormente analizarlos. Para que esto sea posible es común que el sistema requiera algún driver especial para poder ser capaz de capturar paquetes “raw” por la interfaz de red, generalmente, Ethernet. El propósito es evidente, gracias a estos analizadores de paquetes podemos ver de forma simple todo lo que circula por nuestra interfaz de red.

En realidad, aunque “Sniffers” sea el tema principal de este artículo, posiblemente lo que son los sniffers en sí mismos sea el capítulo más corto de todo ello, puesto que estos no son sino las orejas. Es por ello que para comprender bien su funcionamiento era necesario conocer al menos los protocolos más usados a día de hoy, pues básicamente es lo que va a mostrarnos un Sniffer. El como interpretemos dichos datos tendrá en gran medida relación a lo bien que conozcamos los protocolos inferiores que tenemos. Recordemos que el modelo TCP/IP o el modelo OSI son modelos jerárquicos!! una página web usando el protocolo HTTP se encapsula dentro del protocolo de transporte TCP, y este a su vez dentro de IP, y este en un frame Ethernet… El Sniffer puede mostrarnos incluso de forma simple cada uno de estos protocolos, pero la mejor forma de comprender la información que nos muestra es sin duda alguna conociendo los protocolos que se han usado.

Aunque los analizadores/capturadores de paquetes nacieron por la necesidad de analizar los protocolos e implementaciones de estos, a día de hoy su valor para asegurar cualquier infraestructura de red es inestimable. Un Analizador de paquetes a fin de cuentas es capaz de monitorizar todo el tráfico entrante y saliente de un mismo equipo (y incluso todo el tráfico que circula por una red), lo que permite desde detectar problemas en cualquier nodo de la red, detectar ataques desde esta o desde fuera y por supuesto espiar cualquier tipo de información que se transfiera por dicha red. “Sniffer” es el término coloquial para referirnos a un capturador de paquetes, su traducción sería algo así como “Husmeador” u “Olfateador”. Sin embargo la experiencia nos dice que por regla general el término Sniffer se suele relegar al ámbito Hacker o Underground, mientras que en la literatura formal o dentro de la seguridad es más común usar el término “Analizador/Capturador de paquetes”. Como ya se ha visto, aquí generalmente usaremos el término Sniffer, simplemente porque es más corto.

  • Capturando y analizando paquetes
  • Modificando el tráfico a nuestra voluntad: OGame -> OGame Automatizer
  • Envenenamientos: ARP y DNS
  • Certificados y Túneles
  • Un apunte sobre WIFI



Capturando y analizando paquetes

Dada la gran versatilidad y potencial de los analizadores de red, estos jamás pueden pasar desapercibidos para nadie, ni siquiera para usuarios novatos dentro de la informática, los cuales tendrían que conocer al menos su existencia, sus virtudes y sus usos. A fin de cuenta es la única manera de que los usuarios puedan tener cierto grado de seguridad. Con los Sniffers se aplica una de las afirmaciones más comunes de la informática: “Toda la información que pueda maneja el PC, puedes ponerla a tu disposición para el fin que sea por algún medio, pudiendo simplemente desde capturar dicha información a manipularla a tu antojo”. Esto quiere decir que no podemos ver el PC como una caja negra, sino como una caja transparente a la que podemos meter la mano cuando deseemos.

Que un usuario pueda ser capaz de visualizar todo el tráfico que circula por su equipo puede ser de por sí un gran problema de seguridad, pero aun es peor si dicho usuario puede de forma simple visualizar absolutamente todo el tráfico de su red. Pero la constitución de Internet se realizó pensando en su versatilidad y facilidad de uso, no en su seguridad, y cualquier dato enviado o recibido por nuestra red, ya sea de forma interna (una LAN) o externa (Internet), puede ser fácilmente leído si este es enviado en lo que llamamos “texto plano”, lo cual es lo que se realiza el 90% de las veces. Todo el tráfico que no se esté cifrando con algún protocolo o sistema punto a punto, es altamente propenso a ser interceptado e interpretado, y en consecuencia, si así se desea, a ser modificado. Por desgracia la seguridad no es algo en lo que se ponga mucho empeño por regla general por parte de las compañías, y aunque existen método casi inexpugnables en cuanto a seguridad se refiere, estos solo solemos encontrarlos en sitios puntuales. Es decir, la tecnología para ello existe, pero no se usa como se debería ni cuando se debería.

El Modelo TCP/IP es muy simple de manejar, y si los datos se envían siempre de determinada manera, en algún punto el hardware y el software interactúan de tal modo que es posible mediante drivers de sistema o aplicaciones específicas, usar el adaptador de red en lo que llamamos un “monitor”. Dicho de otro modo, podemos inducir en el adaptador de red un modo de funcionamiento tal que pueda “escuchar” todo lo que pasa a través de él, es decir, capturar todo el tráfico de red que llegue hasta él, ya sea tráfico entrante o saliente. Esta es la razón por la que en prácticamente cualquier sistema operativo, se requiere ante todo este driver que permite leer los frames directamente desde el adaptador de red. Nosotros en todo momento nos referiremos a adaptadores de red tipo Ethernet, aunque esto es extrapolable a cualquier tipo de adaptador de red, con más o menos matices por supuesto (WIFI, Fibra, Token-Ring…).

No hay que irse muy atrás el tiempo cuando esto no era algo tan simple. Para que un sistema pueda acceder a estos frames, el mismo hardware (el adaptador de red) como los drivers del sistema que lo gobierna, deben de estar pensados para ello. Del mismo modo el OS que está por encima debe de ser capaz de recibir dichos datos. Técnicamente esto es tarea del capturador de paquetes, mientras que el analizador de paquetes no es más que un software que recibe e interpreta dichos datos. En Windows 7, ya se incorporan mecanismos internos para poder realizar las labores de captura, pero es más común el uso de las librerías y drivers de sistema WinPcap, y será lo que usemos. Por otro lado, WireShark hará el papel de Analizador. Importante: El Sniffer no podrá en ningún momento ser capaz de capturar aquellos bits/bytes que sean filtrados o descargados directamente por el Hardware!! El ejemplo más común de ello (como ya veremos) es que en los frames Ethernet no es posible capturar los bytes del preámbulo o los Bytes interframes. Del mismo modo es común no poder visualizar los 4 Bytes del FCS (El CRC del protocolo Ethernet. Esto en WIFI tiene mayor relevancia, puesto que es complicado poder capturar los llamados Frames de control.

 

Bien, hemos dicho que un capturador de paquetes será capaz de leer todo el tráfico de red que circule por nuestro adaptador de red. Esto nos garantiza que el 100% de todo el tráfico enviado por nuestro sistema al exterior y todo el tráfico enviado a nuestro sistema (ya sea enviado desde el exterior o desde nuestro propio sistema a sí mismo) podrá ser recogido. Pero si se entendieron los capítulos anteriores, los datos enviados desde nuestro sistema o enviados específicamente a nuestro sistema, no son los únicos datos que pueden llegar a nuestra interfaz de red. Un ejemplo sencillo a esto sería cualquier tráfico que sea enviado por broadcast o multicast, que es tráfico enviado no a un host concreto, sino a todos los host de una red o a un conjunto de hosts de esta. Es decir, que todo el tráfico que sea enviado a broadcast o multidifusión podría ser igualmente capturado por nuestro adaptador (por ejemplo tráfico generado por DHCP o ARP).

Es necesario llegado a ese punto diferenciar lo que es que un dato sea enviado a un host concreto de forma lógica o de forma física. Es fácil, imaginar que dos equipos se conectan uno al otro por un cable de red. Independientemente de la IP o configuración de red de cada uno, si uno de los equipos coloca un dato en la linea de recepción del otro, el dato llegará a la interfaz de red del otro equipo, con completa independencia que el equipo destino coincida con los parámetros de destino que envió el emisor. Es decir, que en este caso da igual que el Emisor dijese que dicho paquete estaba destinado a la IP 10.0.0.2, porque al tener ambos una unión física directa, aunque el destino tenga la IP 10.0.0.100 este recibirá el paquete en su interfaz de red. La cuestión es que hace la interfaz de red cuando recibe un paquete que no está designado de forma lógica para él. Y lo habitual es que el adaptador de red mismo simplemente descarte el paquete.

Pues bien, ahora no pensemos en un equipo conectado a otro por un cable, sino una red de 20 equipos, todos ellos conectados mediante un Hub. Los Hub, como se vio en su momento, son meros repetidores, une cada linea de envío de datos de cada hosts conectado a dicho hub, a todas las lineas de recepción de datos de cada uno de los hosts conectados al hub. Es decir, si el equipo 1 envía cualquier dato, con completa independencia de quien sea el destinatario, dicho paquete llegará al 100% de los adaptadores de red de todos los equipos. Dichos adaptadores de red comprobarán entonces el destino de dichos datos, y lo descartarán si no son para ellos. Pero si el adaptador de red nos lo permitiese y el software/driver también, bastaría con dar la orden al adaptador de red que dejase de ignorar el tráfico que no fuese dirigido hacia él, de modo que el capturador de paquetes sería capaz de capturar ya no solo el 100% del tráfico propio, sino el 100% del tráfico de TODA la red. Dicha orden que se le da al sistema se  denomina Modo Promiscuo.

Por suerte, podemos decir que los Hubs pasaron a la historia hace años ya (aun se encuentran en muchos lugares). Recordemos que la forma más habitual de expandir una red es por medios de Hubs y también por medio de conmutadores o Switchs. ¿Que panorama nos encontramos ante redes constituidas por Swichs? En este caso el panorama es muy diferente, los datos son enviados físicamente a sus destinatarios. Es decir, en una red de 20 equipos conectados por medio de un Switch, si el equipo 1 envía un dato al equipo 10, podemos verlo como si el Switch conectase a ambos equipos de forma única, con lo que el resto de equipos jamás sabrán siquiera que el equipo 1 y el 10 están comunicando datos. En este caso el tráfico generado en nuestra red que no esté destinado a nuestro equipo (o no sea procedente de este) quedaría completamente inalcanzable para nosotros… ¿o tal vez podamos hacer algo al respecto? (Lo veremos un poco más adelante)

Dado que los Hubs están a día de hoy en desuso y que aun no vamos a entrar en las opciones de las que disponemos en redes conmutadas (Switchs), ¿que valor puede tener capturar/analizar nuestro propio tráfico? Bueno, del mismo modo que aun cuando nuestro cuerpo es nuestro y sabemos que tenemos sangre, es necesario realizar analíticas de sangre cuando algo no funciona bien en nuestro organismo, o simplemente queremos aprender un poco más de nuesetro metabolismo, funcionamiento… aquí sucede lo mismo. Dado que la mayoría del tráfico generado por nosotros (entrante o saliente) suele ser tráfico HTTP (para Internet), el uso más común quizás sea usar estos analizadores para ver información de interés que de otro modo escaparía a nuestros ojos. Esto lo vimos más o menos cuando hablamos de HTTP Sniffing o HTTP  Headers Sniffing. Evidentemente esto es solo uno de los infinitos usos que puede tener esta técnica. Desde mi punto de vista, es una de las técnicas/herramientas más interesante que existe de cara al aprendizaje, comprensión e incluso defensa dentro de una red, el valor de poder visualizar exactamente cada uno de los paquetes que envía o llega a nuestro PC, no tiene precio: Detección de malware que están enviando datos a host desconocidos, mal funcionamiento de nuestra red, problemas de nuestro router, ataques hacia nuestro PC/red que proviene de nuestra propia red o desde el exterior, estudio/ análisis y/o creación de protocolos de red…

Por desgracia, sería imposible escribir un artículo o un libro con cada uno de los infinitos ejemplos en los cuales un Sniffer no solo es recomendado sino obligado. Aquí, tan solo puedo pretender exponer la idea, su funcionamiento y algunos ejemplos prácticos con la intención de que cada cual que se interese por ello tenga lo suficiente para continuar por ellos mismos.  Para no complicarnos, y dado que el Sniffing puede ser desde  tremendamente complejo (por filtros, análisis…), todos los ejemplos que veremos serán usando Windows 7  y Wireshark 1.4.2, aunque del mismo modo podía haberlo realizado con Linux (que no se enfaden mis amigos Linuxeros).

Por lo general, un Sniffer no es discriminatorio. Es decir, en teoría es capaz de capturar absolutamente TODO lo que circula por el adaptador de red que se esté monitorizando. Somos nosotros como usuarios los que por comodidad indicamos al software que deseamos realmente capturar u observar. Es evidente, generalmente buscamos frames o paquetes concretos, tráfico que nos llega de de un host concreto o el tráfico de un terminado protocolo. Es por ello que cuando se desea estudiar o buscar algún frame o paquete concreto, es bueno intentar evitar el mayor tráfico posible. Wireshark no solo es un mero Sniffer, sino que posee una colección ingente de diseccionadores de protocolos, es decir, una base de datos enorme con la estructura de dichos protocolos. Recordemos que siempre estaremos dentro del modelo OSI/TCPIP, y que este modelo está completamente jerarquizado, en el que un nivel se encapsula dentro de otro para acabar siendo todo un simple flujo de datos. Imaginar por tanto que en el nivel de enlace de datos o nivel físico colocásemos el sniffer, lo que obtendríamos sería los frames que van circulando por él, unos datos estructurados si comprendemos cada uno de los bits de dichos frames o simplemente un conjunto de bits sin significado alguno. Es aquí donde ntra en juego el analizado de paquetes, que es capaz de detectar el inicio de cada frame, y analiza cada uno de ellos desglosándolo en cada uno de sus protocolos. De esta forma, podemos convertir ese amasijo de datos sin sentido en una estructura bastante inteligible y fácil de manejar.

0000 00 25 xx xx xx xx 00 24 xx xx xx xx 08 00 45 00 .%…… ……..
0010 02 b5 33 3d 40 00 80 06 d1 8b c0 a8 xx xx 4a 7d ..3=@… ……J}
0020 e6 52 13 7c 00 50 97 da db af 4b c4 00 72 50 18 .R.|.P.. ..K..rP.
0030 3f c3 f6 21 00 00 47 45 54 20 2f 20 48 54 54 50 ?..!..GE T / HTTP
0040 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 77 77 77 2e /1.1..Ho st: www.
0050 67 6f 6f 67 6c 65 2e 65 73 0d 0a 55 73 65 72 2d google.e s..User-
0060 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 Agent: M ozilla/5
0070 2e 30 20 28 57 69 6e 64 6f 77 73 20 4e 54 20 36 .0 (Wind ows NT 6
0080 2e 31 3b 20 57 4f 57 36 34 3b 20 72 76 3a 32 2e .1; WOW6 4; rv:2.
0090 30 62 39 70 72 65 29 20 47 65 63 6b 6f 2f 32 30 0b9pre)  Gecko/20
00a0 31 30 31 32 31 39 20 46 69 72 65 66 6f 78 2f 34 101219 F irefox/4
00b0 2e 30 62 39 70 72 65 0d 0a 41 63 63 65 70 74 3a .0b9pre. .Accept:
00c0 20 74 65 78 74 2f 68 74 6d 6c 2c 61 70 70 6c 69 text/ht ml,appli
00d0 63 61 74 69 6f 6e 2f 78 68 74 6d 6c 2b 78 6d 6c cation/x html+xml
00e0 2c 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 6d 6c ,applica tion/xml
00f0 3b 71 3d 30 2e 39 2c 2a 2f 2a 3b 71 3d 30 2e 38 ;q=0.9,* /*;q=0.8

La tabla anterior sería un ejemplo de un frame capturado por un sniffer, en el lado izquierdo la representación hexadecimal y en el derecho una representación ASCII. En este caso sería un frame saliente de nuestro adaptador de red, más exactamente una petición HTTP realizada por el navegador para obtener la página web de www.google.es. Esta es simplemente la función del Sniffer, capturar el frame completo. En cambio, el analizador lo que realiza es diseccionar en partes más pequeñas dicho frame, dando a cada una de ellas un significado propio. Esto como hemos dicho es posible en tanto y cuanto conocemos el funcionamiento del modelo OSI/TCPIP, y sabemos que los datos viajan encapsulados en los distintos niveles OSI/TCPIP, usando diferentes protocolos. A fin de cuentas, el navegador en este caso quien ha realizado la petición, no necesita ni le es útil conocer la MAC de la interfaz del router o la suya propia, así como que le interesa bien poco saber que tipo de protocolos llevarán a acabo su petición. El navegador tan solo renderizará el código HTML que le devuelva el servidor de www.google.es (en este caso), es decir, en realidad lo que le interesa al navegador del frame anterior es el contenido que comienza con “GET /HTTP…” (En la columna del código ASCII) hasta el final.

En cambio, para el analizador tan importante es el protocolo HTTP (que comienza en el punto citado) como el protocolo Ethernet, que comienza justo al principio. Así, el analizador es capaz en la mayoría de las ocasiones de interpretar cada una de las partes del frame y su significado:

-Frame Ethernet: La MAC destino (6 Bytes) y la MAC origen (6 Bytes), seguidos del identificador del protocolo de red que tiene encapsulado (oxo800 = IP)
-Paquete IP: El primer Byte representa la versión de IP (4 = IPv4) y el segundo el número de palabras de 4 bytes (32 bits) de la longitud de la cabecera (5  -> 4*5 = 20 Bytes.  1 Byte para TOS, 2 bytes con la longitud total dele paquete IP (0x02b5 = 693 bytes), 2 para el ID del paquete, otros dos bytes indicadores de fragmentación, el byte TTL y el Byte de protocolo, que como en el frame Ethernet especifica el protocolo superior que encapsula, en este caso el prtocolo de nivel de transporte TCP (0×06 = TCP). Antes de incluir las direcciones IP origen/destino aparecen 2 bytes mas del CRC de la cabecera. Despues de esto se especifica simplemente las direcciones IP, en forma de 4 bytes cada una
-Mensaje TCP: Los primeros Bytes pertenecientes al mensaje TCP (nivel 4 del modelo OSI) serían los Bytes 0×13 y 0x7c, que especifican el puerto de origen, seguidos de otros 2 bytes que especifican el puerto de destino (0×0050 = 80, puerto HTTP). Los 4 siguientes bytes especifican el numero secuencia y los 4 siguientes el numero de ACK. Despues de esto, el nibble 0×5 especifica la longitud de la cabecera, mientras que 0×018 (los 12 bits restantes) se usan para los flag (0×018 = PSH y ACK habilitados). Para terminar 2 Bytes con el tamaño de ventana usado y otros 2 para el CRC. El resto son tan solo 2 Bytes de Padding. Nota: Es muy posible que analizadores como Wireshark verifiquen los CRC pro ellos mismos y los comparen con los obtenidos en la captura. Cuando estos datos no coinciden, suelen marcarse los paquetes (en wireshark) como errores en la verificacion de CRC, no obstante no quiere decir que el paquete efectivamente fuese dañado/modificado. La mayoría del hardware de red moderno realiza en ellos mismos ciertas tareas repetitivas para evitar al sistema tener que realizar ciertos cálculos, agilizando el sistema en gran medida. La verificación de CRC es un ejemplo de ello. El hardware en realidad es quien añade y calcula dicho CRC, no el OS, cno lo que la validación/verificación falla. Si tenemos errores de este tipo, solo decir que son normales, y posiblemente nuestro hardware de red esté mejorando el rendimiento de nuestro sistema gracias a estas tecnologías.
-Datos HTTP: Una vez pasado el nivel de transporte, en este caso pasamos al nivel de presentación, tráfico HTTP puro, que será el que maneje directamente nuestro navegador para solicitar o recibir la información en pantalla. En este caso se comienza con una petición tipo GET y toda la cabecera HTTP de petición, especificando el host destino, el User-Agent…

 

Es por todo esto que cuando se desea usar técnicas como el Sniffing es necesario conocer cuanto más mejor los protocolos que intervienen en ello, como ya pudimos ver en otros capítulos. Es evidente que un análisis manual como el que hemos llevado a cabo es imposible de cara a la realidad, donde pueden capturarse cientos de frames por segundo. Pues bien, Wireshark es el que nos ayuda a ello, de un modo mucho más gráfico y sencillo, a la par que nos permite reensamblar PDUs segmentados, descomprimir el tráfico HTTP, filtrar virtualmente por lo que necesitemos, analizar las pilas de protocolos, estudios estadísticos de los frames…

En tanto y cuando el ejemplo anterior tan solo era una muestra del aspecto de un frame que incluye una petición HTTP (y tampoco con demasiado valor), es muy interesante a la hora de estudiar protocolos y ver la seguridad de muchos de ellos, lo cual puede dar juego a posteriori. Por ejemplo, lo inseguro que puede ser el protocolo SMTP ante el Sniffing. Veamos una “Conversación” de una sesión SMTP (por supuesto sin cifrar, sin usar TLS/SSL o STARTLS):

En este caso, es simple usar WireShark para “limpiar” la “conversación” y mostrar los datos de un modo más intuitivo:

220 smtp140.mail.ukl.yahoo.com ESMTP
ehlo prueba
250-smtp140.mail.ukl.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME
auth login
334 VXNlcm5hbWU6
Y3VlbnRhLnBydWViYUB5bWFpbC5jb20=
334 UGFzc3dvcmQ6
MTIzNDU2
235 OK, go ahead
mail from: <cuenta.prueba@ymail.com>
250 OK , completed
rcpt to: <blog@theliel.es>
250 OK , completed
data
354 Start Mail. End with CRLF.CRLF
from: Prueba <cuenta.prueba@ymail.com>
to: Theliel <blog@theliel.es>
Subject: Asunto prueba
Este correo es un claro ejemplo del deficit de seguridad en el protocolo SMTP sin cifrar

.
250 OK , completed
quit
221 Service Closing transmission

Cuando enviamos un correo electrónico usando SMTP en “plano”, es francamente sencillo extraer cualquier tipo de información de él. En este caso se ha usado el método de autentificación “login”, que simplemente usa codificación base64 para el nombre de usuario y la contraseña (completamente reversible y simple). Pero aun cuando se usan sistemas de autentificación como CRAM-MD5, continuarían siendo visibles datos evidentemente “comprometidos”, como las direcciones de correo origen/destino, el nombre de los usuarios, el asunto… y por supuesto el cuerpo del mensaje. Es evidente que el nombre de usuario y la contraseña son los datos más sensibles. Por supuesto, esto por si solo no tendría mayor importancia dado que solo son datos que salen de nuestro equipo, y evidentemente conocemos dichos datos sin necesidad de un Sniffer. Pero esto lo trataremos más adelante.

Idealmente, cualquier comunicación punto a punto debería de estar cifrada. Es por ello que existen los protocolos de encriptación como TLS/SSL. Su propósito principal es que tan solo los extremos de la comunicación puedan tener acceso a dichos datos, evitando que cualquier “man-in-the-midle” que pueda interceptar una comunicación pueda tener acceso a dichos datos de forma “plana”, es decir sin cifrar. Esto evita además, no solo protección ante terceras personas que puedan tener intenciones maliciosas, sino que evita también que nuestros propios ISP o agencias gubernamentales puedan conocer el contenido de la información que estamos transmitiendo. Ojo!! Transmitiendo!! este tipo de protocolos solo garantiza la inviolabilidad de los datos en la transmisión de estos. El destino recibirá dicha transmisión en plano, por así decirlo, su navegador, su gestor de correo, su… mostrará sin problema alguno los datos transmitidos:

Por último, no solo la información en sí es importante, sino su conjunto. La mayoría de los ataques DoS, Escaners de puerto, exploits, envenenamientos… pueden ser detectados por un Sniffer. La gran mayoría de estas técnicas suelen responder a un patrón fácilmente reconocible simplemente explorando un registro de un Sniffer. La gran mayoría de todas las comunicaciones se basan en protocolos bien definidos, lo que hace de estos que sea “fácil” seguir una comunicación entre dos (o más) equipos. Si es una comunicación telnet o HTTP, si es un flujo de datos, si… esto no significa que siempre es posible conocer la finalidad o el objetivo de un frame interceptado, pero muchas veces podemos hacernos una clara idea de ello. En esto juega un gran papel los puertos de conexiones. Por ejemplo, por defecto sabemos que los servidores web usan el puerto 80, o el puerto 25 para servidores SMTP de correo. No quiere decir que todo el tráfico recibido por un equipo remoto por su puerto 80 sea tráfico HTTP, pero desde luego siempre será la primera opción a pensar. Pues bien, del mismo modo que los diferentes servicios que existen suelen estar asociados a uno o varios puertos conocidos, la mayoría de los “ataques” informáticos también pueden llamar la atención. Es aquí donde los analizadores de paquetes juegan un papel muy importante en, nunca mejor dicho, analizar dicha información. Por supuesto, será el usuario final siempre el que tenga que interpretar dichos frames y su posible significado:

La imagen anterior sería el resultado de colocar un Sniffer en nuestro router ante un simple escaner de puertos un tanto “ruidoso”, en la que “Lilith” (el router en cuestión) respondería con un mensaje TCP  con el flag RST a todos los mensajes SYN (uno a cada puerto escaneado) que el equipo “Theliel” está enviando. Todo deja huella, y cuanto más se aleje de un comportamiento “normal”, más ruido. Generalmente, cualquier Hacker o usuario malicioso que quiera efectuar un ataque informático quiere pasar completamente desapercibido, lo cual convierte el anonimato y el silencio en una de las primeras prioridades. Un escaner de puertos como el mostrado anteriormente es muy ruidoso, evidentemente hay formas mucho menos ruidosas de hacerlo. Este papel lo conocen bien los administradores de redes, no todo es un DoS, ni todas las conexiones esporádicas son accidentales.

 

El análisis o estudio estadístico del tráfico por la red sería demasiado extenso como para dedicarle unas pocas líneas, así que nos quedaremos (estudiaremos) tan solo aquel tráfico que pueda ser interesante para nosotros desde un punto de vista más directo, es decir, aquel tráfico que expone directamente datos que podríamos considerar delicados para los usuarios: Nombres de usuario, Contraseñas, números de tarjetas de créditos… pero los Sniffers no solo son capaces de interceptar el tráfico saliente, sino también el entrante. Generalmente, dicho tráfico no está pensado para que sea manejado directamente por nadie, suelen ser datos solicitados por el navegador, o por ejemplo un correo electrónico entrante que descarga un gestor de correos. Pero del mismo modo que se puede capturar el tráfico, podríamos pensar que podríamos interceptarlo y modificarlo al vuelo.

 

 

Modificando el tráfico de la red

Capturar el tráfico puede ser un gran problema de seguridad cuando no existen mecanismos de cifrado que lo protejan, pero tanto o más peligroso es la posibilidad de poder alterar dichos datos. La teoría es simple, si un Sniffer nos permite de algún modo interceptar tráfico en la red, podríamos también alterar dichos datos. Esto suele ser muy útil, particularmente para dos labores: Engañar un software cliente/servidor con datos no legítimos para lograr un comportamiento diferente al esperado a tener y también de cara a minimizar los fallos de seguridad de un software cliente/servidor. Muchas veces un software se crea con el pensamiento de que todo funcionará siempre en un entorno ideal. Un programa servidor podría estar preparado para contestar siempre en función de unas preguntas preestablecidas por un programa cliente. Dado que el programa cliente se crea conjuntamente con el programa servidor, podría caber pensar que el servidor no sería falta programarlo para casos que no se contemplan en el programa cliente. No obstante, comprobar el comportamiento de un software ante cualquier situación debe de ser algo primordial, no solo ceñirse a meras condiciones ideales, ya que a fin de cuenta un atacante es más que posible que use todo tipo de técnicas, aunque sea generar un tráfico que jamás podría generar una aplicación cliente. Es aquí donde suelen nacer la mayoría de los Exploits, programas que generan cadenas de Bytes a conciencia que aprovechan fallos de seguridad de un software objetivo que no estaba diseñado para tal efecto.

De todos modos, la inyección de tráfico es diferente a la modificación del tráfico, que es donde nos vamos a centrar. La gran mayoría de todo el tráfico que existe a día de hoy es tráfico HTTP, páginas web que se envían y solicitan. Incluso ¿la mayoría? de las aplicaciones que requieren de acceso a la red usan peticiones HTTP para comunicarse con los servicios externos. Esto convierte la modificación del tráfico de red en un juego de niños. Aun cuando el tráfico que se quiera modificar no proceda de protocolos bien conocidos, tampoco es una imposibilidad el poder jugar con ellos y modificarlos a voluntad con las herramientas adecuadas. Por ello, vamos a ver lo simple que puede resultar realizar esta operación por medio de un servidor proxy local que interceptará todo el tráfico HTTP, y por medio de unos simples filtros lo modificará. Un servidor Proxy no es exactamente un Sniffer, sino un software que recibe/envía cierto tráfico a través de él, generalmente para filtrar, controlar o modificar pequeños aspectos de este tráfico. Por ello, es una gran herramienta a la hora de probar el comportamiento HTTP de ciertos programas, como navegadores o servidores de aplicaciones web. Estos servidores proxys no capturan frames, ojo!! por lo general tan solo los datos enviados y recibidos desde el nivel de aplicación.

 

En esta ocasión he optado por un ejercicio práctico, que bien podría ser objeto de un artículo independiente de como “piratear” (no me gusta nada dicha palabra) la aplicación en cuestión.

Hay un juego Online relativamente conocido llamado “Ogame“. Es un juego online PHP, que la verdad no nos interesa en absoluto para el objetivo de este pequeño ejercicio práctico. Como todo buen juego online conocido, hay ingeniosos programadores que crean bots (programas que automatizan ciertas tareas del juego) para hacer “trampas” en estos. Lo cierto es que la gran mayoría de todos los Bots que existen para juegos online suelen ser gratuitos, pero la aplicación que vamos a tratar (que no es más que un bot para Ogame) es Shareware, y tan solo nos permite un tiempo limitado de uso sino se compra. La aplicación en este caso es: “Ogame Automizer”.

Aunque sea algo que ya conozca la mayoría de mis lectores, mi intención no es que aparezcan ahora oleadas de tramposos en Ogame, ni mucho menos boicotear la aplicación en cuestión para que pueda usarse sin pagar por ella. Es más, una vez termine la publicación de este artículo, como es costumbre, enviaré un aviso al desarrollador para que sea consciente del fallo de seguridad de su software. He optado por esta aplicación en particular porque muestra perfectamente la importancia de un Sniffer y la modificación del tráfico de red incluso cuando este se genera por nuestro propio equipo, así como la versatilidad e importancia de un servidor Proxy.

Antes de nada, hay por supuesto que comprender le funcionamiento de registro de este programa. Es simple. Si no se registra, el programa permite un tiempo de 1 hora y 30 minutos de forma autónoma, tras dicho tiempo es necesario hacer clic en un botón o el programa no funcionará. Después de presionarlo estará activo de nuevo por el mismo tiempo, así indefinidamente. Es evidente que esto no es viable para un Bot que precisamente puede ser usado para dejarlo activo durante horas o incluso dias de forma completamente autónoma, no tener que “reactivarlo” cada 1 o 2 horas. No obstante, cualquiera puede realizar un registro gratuito que incluye un serial trial que permite el uso del programa por 4-5 días completos, después de dicho tiempo se volverá al estado inicial, con la imposibilidad de poder solicitar un nuevo serial trial, dado que estos serial se asocian al propio nombre de usuario de OGame, con lo que tan solo se permite un serial trial por jugador de OGame.

¿Como podemos estudiar el comportamiento de la aplicación? Bueno, aquí tratamos con Sniffers, así que no hay mejor sistema para investigar el sistema que usa que un Sniffer. Ni que decir tiene que el sistema de verificación del número de serie y el tiempo de activación de dicho número de serie se realiza a través de la red, con lo que colocar un Sniffer a OGame Automizer sería a priori la mejor forma de comprender el sistema de verificación de este programa. Por supuesto, en este punto no podemos saber si la comunicación se realizaría de forma cifrada, o si posee algún sistema mixto, es por ello que como se dijo mucho antes, casi siempre todo comienza analizando el tráfico de red. Si aislásemos el tráfico generado por OA (OGame Automizer a partir de ahora), veríamos que cada X, la aplicación enviaba una petición HTTP con unos datos más que interesantes, y que el servidor respondía con datos igualmente interesantes:

Si extraemos de ahí el paquete 56, tendríamos la madre del cordero:

GET /public.php?action=expire&uni=xxx.ogame.com.es&login=AlmasOscura&serial=xxxxxxxxx HTTP/1.1
Host: 188.165.227.218
User-Agent:Mozilla/5.0 (Windows NT 6.1; x64; rv:2.0b9pre)
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Accept-Language: en-us;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Fri, 19 Nov 2010 02:51:58 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 11
Keep-Alive: timeout=10, max=32
Connection: Keep-Alive
Content-Type: text/html

……72482

La primera parte corresponde a la petición HTTP que realiza la aplicación al servidor de OA, mientras que la segunda parte corresponde a la respuesta por parte de este, y que será procesada por la aplicación. Es evidente por tanto como se realiza la verificación. Cada X segundos la aplicación realiza una petición al servidor de OA, en la que incluye lo que desea hacer (action=expire), el servidor de OGame en el que está activo dicho jugador (uni=xxx.ogame.com.es), el nombre de usuario (login=AlmaOscura) y el serial que está usando dicho usuario para la aplicación OA (serial=xxxxxxx). Es decir, la aplicación envía al servidor de OA todos los datos necesarios para que este pueda verificar el estado de dicho número de serie asociado a dicho usuario en dicho universo OGame.

La segunda parte es la respuesta del servidor, una vez recoge los datos de la petición envía de vuelta los datos del estado de la verificación de la cuenta. En este caso simplemente responde con “…….72482″ (el resto es la cabecera de respuesta del servidor). Bueno, no hay que ser un lince para deducir que dicho número es el período en segundos del que aun disponemos para poder usar OA. En este caso 72482 segundos es algo más de 20 horas, que podemos verificar perfectamente si mirásemos el número de horas y minutos que la aplicación OA nos dice… y por supuesto coincide.

Llegados a este punto todo es relativamente sencillo. El sistema de verificación de OA se basa en peticiones regulares en las que el servidor de OA indica el número de segundos que restan, y se usa como sistema de sincronización, dado que el contador disminuye constantemente (es controlado por la aplicación), pero es siempre el valor devuelto por el servidor el que prima. Si este es el único sistema de verificación/activación, es tan simple como modificar el valor devuelto por el servidor a uno que sea constante (mayor o menor), de forma que cada vez que la aplicación sincronizase con el servidor (cosa como hemos dicho bastante regular y cada pocos segundos/minutos), de cara a la aplicación OA el servidor siempre le respondiese con el mismo valor, con lo que aun cuando la cuenta de la aplicación fuese inferior, esta se restablecería a nuestro valor falso, y tendríamos OA indefinidamente.

Este comportamiento se podría comprobar de forma simple con alguna aplicación que actuase de proxy que permitiese interceptar peticiones HTTP y editarlas, quizás el software más famoso en su época fue “Achilles”, aplicación que siempre tendrá un pequeño hueco en mi corazón. Pero en realidad cualquier servidor proxy que permita crear una simple respuesta HTTP sería suficiente. En mi caso ha sido Paros Proxy, una aplicación ya antigua, pero que siempre me ha gustado por lo bien orientada que estaba.  Sería cuestión de forzar una solicitud HTTP de verificación de OA, interceptar la respuesta del servidor y simplemente cambiar el valor devuelto por el servidor por otro a nuestro antojo, inmediatamente comprobaríamos que el tiempo de activación de OA era correctamente actualizado. En la imagen se muestra como realizar la petición forzada, no la modificación. Para permitir la modificación, OA tendría que estar configurado para pasar todo a través de un proxy local, y en Paros activar la interceptación de tráfico entrante:

Aquí, el servidor nos devuelve algo diferente, y es debido a que los datos introducidos al realizar la petición corresponden a unos datos cuya cuenta hace ya mucho que dejó de estar activa, de ahí el mensaje de “expire”, seguido del número en segundos que hace que expiró. Esto es interesante también, pues será algo que será usado un poco más adelante para facilitar la creación de un filtro. También muestra lo simple que resulta crear peticiones HTTP creadas a mano a un servidor cualquiera, y por supuesto ver su respuesta, lo cual resulta tremendamente útil.

Evidentemente dicho procedimiento sería inviable, dado que la verificación se realiza de forma regular. Esto implica que sería necesario crear un filtro que fuese capaz de reconocer las peticiones realizadas o recibidas por OA y modificarlas al vuelo. Y para esto sin duda alguna es mucho mejor el uso de un servidor Proxy decente, como pueda ser Squid, el mismo Apache o, en este caso concreto, Privoxy. Personalmente creo que es más fácil manejar privoxy a la hora de crear filtros específicos, que es lo único que tendremos que hacer. Privoxy puede modificar cualquier contenido al vuelo en función de un patrón definidos, de forma global o incluso tan solo en determinados hosts. En este caso lo más simple sería tomar de patrón “expired”, y configurar Privoxy para que modifique dicha cadena al número de segundos que deseamos, por ejemplo 64000 segundos.

La única pega que quedaría sería el problema de la compresión HTTP. Prácticamente cualquier servidor HTTP y cualquier aplicación/navegador solicita el contenido comprimido para ahorrar ancho de banda, lo cual suele ser tremendamente efectivo, ya que la gran mayoría de todo el tráfico HTTP es texto plano, y por ende altamente comprimible. Privoxy no podrá reconocer ningún patrón que venga de contenido comprimido, con lo que también habría que instruir a Privoxy para que, o se comunique con el exterior siempre sin usar compresión, o configurando/compilar Privoxy con soporte para ello, con lo que privoxy realizaría la descompresión y compresión del contenido. Todo ello no obstante es muy simple, tan solo hay que configurar correctamente Privoxy:

Por un lado que el filtro tan solo sea efectivo para el servidor de OA y que dicho contenido vaya siempre sin comprimir (Archivo User.action):

{ +prevent-compression }
188.165.227.218

{ +filter{OA} }
188.165.227.218

Por otro lado el filtro que realiza la modificación al vuelo (Archivo User.Filter):

FILTER: OA Modificar la cadena “expired” por “999999″
s/expired.*/999999/

En realidad dicho filtro no solo modifica la cadena expired, sino la cadena expired y todos los caracteres siguientes hasta encontrar un retorno, es decir, modificaría toda la linea por el valor deseado. Con tan solo esas líneas, privoxy sería capaz de modificar al vuelo las peticiones de verificación de OA, haciendo que dicha aplicación estuviese indefinidamente activada, siempre y cuando OA pasase el tráfico a privoxy, evidentemente, y que en este caso la expiración hubiese ocurrido ya, de lo contrario sería necesario modificar el patrón del filtro.

Es normal que los programadores no sean expertos en seguridad, lo cual influye sobre todo en el software creado por programadores independientes que no tienen un gran soporte de una empresa por encima con un buen control de calidad. La solución no solo pasa por usar sistemas seguros como TLS o SSL, sino que independientemente de estos las mismas aplicaciones tendrían que cifrar el contenido ellas mismas, de modo que la información desde que saliese de la aplicación hasta que llegase fuese siempre completamente indescifrable, y digo esto porque aun usando protocolos como TLS o SSL se podrían crear en los servidores proxys soporte para ello, con lo que la aplicación continuaría comunicándose de forma no cifrada con este, y en consiguiente contenido fácil de leer y modificar.

Evidentemente esto no es más que una aplicación simple que tan solo podría tener alguna utilidad para algunos tramposos, pero esto mismo expuesto es aplicable a una gran cantidad de aplicaciones existentes que son vulnerables a todo este tipo de ataques, que no dejan de ser básicamente pequeños Hacks, aunque yo prefiero llamarlo simplemente agujero de seguridad.

 

 

Envenenamientos

Hasta donde hemos visto, el Sniffing es una gran herramienta, pero tiene barreras que no puede sortear. Es evidente que es muy útil poder capturar o analizar todo el tráfico saliente o entrante de nuestro propio equipo, pero seamos sinceros… lo ideal sería poder realizar lo mismo en toda nuestra red. Esto dijimos que era posible siempre y cuando nuestra red estuviese constituida por un Hub, o evidentemente si colocásemos un Sniffer en el router mismo, lo que nos permitiría conocer todo el tráfico saliente o entrante de este (no entre los propios equipos). Es evidente que un administrador de red tendrá acceso a toda la infraestructura de esta, y lo más posible es que tenga acceso directo a todo el tráfico por medio de los puertos especiales llamados “Mirror” (Espejo), que permiten conectar un equipo a él y poder monitorizar todo el tráfico. Ni que decir tiene el poder que otorga un puerto espejo en un switch de una red, imaginar todo lo explicado anteriormente pero no limitado tan solo a nuestro equipo, sino a TODOS los equipos conectados a la red, imaginar una empresa o una universidad, la cantidad de información sensible a la que se podría tener acceso.

Evidentemente los usuarios maliciosos, atacantes, hackers… no suelen tener acceso a estos puertos especiales, ni tampoco un acceso directo a un router ajeno. Pero como ya hemos dicho muchas veces, Internet no se creó desde un principio con la seguridad en mente, sino en su versatilidad y potencial. Prácticamente todos los protocolos de Internet están basados en estas premisas, lo que ha producido que con los años se descubran importantes problemas de seguridad en ellos. No obstante, esto no implica que dichos protocolos sean un error, gracias a la simpleza de estos, Internet es ha día de hoy lo que es, digamos que hemos tenido que pagar un precio en cuanto a seguridad se refiere por entornos mucho más libres, fluidos…

 

El término “Envenenamiento” proviene del acto de manipular una caché concreta de forma que los datos añadidos/modificados aparenten ser legítimos. ¿Caché? En informática es muy común el uso de memorias caché que almacenan de forma temporal aquellos datos que son usados de forma más frecuente. Por ejemplo, un servidor Proxy caché, almacenará en dicho caché las páginas web más visitadas, con el objeto de si se solicita dicha web el servidor proxy sirve de manera inmediata dicha web, sin necesidad de realizar una petición al servidor original. Por ello, las caché suelen ser efectivas para datos que no se actualizan de forma muy regular, o mejor dicho, que la frecuencia en la que dichos datos son necesitados es muy superior al tiempo en el que dichos datos necesitan actualizarse.El objetivo de una caché es evidente, acelerar en mucho la velocidad de un sistema, en concreto el acceso a los datos que se están cacheando.

Pero hay un problema. Por definición, un dato almacenado en una caché no tiene por qué estar actualizado. Aquellos datos que son relativamente constantes no es un problema, cuando el dato necesita actualizarse se actualiza y listo. El problema es que no siempre hay un sistema que dice cuando el dato está actualizado o no. Volviendo al ejemplo de una caché de un servidor proxy, imaginar que el servidor proxy almacena en caché la web de google.es, de tal forma que cada vez que cualquiera de los 300 equipos conectados a dicha red quiere acceder a googole.es el servidor web la sirve sin necesidad de realizar una petición a google.es por cada equipo que quiera acceder a ella. Pues bien, si el caché tiene por ejemplo un tiempo de vida de 24 horas y Google cambia la portada de su página, todos los equipos continuarán accediendo hasta el fin de esas 24 horas a una versión antigua de google.es. Evidentemente esto puede no ser importante, o por el contrario tener una gran importancia. Normalmente este tipo de problemas se soluciona disminuyendo el tiempo de permanencia de los datos en las caché en relación con el tiempo que podría tener validez dichos datos. En el caso del servidor proxy, lo normal es que Google modifique su web a lo mejor de mes en mes, con lo que tener configurado en el servidor proxy un tiempo de vida de dichos datos para 24 horas sería suficiente para tener un sistema eficiente.

¿Como nos afecta esto? Bueno, tenemos caché prácticamente en cualquier aplicación, registros, protocolos… pero aquí vamos a citar dos en especial, por tener relación directa con el Sniffing:

  • Caché ARP
  • Caché DNS

 

Envenenamiento ARP

El protocolo ARP fue explicado en su momento. Resumiendo, el protocolo ARP es el responsable de que un sistema pueda conocer la dirección física de otro por medio de su IP, o al revés, conocer la IP de un sistema por medio de su dirección física. Recordemos que el nivel en el cual se usa IP es el nivel de red, nivel 3, pero por debajo de este es necesario conocer las direcciones físicas (Direcciones MAC). La asociación IP-MAC es mucho más estrecha de lo que uno pueda imaginarse, en realidad usamos direcciones IP por una cuestión de simplicidad y facilidad de uso, pero en última instancia, los datos son enviados por las interfaces de red a otras interfaces de red.

Recordemos que cuando un equipo se conecta a la Red generalmente se anuncia, para indicar a los equipos vecinos que existe. Aun cuando esto no se realiza, cuando cualquier equipo quiere comunicarse con otro equipo vecino, debe conocer su dirección Física, no solo su dirección IP. Si no la conoce, tendrá que preguntar a la red que dirección física tiene, para así poder comunicarse con él. Esto se realizaba gracias al protocolo ARP.

La caché ARP por tanto almacena en cada PC (o sistema) una tabla con la asociación IP <-> MAC de cada equipo conocido, cuando el equipo encuentra una nueva asociación o una actualización de uno de ellos, modifica dicha tabla para actualizar sus datos. ¿Por qué es necesaria dicha caché? En realidad no es necesaria, pero ahorra una cantidad más que importante de ancho de banda!! sin dicha caché, cada vez que nuestro PC quisiese comunicarse con cualquier otro equipo (incluyendo el propio router) tendría que realizar antes una petición ARP para conocer la dirección física de dicho dispositivo y esperar por supuesto la contestación de este. Evidentemente esto sería impensable. Por lo general, las asociaciones IP <-> MAC suele ser suficientemente constante, a veces constante hasta que los equipos se reinician o temporal en caso de que la asignación de IP a los equipos tengan tiempos de leasse relativamente pequeños. La realidad es que en redes pequeñas como las domésticas, estos datos pueden ser constante durante días, mientras que en redes empresariales, universitarias… estos datos pueden tener una constancia mucho menor, normalmente la duración de la sesión. Aun así, si en una sesión se envían cientos de miles de paquetes o conexiones, es más que necesario el uso de una caché ARP.

Es evidente que aun así, debe de existir un sistema de actualización de dichas caché, ya que las mismas IPs se reutilizan para diferentes equipos, sobre todo en entornos en los que estas son asignadas de forma dinámica por sistemas como DHCP. Es por ello que las caché ARP pese a todo suelen usarse, y suelen siendo modificadas de forma dinámica según el propio protocolo ARP, lo cual nos hace ver la verdadera utilidad de un envenenamiento ARP.

ARP es un protocolo simple, que es usado de forma natural en cualquier red. En un buen uso de este, las tablas ARP de todos los dispositivos se van actualizando mientras que las peticiones ARP lanzadas a toda la red van llegando. Por ejemplo, si un dispositivo pregunta por medio de ARP una dirección física, en la misma pregunta especificará su propia IP y MAC, con la idea de que se conteste a dicho equipo. Pero esto puede ser usado de forma maligna para engañar a las caché ARP de los otros equipos. Básicamente se trata de lograr que los equipos vecinos tengan en sus cachés ARP datos incorrectos. ¿Que pasaría si un equipo tuviese en su caché ARP la dirección física asociada al router modificada por la dirección física de un atacante? Que cada vez que la victima quisiese comunicarse con el router, este sin saberlo estaría enviando los datos al atacante, y este por tanto podría interceptarlos por medio de un Sniffer.

Un ataque completo de envenenamiento ARP suele componerse de dos partes. La primera en lograr alterar la caché ARP de una puerta de enlace (o router) para colocar la dirección física del atacante asociada a la dirección IP de la víctima, la segunda en alterar la caché ARP de la víctima para colocar la dirección fisica del atacante asociada a la dirección IP del router. De esta forma, cada vez que el router quiera enviar cualquier dato a la víctica, este será pasado al atacante, y del mismo modo cada vez que la víctima quiera comunicarse con el exterior, pasará ante los datos por el atacante. El atacante ahora tan solo tiene que ser capaz de enrutar los datos para que los paquetes enviados por la víctima crucen el atacante y este los reenvíe al router, y lo mismo para el proceso de recepción. Esta imagen ilustra mejor el proceso:

En una situación de pre envenenamiento, los equipos hacen uso de su caché sin alterar para conocer las direcciones físicas a las cuales dirigirse. Si en ese momento un atacante (el host 192.168.0.10) quisiese comenzar un ataque de envenenamiento, enviaría un frame ARP hacia la MAC e IP del router, pero especificando en el payload ARP que él mismo (el atacante) posee la IP 192.168.0.15 (la IP del host a atacar), en vez de su IP real 192.168.0.10. Con esto provoca que la caché ARP del router actualice la dirección MAC asociada a la IP 192.168.0.15. El mismo proceso se realizará pero hacia el host atacado, en este caso el atacante enviaría un frame ARP especificando en el payload de este que el atacante posee la IP del router, actualizando así en la caché ARP de la víctima la dirección MAC asociada a la IP del router. Una vez las dos caché han sido envenenadas, la víctima cada vez que envíe un paquete a la dirección IP de la puerta de enlace (el router, 192.168.0.1) lo estará enviando sin saberlo al atacante, dado que su equipo la dirección física que tiene asociada a dicha IP es la dirección física de este (el atacante). El atacante a su vez recibirá el paquete de la mano de la víctima, y para evitar cortar la comunicación entre la víctima y el servidor remoto, reenviaría dicho paquete a la puerta de enlace, y de ahí a Internet. Cuando cualquier paquete con destino a la víctima alcanzase el router, este lo enviaría al atacante dado que la dirección física asociada a la IP de la víctima desde el punto de vista del router es el atacante, por tener su caché envenenada. La siguiente imagen ilustra el estado de las caché y del éxito del envenenamiento:

Cual es la utilidad del envenenamiento ARP? pues que el atacante logra que todo el tráfico desde y para la o las víctimas circule por él, y por tanto podrá usar un Sniffer para capturar todo su tráfico, exponiendo cualquier dato sensible que este intercambiando la víctima y no esté siendo cifrado. Todo ello sin que la víctima sea consciente de nada. Evidentemente hay medidas para evitar los envenenamientos, como por ejemplo usar en los routers tablas ARP estáticas (aunque suelen dar problemas) o tener un software que monitorice la red y ante la sospecha de un ataque de envenenamiento ARP actúe o desconectando al equipo sospechoso, ignorando los frames ARP que vengan de la MAC sospechosa, actualizando la caché ARP interna… los ataques de envenenamiento ARP suelen ser ruidosos, con lo que también suelen ser fácilmente reconocibles y usar contramedidas, las cuales también pueden ser fácilmente sorteadas por un atacante.

¿Conclusión? Una regla de Oro muy simple, si te encuentras en una red pública o que no puedes controlar, jamás enviar a dicha red ningún dato que pueda ser sensible a menos que se tenga la certeza de que la conexión se realiza de forma segura, y aun así, se debe de tener cuidado! No nos gustaría que un usuario malicioso estuviese viendo cualquier conversación vía mensajería instantánea, correos electrónicos, videoconferencias… no hay límites.

 

Envenenamiento DNS

Si bien el envenenamiento DNS no posee una relación directa con el Sniffing, es buena idea añadirlo aquí, como segundo envenenamiento de caché conocido. El envenenamiento de DNS suele tener una relación más directa con el Spoofing, dado que por regla general su objetivo no es otro que redirigir las peticiones de una web hacia otra.

Aunque los equipos poseen también una caché DNS, al igual que poseían una caché ARP, no nos referimos generalmente al envenenamiento de DNS como el envenenamiento de esta caché, lo cual sería generalmente conocido como un envenenamiento de caché DNS por ARP (que también es posible realizar). Al igual que la mayoría de todos los protocolos en los que se basa internet. el protocolo DNS es abierto y tiene un ámbito global, lo cual implica que en teoría cualquiera puede montar un servidor DNS completamente funcional y sincronizado con otros servidores DNS. Cualquier servidor DNS suele tener una caché temporal que almacena las peticiones más recientes de DNS para evitar en la medida de lo posible la recursividad, y así evitar un importante ancho de banda.

Al igual que el protocolo ARP, el protocolo DNS permite la sincronización/actualización de los datos de su caché. De nuevo, en un mundo ideal, tan solo los servidores DNS legítimos tendrían que poder realizar dichas actualizaciones (por así decirlo), pero la vida real es bien diferente. Por tanto, un atacante que tuviese un servidor DNS colocado para tal efecto podría intentar enviar peticiones de actualizaciones a un segundo servidor DNS víctima. Si este no tuviese los protocolos y mecanismos adecuados para autentificar dichas peticiones, vería como su caché sería modificada, provocando que supuestos los nombres de dominio deseado apuntasen a direcciones IP bien diferentes. ¿Qué utilidad? Pues bien, dado que los usuarios suelen depender de los servidores DNS, si nuestro servidor DNS estuviese envenenado por un atacante, podría darse el caso que cuando quisiésemos acceder por ejemplo al servidor de google para google.es (que legítima mente tiene la IP 74.125.230.81), nuestro servidor DNS nos devolvería una IP falsa, lo que haría que nuestro navegador aun cuando pusiese que la web visitada era google.es no estaría enviando a cualquier otra web, archivo… o lo que fuese. Esta técnica es tremendamente útil a la hora de realizar por ejemplo ataques de Phishing

Estos ataques suelen tener una importancia en mayúscula por muchos motivos. Para empezar, envenenar un solo servidor DNS (el de un ISP, una empresa, un partícular…) puede afectar a su vez a decenas, cientos, miles… de usuarios!! En segundo lugar, y no menos importante,  al usuario le sería imposible saber que está pasando, a menos que usase un servidor DNS diferente al que está envenenado, ya que desde su punto de vista todo ha sido normal.  Por suerte, este tipo de ataques suelen ser bastante sofisticados y cada día más difíciles de llevar a cabo, sobre todo ahora que se está comenzando la implementación de DNSSec de forma masiva en la mayoría de servidores DNS, añadiendo un método eficaz de autentificación entre servidores DNS.

 

 

Certificados y Túneles

El Sniffing nos permite capturar y analizar todo el tráfico de nuestro sistema, mientras que los envenenamientos nos permiten aplicar el Sniffing a redes completas. ¿Que nos queda por tanto? Para evitar cualquier tipo de escucha, lo ideal sería siempre que todo el tráfico enviado de punto a punto fuese cifrado. El problema es que prácticamente todos los sistemas de cifrado punto a punto que existen suelen basarse en algún momento del intercambio de certificados o claves a través de la misma red.

En su momento, cuando se trató el cifrado asimétrico y los protocolos SSL/TLS todo parecía que era perfecto. Estos sistemas nos daban los métodos adecuados y aparentemente perfectos para poder transmitir y recibir información de forma completamente segura. No obstante, cuando se indaga un poco más adentro, vemos que en realidad cualquier sistema por seguro que sea siempre tiene puntos por los cuales se puede echar a perder dicha seguridad. Los métodos de seguridad que existen son únicamente seguro siempre y cuando tanto el usuario como el entorno que le rodea es seguro. Dicho de otro modo, una contraseña puede ser un sistema sencillo y eficaz para proteger algo, pero si el usuario usa de contraseña su propio nombre, habría sinceramente que detenerse a pensar si el método de proteger algo por contraseña es realmente inseguro o es el usuario el único responsable del fallo de este sistema. Con los años te das cuenta que la tecnología en la medida que puede intenta tapar dichas “torpezas” de los usuarios, pero por mucho que esta avance y por mucho que se le ponga fácil al usuario, este siempre tiene la última palabra sobre si un sistema es seguro o no lo es.

El caso de TLS/SSL es lo mismo. Recordemos por encima y de forma rápida, que cuando un equipo realiza una conexión segura entre este y un servidor remoto, lo que sucede básicamente es que el usuario solicita una conexión segura, el servidor le envía su certificado público, el usuario verifica dicho certificado y cifra una key con dicho certificado (que posee la clave pública), el servidor recibe el mensaje y lo descifra con el certificado privado y la comunicación se realiza con la key escogida/generada por el cliente. Este esquema parece perfecto, una vez el canal se ha asegurado todo parece perfecto, y puede ser cierto… ¿Pero que pasa si el canal aun no se ha establecido? Este procedimiento es eficaz siempre y cuando se de por sabido que el certificado del servidor al cliente es válido y legítimo!! Evidentemente el cliente puede y tiene la obligación de verificar la validez del certificado del emisor, pero el hacerlo o no hacerlo, o como actuar cuando el certificado no es válido es otro cantar.

El problema de una sesión SSL/TLS es el mismo que se ha visto en el envenenamiento ARP. Ante un posible ataque de man-in-the-middle, el usuario creería siempre que está comunicándose directamente con el equipo remoto, y este a su vez con la víctima, pero podría suceder que entre la comunicación de ambos existiese un tercero, un atacante que estuviese interceptando todo el tráfico enviado por la víctima y el tráfico originado por el servidor remoto hacia la víctima. Ante esta situación, el atacante podría estar realizando una conexión segura TLS/SSL con el servidor remoto, a la par de intentar engañar a la víctima con que su sesión SSL/TLS es genuina:

No obstante, hacer pasar por válido un certificado que no lo es, no es algo tan fácil, y depende en gran medida de la víctima. La veracidad o genuicidad de un certificado digital se basa principalmente en la cadena de verdad, en la que un certificado es firmado por una autoridad certificador en la que el cliente confía. En realidad, cualquier certificado puede autofirmarse a sí mismo, cualquiera puede emitir un certificado raiz con el que dar supuesta validad a otro certificado, el único problema siempre es el mismo, que el cliente tenga en su lista dicha entidad raiz o certificadora como legítima o adecuada. Todo esto se traduce en que (y todos lo hemos visto alguna vez) puede llegar a nuestro equipo un certificado que dice ser incorrecto. Generalmente esto suele indicar o que el certificado está caducado o lo más normal, que la entidad que lo firmó no consta en la base de datos de nuestro navegador o gestor de correo o almacén de certificados… como una entidad segura, y por ello el aviso. ¿Que sucede? Que la base de datos de nuestro almacén de certificados no tiene por qué ser ni mucho menos completa.

El ejemplo más sencillo a esto es aquí en España los certificados usados por la administración pública. Dichos certificados suelen estar validados (es decir, la entidad certificadora) por la policía o la casa de moneda y timbre (la FNMT, fábrica nacional de moneda y timbre), incluido nuestro DNIe. El problema es que por defecto, las bases de datos de nuestros navegadores o equipos no tienen incluída dichas CA como entidades legítimas, lo que produce que si visitamos cualquier site que use un certificado legítimo emitido por una de estas entidades, nuestro navegador podría desde rechazar la conexión, tan solo advertirnos o por supuesto también permitir la conexión aunque el certificado no sea válido desde el punto de vista de nuestro equipo, navegador, gestor de correo… Es decir, que nuestro equipo en algún momento nos advierta de que el certificado no es válido o que supone un riesgo no tiene por qué ser cierto tampoco.

En el caso que nos ocupa, es exactamente lo mismo. El atacante podría crear un certificado propio, incluso estableciendo en él los supuestos datos del servidor al que la víctima quiere tener acceso pero firmado por sí mismo o cualquier otro “truco”. Llegado este momento, las consecuencias dependen de muchos factores, desde la configuración del equipo de la víctima, del programa que esté creando la conexión segura y por supuesto del usuario que hay detrás de la máquina de la víctima:

-Si el programa que está creando la sesión en el equipo de la víctima no impide por defecto la comunicación, el cliente puede no darse cuenta nunca de lo que está sucediendo. Este sistema sería muy inseguro, pero por otro lado el usuario no tendría que tratar con la incomodidad de toparse con CA que simplemente no tiene instalados.
-El programa que está creando la sesión puede estar configurado por defecto y sin advertir de denegar cualquier comunicación que él crea incorrecta, lo cual sería un sistema muy seguro pero tendría el problema de que muchas conexiones legítimas se impedirían, sin que el usuario fuese consciente de ello, para él simplemente no podría conectarse.
-El programa podría tener una política mixta, denegar o aceptar por defecto la conexión pero informando en tiempo real de ello al usuario, ofreciéndole la opción contraria si así lo desease. Este sería el sistema desde mi punto de vista más seguro, el problema es que muchos usuarios al acceder a una web legítima que requiera de un certificado cucha CA no se encuentra en el programa del cliente, se asustarían y no sabrían que está sucediendo, con lo que el aviso les haría cerrar la sesión por precaución, simplemente por desconocimiento de que implica dicha advertencia.

De nuevo, es aquí donde el usuario siempre juega un papel importante. Hasta que punto la víctima está preparada ante la posibilidad de un certificado falso, como actuaría. Lo aceptaría por defecto? Tendría medio y cancelaría ante una alerta? Usaría software que le advierta de los peligros o usará software que simplemente aceptará? Todo lo que dependa exclusivamente del usuario no hay respuestas, pero por suerte o desgracia de los atacantes (siempre he creído que el término Hacker es complicado de acuñar) suelen hacer antes que nada un perfil de la víctima, comenzando por conocer el software que usa, y conociendo dicho software. ¿Por qué? Por que es muy diferente saber que el navegador que usa por ejemplo rechaza por defecto cualquier comunicación TLS que parezca insegura o saber si dicho navegador la acepta sin problema!! lo mismo se puede decir del Phising, de los sites malignos, de… Por desgracia, los usuarios son muy rápidos en decidir que es mejor o peor por su estética o su uso a primera vista, y son incapaces de ver que lo importante no es eso, sino las capas de seguridad que hacen que dicho software sea seguro. Veamos ejemplos:

Firefox: Tiene una política de bloqueo por defecto, dando la opción en dicho momento de añadir el certificado a priori inseguro como un certificado seguro, mostrando antes de ello todos los datos de dicho certificado. Ojo!! no añade a la CA que lo emite como segura, solo marca dicho certificado de dicho site como válido. No obstante,  en las opciones de configuración permite la inclusión de entidades CA genuinas que no estén incluidas por defecto y que validen cualquier certificado emitido por ellas, para evitar tener que ir aceptando todo y cada uno de los certificados de cada site que usen dicha entidad.

Internet Explorer: Usa un sistema similar a Firefox, pero es más restrictivo. Para añadir dicho certificado como válido hay primero que aceptar el aviso de peligro (que claramente invita a cancelar la conexión), y más tarde habría que buscar el botón del certificado para instalarlo, y así marcarlo como seguro. De lo contrario, en cuanto el navegador se reinicie volverá a mostrar la misma advertencia.

Chrome: Usa una política casi idéntica a Internet Explorer, invita a abortar la conexión, aunque el mensaje es algo más claro que el usado por Internet Explorer. En contrapartida, es aun más difícil añadir el certificado como seguro en el caso de que estemos seguro de que dicho certificado es válido.

Quizás, de los tres navegadores el que use el sistema más molesto sea Internet Explorer, da poca información e invita a salir corriendo de dicha web, pero también sería el más seguro. Firefox da la opción de añadir el certificado en concreto como válido, lo cual ahorra muchos pantallazos de error similares para consiguientes conexiones, y además especifica el motivo por el cual el certificado no es válido. Chrome no permite añadir como un certificado seguro, pero si explica más o menos de forma sencilla el peligro o no peligro que realmente puede haber, y recomienda instalar los certificados raíces para evitar más avisos. Personalmente me quedo con el modelo de Firefox, aunque al menos, los tres métodos bloquean por defecto y hacen que no sea tan trivial el darle al “Si” de toda la vida que tantos usuarios están acostumbrados a hacer.

Por otro lado nos quedaría Safari y los navegadores de los dispositivos móviles. Safari opta más bien por un popup de advertencia que advierte del peligro de forma muy concisa. El problema, es que Safari usa un sistema de Continuar/Cancelar, y la experiencia nos dice que ante este tipo de ventanas o advertencias el usuario no suele pensarlo mucho y simplemente acepta el cartel.

En dispositivos móviles la cosa cambia, y generalmente se opta por políticas menos restrictivas. En este caso la cosa cambia:

-Safari (iPhone, iPad, iPod Touch): Por regla general acepta el certificado y no advierte de ningún tipo de problema, aunque dicho certificado sea incorrecto
-Firefox Mobile: Usa exactamente el mismo sistema que el usado por la versión tradicional.
-Chrome Mobile: Usa un popup de advertencia que nos avisa del riesgo, el problema es que como hemos dichos estos popup de “si” ó “no” generalmente se aceptan por parte de los usuarios sin preocuparse o preguntarse

Pero por supuesto no solo se limita a navegadores, tenemos del mismo modo gestores de correos, conexiones VPN, conexiones remotas, software que usa estos sistemas para dar un acceso supuestamente seguro a los datos… y cada uno de dichos programas se comportará según sus programadores. Y siempre, sin perder de vista al usuario final, que es quien suele tener siempre la última palabra ante cualquier riesgo de seguridad. Veamos una última imagen ilustrando el robo de una sesión TLS de un HTC Desire accediendo a Gmail:

Evidentemente el host “dTheliel” de este ejemplo corresponde a un dispositivo completamente diferente al que realizó la captura y la manipulación, el cual se aprovechó de un ataque de envenenamiento ARP. Un ejemplo de como incluso los protocolos seguros como TLS/SSL son vulnerables a ataques tipo “man-in-the-midle”. En este caso, tan solo una pantalla de advertencia en el dispositivo portátil avisaba de un posible certificado incorrecto, advertencia que como hemos dicho en muchos dispositivos ni siquiera aparece, quitando por supuesto el darle a sí directamente que hace la gran mayoría. En la sesión robada, en los datos eliminados de la imagen por motivos evidente, se podía encontrar no solo la cookie de sesión (que simplemente con ella bastaría para acceder a su correo), sino su correo y su contraseña en “plano”, y lo pongo entre comillado porque dichos datos no se enviaron en texto plano, sino en una sesión completamente cifrada bajo TLS (para la autentificación) y RC4 como algoritmo de cifrado de todo el contenido, no solo el nombre de usuario y la contraseña. Este ejemplo puede extrapolarse a cualquier situación en la que se realicen conexiones seguras o túneles por medio de certificados.

 

No hay que sacar en conclusión que los protocolos seguros no lo son, sino que por buenas que sean las medidas de seguridad que existen a día de hoy, más importante es la educación a nivel particular de cada usuario. El ataque anterior habría sido imposible de llevar a cabo si la víctima (en este caso yo mismo) me hubiese parado a pensar en la advertencia de seguridad que mi navegador lanzaba, a ver me parado en ver los detalles de esta y habría comprobado el motivo por el cual el certificado no era válido. En consecuencia, si una víctima hubiese tomado dicha molestia, simplemente habría impedido la conexión a dicho site y nada hubiese sucedido.

 

 

Un apunte sobre WIFI y otras conexiones Wireless

Antes de terminar este capítulo, hay que hablar de las redes WIFI.

Todo lo que hay detrás del Sniffing a fin de cuenta es siempre lo mismo, una técnica que permita conocer los datos que hay a nuestro alrededor. Pero la libre circulación de estos datos depende en última instancia del medio por el cual son transferidos. Podemos capturar tráfico que sale y entra de nuestro equipo porque estos datos llegan a este, y lo mismo cuando estamos conectado a un Hub o usamos técnicas de envenenamiento ARP en un Switch, ya que cuando el ataque está en curso podemos ver nuestro equipo como si estuviese conectado directamente a las víctimas. Pero con las tecnologías inalámbricas estos problemas no existen!! El medio en estas redes es el aire, y todos los equipos que están en su rango, absolutamente todos, reciben por igual la información, no existe un cable que conecta punto a punto dos equipos, la información se transmite al aire.

GSM, 3G, WIFI, Bluetooth… cualquier tecnología que use el aire como medio de transmisión es directamente vulnerable al Sniffing, a fin de cuenta tan solo hay que tener un dispositivo que soporte dicha tecnología que esté escuchando. Esto es bien conocido, por eso estos protocolos, al contrario que los que vieron nacer internet, son constituidos de base pensando en la seguridad. Esto no quiere decir sin embargo que todas estas tecnologías sean completamente vulnerables ante agentes externos, solo que hay que tener más cuidado con ellas. Posiblemente, las dos redes Wireless más comunes a día de hoy sean las redes telefónicas GSM y las redes WIFI.

Si hablamamos de redes WIFI casi todos habrán escuchado en algún momento que es posible robar WIFI, o incluso más actual la extensión de Firefox que permitía robar sesiones de usuarios de aquellas redes WIFI que estaban abiertas. Para evitar que cualquiera pueda capturar de forma simple aquellos datos que no iban destinado a ellos, se suelen usar sistemas de autentificación y cifrado. En el caso de WIFI, el primero y aun usado de forma mayoritaria aquí en españa, WEP, es a día de hoy un sistema roto. Los protocolos WIFI se fueron actualizando con los años añadiendo sistemas de seguridad mejores, hasta llegar a día de hoy con el sistema WPA2 y extensiones de seguridad para entornos más seguros. Pero que existan estos cifrados o métodos de enmascaramiento, no implica que los datos sean recibido por todos los usuarios, solo significa que dichos usuarios no entenderán nunca el contenido. Es evidente que la primera medida de precaución que se tendría que tener ante un dato sensible es el no comunicarlo a quien no vaya dirigido, pero en el caso de las redes inalámbricas esto no es posible.

Podemos hablar también de las redes GSM, actualmente usadas a nivel mundial para la comunicación telefónica. En realidad sucede lo mismo!! los datos son transmitidos desde las torres de forma omnidireccional hasta alcanzar aquel terminal que está emitiendo o recibiendo dichos datos. En teoría, cualquier usuario que esté en rango de dicha torre recibiría igualmente esos datos. Esto abre rápidamente la cuestión sobre si es posible sniffar (capturar) conversaciones telefónicas, y la respuesta es evidente… claro que se puede. Con equipo básico es posible crear un capturador de de señales GSM, lo cual de nuevo no implica que las señales o los datos obtenidos tengan ningún tipo de significado o validez para aquellos a los cuales no estaba destinado dicha comunicación. No obstante, no hay que ser muy listo para tener la certeza absoluta de que es posible (y se hace) realizar escuchas telefónicas realizadas por GSM. Es más, recientemente se hizo público y se mostró una serie de vulnerabilidades que permitirían capturar cualquier conversación telefónica GSM por medio de un pequeño dispositivo dedicado para tal afecto que no sería caro de fabricar (no llegaría a los 1200€), y un par de antenas.

 

 

Es evidente que es el juego del ratón y el gato que nunca termina. Con los años nuevas mentes y sistemas darán jaque a las tecnologías actuales,  y entonces nuevas tecnologías emergerán para hacer frente a las antiguas. Y esto posiblemente se suceda durante aun muchos años. Redes inalámbricas, redes cableadas… incluso se conocen de estudios que logran capturar el tráfico que circula por los cables Ethernet o de fibra sin estar conectados a ellos, simplemente por medio de los cambios electromagnéticos que producen los datos al circular por los cables. Un obseso con la seguridad puede ser un paranoico, pero aquel que se toma la seguridad como algo ilusorio es un loco