martes, 24 de junio de 2014

Mercury: auditoría de aplicaciones Android


Una de las herramientas que más nos llamaron la atención de la última BlackHat Europe es la que presentó Tyrone Erasmus en su ponencia 'The Heavy Metal That Poisoned the Droid' (whitepaper y slides).

Se llama Mercury de MWR Labs y es un framework gratuito que ayudará a los "cazadores" de bugs a encontrar vulnerabilidades, escribir exploits PoC y, en definitiva, a jugar con Android.

Se trata de una herramienta que nos permitirá examinar de forma dinámica y a explotar las posibilidades de ataque de las aplicaciones que residen en un dispositivo Android. Se divide en dos partes: una aplicación servidor que requiere pocos privilegios y se instala en el teléfono y un cliente escrito en Python para interactuar con el servidor desde la línea de comandos.

Características

El principal objetivo de Mercury es ser una herramienta de auditoría que pueda utilizarse con muchos propósitos. Algunas de sus características nos permitirán:

- Encontrar más fácilmente información relevante acerca de los vectores de ataque de una aplicación
- Interactuar con los 4 endpoints IPC (actividades, broadcast receivers, proveedores de contenido y servicios) de una aplicación desde la línea de comandos con el fin de encontrar vulnerabilidades
- Jugar con el sistema operativo Linux desde el punto de vista de una aplicación sin privilegios (sorprende lo mucho que se pueden ver)
- Encontrar información sobre los paquetes instalados con filtros de búsqueda opcionales que permiten un mejor control
- Subir y bajar ficheros sin usar ADB (¡esto incluye poder hacerlo a través de Internet también!)
- Escribir nuevos módulos con exploits para las vulnerabilidades encontradas por medio de una rango de comandos predefinidos, y utilizar los módulos que otros hayan creado

Requisitos previos


- Teléfono o emulador con Android 2.2 o superior
- PC con Linux y Python 2.7 – (el autocompletar de comandos no funciona en Windows)

Instalación
- Descarga el zip desde aquí http://labs.mwrinfosecurity.com/assets/254/mercury-v1.0.zip
- Instala el servicio server/mercury.apk en el teléfono e inícialo:


- Arranca el cliente client/mercury.py en el PC
vmotos@linux-nsl1:~/Descargas/client: ./mercury.py
- Conecta con el servidor Mercury:
  • Si tenemos conectado el teléfono al PC por USB o estamos usando un emulador, necesitaremos redireccionar el puerto 31415 (puedes hacerlo con el comando ‘adb forward tcp:31415 tcp:31415’)
  • Si nos vamos a conectar al teléfono por la red inalámbrica, necesitaremos obtener la IP del teléfono, en nuestro caso la 192.168.1.35
- Escribimos en el cliente "connect" seguido de la dirección IP del teléfono (127.0.0.1 si utilizamos un emulador o lo tenemos conectado por USB al PC)
mercury: connect 192.168.1.35
Commands - type help for more info
--------------------------------------------
activity broadcast help packages service tools
back debuggable modules provider shell

Empezando a jugar con Mercury


Cuando buscamos fugas de información en un dispositivo Android, los proveedores de contenido exportados son un buen comienzo. Dentro de la sección 'provider', con 'info -p null' obtendremos un listado de todos estos proveedores y sólo tendremos que ver aquellos que no requieran permisos para leerlos (Required Permission - Read: null o Required Permission - Write: null).

El desarrollador de una aplicación tiene que configurar específicamente 'android:readPermission' o 'android:permission' en el proveedor de contenidos dentro del fichero 'AndroidManifest.xml' si no quiere que la información sea accesible por otras aplicaciones del dispositivo. Si no lo hace, a veces no encontraremos información delicada y otras veces encontraremos datos que al desarrollador no le gustaría que leyéramos.
*mercury: provider
*mercury#provider: info -p null

Package name: com.sec.android.app.callsetting
Authority: com.sec.android.app.callsetting.allcalls
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false
Una vez que seleccionamos la aplicación objetivo, el siguiente paso será obtener las direcciones de sus contenedores (content URI). Para ello utilizaremos el comando 'finduri':
*mercury#provider: finduri com.sec.android.app.callsetting

/system/app/CallSetting.apk:
Contains no classes.dex

