Sniffing

Cuando hablamos de este término a todos nos viene a la cabeza la captura de tráfico de una red, pero no tiene porqué ser así, realmente este término puede estar aplicado a cualquier medio por donde se transmita información.

Voz

Cualquier información que se transmita de forma hablada es susceptible de ser interceptada, podemos hacer la siguiente recopilación dependiendo del medio de transmisión.

Aire

Existen numerosísimos artilugios para espiar conversaciones, éstos son algunos de los más interesantes:

• Dispositivos de escucha mediante GSM: Es un dispositivo en el que se introduce una tarjeta SIM y tienen un micrófono, pero no altavoz. Te permiten escuchar lo que pasa a su alrededor simplemente llamando al número de teléfono de dicha tarjeta. Algunos modelos disponen de un modo automático que realiza una llamada a un número de la agenda cuando detectan sonido.
  • GSM Dual-Band Cellular Network Bug (900Mhz/1800Mhz)
  • Two-Way Spy Audio Device with Auto Call Feature
  • Professional High Sensitive Spy Audio Bug

• Micrófonos laser: Permiten capturar las vibraciones de una superficie (por ejemplo un cristal o un espejo) haciendo haciendo incidir un haz laser en ella y capturando su reflejo con una detector. Existen variantes de esta técnica que podéis ver aqui. Lo interesante de este método es que permite hacer escuchas a grandes distancias sin tener acceso físico.
  • SPECTRADOME
  • Build a Laser Spy Microphone On the Cheap

  

• Otro tipo de micrófonos:
  • Micrófonos direccionales
  • Para escuchar a través de paredes
  • Ocultos (algunos con vídeo), 2, 3

Teléfono

No me voy a meter en historia, porque podéis encontrar kilos de literatura sobre este tema, me referiré sólo a los campos actuales que me parecen interesantes:

• Sniffing VoIP: Consiste en capturar las tramas de Voz sobre IP, recomponerlas y decodificarlas para capturar una conversación telefónica.
  • Sniffing VoIP Using Cain
  • Sniffing VOIP with Wireshark
  • VoIP Sniffing Tools
• GSM Hacking:
  • A5/1 Security Project
  • GSM – SRSLY?

Monitor CRT/LCD

Estas técnicas son poco conocidas y supongo que por eso muy curiosas. La idea básica es reproducir la imagen que emite un monitor remotamente capturando las emisiones electromagnéticas que emite. Este tipo de ataque se denomina TEMPEST y son de tipo pasivo, aquí tenéis un poco de historia.

• LCD
• CRT

Teclado

Mi favorito, sin duda.

Física

La manera más sencilla de capturar las pulsaciones de un teclado es mediante un keylogger hardware. Este tipo de aparatos se conectan entre el PC y el teclado; y graban, en una memoria interna, todo lo que pasa a través de ellos.

• Keelog: USB, PS/2, módulo interno.

Teclados Wireless

Se está trabajando bastante en esto y ya hay resultados excelentes. La gente de remote-exploit.org publicó hace tiempo Keykeriki, que si no recuerdo mal, funcionaba con teclados inalámbricos Microsoft. Ahora están preparando la versión 2, que funcionará para “todo” tipo de teclados y, según he entendido, harán pública durante la CanSecWest Vancouver 2010

• Keykeriki V2

Otros métodos

Existen otras maneras más esotéricas de conseguir las preciadas pulsaciones:

• Compromising Electromagnetic Emanations Of Wired And Wireless Keyboards: Esta me encanta, es un método tempest (bueno, en realidad 4 métodos) para obtener las pulsaciones de un teclado capturando las emisiones electromagnéticas que emana, filtrándolas y decodificándolas. Os recomiendo el paper.
• Keyboard Acoustic Emanations: Muy interesante, capturando el sonido que producen las teclas al ser pulsadas, un atacante puede identificar el texto tecleado con bastante éxito.

Y hasta aquí por hoy, continuará…

Como consecuencia, me llamó la atención la idea de automatizar este tipo de procesos para elimiar el factor tiempo. Se me ocurrió que si fuera posible hacer un dispositivo que, conectado al USB o PS/2, se comportase como un teclado con la salvedad de que en vez de enviar caracteres al PC generados al pulsar teclas, enviara secuencias de caracteres que leyera de ficheros; estaríamos ante un arma muy potente ( casi tanto como un palo con un clavo!)

