Universidad

Internacional
de
La
Rioja
Mster universitario en Seguridad Informtica

Tactical Combat
SmartPhone

Trabajo Fin de Mster

presentado por: SETIEN DODERO, FERNANDO
Director/a: VZQUEZ POLETTI, JOS LUIS

Ciudad: MADRID
Fecha: 19/09/2014

NDICE

ANTECEDENTES................................................................................................................... 5
ESCENARIO....................................................................................................................... 7
ANLISIS DE LAS DIMENSIONES DE LA SEGURIDAD.......................................................7
CONFIDENCIALIDAD......................................................................................................7
INTEGRIDAD................................................................................................................... 8
DISPONIBILIDAD............................................................................................................ 9
AUTENTICIDAD.............................................................................................................. 9
ESTADO DEL ARTE EN SEGURIDAD EN ANDROID..........................................................10
SOLUCIONES COMPLETAS DE SEGURIDAD................................................................10
FreedomPops Snowden Phone..................................................................................10
The Boeing Black Smartphone......................................................................................10
The Blackphone............................................................................................................. 11
The Guardianproyect......................................................................................................11
Whispersystems.............................................................................................................12
Divide............................................................................................................................. 12

Samsung KNOX Workspace..........................................................................................12

Servicios de Seguridad Integrados en Android..............................................................13
SOLUCIONES DE MENSAJERA Y LLAMADA SEGURA.................................................15
SOLUCIONES DE REDUCCIN SUPERFICIE DE ATAQUE (BASTIONIZADO)..............15
SOLUCIONES PARA LA CONFIDENCIALIDAD EN COMUNICACIONES........................16
SOLUCIONES PARA INTEGRIDAD DE LA PLATAFORMA ANDROID.............................17
SERVICIO DE CONTROL DE ACCESO...........................................................................17
SERVICIO DE CONFIDENCIALIDAD...............................................................................18
CONCLUSIONES..............................................................................................................18
El telfono Opaco que se hace Brillante........................................................................19
ANLISIS DE LOS PATRONES DE TRFICO.....................................................................20
INTRODUCCIN............................................................................................................... 20
MATERIALES Y MTODOS..............................................................................................20
TERMINALES MVILES...............................................................................................20
PROCEDIMIENTO DE CAPTURA DE DATOS..............................................................20
PROCEDIMIENTO DE ANLISIS DE LOS DATOS.......................................................21
RESULTADOS...................................................................................................................22
COMPROBACIN DEL SISTEMA DE CAPTURA.........................................................22
Estadsticas bsicas......................................................................................................26
Anlisis Temporal...........................................................................................................27
Anlisis de la Confidencialidad......................................................................................29
Anlisis de los destinos de Conexin.............................................................................37
HAYAZGOS RELEVANTES...............................................................................................40
PROPUESTA DE SERVICIO DE OCULTACIN...................................................................41
ANLISIS DE COSTES........................................................................................................42
CONCLUSIN...................................................................................................................... 43
REFERENCIAS.................................................................................................................... 44
Bibliografa........................................................................................................................ 44
Web-grafa......................................................................................................................... 46

INDICE DE TABLAS

Tabla 1: Sistemas de Comunicacin Tcticos.........................................................................6

Tabla 2: Resumen de Capturas.............................................................................................26
Tabla 3: Puertos TCP en las capturas...................................................................................27
Tabla 4: Intervalos sin Datos.................................................................................................28
Tabla 5: Conversaciones XperiaZ.........................................................................................29
Tabla 6: Conversaciones MediaTek.......................................................................................29
Tabla 7: Datos y Tiempo de conexion XperiaZ......................................................................37
Tabla 8: Datos y tiempo de conexion MediaTek....................................................................37
Tabla 9: Procesos que originan las conexiones.....................................................................39

INDICE DE ILUSTRACIONES

Ilustracin 1: Patrn de desbloqueo......................................................................................18

Ilustracin 2: Interfaces de Red.............................................................................................22
Ilustracin 3: Captura de Datos.............................................................................................23
Ilustracin 4: Comparacin de Capturas de Trfico...............................................................24
Ilustracin 5: Captura con Wifi..............................................................................................24
Ilustracin 6: Captura con tPacketCapture............................................................................25
Ilustracin 7: Grfico de captura Sony Xperia Z....................................................................27
Ilustracin 8: Grafico catpura MediaTek................................................................................28
Ilustracin 9: Mapa de conexiones del Xperia Z....................................................................38
Ilustracin 10: Mapa de conexiones del MediaTek................................................................38

ANTECEDENTES
Los antecedentes que justifican este estudio de seguridad, no se publican dado que se trata
de informacin que se podra considerar sensible.

ESCENARIO
Dentro de las misiones Internacionales llevadas a cabo por las FAS vamos a centrarnos en
un escenario especfico, aunque posteriormente lo podamos ampliar a ms contextos
similares. Vamos a centrarnos en unidades que realizan su labor diaria dentro de la zona de
operaciones, que pueden entrar en conflicto en cualquier momento como respuesta a un
ataque, pero que esta no es su misin principal. Vamos a aadir los siguientes supuestos:

La red telefnica est completamente intervenida por el enemigo.

Se pueden conseguir terminales y tarjetas SIMs no conocidas por el enemigo.
Para simplificar el anlisis nos centraremos en la plataforma Android.
Nos centraremos slo en las comunicaciones (mensajera y voz) y no en la utilizacin
de aplicaciones sobre la plataforma.

ANLISIS DE LAS DIMENSIONES DE SEGURIDAD

En los siguientes apartados analizaremos las diferentes dimensiones de la seguridad dentro
del escenario propuesto. Este anlisis nos concretar las soluciones de seguridad que
debemos incorporar a nuestra plataforma.
Por solucin de seguridad no entendemos ni un servicio, ni un mecanismo de seguridad. Es
un conjunto de mecanismos (y por tanto servicios) relacionados por su funcin dentro de la
plataforma. Por ejemplo, la solucin de mensajera segura contempla distintos mecanismos
dentro de los servicios de confidencialidad, integridad y autenticacin, pero todos ellos
relacionados todos con la funcin de mensajera.
Algunas soluciones son directamente los servicios de seguridad de la plataforma. Algunos
servicios los proporciona directamente la plataforma sin necesidad de instalar ningn
software adicional.

CONFIDENCIALIDAD
Las amenazas a la confidencialidad, pueden venir principalmente por tres caminos:

El trfico generado por nosotros mismos para comunicarnos que es interceptado.

El trfico generado por el dispositivo y que no podemos controlar.
El dispositivo ha sido comprometido y enva informacin sin que nosotros lo

sepamos.
El dispositivo ha sido capturado y es analizado de forma forense.

Para proteger el trfico generado voluntariamente por nosotros, utilizaremos servicios de

mensajera y llamadas seguras que adems tambin nos proporcionarn otros servicios de
seguridad.
El trfico generado por el dispositivo y que no podemos controlar, es objeto de este
trabajo. Primero estudiaremos la naturaleza de este trfico y despus propondremos
soluciones para controlarlo.
Para poder vulnerar la confidencialidad en base a software malintencionado en el
dispositivo, es preciso que primero se haya violado la integridad de este. Por tanto lo
consideramos dentro de las amenazas a la Integridad.

En caso de que el dispositivo haya sido capturado debe de tener un control de acceso fuerte
que impida el acceso al propio dispositivo. Adems la informacin que permite la
Autenticacin del dispositivo debe protegerse criptogrficamente con fuerza para evitar un
ataque de suplantacin de identidad. Este ataque ser inevitable si se supera el servicio de
control de acceso.
En cuanto a la informacin almacenada, dado que el escenario que contemplamos slo
utilizamos el telfono como sistema de transmisin, los nicos datos que se almacenarn
sern las conversaciones va mensajes y el registro de llamadas. Esta informacin podra no
almacenarse de ninguna manera, almacenarse en la red, almacenarse de forma voltil o
cifrarse fuertemente. Este comportamiento depende de la solucin de mensajera segura
que escojamos.
Tambin podra ser til la capacidad de destruccin del propio terminal, bien localmente o
remotamente. Aunque hay que tratarlo con cautela dado que su implementacin puede
generar un problema de seguridad en s mismo.

INTEGRIDAD
Para mantener la integridad en las comunicaciones utilizaremos tambin soluciones de
mensajera segura. Sin embargo tambin debemos de asegurar la integridad del propio
dispositivo que debe comportarse como nosotros deseamos.
Para mantener la integridad en el escenario que planteamos lo primero que es necesario es
no instalar ningn tipo de software ms all del estrictamente necesario y comprobado.
Lamentablemente esto no es suficiente, puesto que el dispositivo puede sufrir alguna
vulnerabilidad que permita la instalacin de software malicioso. Por tanto necesitaremos
soluciones que:

Comprueben la integridad del dispositivo.

Limiten la superficie de ataque (Bastionado).

Tambin puede ser importante mantener la integridad de los datos que tratamos en el
dispositivo. Pero en este trabajo estamos suponiendo que utilizamos el dispositivo como un
sistema de comunicacin, y no como una plataforma con aplicaciones y datos, por tanto no
existe necesidad de integridad ms all del software y de la informacin transmitida.