/system/app/CallSetting.odex:
content://com.sec.android.app.callsetting.allcalls/prefix_num
content://com.sec.android.app.callsetting.allcalls/reject_msg
content://com.sec.android.app.callsetting.allcalls/reject_num
Para mostrarnos esta información el comando finduri ha tenido que seguir los siguientes pasos para la enumeración:
- Encontrar la localización del fichero APK
- Descomprimir el fichero classes.dex situado dentro del APK (si no lo hubiera, buscaría los ODEX del paquete)
- Emplear código similar al string de UNIX para encontrar todas las cadenas válidas dentro del binario (fichero DEX u ODEX)
- Filtrar la salida final parseando las cadenas con content://.

Ahora que tenemos las direcciones de los contenedores, con query podemos leer su contenido. Por ejemplo:
*mercury#provider: query content://com.sec.android.app.callsetting.allcalls/reject_msg

_id | reject_message | edit_checked
.....

1 | Lo siento, estoy ocupado. LLámame más tarde | 2131165242

2 | Estoy en una reunión | 2131165243

3 | Estoy en clase | 2131165244

4 | Estoy en el cine | 2131165245

5 | Estoy conduciendo | 2131165246
E incluso realizar inyecciones SQL:
*mercury#provider> query content://com.sec.android.app.callsetting.allcalls/prefix_num --projection "'"

unrecognized token: "' FROM prefix_num": , while compiling: SELECT ' FROM prefix_num

*mercury#provider> query content://com.sec.android.app.callsetting.allcalls/prefix_num --projection "* FROM SQLITE_MASTER--"

type | name | tbl_name | rootpage | sql
.....

table | android_metadata | android_metadata | 3 | CREATE TABLE android_metadata (locale TEXT)

table | prefix_num | prefix_num | 4 | CREATE TABLE prefix_num (_id INTEGER PRIMARY KEY AUTOINCREMENT, prefix_number TEXT NOT NULL,prefix_checked INTEGER)

table | sqlite_sequence | sqlite_sequence | 5 | CREATE TABLE sqlite_sequence(name,seq)
Y esto es sólo una muestra de lo que se puede hacer con Mercury. Os aconsejamos que lo probéis y compartáis con nosotros vuestra experiencia. Podéis probar y probar, lanzar los módulos que vienen ya precargados o crear los vuestros propios.

Por nuestra parte,
más adelante publicaremos otra entradas relacionadas con esta fantástica herramienta :)

Fuente: http://www.hackplayers.com/2012/03/mercury-framework-para-la-auditoria-de.html

Hooker – análisis dinámico de aplicaciones Android

Hooker es un proyecto de código abierto para el análisis dinámico de aplicaciones Android. Este proyecto facilita varias herramientas y aplicaciones que pueden usarse para interceptar y modificar cualquier llamada al API hecha por la aplicación objetivo. Aprovecha el framework Android Sustrate para interceptar esas llamadas y agregar toda su información contextual (parámetros, valores devueltos, ...) en una base de datos con búsqueda elasticsearch. Se pueden utilizar varios scripts en Python para automatizar la ejecución de un análisis con el fin de recolectar cualquier llamada al API realizada por un conjunto de aplicaciones.

Hooker está compuesto de varios módulos:

- APK-instrumenter: la aplicación que debe instalarse antes de realizar un análisis en un dispositivo Android (por ejemplo, un emulador).
- hooker_xp: es una herramienta en Python para controlar el dispositivo Android y preparar la instalación y ejecución de una aplicación en él.
- hooker_analysis: es un script en Python para recoger los resultados almacenados en la base de datos elasticsearch.
- tools/APK-contactGenerator: es una aplicación Android instalada por hooker_xp para inyectar datos falsos de contactos.
- tools/apk_retriever: es una herramienta en Python que puede usarse para descargar APKs desde varios markets online.
- tools/emulatorCreator: es un script que puede usarse para preparar un emulador.
 

Descarga Hooker

Fuente: http://www.hackplayers.com/2014/06/hooker-analisis-dinamico-de-apps-android.html

miércoles, 18 de junio de 2014

Auditar la WiFi del hotel con resaca y un jailbroken iPhone

Durante estas vacaciones de Semana Santa regresé a mi querida isla de Tenerife para disfrutar de unos días de vacaciones con la familia. Como el objetivo de estos días era desconectar de la frenética actividad a que nos lleva esta vida en el mundo de la seguridad informática, decidí dejar el ordenador portátil en casa, y disfrutar de estos días de playa, relax y algo de copas en alguno de los locales de moda de la isla.


Figura 1: Uno de los locales de moda en la isla de Tenerife.