Aclaración: La idea no es hacer un dispositivo para hacer fuerza bruta. Sino un dispositivo, que al conectarse a un sistema en el que no hay protección (un windows sin bloquear sesión, una consola de linux, etc), ejecute los mismo comandos que podría ejecutar cualquier persona, pero a gran velocidad. Lo que nos da una capacidad muy grande para hacer ataques. Véase echopy.

Implementación

Estoy usando un microcontrolador PIC18F4550 montado sobre una placa de desarrollo OLIMEX que he comprado en www.sparkfun.com. Es un cacharrito simple que hace justo lo que necesito, dispone de:

• PIC18F4550
• Puerto USB
• ICSP (Aunque no es necesario para programarlo porque viene con un bootloader precargado que te permite cargar usando USB directamente)
• Un pulsador
• Un led

  

Modificando el código de ejemplo que venía con la documentación he conseguido que se comporte como un dispositivo HID de teclado y que escriba a unos 1000 caracteres por segundo. ¡Increible!

El siguiente paso ha sido modificar nuevamente el programa para que lea los caracteres que debe enviar de un array.

Es interesante mencionar que los codigos HID no son iguales al código ASCII y he tenido que programar un pequeño script que transforma ficheros TXT a arrays de codigos HID. Lo tenéis aqui: txt2hid.pl

Futuro

Sigo desarrollando y pronto montaré en la placa un lector de tarjetas MMC para que lea de este tipo de dispositivos los caracteres que debe enviar y así no será necesario reprogramar cada vez que quiera cambiarlos. Además de que podrán ser series mucho más largas.

Sería interesante desarrollar un GUI para poder autogenerar los ficheros que debe leer el PIC, dependiendo de: el sistema operativo al que se quiera conectar, versión, ataques que se quieran hacer, etc.

Pronto publicaré los esquemas y el código para que os montéis vuestro propio Címbulo.

Otros usos

Este cacharro tiene otros posibles usos a parte de los malignos ya mencionados, como por ejemplo, automatizar taréas repetitivas: Configuraciones de bios, instalaciones…

Usando este mismo PIC se pueden emular otros tipos de dispositivos, conversores RS232, dispositivos de almacenamiento, etc; que se podrían usar en combinación con los comandos ejecutados por teclado. Por ejemplo, montar un disco de almacenamiento emulado y volcar el resultado de una ejecución.

Documentación y referencias

1. http://www.electronicfr.com/index.php/Microcontrollers-and-USB/Part-1-How-to-build-a-USB-device-with-a-PIC-18F4550-or-18F2550.html
2. http://www.edaboard.com/ftopic313796.html
3. http://www.sparkfun.com/commerce/product_info.php?products_id=8562
4. http://www.edaboard.com/ftopic214195.html
5. http://www.beyondlogic.org/usbnutshell/usb1.htm
6. http://blog.bricogeek.com/noticias/electronica/mini-sistema-operativo-para-pic-18f-y-tarjeta-mmc/

El script hace lo siguiente:

1. Lee el fichero pasado por parámetros.
2. Lo codifica en base64 y escribe comandos del tipo “echo [base64] >> fichero.b64″
3. Escribe un script de VB que es capaz de decodificar el fichero copiado en base64; usando comandos echo.
4. Ejecuta el script de decodificacion y borra los ficheros temporales.

Toda esta serie de comandos generados se guardan en un fichero de texto.

El resultado tiene esta pinta:

cd %TEMP%

echo /9j/4AAQSkZJRgABAQEAYABgAAD/4QAWRXhpZgAATU0AKgAAAAgAAAAAAAD/2wBDAAUDBAQE > file.b64

echo AwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIe >> file.b64

echo JBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e >> file.b64

[...]

echo c6+moJUUWWoc8QGR3dsZo4i5V5FI+WxlcGi3IqKKUVmSM/CLac073gMsCoooqnNd8BHTZYut >> file.b64
echo JNbGb/ulRREiEoXUUWWwLroXUURAJ1UUUQf/2Q== >> file.b64
echo Option Explicit > base64.vbs
echo Dim a, inFile, outFile, b64Enc, b64Dec, s, DM, EL >> base64.vbs
echo Set a = WScript.Arguments >> base64.vbs
[...]
cscript base64.vbs file.b64 yofoto.jpg
del base64.vbs file.b64