DISPONIBILIDAD
En general los dispositivos mviles no tienen problemas de disponibilidad, y lo que
determina la disponibilidad es la propia red de telefona mvil. Dado que en nuestro
supuesto la red de telefona mvil est comprometida, lo nico que nos puede asegurar
nuestra disponibilidad es pasar desapercibidos, es decir la confidencialidad. Pero para que
esto sea suficiente, esta confidencialidad debe incluir tanto los mensajes como el patrn de
trfico. Esto es tambin objetivo del estudio.
La disponibilidad tambin se ve afectada por la duracin de la Batera de los dispositivos,
normalmente esta se puede alargar con bateras adicionales y dado que la duracin de los
terminales actuales es suficiente, no la consideraremos.

AUTENTICIDAD
Nuestra solucin de mensajera y llamada segura debe incluir este servicio, esto significa
que o bien se firman los mensajes o se identifica al interlocutor de forma segura al inicio de
la conversacin. De alguna forma tambin habr que administrar una infraestructura PKI
para contemplar el robo de los dispositivos.

ESTADO DEL ARTE EN SEGURIDAD EN ANDROID

SOLUCIONES COMPLETAS DE SEGURIDAD
Existen varias soluciones de telefona supuestamente seguro la mayora estn basadas en
la plataforma Android, esto es bastante lgico ya que esta plataforma es la que permite ms
modificaciones y no es tan cerrada como iOS,

Windows Phone o BB (Symbian se ha

quedado un poco anticuada). Todas ellas se basan en los mismos principios:

Eliminar todos los servicios innecesarios de la plataforma.

Crear una VPN sobre la que funcionan un servicio de mensajera y llamadas de voz
IP.

FreedomPops Snowden Phone

Este telfono se vende junto con el servicio de seguridad basado en VPN que utiliza cifrado
de 128bits. Adems permite cambiar de nmero de telfono IP todas las veces que se
quiera para proporcionar an ms anonimato. Adems de las llamadas y la mensajera la
navegacin web y cualquier otra aplicacin tambin se aseguran a travs de la conexin
VPN.

The Boeing Black Smartphone

Este dispositivo es un Hardware especficamente diseado para aumentar la seguridad y
provee ms servicios de seguridad que el FreedomPops y el BlackPhone.

El dispositivo est sellado de forma que si se intenta abrir la carcasa para acceder al
hardware lo detectar y se autodestruir. Esta caracterstica de funcionar

adecuadamente dificultara en teora el posible anlisis forense.

La verificacin de los certificados se hace directamente desde el hardware en una

memoria de slo lectura.

El arranque del dispositivo est protegido con una comprobacin de integridad

utilizando los certificados protegidos por hardware.

Cifrado y almacenamiento de claves por hardware.
Cifrado de disco completo.
Mdulos hardware diversos: Acceso Biomtrico, Telefona satelital, etc.

La mayora de los detalles de este telfono no se desvelan, esperando ganar seguridad por
oscuridad. Entendemos que al comprador final si se comunicarn los detalles de las
caractersticas de seguridad, y que tan solo se trata de otra capa ms de seguridad y no un
error de base.

The Blackphone
El BlackPhone provee los servicios de llamadas, mensajera y navegacin segura a travs
de una conexin VPN. Adems el SO Android est bastionado contra los posibles ataques
desde la red.
Todos los servicios de Google incluyendo la tienda Google Play no estn en el dispositivo,
de forma que el telfono solo se comporta como telfono en un principio, evitando la
principal causa de posibles vulnerabilidades.
Tambin provee un servicio adicional para controlar los permisos de las aplicaciones. En la
plataforma Android, cuando se instala una aplicacin se conceden permisos que no se
vuelven a revisar y que en ocasiones son mayores de los realmente necesarios. Con este
control adicional aadimos privacidad evitando que las Apps accedan a datos nuestros que
no deberan necesitar.
Otro servicio permite detectar las redes inalmbricas que pueden ser comprometidas
(Cifrado dbil, Rogue AP, etc.,) no permitindonos utilizar aquellas redes WiFi que l detecta
como no son seguras.
Las aplicaciones de comunicacin se llaman: Silent Circle, Silent Phone y Silent Text. Y
estn creadas por el mismo creador del algoritmo PGP.

The Guardianproyect
Se trata de un conjunto de aplicaciones para la plataforma Android que pretenden dar
seguridad a los telfonos utilizando la red Tor. Dada la naturaleza de la red Tor, lo que
obtenemos principalmente es anonimato, pero protegemos de ninguna manera la integridad
del dispositivo.
La aplicacin de mensajera que funciona bajo la red Tor se llama ChatSecure, y proponen
varias aplicaciones de VozIP as como aplicaciones para la destruccin del telfono de forma
rpida y otros servicios de seguridad.

Whispersystems
Se trata de dos aplicaciones, una de mensajera y otra de llamadas de voz cifradas. Utilizan
combinaciones de los estndares actuales y el cdigo fuente es abierto en busca de obtener
seguridad y confianza.

Divide
Es una solucin comercial que promueve el uso seguro del dispositivo para fines
corporativos sin impedir el uso recreativo del dispositivo. Sus principales caractersticas son:

Separacin del entorno empresarial del personal a travs de control de acceso MAC,

SELinux y cifrado de los discos.

Conexin segura a travs de VPN.
Una serie de aplicaciones de productividad bien diseadas e integradas con los
entornos corporativos habituales.

Samsung KNOX Workspace

Es una respuesta al exitoso software Divide recientemente adquirido por Google, pero
aprovechndose de la utilizacin del hardware. Se basa en mecanismos hardware
(Samsung es fabricante) y el objetivo principal es permitir un uso personal y recreativo del
telfono sin comprometer una parte segura y corporativa.
Esta es la propuesta de telefona segura de Samsung que utilizada en conjunto con otras
herramientas puede ser proporcionar una solucin completa de seguridad, de hecho esta
tecnologa est aprobada por el Departamento de Defensa del Gobierno de los Estados
Unidos.

Crea una VPN con la red corporativa.

Permite una comprobacin de integridad previa al arranque del dispositivo.
Realiza una comprobacin constante de integridad del ncleo del SO.
Aade un sistema de control de acceso MAC (SELinux), ahora mismo no aporta

nada puesto que es as por defecto en Android.

Separa completamente (utilizando SELinux) la parte personal de la parte corporativa
del telfono.

Esta tecnologa solo es compatible con algunos dispositivos de la compaa como Galaxy Note 3 "phablet," the
Galaxy S III smartphone, the Galaxy S4 smartphone, y el Galaxy Note 10.1 tablet.

Servicios de Seguridad Integrados en Android

Si nos centramos en la ltima versin de la plataforma Android KitKat 4.4, vemos que
tenemos muchas de las funcionalidades que algunos fabricantes de soluciones de seguridad
intentan vender.

Integridad en el Arranque (dm-verity). Para que este procedimiento sea

completamente seguro los fabricantes de hardware tendrn que asegurar el
lanzamiento del kernel de una forma similar a como lo hace Samsung adems de

utilizar dm-verity. Google espera que en el futuro sea as.

SandBoxing, cada aplicacin se ejecuta como un usuario nico adems ahora
soporta SELinux de forma que los permisos estn establecidos de forma fija y los
usuarios incluidos el administrador no los pueden modificar. El hecho de activar
SELinux parece reducir drsticamente la posibilidad de que se encuentren futuros

exploits, como afirma Sthephen Smalley en un artculo de la NSA [1].

Control de Acceso, se impide el acceso al dispositivo y a los certificados

almacenados si no proporciona una contrasea o patrn de acceso.

Cifrado, se puede cifrar toda el rea de usuario del disco, este cifrado est

coordinado con el control de acceso.

Lleva embebido un sistema de conexin a VPN con diferentes tecnologas entre ellas

IPSec.
Proteccin contra Buffer Overflow, soporta tecnologas como NSRL, NX, safe_iop
etc.

Las ltimas versiones de Android han hecho mucho nfasis en la seguridad dejando una
plataforma que por defecto es razonablemente segura.

La principal fuente de

vulnerabilidades en Android viene dada por el hecho de que pueden existir y existen
aplicaciones malintencionadas directamente publicadas en la tienda de Google y as lo
afirma el anlisis de Symantec Internet Security Threat Report y otras fuentes [2,3,4,5].
Google retira las aplicaciones dainas pero no hace una revisin exhaustiva de estas, previa
a su publicacin.
Por otro lado entre las crticas que se pueden hacer respecto a la arquitectura son pocas,
quizs las ms importantes la comunicacin entre procesos, que no es la original de Linux y
se ha desarrollado especficamente para Android[6,7]. Utiliza Binder() y es segura slo si se
utiliza adecuadamente y la ausencia de un sistema de comprobacin de certificados
revocados. El nmero de vulnerabilidades se reduce ao a ao, y en el ltimo ao se redujo
un 70% segn el informe de Symantec.

Acceso Super Usuario (Root)

La filosofa de Android no contempla que el usuario del telfono funcione con privilegios
elevados en ningn momento. La configuracin de seguridad se realiza de fbrica y no se
debe modificar nunca, por tanto, es ms seguro eliminar la posibilidad de ejecucin con
privilegios elevados.
La comunidad de usuarios de Android ha querido exprimir al mximo las capacidades de los
telfonos ms all de lo que proporcionaban los fabricantes, y para ello ha necesitado
buscar exploits de elevacin de privilegios, para posteriormente poder modificar el SO. La
mera existencia de estos es una terrible noticia desde el punto de vista de seguridad,
aunque afortunadamente, gracias a los incrementos de seguridad en Android, casi todos los
que actualmente funcionan requiere interactuar con botones fsicos del terminal y conexin
va cable USB.
Para permitir el legtimo desarrollo de modificaciones del sistema operativo con fines
corporativos o de investigacin, Google y diversos fabricantes de hardware como Sony o
Samsung han promovido versiones de los telfonos Versin para Desarrollador que
permiten la instalacin de Android Open Source Proyect (AOSP). Bsicamente estos
terminales tienen desactivada la proteccin para cambiar el gestor de arranque, con lo que
se puede instalar una versin modificada y sin firmar del Sistema Operativo sin necesidad
de realizar ningn exploit.
La conclusin es que si queremos desarrollar una versin bastionizada de Android, al no ser
fabricantes de Hardware, perderemos la proteccin del gestor de arranque, lo que permitir
modificar y comprometer el terminal en caso de que se tenga acceso fsico este.