Tras una noche de fiesta me desperté a eso de las 9:15 con la cabeza apunto de estallar, a causa del famoso Ron Arehucas de Canarias, pero mi insomnio crónico no me dejaba dormir, así que como no tenía ninguna computadora a mano, cogí el teléfono móvil y me puse a teclear para ver qué había pasado por Internet. Tras revisar los feeds RSS de seguridad y leer un post del blog del Maligno, reparé en que el hotel en el que me alojaba disponía de una red WiFi privada según nos habían dicho. Como no tenía mucho que hacer, me entretuve en saber cuál sería el nivel de seguridad que ellos entendían por privado.


Figura 2: Portal Cautivo WiFi del hotel.

Al abrir el navegador tras conectarme a la red inalámbrica, apareció el clásico portal cautivo en el que debía introducir mis credenciales. Lo primero que me llamó la atención fue el nombre del host que aparecía en la URL de login: “gateway.example.com”. Lo siguiente que hice fue consultar el direccionamiento de la red WiFi a la que me había conectado en el apartado de Ajustes de mi iPhone, para ver si el portal estaba aplicando aislamiento de clientes a nivel IP:


Figura 3: Direccionamiento de la red WiFi del hotel

Como se puede observar en la imagen, la máscara de subred que se aplica para esta red es “255.255.0.0”, por lo que hablamos de una red de clase B con direccionamiento “192.168.0.0” y no sólo el portal cautivo o la puerta de enlace son accesibles, sino también el resto de equipos.

Además del nombre del hotel, he tapado el nombre que aparece en el apartado de dominios de búsqueda, pues parece que corresponde al de la empresa que instaló y configuró esta red. No obstante, centré mi atención en el nombre de servidor del portal, “gateway.example.com”, así que abrí la aplicación Terminal instalada en mi dispositivo con jailbreak para realizar un ping al host:


Figura 4: Dirección del servidor gateway.example.com

La respuesta al comando ping situaba la dirección IP del portal en la “192.168.2.1”, así que el siguiente paso fue hacer una petición directamente al servidor sin utilizar el nombre de host, para ver si se veía algo diferente:


Figura 5: Portal de administración de Hotspot 4ipnet

Lo que se veía en el navegador ahora ya no era la página de inicio de sesión en el portal cautivo, sino la página de administración del dispositivo que implementaba dicho portal, y que como se puede observar era del fabricante “4ipnet”. No pude reprimirme, y el siguiente paso fue buscar rápidamente en Google las credenciales por defecto, que tanto juego dan en muchos casos, para el usuario administrador de estos dispositivos:


Figura 6: Manuales de dispositivos 4ipnet con credenciales por defecto