Espero que os sea útil.

Descargas

echopy: Codifica ficheros en series de comandos de DOS

Para los que no lo conozcais EICAR (Standard Anti-Virus Test File) es un fichero de texto que se puede ejecutar como un .COM; no es ningún código malicioso, ya que está desarrollado a propósito para el testeo de antivirus, y por lo tanto, es detectado por el 100% de los antivirus.

EICAR tiene esta pinta:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Si copias y pegas esa cadena en un fichero con extension .COM (sin más caracteres que la cadena), y lo intentas guardar, seguro que tendrás un aviso de tu antivirus… ¿Pero qué pasa si automatizamos esto para que se haga cientos de veces por segundo? ¡Pues cosas bastante curiosas!

insaneicar

Es mi implementación de una herramienta de estrés de antivirus. Su función es crear subdirectorios en el directorio donde se ejecuta y dentro de estos miles de copias de EICAR. Se pueden lanzar varias instancias a la vez acelerando el proceso.

Como no he tenido la oportunidad de probarlo en diferentes antivirus os agradecería que lo probárais y me mandaseis una descripción del comportamiento del antivirus y unas capturas de pantalla

Por cierto, si lo ejecutais dentro de una unidad compartida podeis divertiros un rato

Descargas

• insaneicar.c: Código fuente Windows/Linux
• insaneicar.exe: Ejecutable para Windows

Para empezar he subido msntunnel.py, este pequeño script permite conectarte a un puerto de un host remoto usando como pasarela una conexion de MSN Messenger.

Teoría

La teoría es bien simple, en la máquina origen de la conexión se pone un puerto a la escucha que es leido por msntunnel.py, cada uno de los paquetes que se leen en ese socket se codifica en base64 y se mandan usando una cuenta de messenger como un mensaje de chat a una segunda cuenta de messenger manejada por otro proceso msntunnel.py en el host remoto,  el mensaje se decodifica y se envía al host (normalmente localhost) y puerto de destino.

Ejemplo

No os distraigais con el pedazo de esquema que he hecho con el Dia; os pongo un ejemplo.

Digamos que tenemos dos cuentas de MSN Messenger (host_a@hotmail.com y host_b@hotmail.com) previamente asociadas entre si como contactos.

Si quisiéramos conectarnos al puerto 22 de HOST B desde HOST A haríamos lo siguiente:

En HOST A:

root@host_a# python msntunnel.py -u host_a@hotmail.com -p passhosta -r host_b@hotmail.com -L 2222

En HOST B:

root@host_b# python msntunnel.py -u host_b@hotmail.com -p passhostb -r host_a@hotmail.com -R 127.0.0.1 -P 22

Una vez ejecutados estos comandos en sus respectivas máquinas deberíamos tener el puerto 2222 abierto en HOST A que corresponde con el puerto 22 en HOST B.

Ventajas

• La ventaja principal de este tipo de tunneling es que no es necesario conocer la dirección IP de la máquina destino ya que todo el routing de mensajes se hace a través de un servidor externo.
• Otra de las ventajas es que no existe comunicación directa entre las máquinas y por lo tanto es un poquito más dificil de rastrear.

Limitaciones

• En esta versión no se verifica que el tamaño del paquete codificado en base64 sea lo suficientemente pequeño para que el protocolo de messenger lo admita, por lo tanto los paquetes grandes dan un error de envio (más bien creo que no llegan xD). Lo dicho, como ésta versión falla con paquetes grandes, lo mejor es que la probeis con algo como SSH o quizas sea suficiente con bajar el MTU de loopback (no lo he probado).
• Otra limitación es la velocidad que se ve bastante afectada.
• El canal de comunicación es controlado por un tercero (Microsoft) por lo que la modificación/intercepción/almacenamiento de la comunicación es posible para el.

Posibilidades

• No sería demasiado complicado reescribir modificar el código para usar interfaces TUN en vez de sockets y así poder tener más libertad en la conexión.
• Otra mejora interesante sería permitir la comunicación simultanea con más de una cuenta de messenger de la lista de contactos y así tener un auténtico servicio de VPN sin un servidor dedicado (OpenVPN/Hamachi por messenger x”D).
• Incluir otros servicios de mensajería instantanea como jabber, icq, irc…

Descargas

• msntunnel.py
• msnlib: a Python MSN messenger protocol library and client (dependencia)

Al ataque!!