SOLUCIONES DE MENSAJERA Y LLAMADA SEGURA

Cualquier sistema de mensajera no seguro que controlemos nosotros mismos, lo podemos
hacer seguro desde el punto de vista de red (Confidencialidad, Integridad), si le aadimos
una VPN por encima. Existen multitud de soluciones VPN de diferentes compaas (como
Moncada), pero lo cierto es que el propio motor de VPN que incorpora Android es ms que
suficiente, siempre y cuando tengamos suficiente control de los certificados, dado que
Android no controla los certificados revocados. Para la mensajera y las llamadas podemos
utilizar soluciones de cdigo abierto como Xabber y CSipSimple. Habr que tener especial
cuidado en configurar la autenticacin de forma suficientemente segura.
Tambin existe la posibilidad de chatear a travs de la red Tor, aadiendo ms
confidencialidad la conversacin, puesto que dificultamos que puedan trazar el origen y el
destino de la comunicacin.
Existen soluciones que directamente proporcionan los servicios seguros, por ejemplo la
aplicacin de mensajera Telegram, ofrece de forma continua un premio de 200.0000$ al que
se sea capaz de romper su seguridad, dndonos una idea de la confianza que tienen en s
mismos, aunque existen muchas dudas sobre la forma en que se realiza este desafo sobre
todo desde los creadores de Whyspersystems. El motivo por qu no se utilizan soluciones
altamente probadas en el mundo del PC para cifrar, es el rendimiento esperado por el
terminal.
Existen soluciones que podran tildarse casi de paranoicas. Hermes propone un sistema de
mensajera con criptografa asimtrica donde cada mensaje es cifrado con 1024bits y
doblemente ocultado por estenografa dentro de una fotografa, adems los mensajes en
claro no se almacenan en ningn momento ms all del momento de su visualizacin.

SOLUCIONES

DE

REDUCCIN

SUPERFICIE

DE

ATAQUE

(BASTIONIZADO)
Es fundamental para reducir la superficie de ataque eliminar todas las aplicaciones
innecesarias del dispositivo. Con frecuencia los dispositivos vienen de serie con aplicaciones
como Facebook, Tweeter, Dropbox etc. Instaladas que pueden potencialmente sufrir
vulnerabilidades.
Otra medida adicional, sera desactivar todos los servicios de Google. Aunque Google se
esfuerzan en que estos sean seguros y en principio no son vulnerables (en la ltima versin

a trabajado mucho en evitar la falsificacin de sus certificados); no tienen ninguna utilidad a

la hora de utilizar el telfono como mero sistema de comunicacin. Distribuciones de Android
como CyanogenMod o AOSP vienen por defecto con los servicios y aplicaciones mnimos
instalados.
Adems de las aplicaciones y los servicios de Google, tambin se pueden detener servicios
del SO que no son estrictamente necesarios. SecDroid es aplicacin que aade seguridad
realizando lo siguiente:

Detiene servicios que funcionan por defecto y podran ser atacados desde la red o la

lnea de comandos como como son ssh, ping o net cat.

Modificar la pila TCP/IP para limitar los paquetes ICMPs aceptables y algunos
parmetros ms.

Existe la posibilidad de modificar la configuracin de las IPTables (Firewall) por defecto de

Android utilizando aplicaciones como DroidWall o directamente desde lnea de comandos,
lgicamente esta modificacin requiere permisos de administrador (root), que debern ser
eliminados una vez revisada la configuracin.
Tambin existen programas (MobiWall, NoRootFirewall) que permiten realizar un control de
las conexiones de red del dispositivo de forma similar a un FireWall. Estos programas
utilizan la API de Android para gestionar VPNs y hacen que todo el trfico pase a travs de
ellas para posteriormente controlarlo.

SOLUCIONES DE CONFIDENCIALIDAD EN COMUNICACIONES

La solucin ms sencilla para proteger la confidencialidad del dispositivo es cifrar todo el
trfico emitido a travs de una VPN hasta un punto que podamos controlar, y es lo que
realizan la mayora de las soluciones comerciales de telefona segura. Esto se puede hacer
de una forma muy sencilla con el software de base.
En otro contexto, que no debera aplicarse en nuestro escenario, existe una preocupacin
mucho ms importante sobre la privacidad. Se trata de la capacidad que tienen las
aplicaciones instaladas de acceder a informacin personal del usuario del dispositivo a
travs de la API de Android. Soluciones como OpenPDroid y sus clones, realizan un filtrado
de todos los intentos de acceso a informacin personal.

Multitud de aplicaciones como los servicios de Google Play, Google +, Google Contacts o
servicios de fabricantes como Samsung o Sony y programas instalados como Tweeter,
Dropbox, Instagram o Facebook, realizan continuas conexiones de actualizacin. Estas
conexiones se realizan de forma segura en un principio utilizando conexiones SSL, pero
como mnimo pueden proporcionan informacin proveniente del patrn de trfico generado.
La solucin consiste en no tener instalada ninguna aplicacin ms all de las necesarias.

SOLUCIONES PARA INTEGRIDAD DE LA PLATAFORMA ANDROID

Los telfonos inteligentes actuales utilizan memorias flash y habitualmente montan
particiones ext4 que proporcionan cierta proteccin de la integridad gracias a la
funcionalidad de journal. En general no se toman medidas excepcionales para proteger la
integridad dado que las memorias flash se consideran suficientemente fiables.
As que solo queda el malware como fuente potencial de violacin de la integridad del
dispositivo. Todos los fabricantes realizan un chequeo del kernel que se va a cargar durante
la ejecucin del BootLoader (secuencia de arranque), para comprobar que este est firmado
y adems la zona de memoria de este BootLoader suele estar protegida contra escritura.
Lamentablemente dado que esta zona de memoria, permite actualizaciones esta proteccin
en general no es suficiente y es vulnerada habitualmente con la intencin de instalar ROMs
modificadas.
Si estas protecciones llegaran a madurar lo suficiente, seran junto con el servicio de dmverity que extendera la proteccin a todo el sistema sin alargar los tiempos de arranque y
que est incluida en la ltima versin de Android, proteccin suficiente para la integridad del
disco durante el arranque. Pero lamentablemente, por el momento si queremos asegurar la
integridad del sistema Operativo durante el arranque tenemos que confiar en plataformas
propietarias como KNOX de Samsung o el Black Smartphone de Boeing.
El Black Smartphone va un paso ms all, y promete proteger la integridad del hardware,
auto destruyndose si detecta que este ha sido manipulado.

SERVICIO DE CONTROL DE ACCESO

Android proporciona un servicio de control de acceso basado en contrasea (mx. 17
caracteres) o en un patrn de dibujo (9! combinaciones). Utilizando esta contrasea junto
con un salt se genera la clave que cifra la clave que cifra el disco. El nmero de intentos

consecutivos fallidos es de 5, lo que parece suficientemente seguro siempre que se siga una
correcta poltica de contraseas de acceso.

SERVICIO DE CONFIDENCIALIDAD
Existen soluciones de cifrado de disco ms fuerte que la
que proporciona por defecto Android (128bits AES)
algunas de software libre como Cryptonite y otras de
pago de cmo F-Secure o Divide que proporcionan
cifrados ms potentes.
En realidad la debilidad del cifrado se encuentra en la
propia clave que tan solo se cifra con la entropa
proporcionada con la clave de usuario ms un salt.
Potencialmente puede ser atacado por ataques de
diccionario si no se utilizan claves suficientemente
fuertes. Patrones de desbloqueo del terminal sencillos
como una L, U, A, T, etc. no seran seguros.

Ilustracin 1: Patrn de desbloqueo

CONCLUSIONES
Hemos visto que en la actualidad a pesar del origen que haya podido tener el SO Android es
bastante seguro, y la mayor parte de las amenazas provienen del uso y del software que el
mismo usuario instala. Con una adecuada poltica de uso razonable del terminal (Control de
Acceso, Cifrado, Poltica de Claves, Aplicaciones instaladas) se puede obtener una
seguridad aceptable utilizando aplicaciones de mensajera que aportan cierto nivel de
seguridad como Telegram o mucho mejor Whisperingsystems o Hermes.
Ms interesante an es crear un distribucin del SO con un nivel de seguridad an ms
elevado. Basndose en AOSP o CM, realizando pequeas modificaciones, utilizando las
polticas antes mencionadas y aadiendo una conexin IPSec con la red corporativa se
puede obtener un mvil de alta seguridad. Es ms, existen soluciones comerciales que se
pueden adquirir a un precio razonable y que siguen esta misma filosofa como el
FreedomPop, el BlackPhone o el Boeing Black SmartPhone.

Lamentablemente si creamos esta distribucin de forma manual perderemos la capacidad

