Hace no mucho los servicios de microblogging como twitter no me gustaban. Empero, he aprendido a vivir con ellos (incluso ahora me gustan un poquito), y a sacarles provecho.

¡Empecemos a jugar! Vamos a implementar una pequeña idéa (gracias WorldDebug y PabloForThePPL por el brainstorming!) que puede sernos muy útil.

Dicha idéa consiste en un bot asociado a una cuenta de twitter, que hará búsquedas periódicas de trending topics y seleccione tweets sobre estas búsquedas que cumplan dos condiciones:

• Que contengan un enlace.
• Que no mencionen a ningún otro usuario. (no contengan @)

Estos tweets se almacenarán y, después de un tiempo aleatorio, el bot los publicará modificando la URL.

1. El bot busca los temas del momento.
2. Para cada tema se hace una búsqueda en twitter.
3. En los resultados seleccionaremos tweets que contengan URLs pero no el símbolo @ (para no mencionar usuarios).
4. Guardaremos esos tweets junto con una marca de tiempo.
5. Después de recorrer los temas de la lista, generaremos nuevas URLs malintencionadas para cada tweet y los publicaremos.

Por otra parte, desarrollaremos un script PHP que presente cierto contenido (configurable) y después redirija al usuario a otra URL pasada por un parámetro GET.

El proceso para crear la URL maligna es el siguiente:

1. Partimos de la URL ORIGINAL CORTA que encontramos en el tweet que estamos copiando.
2. Creamos la URL MALIGNA pasando por parámetros la URL anterior.
3. Volvemos a hacer corta la URL y obtenemos la URL MALIGNA CORTA

A simple vista es imposible que el usuario detecte el cambio de URL (siempre que el usuario no sea Chuck Norris; ¿sabías que GOOGLE es una neurona de Chuck?).

Una vez que el usuario haga click en el enlace la carga de páginas será en sentido contrario al del gráfico anterior:

URL MALIGNA CORTA -> URL MALIGNA -> URL ORIGINAL CORTA -> URL ORIGINAL

Cuando el navegador del usuario cargue la URL MALIGNA tendremos la oportunidad de mostrarle el contenido que queramos.

Diseño

Una pieza clave de nuestro bot es la interacción con Twitter. Tenemos dos opciones, cada una con sus ventajas y desventajas:

• Utilizar una libraría estandar como python-twitter.
  • PROS:
    • Nos permite hacer las cosas de “la manera correcta”.
    • Utiliza oAuth así que el interfaz no debería cambiar.
  • CONTRAS:
    • Es una API específica para aplicaciones, twitter sabrá que somos un bot y, por lo tanto, no podremos hacer cosas raras (como nuestra pequeña idéa).
• Usar Selenium y un navegador web.
  • PROS:
    • Estaremos utilizando un navegador web para que nuestro bot interactue con Twitter, ¡pareceremos un usuario más!
  • CONTRAS:
    • Cualquier cambio en el interfaz web de Twitter puede afectar al funcionamiento de nuestro bot.
    • Necesitamos tener un navegador abierto, esto es molesto ( a menos que lo tengamos en una máquina virtual, recomendado) y además consume muchos más recursos.

Como nuestra idéa está orientada al mal }:~) optaremos por la segunda opción. Por otra parte, hay suficientes tutoriales en Internet  sobre la API de twitter, asi que no os costará mucho encontrar información. Decidido pues, utilizaremos Selenium.

Utilidad

Estos son los posibles usos (se aceptan sugerencias) :

• Lanzar exploits contra los navegadores de los usuarios. Esta es de cajón. :)
• Abrir frames con otros contenidos (publicidad).
• Abrir frames ocultos para realizar peticiones masivas a servidores web y así crear denegaciones de servicio distribuidas (DDOS).
• Hacer que el usuario resuelva un captcha (que necesitemos resolver para otro bot) antes de ir al contenido.
• XSRF

Empezamos con algo divertido, ¿no os parece? :) .

Hasta aquí la teoría, en los siguientes artículos veremos como implementar todo este tinglao.

Es bastante dificil hacer una definición formal, porque es un término que engloba muchas cosas, pero yo diría que un bot es un programa diseñado para realizar tareas repetitivas, en muchas ocasiones imitando el comportamiento humano, y en la mayoría de los casos, utilizando recursos externos. Un tipo especial de bots son los crawlers (arañas, spiders…), su misión reunir información, normalmente recorriendo internet, y procesarla de distintas maneras. Los términos bot y crawler se suelen usar como sinónimos.

Un ejemplo de crawler que todos conocemos es GoogleBot: recorre la Red e indexa páginas web y documentos para el buscador Google.

Vamos a empezar esta pequeña serie de desarrollo de bots enumerando las herramientas básicas que necesitaremos para crear nuestros bichitos…

Firefox

Todos lo conocéis. No tiene rivales en cuanto a complementos se refiere. Y eso es lo que necesitamos, pequeñas utilidades que nos den acceso rápidamente a la información que deseamos. ¿Para qué rompernos la cabeza?

Firebug

Creo que este plugin para firefox es lo mejor que nos ha pasado a los desarrolladores web después de la cafeína. Puedes ver y editar cualquier parte de una web en vivo, desde el css al javascript. ¡Genial!

TamperData

Este plugin te permite interceptar las peticiones que salgan de tu navegador y ver todos los detalles del HTTP, desde el referer hasta los parámetros POST. No es lo mejor que hay para esto, pero es el que he usado desde hace mucho tiempo, y le tengo cariño.

XPather

Otro plugin para firefox, selecciona cualquier elemento de la página, pulsa botón derecho y tendrás al momento su xpath. Imprescindible.

Python

A día de hoy recomiendo la versión 2.7.x en 32 bits.

Dreampie

La consola interactiva para Python con la que siempre soñastes. ;)

Selenium

Está pensado originalmente para automatizar pruebas sobre páginas web usando un navegador real, pero es tan potente que podemos utilizarlo para muchas maldades.

Además, si eres más vago que un charco, existe un plugin para firefox con el que puedes guardar tus acciones directamente en el lenguaje que quieras (Selenium IDE).

Sikuli

Automatiza cualquier cosa que se te ocurra dentro de un entorno gráfico utilizando capturas de pantalla y jython. Una gran idea.

Y esto es todo por hoy. Como soy un desastre estoy seguro de que se me habrán olvidado la mitad de las cosas, pero a medida vaya escribiendo iré actualizando el post.

Voy a proponerme escribir todas las semanitas un post, y para los que tengáis un problema más serio con esto del onanismo virtual os dejo por aqui mi nuevo y flamante twitter, donde podréis leer hasta cuando hago mis cositas en el baño.
Ale, que agusto me he quedao. No, si esto va a relajar y todo al final.

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 :D

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!!