Quería comprobar, que en efecto los administradores habrían cambiado la clave por defecto. Y en efecto, afortunadamente la combinación “admin” “admin” que se puede observar en la mayoría de manuales para los productos de 4ipnet me devolvió un mensaje de “Contraseña incorrecta. Siga probando :( “

Como también tenía instalada en mi iPhone el escaner de red para iPhone Scanny, y como este tipo de dispositivos ofrece habitualmente más servicios además del HTTP para la administración de los mismos, decidí comprobar qué otros puertos estaban abiertos:


Figura 7: Escaneo de puertos del servidor con Scanny

Además de HTTP, HTTPs y PPTP, también se podía acceder al host mediante ssh. En ese momento recordé que al buscar la contraseña por defecto para los dispositivos de este fabricante, visualizando el avance del texto para el primero de los resultados se podía entrever que además del usuario admin, existía una cuenta de root.

Si el administrador de la red WiFi privada del hotel había cambiado la password de administrador, lo suyo es que hubiera hecho los deberes y cambiado también de la de root. Si no fuera así, para un posible atacante de esta red WiFi privada sería tan fácil como elegir él mismo cómo quiere configurarse la red. Volví a abrir el Terminal, para intentar conectarme por ssh al hotspot utilizando la cuenta de root, y la clave por defecto “admin”..... Owned! Cual fue mi sorpresa al ver que éste me recibía con los brazos abiertos:


Figura 8: La clave de root no estaba cambiada

En este instante me levanté sobresaltado, con el móvil en la mano y el post de El Lado del Mal que había comenzado a leer en la pantalla. La red WiFi privada había pasado a ser un entorno inseguro donde simplemente con el móvil desde la cama y en unos minutos, un atacante podría tener acceso completo a la consola del servidor que administra la red WiFi del hotel, para desde ahí poder hacer cualquier tipo de maldad: robar información, instalar una backdoor, saltar a otros servidores o clientes de la red... al estilo NSA. Nada de cosas "complicadas" como atacar WPA/WPA2, hacer cracking de las claves WPA/WPA2 o romper un hash MS-Chapv2 PPTP por diccionario o CloudCracker en una conexión PPTP.

No iba a conectarme a esa WiFi nunca, así que recopilé todos los datos y esperé a que una buena ducha luchara contra los efectos del alcohol para notificar en la recepción del hotel que deberían cambiar esa password

Autor: Deepak Daswani
http://deepakdaswani.es
http://twitter.com/dipudaswani

Fuente:
http://www.elladodelmal.com/2014/05/auditar-la-wifi-del-hotel-con-resaca-y.html

Herramienta de colaboración web : Pizarra para diagramar

Buenos días.

Algunas veces nos ocurre que al tratar de demostrar una idea/solución a un compañero de trabajo (tele trabajo) este no logra entendernos. Bueno esta herramienta es al mismo estilo de paint con la diferencia que permite compartir y ver los diagramas en tiempo real.

Herramienta: https://awwapp.com/draw.html#

Sirve para compartir ideas y soluciones aunque también se necesita skills de dibujante.

Saludos jadcodianos.

Cómo saber el WhatsApp de alguien con WhatsApp Discover

A finales del verano pasado, justo antes de las vacaciones, y de la importante decisión de abandonar mi cálida isla de Tenerife para trasladarme a León e incorporarme a la disciplina de INTECO, me entró curiosidad por analizar el protocolo de comunicación de Whatsapp, que a lo largo de los últimos años se ha erigido como líder absoluto e indiscutible en el trono de los sistemas de mensajería móvil - y si no que se lo digan a Mark Zuckerberg -.


Figura 1: WhatsApp se ha erigido en app por excelencia para chatear

A lo largo de su historia este popular aplicativo ha sido noticia constantemente por sus problemas relacionados tanto con la seguridad de la información transmitida, que en su día llegó a viajar en texto plano, como por la privacidad de las diferentes versiones de WhatsApp para Android o de las versiones de WhatsApp para iPhone. Conocidas estas debilidades, todo el mundo siempre ha tenido mucho interés en saber cómo se pueden espiar las conversaciones de WhatsApp. No obstante, desde finales de 2012, la comunicación entre servidor y clientes van cifradas a día de hoy, aunque es conocido que todavía existen debilidades graves con el cifrado que se usa por la red, así que mi interés se encontraba precisamente en analizar cómo se producía el cifrado de dicha comunicación.

Para ello, el primer paso era investigar y obtener toda la información disponible en la red acerca del protocolo FunXMPP utilizado por WhatsApp, que en aquel momento no era tanta como ahora, así que tras un poco de investigación llegué a la conclusión de que en primer lugar tenía que descubrir la clave de cifrado que utiliza el dispositivo con el que iba a realizar el análisis, (en este caso mi iPhone 4S), y que se transmite únicamente la primera vez a la hora de instalar la app en el terminal.

Esta clave se intercambia mediante SSL, pero el tráfico correspondiente a las conversaciones puede discurrir por los puertos 443, 5222 y 5223 así que para poder inspeccionar no sólo el tráfico SSL sino todos los paquetes, hice pasar el tráfico de mi móvil a través de mi equipo implementando un esquema de ataque de red tipo "machine" in the middle como el que monté en la famosa historia del vecino que me robaba la WiFi y acabo hackeado, utilizando además el famoso proxy Burp, instalando el certificado PortSwigger como enseñaba Alejandro Ramos (@aramosf) en este post en Security By Default.

Tras reinstalar la app de WhatsApp y obtener la interacción de mensajes entre cliente y servidor, pude tener acceso a la clave de cifrado de mi dispositivo, como se puede observar en la siguiente imagen:


Figura 2: Capturando el tráfico de WhatsApp de un iPhone

Además de esto, en esta conexión el cliente enviaba también otras peticiones entre las que incluía la información correspondiente a los teléfonos que tenía en su agenda para actualizar los estados de todos sus contactos, pero no voy a profundizar en estas cuestiones para no dispersarme del tema central de este artículo, porque además ya se han escrito otros al respecto y realmente cualquiera que conozca tu número puede consultar tu perfil.

Una vez tenía en mano mi propia clave de cifrado, me dispuse a analizar el tráfico generado entre mi móvil y los servidores de WhatsApp. Para esto, decidí utilizar WhatsAPI, una API desarrollada por Max Kovaljov utilizando ingeniería inversa para poder conectar con WhatsApp desde PHP de cara a implementar un cliente de escritorio o cualquier cosa que a alguien se le pueda ocurrir. Cuando me puse en contacto con él, y le conté que estaba usando WhatsAPI para analizar el tráfico generado por mi propio dispositivo, se quedó a cuadros, porque según me comentaba Max, el uso habitual que la gente hacía de esta API era intentar registrar un teléfono desde el PC para poder enviar y recibir mensajes.


Figura 3: WhatsAPI en PHP

La verdad que tras las vacaciones, así como con el ajetreo del cambio de vida y rumbo a León, no pude llegar a concluir mi investigación y llegar a descifrar completamente una conversación que había capturado. Hice algunos avances empezando a entender el protocolo FunXMPP, a decodificar los paquetes transmitidos en busca del inicio de la comunicación, y los challenge_node enviados por los servidores de WhatsApp para proceder al cifrado de los mensajes:


Figura 4: Obtención del challenge_node

Uno de los problemas añadidos al evidente que supone trabajar desde el otro lado, es que además los desarrolladores de WhatsApp introducen constantemente cambios tanto en su plataforma como en el comportamiento de sus clientes, y durante el tiempo que estuve investigando este tema descubrí con Max algunas de estas modificaciones, que además variaban dependiendo del sistema operativo del dispositivo móvil (iOS, Android, BlackBerry, Windows Phone...) y la versión del cliente. Un ejemplo de estas modificaciones es que, al retomar la investigación tras un tiempo, pude ver que al menos conectando desde mi iPhone, ya no se enviaba ningún challenge_node por parte de los servidores de WhatsApp, por lo que concluimos que se había pactado en una sesión anterior.

Durante esta etapa, además de Max, me puse en contacto con Pablo San Emeterio, que estaba haciendo algo parecido estudiando también el protocolo por su cuenta, utilizando Yowsup en lugar de WhatsAPI, y quien junto a Jaime Sánchez hace tan sólo unos meses, consiguió llegar al final y publicar este excelente trabajo.



No he descrito con excesivo detalle el protocolo FunXMPP porque no es el objeto de este artículo, y porque a día de hoy, pasado un tiempo, ya Pablo y Jaime se han encargado de explicarlo con pelos y señales para quien quiera echarle un vistazo.

De todo lo que pude deducir durante esta fase de análisis, una de las cosas que más me llamó la atención es que cuando un cliente establece la conexión con los servidores de WhatsApp, antes de iniciar la comunicación cifrada se envía siempre un paquete previo en texto plano para iniciar la comunicación, que comienza con la cadena “WA”, y en el que se envían además de otros parámetros que van codificados como la versión del protocolo o el mecanismo de autenticación, la siguiente información legible a simple vista:

- Sistema operativo del cliente
- Versión del aplicativo Whatsapp
- Puerto utilizado para la transmisión: 443, 5222 o 5223 (salvo en Android)
- Número de teléfono con prefijo del país
Figura 6: Paquete con el número de teléfono enviada desde un terminal iPhone

El paquete que se puede observar en la imagen corresponde al enviado por mi teléfono móvil durante la sesión en la que capturaba el tráfico, pero inmediatamente pensé en cuántos de estos paquetes se transmitirían en redes WiFi públicas. Tras realizar algunas pruebas y obtener capturas en diferentes lugares y momentos a lo largo de este tiempo, por aquello de los posibles cambios que han podido introducir los desarrolladores de WhatsApp en el protocolo, he podido confirmar que a día de hoy esto sigue igual - a expensas de lo que pueda pasar ahora tras la compra de WhatsApp por parte de Facebook -. A continuación muestro algunos ejemplos de paquetes de diferentes dispositivos obtenidos en capturas aleatorias: 


Figura 7: Paquete enviado desde WhatsApp para Android con el número de teléfono
Figura 8: Paquete enviado desde WhatsApp para Symbian con el número de teléfono

Tras confirmar esto, pensé en el uso potencial que esta característica de la implementación del protocolo de WhatsApp puede tener para detectar números de teléfonos de personas que se encuentren usando alegremente esas redes WiFi abiertas de cafeterías, centros comerciales, hoteles o aeropuertos, sobretodo para mis amigos solteros. Esa rubia que se encuentra en la mesa enfrente de nosotros, tecleando compulsivamente como si se le fuera la vida en ello, seguramente utilizando WhatsApp. ¿Se imaginan poder obtener su teléfono para primero ver su estado, foto de perfil, confirmar que es ella y enviarle un mensaje?


Figura 9: Verdad verdadera

Como esto de capturar el tráfico, abrir un .pcap y analizar los paquetes no es para mis amigos solteros, que de esto saben lo mismo que yo de jardinería, me decidí a hacer una herramienta que pudiese capturar estos paquetes y hacer el trabajo sucio por ellos, a la que he bautizado como “WhatsApp Discover”: 


Figura 10: WhatsApp Discover corriendo en Kali Linux

La herramienta consiste en un sencillo script en Perl, que puede funcionar directamente en modo sniffer, pasándole por parámetro una interfaz de red, o tomando como entrada ficheros de captura de paquetes, que además se pueden procesar por lotes. Lo único que hace es abrir los ficheros de captura, diferenciando entre tramas Ethernet o IEEE802.11, detectar los paquetes que siguen el patrón especificado anteriormente, y extraer de los mismos la información correspondiente, que dependiendo del sistema operativo de cada dispositivo, no siempre se encuentra en el mismo lugar del paquete. Gracias a la potencia de las expresiones regulares con las que mantengo un idilio desde que las conocí, esto no supone mucho problema.


Figura 11: Expresiones regulares en WhatsApp Discover

De este modo, con un sencillo “./whatsapp_discover.pl -f *.cap” podemos obtener los números de teléfono de todas las personas que hayan estado utilizando WhatsApp en todas las redes WiFi públicas (o no públicas) en las que hayamos capturado pasivamente tráfico. Y eso he hecho yo con mis propias capturas: 


Figura 12: Buscando los números de teléfono de WhatsApp las capturas de red

Si vemos con atención la salida de “Whatsapp Discover”, podemos ver que se obtienen números de todo tipo de dispositivos (Blackberry y Symbian incluidos), y que entre los teléfonos que he obtenido tras procesar mis capturas, existe uno que corresponde a un número de móvil americano. Lo curioso es que yo no había identificado este número al mirar las capturas con Wireshark, porque obviamente no las había abierto una a una, pero gracias a haberme construido esta herramienta, pude identificar un número que me llamó la atención.

El siguiente paso fue agregarlo en mi agenda de contactos, porque me picaba la curiosidad, ya que la captura de paquetes la había realizado en una red wifi abierta de un Centro Comercial en mi querida isla, durante las fechas navideñas. Así que supuse que sería alguien que como yo, había vuelto a casa por Navidad. Y parece que así era, ya que de lo que se deduce por su estado, se ve que habla español con se ve en su mensaje de estado:


Figura 13: Un número americano en el centro comercial

He colgado el código fuente de WhatsApp Discover en el repositorio de GitHub como PoC, ya que de momento he eliminado la funcionalidad de sniffer en tiempo real, porque por limitaciones de tiempo no he podido validar su comportamiento como es debido, y además así evitamos el uso malicioso e indiscriminado de la misma por script kiddies, los que como mínimo necesitarán saber obtener una o más capturas de paquetes válidas para probar la herramienta.  Podría ser muy útil en herramientas de análisis de pcaps, como Immunity Stalker, donde se conseguiría sacar más información de las capturas. Además, habrá que comprobar si ahora que Mark Zuckerberg está detrás de WhatsApp, este leak de privacidad sigue vigente dentro de un tiempo.

Aparte de la rubia de la cafetería, imaginen qué pasaría si una celebrity o un alto cargo público utiliza su smartphone desde la red WiFi de su hotel, para enviar mensajes de WhatsApp, dado lo valioso que es para ellos preservar la privacidad de su número de teléfono. Yo por si acaso, no lo haría si no fuera protegiendo mi WhatsApp con una conexión VPN de por medio ;).

Sólo me queda agradecer a Chema Alonso, como en otras ocasiones, la oportunidad de poder publicar en este privilegiado espacio, así como a mi mujer e mi hija la paciencia que han mostrado estas semanas en las que les he robado el poco tiempo libre que me queda tras la jornada laboral y las tareas diarias de rigor.

Autor: Deepak Daswani
http://twitter.com/dipudaswani
http://deepakdaswani.es

Fuente:
http://www.elladodelmal.com/2014/03/como-saber-el-whatsapp-de-alguien-con.html