de controlar la integridad del sistema operativo durante el arranque. As que en principio
sera algo ms seguro adquirir un terminal seguro siempre que exista una relacin de
confianza con los proveedores.
En el caso militar podra ser ms interesante realizar una distribucin propia e intentar paliar
esta falta de comprobacin de integridad con polticas de uso aun ms estrictas, como por
ejemplo realizando chequeos externos de la integridad del terminal desde un PC. En estos
momentos ciertos grupos especficos de las FAS ya estn utilizando este tipo de
distribuciones, pero aun no es de uso generalizado.

El telfono Opaco que se hace Brillante

Dado que la mayora de los telfonos inteligentes actuales estn continuamente
conectndose con servicios de las compaas suministradoras de software, habitualmente
sin conocimiento del usuario; un mvil que sea completamente opaco y que realice
conexiones cifradas con un solo destino, se puede convertir de forma no esperada en un
dispositivo ms visible que el resto.
Podemos utilizar relleno de trfico para garantizar la Confidencialidad y evitar que se
averige cuando se realizan o no comunicaciones y la naturaleza de estas, pero no es
posible asegurar el anonimato total. La propia naturaleza de la red de telefona localiza los
terminales, lo que supone un grave problema de seguridad.
En este trabajo vamos a estudiar si es posible aadir el servicio de seguridad de ocultacin
a un telfono mvil seguro. Analizando el trfico veremos si es viable la creacin de dicho
servicio, y si es compatible con el aumento de la resistencia contra vulnerabilidades
manteniendo el comportamiento estndar del telfono.

ANLISIS DE LOS PATRONES DE TRFICO

INTRODUCCIN
Los objetivos de este anlisis son dos, por un lado determinar el grado de confidencialidad
que proporciona un telfono inteligente bajo la plataforma Android y por otro determinar si es
posible ocultar un sistema de comunicacin seguro bajo el comportamiento normal del
telfono.

MATERIALES Y MTODOS
TERMINALES MVILES
Para el propsito de este estudio era necesario analizar dispositivos como los que se
encuentran en zona de operaciones. Afortunadamente esto es ms sencillo de lo que en un
principio podra haber sido. Los dispositivos mviles que se encuentran a la venta en
Afganistn o el Lbano vienen directamente desde China con firmwares que soportan varios
de los idiomas y dialectos locales.
El anlisis se realizar desde territorio nacional, porque suponemos que el comportamiento
del firmware del telfono no depende del operador mvil con el que est conectado.
Realizaremos el experimento con dos terminales en dos situaciones distintas. La primera
con nicamente las aplicaciones instaladas de serie en el terminal; y la segunda, con unas
pocas aplicaciones instaladas intentando simular un uso habitual. Los terminales que
utilizaremos sern un Sony Xperia Z comprado en Europa con firmware europeo y una copia
china del Samsung Galaxy Note 3 con el firmware de Oriente Medio que por dentro tiene un
hardware similar al Samsung Galaxy SII y est fabricado por la conocida empresa China
MediaTek.

PROCEDIMIENTO DE CAPTURA DE DATOS

Para el anlisis de trfico el Gold Standar es utilizar un dispositivo de captura en el mismo
nivel I del protocolo de comunicacin. En el caso para capturar de la interfaz de red
inalmbrica slo se requiere una tarjeta de red capaz de funcionar en modo promiscuo. Se
puede utilizar un porttil conectado a la misma red con el software de captura wireshark. En

el caso de que queramos capturar trfico de la red de telefona ya no es tan sencillo, los
equipos necesarios se escapan de lo disponible para este estudio.
Existen Apps que permiten la captura de todo el trfico del terminal en un formato estndar
(pcap, tcpdump) que luego se puede evaluar con otras herramientas anlisis. Estas
herramientas basan la captura en la creacin de una VPN virtual a travs de la cual
encaminan todo el trfico.
La primera fase del estudio consistir en comprobar que la herramienta tPacketCapture se
comporta de igual manera que un ordenador porttil con la distribucin Linux para la
auditoria de redes inalmbricas WifiWay instalada y una tarjeta de red compatible.
Una vez comprobado esto, el resto de las capturas se realizar con App de captura de
trfico y la interfaz inalmbrica deshabilitada, pues es la interfaz radio, la que realmente nos
interesa analizar y los terminales no se comportan exactamente igual cuando tienen
cobertura inalmbrica que cuando solo tienen cobertura radio.
Los anlisis se realizarn con los dos terminales en reposo durante un da completo.

PROCEDIMIENTO DE ANLISIS DE LOS DATOS

Se realizar un listado de todos los destinos con los que se conecta el terminal y de si esta
conexin es o no cifrada. En las conexiones que no sean cifradas se investigar la clase de
informacin que se transmite en busca de alguna posible debilidad. Despus se realizar un
anlisis grfico durante 24 horas de cuando conecta, con quien y donde.
Estos anlisis se realizarn utilizando el reconocido analizador de protocolos WireShark,
utilizando las herramientas de anlisis de conversaciones y de destinos y la funcionalidad de
localizacin geogrfica y resolucin de nombres de dominio.

RESULTADOS
COMPROBACIN DEL SISTEMA DE CAPTURA
Lo primero que vamos a hacer es comprobar que la herramienta tPacketCapture captura la
misma informacin que capturando directamente los datos de la red inalmbrica con
WifiWay.
Primero investigamos las interfaces de red que tenemos para que luego nos resulte ms
sencillo analizar los datos. Desde la consola del propio terminal podemos visualizar
informacin de red y con el comando netcfg (En Android no estn exactamente los mismos
comandos que en Linux). Averiguamos las interfaces de red que tenemos:

Ilustracin 2: Interfaces de Red

Todos los paquetes debera tener el mismo origen o destino y este debiera ser la interfaz del
tnel VPN virtual, sin embargo algo raro sucede porque el sistema tambin captura
paquetes desde la interfaz WiFi. Estos paquetes no llegan al 1% de la captura. Investigando
un poco descubrimos que el origen es la funcionalidad que tiene el telfono mvil de activar
la Wifi en funcin de la posicin geogrfica cuando se encuentra cerca de un lugar conocido.
Esto nos obliga a repetir el anlisis con la funcionalidad desactivada.

Ilustracin 3: Captura de Datos

Descargamos la ltima versin de WifiWay y la instalamos en un disco flash USB.

Configuramos la red inalmbrica con cifrado WEP. En teora debera funcionar sin ninguna
clase de cifrado, pero despus de realizar varias pruebas, descubrimos que por algn
motivo WireShark no analiza bien los datos capturados sin cifrado, y se limita a mostrar solo
el nivel de Radio 802.11 sin entrar en el nivel IP ni ningn otro nivel de red inferior. Es
posible que esto sea debido a que la tarjeta de red que usamos para capturar en modo
promiscuo (DELL 1390) no es la ms recomendada.
Durante las pruebas tambin descubrimos que debemos alejar el telfono del ordenador
porttil que tiene la tarjeta de captura, de no hacerlo as se pierden paquetes por exceso de
seal.
Finalmente el procedimiento fue el siguiente:

Intentamos iniciar las dos capturas simultneamente.

Navegamos por Internet durante algunos minutos.
Guardamos las capturas y las abrimos en el mismo ordenador cada una en una

ventana.
Sincronizamos las capturas buscamos dos paquetes fciles de identificar (uno para
el inicio y otro para el final de la captura), este caso utilizamos peticiones DNS a

es.gizmodo.com y b.scorecardresearch.com.
Nos quedamos con los paquetes en estos intervalos y posteriormente filtramos por
las IPs adecuadas.

ip.src == 192.168.7.148 || ip.dst == 192.168.7.148

ip.src == 10.8.0.1 || ip.dst == 10.8.0.1

Ilustracin 4: Comparacin de Capturas de Trfico

Se aprecia claramente los paquetes de fragmentan de forma diferente. En general en la Wifi

se transmiten paquetes ms pequeos que los que salen de la interfaz virtual. Esto se debe
en parte al cifrado en bloques que proporciona WEP.
Esta fragmentacin provoca que se desordenen tambin los paquetes. En este caso las
peticiones DNS que salen todas juntas a travs de la interfaz VPN, posteriormente en
interfaz inalmbrica se ven dispersadas entre otros paquetes de peticiones http
fragmentados. Sin embargo, mirando con detenimiento comprobamos que el tiempo de
envo de los paquetes es prcticamente idntico en ambas capturas.

Ilustracin 6: Captura con tPacketCapture

Ilustracin 5: Captura con Wifi

Aunque a nivel IP nos encontramos con informaciones diferentes de cara a nuestra

investigacin lo que queremos saber, es si a nivel de transporte no perdemos ninguna

informacin. Para ello podemos utilizar la herramienta de WireShark, que analiza las
conversaciones TCP/UDP.
El nmero de conversaciones TCP, el origen el destino y la duracin coinciden
completamente, aunque vara ligeramente el nmero de Bytes, transmitidos. Entendemos
que esto es debido a la variacin del overhead debido a la fragmentacin.
Parece razonable concluir que el procedimiento de captura utilizando la aplicacin
tPacketCapture es vlido a nivel de transporte aunque no lo es a nivel IP.

Estadsticas bsicas
Se realizaron 2 capturas durante 24h con cada telfono. El telfono Mediatek con las
aplicaciones por defecto instaladas, y el telfono XperiaZ de uso personal que tiene docenas
de aplicaciones instaladas pero solo un programa de mensajera (Whatsapp) funcionando.
Durante la captura de datos no se interacciona con los dispositivos.

DURACIN
24h
24h

TRFICO

CONEXIONES

PAQUETES

PAQUETES

CAPTURA

TERMINA

TOTAL
6199 pqs
21,6 Mbytes
1102 pqs

ENTRANTES
0

UDP/DNS
1828

TCP
4371

16/08/2014

L
XperiaZ

138

964

19/08/2014

MediaTek

280 Kbytes
Tabla 1: Resumen de Capturas

Anlisis de las Conexiones entrantes no iniciadas por el terminal

Queremos saber si el terminal recibe algn tipo de comunicacin no iniciada por el mismo.
Esto es importante porque supondra la comprobacin de que los terminales mviles no
estn protegidos por la red telefnica y estn siendo atacados directamente desde Internet.
(ip.dst == 10.8.0.1 && tcp.flags.syn==1 && tcp.flags.ack==0)

Afortunadamente y como era de esperar, no encontramos ningn paquete en ninguna de las

capturas, con lo que suponemos que esta situacin no sucede habitualmente.

Anlisis del tipo de trfico a nivel de transporte (TCP/UDP)

Lo que queremos averiguar es que porcentaje del trfico es TCP y UDP. Y dentro del trfico
UDP que tipo de protocolo se utiliza.
El 99% trfico UDP observado son peticiones DNS, exceptuando una peticin NTP, siendo el
resto del trfico nicamente TCP.

Anlisis de puertos TCP y protocolos conocidos

La mayora del trfico utiliza los puertos de los protocolos http o https. Los servicios de
mensajera (Whatsapp y Gtalk) utilizan otros puertos estndar como 5222 y 5228. Unas
pocas aplicaciones utilizan puertos diferentes.

http(80)
1935 paq

PUERTO
https(443) 5228*
5287**
1842 paq 268 paq 186 paq

5222***
140 paq

XperiaZ

44%
264 paq

42%
423 paq

6%
277 paq

3%
-

16/08
MediaTek

27%

44%

29%

4%
-

CAPTURA

19/08

Tabla 2: Puertos TCP en las capturas

*Todas las conexiones son con mobile-gtalk.l.google.com
**Todas las conexiones son con agentchannel.api.n.shifen.com
***Todas las conexiones son con whatssap.net

Anlisis Temporal
WireShark nos proporciona directamente la posibilidad de dibujar una grfica de los
paquetes transmitidos y recibidos en funcin del tiempo. Como las posibilidades de dibujo de
la versin actual de WireShark son algo limitadas, utilizamos el Preview de la versin 2 de
WireShark todava en desarrollo que tiene un motor ms potente de dibujo de grficas. Lo
que mostramos es directamente el volumen de trfico segn la hora del da durante 24h.

Ilustracin 7: Grfico de captura Sony Xperia Z

Ilustracin 8: Grafico catpura MediaTek

Tambin nos interesa analizar los intervalos sin transmisin de datos a lo largo del da. Para
ellos utilizando una hoja de clculo analizamos los intervalos mayores de 1min.

MEDIA
6min
9min 30s

INTERVALO SIN DATOS

DESVIACIN
MXIMO
5min
34min
5min 40s

15min

CAPTURA
XperiaZ
16/08
MediaTek
19/08

Tabla 3: Intervalos sin Datos

Lo que se apreci de este anlisis es lo siguiente:

Peticiones peridicas por parte del terminal, con una cadencia menor para el terminal
Sony que para el MediaTek, probablemente debido a un sistema de ahorro de

energa que reclama tener.

Una considerable mayor cantidad de trfico desde el mvil Sony, presumiblemente
debido a que el terminal tiene ms aplicaciones instaladas, entre ellas una de

mensajera.
Los mviles no llegan a estar en silencio un intervalo mayor de media hora nunca.

Anlisis de la Confidencialidad
Vamos a determinar si hay y cuantas son las conexiones no cifradas. Entraremos a analizar
en detalle que nos sea posible las conexiones no cifradas para averiguar si hay un peligro
de information leakage.
En este cuadro mostramos todas las conversaciones mantenidas por los terminales.

XperiaZ
CIFRADO TCP
SI
NO
SI
NO
NO
NO
NO
SI
SI
NO
SI
SI y NO
SI

DESTINOS
Facebook.com
Whatsapp.net
Xperialounge.sonymobile.com
Amazonaws.com
Agentchannel.api.n.shifen.com
Mobile-gtalk.l.google.com
Android.Clients.google.com
Googleapis.l.google.com
Edgecastcdn.net
Accu-weather.com.cdngc.net
Pushct.n.shifen.com
Googleusercontent.com
Dataflurry.com
TOTAL: 140 Conexiones a 12 Destinos

Tabla 4: Conversaciones XperiaZ

CIFRADO TCP
NO
Si
NO
SI
SI y NO
SI
SI
SI

MediaTek
DESTINOS
proxy.sogou.com
195.57.81.42 (Akamai)
gstatic.com
android.l.google.com
clients.l.google.com
mobile-gtalk.l.google.com
64.233.166.188 (Google)
facebook.com
TOTAL: 42 Conexiones a 11 Destinos
Tabla 5: Conversaciones MediaTek

Analizamos los destinos uno por uno entre los que el trfico no est cifrado, los destinos que
no deberan existir o los que por cualquier otro motivo nos parece sospechosos.

Proxy.sogou.com
Sogou.com es un proveedor de bsqueda chino. La conexin es con un servidor nginx, que
es un servidor web/proxy inverso para balanceo de carga.
Las peticiones son todas iguales, son peticiones GET con el mismo parmetro y reciben
siempre la misma respuesta. Se realizan en total 12 peticiones a intervalos que varan
entre dos horas, 1 hora o 30 minutos de diferencia.
GET /jsp/openapi/reciapi.jsp?d=1408447480000 HTTP/1.1
Accept-Encoding: identity
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.2.2; SM-N900 Build/JDQ39)
Host: input.shouji.sogou.com
Connection: Keep-Alive
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 19 Aug 2014 21:53:07 GMT
Content-Type: text/plain;charset=UTF-8
Set-Cookie: IPLOC=ES; expires=Wed, 19-Aug-15 21:53:07 GMT; path=/
P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"
Cache-Control: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Set-Cookie: JSESSIONID=abc6xd1lQWyeTeI3LqWFu; path=/
Connection: Keep-Alive
Keep-Alive: timeout=60, max=8
Transfer-Encoding: chunked
Via: 1.1 80.58.250.68
56
<?xml version="1.0" encoding="UTF-8"?>
<root><datetime>1408447480000</datetime></root>
0

195.57.81.42, Facebook.com
La direccin IP 195.57.81.42 pertenece a Akamai Technologies y una empresa de servicios
en la nube. Se recibe el mismo mensaje desde ambos servidores. Es un SSL Alert iniciado
desde el lado servidor.
Puede que simplemente se trate de un fin de conexin provocado por un cambio de IP. El
ltimo de estos mensajes sucede 3min despus de empezar la grabacin, y hay que tener
en cuenta que se realiz una prueba de conexin a la web www.meneame.net que se
termin un minuto antes de empezar la grabacin.
Tambin podra tratarse de alguna clase de ataque en busca de una vulnerabilidad. El caso
es que el terminal responde con un ACK al mensaje SSL Alert.

Whatsapp.net
A simple vista no se aprecia ninguna fuga de informacin personal. Por lo que sabemos de
la aplicacin la conexin est cifrada a nivel de aplicacin aunque no lo est a nivel de
transporte.
WA.............Android2.11.301............privacy..B......34647558807U..-.......Zy+....T...U|..+Y..PK.
$...Uh.....z_.3.......:.........H..o"M...4".>...lkE...P.w.T2C..&e...d."Q....
{....m....a....E..........4.....%...l...M..=U..2a.fr]@.....!..VG...l..`3WIN.HgJ....._.....Z=.
..W..tj..k..#.A...W..y...D....z...>.3.jd#...>./.h....uUK...........c..B
a......P.r...E..PB...A...iC..%.U
.'.8.T...K.' .#.^....3`...$.T.t....py ....?c......N].b.s.0,.L......w.eO....g..C.w...
[ub&.@l....?...I8..O...4......N..........\....<c.....
.%.../............/...
..MV.
..~...G..../yw..d.8.L.<t..;.g.>.at.=..._3...S....T...0+
.HVN...wd.9...(.....9.........9...<.?....C.z...&..
B*}.Z........|....\..
|.~....]&..._..z..9....F.V.....<u.K...A.|.e?.. .G.
jn`...$...9.......D......!..u%...^eE.....$..... V.L..........q.)m.a...G
.MFm..u......8..t...I.0..8."..b..!.7 ...[.j.+Fe..P{...;...g{j..^.D$)...S..|+.mS..`..}T..zn..JF3.$...?.....*h.....n.n%\%...u..Dy./,z....l.. 6......h.g@../.c......
0..P.$..c......7)..E..(.u&s,.9p..........F:.e.;>KbW.\7%......&..u...k...T0.....

Amazonaws.com
Aparentemente se realiza como una conexin con un WebService (JSON) en claro y se
utiliza una Cookie para su autenticacin. Se conecta con los servidores Cloud de Amazon.
Aunque no se aprecia a simple vista informacin personal esta conexin es potencialmente
vulnerable.
La compaa que est finalmente detrs de esta conexin es http://www.appoxee.com.
Que es una compaa de marketing para aplicaciones mviles.
POST /api/ HTTP/1.1
Content-Length: 205
Host: saas.appoxee.com
Connection: Keep-Alive
{"action":"getApplicationConfiguration","auth":
{"random":"8806c805bc7b8c1a9b0514c7550c5acb47b","timestamp":14081808772,"AppSDKKey":"53bfcb25
985de4.28229413","signature":"8edc0194a8a258e3d7cd7e7ddfbc6e78"}}
HTTP/1.1 200 OK

()
{"result":
{"AppSDKKey":"53bfcb25985de4.28229413","AppID":"103926","mailboxTitle":"","RTL":false,"moreAp
psEnabled":false,"feedbackEnabled":false,"android":
{"projectId":"339763567478"}},"response":"Success"}

()

Agentchannel.api.n.shifen.com
Se enva trfico JSON a un servidor de forma no cifrada. Tampoco se aprecia informacin
personal pero es tambin potencialmente vulnerable.
El servidor pertenece la compaa Chinaunicom, probablemente a sus servicios en la nube
aunque podra ser el propio operador telefnico.
........DevApp............p.........
{"tiny_msghead":1,"channel_token":"1541413976285008409810696791510117680696106967221801180552
24","tinyheart":1,"period":1800,"connect_version":2,"channel_type":3,"channel_id":"4222156819
441981330"}........serveragent.head..p.........{"ret":0}..

mobile-gtalk.l.google.com
La nica informacin legible que se encuentra son los intercambios de Certificados,
previsiblemente para iniciar una conversacin cifrada. Parece una conexin SSL pero en
un puerto diferente.
Google Inc1%0#..U....Google Internet Authority G20..
140730121326Z.
141028000000Z0f1.0...U....US1.0...U...
California1.0...U...
Mountain View1.0...U.
.
Google Inc1.0...U....*.google.com0Y0...*.H.=....*.H.=....B..2...g1.P.RL..kx..U.....
(Q0..X.J7..p."?.

()
.....0N1.0...U....US1.0...U.
..Equifax1-0+..U...$Equifax Secure Certificate Authority0..
020521040000Z.
180821040000Z0B1.0...U....US1.0...U.
.
GeoTrust Inc.1.0...U....GeoTrust Global CA0.."0

android.l.google.com
Son conexiones cifradas que se realizan con una periodicidad que vara bastante entre
20min y 4h. Desconocemos su utilidad. Son conexiones relativamente simtricas donde se
envan y se reciben datos en similar cantidad.

gstatic.com
Parece que este tipo de conexin es la manera que tiene el navegador Chrome de recibir
actualizaciones de certificados revocados a travs de los llamados CRLSets.
GET /chrome/crlset/1798/crl-set-delta-1797-10890578632700302864.crx.data HTTP/1.1
Host: www.gstatic.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Linux; Android 4.2.2; SM-N900 Build/JDQ39) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/36.0.1985.131 Mobile Safari/537.36
Accept-Encoding: gzip,deflate,sdch
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Tue, 19 Aug 2014 08:21:06 GMT
Date: Tue, 19 Aug 2014 08:33:34 GMT
Expires: Wed, 19 Aug 2015 08:33:34 GMT
X-Content-Type-Options: nosniff
Server: sffe
Content-Length: 1589
X-XSS-Protection: 1; mode=block
Cache-Control: public, max-age=31536000
Age: 37684
Alternate-Protocol: 80:quic
Connection: Keep-Alive
Keep-Alive: timeout=60, max=8
Via: 1.1 80.58.250.68
Cr24....&.......0.."0
..*.H..
()
D..?............2.%(x..?...........+...n+......D....w.|
{.......PK..l..E........PK...............)jQ&..."...
.................manifest.jsonPK..............l..E......................a...crlsetPK..........p...y.....

android.clients.google.com
Son descargas de aplicaciones (actualizaciones del mvil). No viajan con ningn tipo de
seguridad, supongo que porque se confa en que la propia aplicacin est firmada
digitalmente. Potencialmente habra que estudiar si se puede realizar un ataque MAN-INTHE-MIDDLE.
En este caso se ve como se actualiza la aplicacin e-Park, lo que ya es un problema de
seguridad puesto que cualquiera puede obtener las aplicaciones que tenemos instaladas
buscando las vulnerables.
GET /market/GetBinary/GetBinary/com.setex.epark/31:30:2?
mm=31&ms=au&mt=1408180932&mv=m&mws=yes&expire=1408353779&ipbits=0&ip=0.0.0.0&cp=SmFub2R1Q0Q6N
zYxODQwMTkwNjI5ODIxNTg2NDU&sparams=expire,ipbits,ip,q:,cp&signature=7E11BE99B6E9DF229CA473578
7F206D0E64AB433.DC6641916C92297EAB2A8E07E9274119C5024297&key=am3 HTTP/1.1
Cookie: MarketDA=07908988515064545590
User-Agent: AndroidDownloadManager/4.4.2 (Linux; U; Android 4.4.2; C6603 Build/10.5.A.0.230)
Accept-Encoding: identity
Host: r11---sn-h5q7enek.c.android.clients.google.com
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Thu, 14 Aug 2014 12:09:05 GMT
ETag: da39a3ee_5e6b4b0d_3255bfef_95601890_afd80709

Expires: Fri, 14 Aug 2015 12:09:05 GMT

Content-Type: application/vnd.android.package-delta
Content-Length: 1732190
Accept-Ranges: bytes
Cache-Control: public, max-age=31536000
Server: UploadServer ("Built on Jul 31 2014 18:25:34 (1406856334)")
Last-Modified: Sun, 01 Apr 2007 07:00:00 GMT
Connection: close
Alternate-Protocol: 80:quic
X-Content-Type-Options: nosniff
..........T..X...?..KI.t.......Hw.H.J....%(*.....,...t.." .
{...........33g......w.........F......r$R..........G?...4y:.....5
4.7j.SY..8s.`.b``\a@...y@..+...=..Xh.Z...e.&C.nTH...l........e....W........).(...........h.={.#.z..........
a"Dso.4./........Z...1\...[.v.4c........
.4|w..'.%x........C$n...7.<?.;.....{x.....=...i>.......C.....qL......s..........!.F..H....!
z...........B..uhJ...#.A10x..|...%.7.z1DC~g....a.......A!q.`*45.. .....uF....
.....W.q........0$.....Z...Xh.a`._..( ~...t.7...z..d..|R".u......hb[C\A..<...`#!
L...@.|.......@.A.[C.s/...G.Q'F.tw......ah.

Accu-weather.com.cdngc.net
Se trata tan solo de una peticin de informacin meteorolgica que viaja sin cifrar. Aunque
pueda parecer inofensivo, quizs existan situaciones en que se pueda comprometer la
seguridad con partes meteorolgicos falsos. En cualquier caso la propia peticin de
informacin meteorolgica ya nos puede proporcionar cierta informacin, como por ejemplo
donde estamos o a donde nos dirigimos.
<?xml version="1.0" encoding="utf-8"?>
<adc_database xmlns="http://www.accuweather.com">
<units>
<temp>C</temp>
<dist>km</dist>
<speed>kph</speed>
<pres>kPa</pres>
<prec>mm</prec>
</units>
<local>
<city>Madrid</city>
<state>Comunidad de Madrid</state>
<lat>40.4096</lat>
<lon>-3.68629</lon>
<time>18:58</time>
<timeZone>1</timeZone>
()
</forecast>
<copyright>Copyright 2014 AccuWeather.com</copyright>
<use>This document is intended only for use by authorized licensees of AccuWeather.com.
Unauthorized use is prohibited. All Rights Reserved.</use>
<product>sonyericsson - windows mobile development team</product>
<redistribution>Redistribution Prohibited.</redistribution>
</adc_database>

Pushct.n.shifen.com /agentchannel.api.n.shifen.com
El terminal est enviando de forma automtica y peridica cierta informacin a un
servidor que pertenece a la empresa baidu.com empresa de la que no puedo
averiguar nada porque toda la informacin est en chino.
........DevApp............p.........
{"tiny_msghead":1,"channel_token":"1541413976285008409810696791510117680696106967221801180552
24","tinyheart":1,"period":1800,"connect_version":2,"channel_type":3,"channel_id":"4222156819
441981330"}........serveragent.head..p.........{"ret":0}..
POST /pushlog HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 705
Host: statsonline.pushct.baidu.com
Connection: Keep-Alive
User-Agent: Baidu-Frontia-Android
Accept-Encoding: gzip
stats=dXsIAAAAAAAAAI1STa%2BbMBD8Lz5T4g8MhNtTDz1X7a15slyzPKwXDLJNojTiv3ftfB1bIYR3PZ6d
%0AGXMlZp6m2ZHuSpY1jMqM2jk4Pmu%2FOmfdhzqBDzbhOC
%2FIHaRsTzpScc6ZrFu2ryq2b5kQlGwFWQN4%0A1cPJGkhkg%2FXTWXtckx%2Bzuxx2X
%2Buaivunq8qq5Icdo6Us30packEPu2%2FDXvnvXSI67DwcQQf48gmX%0AQAoyzX0SSfJxrOegnJ4S%2B5vr
%2FYzCEKPdOmgT1%2BdUbAbjAZw62z6O2GVNU2PXLKsaQN%2BhDtDoE9qD%0ACzZektOWZlpzMw60q0UHsjO
%2FO4keHkQPbdpPpwZ7ZxtAmTWfEbKWQlJZVULUTCY6mFSwfyCL2cub%0Al2faJCfzEjOC
%2FRhjwtL2FbODeJ79Z8p5coZ0TUHiZUFKWhBtDISgbjVqGWwaahDFWYXDFvA6zh73%0Afq7gYtrNnHbJU8oWr4ORDUfp
ZTlaoyMKU9YNM%2Bl%2BXVNT4ZvN7SVPfvN%2Fg7lnAwmSl4%2F7oQIfhrBo
%0AJwhRTziHVbTlrOaNlJUoyN2Owt24hpfqEbRH7%2B1W%2FD9pk264of8kFdv79l6QV%2FCsxHz%2FAu7eWGcf
%0AAwAA&pbVer=1.0&os=androidHTTP/1.1 200 OK
X-Powered-By: Express
Vary: X-HTTP-Method-Override
Content-Type: text/html
Date: Sun, 17 Aug 2014 08:19:53 GMT
Connection: keep-alive
Transfer-Encoding: chunked
10
{"error_code":0}
0

googleusercontent.com
La mayor parte de las conexiones mueven cantidades relevantes de datos y viajan cifradas
por SSL. Sin embargo, tambin hay peticiones GET constantes para mantener abierta la
conexin.
GET /generate_204 HTTP/1.1
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.2; C6603 Build/10.5.A.0.230)
Host: clients3.google.com
Connection: Keep-Alive
Accept-Encoding: gzip
HTTP/1.1 204 No Content
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Sat, 16 Aug 2014 16:40:02 GMT
Server: GFE/2.0

dataflurry.com
Esta es tambin una compaa de marketing, pero al menos tiene la decencia de cifrar sus
comunicaciones. De alguna manera el usuario debiera ser consciente de esta violacin de
la privacidad. El volumen de datos es un tanto inquietante aunque probablemente se deba
al inicio de la conexin segura.
...........S.".|.R......5EsB.,T}...._....s...F...../.5.................
.......3.9.2.8.
...
...........................@.........
.4.2...
...........
......................................Q...M..S."..G.h?.R....4..a7..`.#)f.(.k,
...>..\..jC.n}.y........K.SZ.j!../............O...K..H..Y0..U0..=.......+\....Y0
..*.H..
.....0..1.0...U....US1.0...U....Arizona1.0...U...
Scottsdale1.0...U.
..GoDaddy.com, Inc.1301..U...*http://certificates.godaddy.com/repository100...U...'Go Daddy
Secure Certification Authority1.0...U....079692870..
121030185119Z.
171030185119Z0Q1.0...U.
..*.flurry.com1!0...U....Domain Control Validated1.0...U....*.flurry.com0.."0

()
R....?N.aQ.}.+b
.!....8.K...9....H....P...._d9..:.H..3' ..$o.u.... ..#.`RME.J3.*.. .JRlM|....d..&..s...,iE.
(....Y..~ek.[.F,..< ..X.k..O..(.w.|.H..n`....PNi.:.=...&+..vR......@..
{4..q.i.o....nl...L..)..qH..+.W..!.4^*.~...../..*...-..^.Kq..
...y..!.y......l'........M<.=..k......zC..../..).............P)u...G. y.As....
(.K.`}.h..*.<\Jy...DP...>..*..o......D............G...!0J.....
$...)..za33E={x...Z...@B.er[.K.......DpZ<....W$.x...&c.#.E...P...~.lKA...e*i..q..
%..l...K..J..@.7..,..v.-z<ck.....uJ......|{..`0@...5........&..L.....]{i.\.$....
....py....m".........`...D./..X.

Anlisis de los destinos de Conexin

Intentaremos determinar cuntos destinos de informacin existen, cual es el domino destino,
el puerto, los Kbytes transmitidos totales y el nmero de minutos entre conexiones
consecutivas.
No nos sirven las herramientas automticas puesto que queremos averiguar la organizacin
que est detrs de cada conexin y no siempre basta con el nombre de host y debemos
investigar un poco ms. Hay compaas con IP asignadas pero sin nombre de dominio
atribuido.
Algunos servicios como whatsapp.net o clients.google.com realizan las conexiones a
multitud

de

host

con

similares

nombres

de

dominio.

Ej:

e1.whatssap.com,

e12.whatssap.com, e16.whatssap.com etc. Entendemos que se trata de la misma conexin

a nivel de aplicacin, pero utilizando varias mquinas para permitir la alta disponibilidad, por
tanto de cara al estudio los consideraremos como uno solo destino.
Primer analizamos el nmero de empresas, el nmero de host diferentes los datos
transmitidos y la duracin de la conexin:

EMPRESA
AMAZON CLOUD
CDNETWORKS
CHINAUNICOM
EDGECAST
FACEBOOK
GOOGLE
INTERNAP
SOFTLAYER

# HOSTS
3
2
3
2
2
31
1
12

# DATOS
3 MB
4,92 KB
10,22KB
16,91KB
7,75KB
18,61MB
6,18KB
300KB

Xperia Z
DURACIN (media/mxima)
7h
2h30min
23h
16h
24h
10h
7h
7h
8h
8h30m
10h
24h
2,5s
2,5s
10h
24h

Tabla 6: Datos y Tiempo de conexion XperiaZ

EMPRESA
AKAMI TECH
BJTELECOM
GOOGLE

# HOSTS
1
9
21

# DATOS
3,3 KB
24 KB
228 KB

Tabla 7: Datos y tiempo de conexion MediaTek

MediaTek
DURACIN (media /mxima)
10s
10s
1min
1min
24h
10h

Todas las empresas que hemos detectado excepto Facebook y Google son empresas de
servicios en la nube. Esto dificulta un poco ms averiguar qu organizacin es el receptor
final de todos los datos.
Organizaciones y Situacin geogrfica
WireShark nos permite utilizar geo-localizar las conexiones instalando las correspondientes
bases de datos.

Ilustracin 9: Mapa de conexiones del Xperia Z

Ilustracin 10: Mapa de conexiones del MediaTek

Anlisis de los procesos que generan la conexin

Hasta ahora hemos analizado el trfico generado por el terminal, pero no tenemos claro que
aplicaciones son las causantes de este flujo. Para ellos vamos a utilizar una de tantas
aplicaciones disponibles Connection Tracker PRO.
Esta la lista de los procesos que generan las conexiones:
Xperia Z
android.process.media
com.android.vending
com.facebook.katana
com.google.android.apps.genie.geniewidg
et
com.google.android.apps.maps
com.google.android.gm
com.google.android.gms
com.google.android.gms.drive
com.google.android.gms.wearable
com.google.android.googlequicksearchbox
:search
com.google.android.music:main
com.google.android.talk
com.google.process.location
com.mobisystems.fileman
com.mxtech.videoplayer.ad
com.sonyericsson.advancedwidget.clock:lo
ckscreen
com.sonyericsson.album
com.sonyericsson.music
com.sonyericsson.textinput.uxp
com.sonyericsson.updatecenter
com.sonyericsson.xhs
com.sonymobile.cameracommon
com.sonymobile.enterprise.service
com.whatsapp
system
System Process
Tabla 8: Procesos que originan las conexiones

De Nuevo nos surgen sospechas de que la actividad de todos esos procesos aporte algo al
usuario.

RESUMEN DE HAYAZGOS RELEVANTES

De la simple observacin directa de todos los datos previamente presentados obtenemos:

Por un lado existen conexiones legtimas, como la consulta meteorolgica, que se

realizan de forma no seguras y que potencialmente podran ser vulnerables a un
ataque MITM o de otro tipo. Las consecuencias podran ser diversas dependiendo

del servicio atacado.

Por otro lado hay conexiones de dudosa legitimidad, que sin duda suponen una
amenaza para la privacidad del usuario. La cantidad de procesos diferentes que

generan ests conexiones tambin son preocupantes.

En concreto en el caso del terminal Sony Xperia Z, el volumen de informacin
enviada y recibida es bastante relevante y adems sabemos que algunas de estas
empresas son compaas de marketing que supuestamente vendern nuestros datos
lo que concuerda con los hallazgos encontrados por el equipo de la Universidad de

Pennsylvania en 2011[8].
Prcticamente todas las conexiones se realizan con empresas de servicios en la
Nube situados en California (EEUU) o China.

Por otro lado, de la comparacin de los resultados entre los dos terminales obtenemos:

Que los dispositivos recin instalados de fbrica envan mucha menos informacin
que aquellos se estn utilizando y tienen varias aplicaciones instaladas. Sera muy
interesante investigar cmo se comportan otros fabricantes de telfonos o

distribuciones de software como CyanogenMod.

Que el nico trfico generado que tienen en comn ambos dispositivos, es el trfico
destinado a los servidores de Google.

Por tanto se puede concluir desde el punto de vista de seguridad:

Se debe filtrar totalmente todo el trfico que no viaja hacia los servidores de Google.
Esta forma de comportamiento no llamar la atencin a un potencial atacante que

estuviera observando nuestro trfico.

Se debe filtrar todo el trfico que viaja sin proteccin SSL/TLS, incluida el que viaja a

los servidores de Google.

Sera objeto de discusin si debemos filtrar el trfico que viaja protegido hacia los
servidores de Google, pues de esta manera nos encontraramos con el problema
descrito en la seccin el telfono opaco que se hace brillante.

PROPUESTA DE SERVICIO DE OCULTACIN

Como esperbamos los telfonos inteligentes generan un patrn de trfico distinguible. Por
otro lado un telfono seguro no debiera permitir que se realicen tantas conexiones con
servicios de dudosa o ninguna utilidad para el usuario. El nico inconveniente de mejorar la
seguridad limitando estas conexiones que puede hacer que el telfono destaque entre el
resto.
Sin embargo, dado que la nica interseccin de destinos de trfico entre los dos telfonos
son los servidores de Google. Por tanto, podemos estar tranquilos si eliminamos todas las
dems conexiones de dudosa utilidad.
Por otro lado, todas estas conexiones son a empresas de servicios en la nube con IPs que
pueden variar dentro de unos ciertos rangos consecutivos. Lo que significa que podramos
contratar servidores con direcciones IP prximas y generar un trfico muy similar al de un
terminal sin modificar pero controlado por nosotros mismos. De esta forma la huella de
nuestro telfono sera muy similar a la de un terminal recin salido de fbrica.
La conclusin es que si queremos que nuestro telfono no destaque entre los dems no
debemos eliminar las conexiones con los servidores de Google, asumiendo por otro lado
potenciales vulnerabilidades.
A la hora de establecer conexiones seguras para la voz y la mensajera, el hecho de que
haya cientos de terminales comunicndose con distintos servidores alojados en empresas
de servicios en la nube, nos proporciona cierta ocultacin y nos permite contratar con
cualquiera de las compaas ms populares de servicios en la nube sin llamar la atencin.
Incluso podramos contratar varios y de esta forma simular el comportamiento de un telfono
no modificado pero con el habitual spyware instalado.

ANLISIS DE COSTES
En el caso de que decidamos adquirir una solucin comercial, la utilizacin de servicios de
mensajera y llamada segura tiene un coste relativamente bajo. Por ejemplo, Samsung
KNOX cuesta 40$ al ao y el BlackPhone incluye el servicio de por vida a cambio un precio
de venta de terminal algo ms elevado (629$) de lo esperable por el resto de sus
prestaciones.

Lamentablemente, estas soluciones comerciales no dispondran de un

servicio de ocultacin como el que hemos descrito previamente; de forma que sera
claramente observable que todas las conexiones viajan haca un mismo servidor, incluidas
tambin, las actualizaciones de Google.
El desarrollo propio sera algo ms caro en principio, aunque podra amortizarse segn el
nmero

de

terminales

que

se

manejasen.

Los

costes

ms

relevantes

seran

fundamentalmente laborales. Al menos haran falta 150 horas/hombre* de trabajo para

desarrollar una solucin aceptable. Despus habra que aadir los costes de mantenimiento
asociados, que seran: el hosting del servidor, la generacin de certificados, la instalacin
del software en cada dispositivo y el mantenimiento preventivo de la solucin. Esto requiere
que al menos haya una persona dedicada una cantidad relevante de su tiempo de trabajo,
para que pueda realizar las tareas de mantenimiento con diligencia.
Una solucin propia se la puede permitir cualquier corporacin de tamao mediano o una
corporacin con un enfoque fundamental en la seguridad. En el caso de las FAS no hay
ninguna duda de que es lo ms adecuado aunque surge un nuevo inconveniente. Realizar
un desarrollo propio supone renunciar a un control de la integridad del dispositivo, que
lamentablemente solo pueden realizar los fabricantes de hardware.
La solucin ideal es sin duda una colaboracin entre las FAS y empresas de desarrollo
hardware, pero seguramente esto ya no sea tan econmico y viable.

PD - Basado en mi experiencia profesional modificando el Kernel de Android.

CONCLUSIN
La telefona mvil basada en terminales Android no es por defecto segura. Esto no se debe
a la falta de preocupacin por parte de Google, sino a la propia naturaleza de un terminal
pensado para un uso recreativo donde cualquiera puede fabricar software sin pasar por una
revisin en profundidad. Segn al artculo de Yajin Zhou y Xuxian Jiang Dissecting Android
Malware: Characterization and Evolution el 84% del malware proviene de aplicaciones que
se encuentran re-empaquetadas en la tienda de Google Play.
Adems hay comportamientos que realizan algunos telfonos por defecto entraan serias
dudas ticas e incluso legales, dado que envan informacin privada del usuario a empresas
de marketing.
Sin embargo es realmente sencillo convertir el terminal Android en un dispositivo muy
seguro reduciendo su funcionalidad y utilizando los estndares ms comnmente
aceptados. Adems se pueden adquirir soluciones comerciales aceptables por precios muy
razonables.
El caballo de batalla que an queda por resolver es la integridad del dispositivo durante todo
su ciclo de funcionamiento, aunque hay empresas que parecen haberlo resuelto como
Boeing o Samsung.
Finalmente era objeto de este estudio determinar si el hecho de bastionar el telfono lo
haca ms visible a posibles espas instalados en las redes telefnicas. La conclusin es que
este efecto se puede evitar siempre y cuando

se mantengan los servicios de Google

activos. Aunque lo ms recomendable sera desactivar aquellos que no utilizan conexiones

SSL/TLS.

REFERENCIAS
Bibliografa

Libros Impresos:
o Telecomunicaciones Militares para el despliegue de fuerzas en misiones
humanitarias y de mantenimiento de la Paz, Grupo de Trabajo de Defensa y
Seguridad del Colegio Oficial de Ingenieros de Telecomunicacin, 2013,
o

ISBN: 978-84-936910-2-8
Android Security Cookbook, Keith Makan and Scott Alexander-Bown,

December 2013, ISBN 9781782167167

Publicaciones digitales:
o Symantec Internet Security Threat Report 2014, Abril 2014, Volume 19. [2]
o Number of the Week: at Least 34% of Android Malware Is Stealing Your Data.
http://www.kaspersky.com/about/news/virus/2011/Number of the Week at

Least 34 of Android Malware Is Stealing Your Data[3]

Artculos:
o The Case for SE Android Stephen Smalley sds@tycho.nsa.gov Trust
Mechanisms
o

(R2X) National Security Agency[1]

The Impact of Vendor Customizations on Android Security, Lei Wu, Michael
Grace, Yajin, Zhou, Chiachih Wu, Xuxian Jiang, Department of Computer

Science, North Carolina State University.

A Study of Android Application Security William Enck, Damien Octeau, Patrick
McDaniel, and Swarat Chaudhuri USENIX Security Symposium August 2011
Network and Security Research Center, Department of Computer Science and

Engineering, Pennsylvania State University. [8]

Dissecting Android Malware: Characterization and Evolution Yajin Zhou,
Xuxian Jiang Department of Computer Science North Carolina State

University[4]
Understanding Android Security WILLIAM ENCK, MACHIGAR ONGTANG,
AND PATRICK MCDANIEL Pennsylvania State University, IEEE security &

privacy, 2009[6]
TaintDroid: An Information-Flow Tracking System for Realtime Privacy
Monitoring on Smartphones, Paper by W. Enck, P. Gilbert, B.-G. Chun, L. P.
Cox, J. Jung, P. McDaniel, A. N. Sheth

MockDroid: Trading Privacy for Application, Functionality on Smartphones,

Paper by A. R. Beresford, A. Rice, N. Skehin, R. Sohan

Paranoid Android: Versatile Protection for Smartphones, Paper by G.
Portokalidis, P. Homburg, K. Anagostakis, H. Bos, Efcient, Context-Aware
Privacy Leakage Connement for Android Applications without Firmware

Modding,Mu Zhang, Heng Yin, Department of EECS, Syracuse University

T. Book, A. Pridgen, and D. S. Wallach. Longitudinal Analysis of Android Ad
Library Permissions. In IEEE Mobile Security Technologies, MoST 13, 2013.
S. Chakradeo, B. Reaves, P. Traynor, and W. Enck. MAST: Triage for Marketscale Mobile Malware Analysis. In Proceedings of the 6th ACM Conference on

Security and Privacy in Wireless and Mobile Networks, WiSec 13, 2013.
J. Crussell, C. Gibler, and H. Chen. Attack of the Clones: Detecting Cloned
Applications on Android Markets. In Proceedings of 17th European
Symposium on Research in Computer Security, ESORICS 12, 2012 A. P. Felt,
E. Chin, S. Hanna, D. Song, and D. Wagner. Android Permissions
Demystified. In Proceedings of the 18th ACM Conference on Computer and

Communications Security, CCS 11, 2011.[5]

Android Permissions Demystified, Adrienne Porter Felt, Erika Chin, Steve
Hanna, Dawn Song, David Wagner, University of California, Berkeley[7]

Web-grafa

Fabricantes de telfonos seguros:

o https://www.blackphone.ch
o http://www.boeing.com/boeing/defense-space/ic/black/index.page
o http://www.freedompop.com
o https://guardianproject.info
o http://www.hermessecur.com
o https://www.samsungknox.com/en/solutions/knox/technical
o https://www.divide.com/features/security
o https://whispersystems.org
o http://c-skills.blogspot.com/

Foros de Seguridad
o http://forum.xda-developers.com
o http://nakedsecurity.sophos.com/es/2012/09/04/russia-secure-tablet-romos/
o https://securityinabox.org
o https://learningnetwork.cisco.com/blogs/vipo

perspectives/2010/12/11/geolocation-in-wireshark
http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-

o
o
o
o

maths/
http://thoughtcrime.org/blog/telegram-crypto-challenge/
http://c-skills.blogspot.com/2011/04/yummy-yummy-gingerbreak.html
http://www.csc.ncsu.edu/faculty/jiang/AnserverBot/
http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu.html

Wikipedia
o http://en.wikipedia.org/wiki/Socialist_millionaire

Otros
o http://www.gsmarena.com