TacticalCombatSmartPhone_final

Trabajo Fin de Máster
presentado por: SETIEN DODERO, FERNANDO
Director/a: VÁZQUEZ POLETTI, JOSÉ LUIS
Ciudad: MADRID
Fecha: 19/09/2014
Universidad Internacional de La Rioja
Máster universitario en Seguridad Informática
Tactical Combat
SmartPhone

Resumen
Este trabajo surge de una necesidad detectada en el ámbito de las operaciones militares
desarrolladas por las Fuerzas Armadas Españolas. Se trata evaluar la posibilidad de utilizar
teléfonos inteligentes de forma segura en zona de operaciones. Además de revisar las
soluciones actuales tratamos de responder al interrogante de si un teléfono bastionizado se
convierte en más visible que el resto por el hecho de ser diferente del resto. Para contestar a
este interrogante se analizará el tráfico de varios terminales, con el fin de definir su huella y
compararla. La conclusión es que dada la naturaleza del tráfico de los dispositivos Android,
se puede hacer un teléfono seguro, pero debemos mantener las conexiones con Google
para no llamar la atención a un posible atacante instalado en la red telefónica.
Palabras Clave: Android, Seguridad, Análisis de tráfico
Abstract
This dossier issue from the Spanish Armed Forces needs on the actual peace-keeping
operations. It aims to evaluate the possibility of using smart phones on the operational
theatre. More than reviewing the actual solutions we target to answer the question if a
bastionized terminal becomes localizable just for the matter of being different from the rest of
the terminals. In order to answer this question we analyze the spontaneous traffic generated
from several terminals looking for its footprint. The conclusion is that we can create a secure
Android terminal, but we should maintain communications with Google, if we want to be
silent to a possible attacker inside the telephone network.
Keywords: Android, Security, Sniffing

íNDICE
ANTECEDENTES ..................................................................................................................5
ESCENARIO ......................................................................................................................7
ANÁLISIS 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
FreedomPop’s “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 MENSAJERÍA Y LLAMADA SEGURA................................................15
SOLUCIONES DE REDUCCIÓN 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 teléfono Opaco que se hace Brillante........................................................................19
ANÁLISIS DE LOS PATRONES DE TRÁFICO ....................................................................20

INTRODUCCIÓN..............................................................................................................20
MATERIALES Y MÉTODOS.............................................................................................20
TERMINALES MÓVILES ..............................................................................................20
PROCEDIMIENTO DE CAPTURA DE DATOS .............................................................20
PROCEDIMIENTO DE ANÁLISIS DE LOS DATOS ......................................................21
RESULTADOS .................................................................................................................22
COMPROBACIÓN DEL SISTEMA DE CAPTURA ........................................................22
Estadísticas básicas......................................................................................................26
Análisis Temporal..........................................................................................................27
Análisis de la Confidencialidad......................................................................................29
Análisis de los destinos de Conexión ............................................................................37
HAYAZGOS RELEVANTES .............................................................................................40
PROPUESTA DE SERVICIO DE OCULTACIÓN .................................................................41
ANÁLISIS DE COSTES .......................................................................................................42
CONCLUSIÓN .....................................................................................................................43
REFERENCIAS....................................................................................................................44
Bibliografía........................................................................................................................44
Web-grafía........................................................................................................................46

INDICE DE TABLAS
Tabla 1: Sistemas de Comunicación Tácticos ........................................................................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
Ilustración 1: Patrón de desbloqueo .....................................................................................18
Ilustración 2: Interfaces de Red............................................................................................22
Ilustración 3: Captura de Datos ............................................................................................23
Ilustración 4: Comparación de Capturas de Tráfico..............................................................24
Ilustración 5: Captura con Wifi..............................................................................................24
Ilustración 6: Captura con tPacketCapture ...........................................................................25
Ilustración 7: Gráfico de captura Sony Xperia Z ...................................................................27
Ilustración 8: Grafico catpura MediaTek ...............................................................................28
Ilustración 9: Mapa de conexiones del Xperia Z ...................................................................38
Ilustración 10: Mapa de conexiones del MediaTek ...............................................................38

ANTECEDENTES
Este trabajo surge de una necesidad detectada en el ámbito de las operaciones militares
desarrolladas por las Fuerzas Armadas Españolas (FAS). Las FAS disponen de multitud de
soluciones de transmisiones altamente seguras y fiables. En los despliegues más habituales
se utilizan combinaciones de enlaces de radio en la banda UHF con sistemas Satélite, que
se integran a través de vehículos específicos de comunicaciones con la capacidad de
integrar varias redes. Cada uno de estos sistemas tiene alguna limitación de forma que
ninguno llega a ser un sistema de comunicaciones perfecto.
RADIO UHFSISTEMAS
SATCOM
TELEFONÍA
CELULAR
50KmILIMITADOILIMITADOALCANCE
Muy alta dentro de
cobertura
Limitada según la
orografía
Muy alta dentro de
cobertura
DISPONIBILIDAD
>10Kg<1Kg<200grPESO
9,6Kbs512Kbs9,6Kbs – 2MbsCAPACIDAD
Tabla 1: Sistemas de Comunicación Tácticos
Como se aprecia en la tabla, actualmente ningún sistema de transmisiones militar puede
igualar a un sistema de comunicaciones móviles civil desplegado. Esto parte lógicamente
del tremendo despliegue de recursos que supone el despliegue de una red de telefonía
celular.
En un conflicto abierto, muy probablemente se destruirían la capacidad de comunicación del
enemigo como un primer paso previo a la invasión. Sin embargo las Fuerzas Armadas
Españolas se ven principalmente desplegadas en misiones humanitarias y de
mantenimiento de la paz, donde no tiene sentido destruir la infraestructura de
comunicaciones del País.
Por tanto, nos encontramos en la paradoja de que grupos armados terroristas que acosan a
nuestras FAS disponen en ocasiones de mejores sistemas de comunicaciones que las
propias tropas de mantenimiento de la paz, ya que la telefonía móvil celular no se considera
segura y por tanto en general no se utiliza.

ESCENARIO
Dentro de las misiones Internacionales llevadas a cabo por las FAS vamos a centrarnos en
un escenario específico, aunque posteriormente lo podamos ampliar a más 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 misión principal. Vamos a añadir los siguientes supuestos:
• La red telefónica está completamente intervenida por el enemigo.
• Se pueden conseguir terminales y tarjetas SIMs no conocidas por el enemigo.
• Para simplificar el análisis nos centraremos en la plataforma Android.
• Nos centraremos sólo en las comunicaciones (mensajería y voz) y no en la utilización
de aplicaciones sobre la plataforma.
ANÁLISIS DE LAS DIMENSIONES DE LA
SEGURIDAD
En los siguientes apartados analizaremos las diferentes dimensiones de la seguridad dentro
del escenario propuesto. Este análisis nos concretará las soluciones de seguridad que
debemos incorporar a nuestra plataforma.
Por solución de seguridad no entendemos ni un servicio, ni un mecanismo de seguridad. Es
un conjunto de mecanismos (y por tanto servicios) relacionados por su función dentro de la
plataforma. Por ejemplo, la solución de mensajería segura contempla distintos mecanismos
dentro de los servicios de confidencialidad, integridad y autenticación, pero todos ellos
relacionados todos con la función de mensajería.
Algunas soluciones son directamente los servicios de seguridad de la plataforma. Algunos
servicios los proporciona directamente la plataforma sin necesidad de instalar ningún
software adicional.
CONFIDENCIALIDAD
Las amenazas a la confidencialidad, pueden venir principalmente por tres caminos:
• El tráfico generado por nosotros mismos para comunicarnos que es interceptado.

• El tráfico generado por el dispositivo y que no podemos controlar.
• El dispositivo ha sido comprometido y envía información sin que nosotros lo
sepamos.
• El dispositivo ha sido capturado y es analizado de forma forense.
Para proteger el tráfico generado voluntariamente por nosotros, utilizaremos servicios de
mensajería y llamadas seguras que además también nos proporcionarán otros servicios de
seguridad.
El tráfico generado por el dispositivo y que no podemos controlar, es objeto de este
trabajo. Primero estudiaremos la naturaleza de este tráfico y después 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. Además la información que permite la
Autenticación del dispositivo debe protegerse criptográficamente con fuerza para evitar un
ataque de suplantación de identidad. Este ataque será inevitable si se supera el servicio de
control de acceso.
En cuanto a la información almacenada, dado que el escenario que contemplamos sólo
utilizamos el teléfono como sistema de transmisión, los únicos datos que se almacenarán
serán las conversaciones vía mensajes y el registro de llamadas. Esta información podría no
almacenarse de ninguna manera, almacenarse en la red, almacenarse de forma volátil o
cifrarse fuertemente. Este comportamiento depende de la solución de mensajería segura
que escojamos.
También podría ser útil la capacidad de destrucción del propio terminal, bien localmente o
remotamente. Aunque hay que tratarlo con cautela dado que su implementación puede
generar un problema de seguridad en sí mismo.
INTEGRIDAD
Para mantener la integridad en las comunicaciones utilizaremos también soluciones de
mensajería segura. Sin embargo también 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 ningún tipo de software más allá del estrictamente necesario y comprobado.
Lamentablemente esto no es suficiente, puesto que el dispositivo puede sufrir alguna
vulnerabilidad que permita la instalación de software malicioso. Por tanto necesitaremos
soluciones que:
• Comprueben la integridad del dispositivo.
• Limiten la superficie de ataque (Bastionado).
También 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 comunicación, y no como una plataforma con aplicaciones y datos, por tanto no
existe necesidad de integridad más allá del software y de la información transmitida.
DISPONIBILIDAD
En general los dispositivos móviles no tienen problemas de disponibilidad, y lo que
determina la disponibilidad es la propia red de telefonía móvil. Dado que en nuestro
supuesto la red de telefonía móvil 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 patrón de
tráfico. Esto es también objetivo del estudio.
La disponibilidad también se ve afectada por la duración de la Batería de los dispositivos,
normalmente esta se puede alargar con baterías adicionales y dado que la duración de los
terminales actuales es suficiente, no la consideraremos.
AUTENTICIDAD
Nuestra solución de mensajería 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 conversación. De alguna forma también 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 telefonía supuestamente seguro la mayoría están basadas en
la plataforma Android, esto es bastante lógico ya que esta plataforma es la que permite más
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 mensajería y llamadas de voz
IP.
FreedomPop’s “Snowden Phone”
Este teléfono se vende junto con el servicio de seguridad basado en VPN que utiliza cifrado
de 128bits. Además permite cambiar de número de teléfono IP todas las veces que se
quiera para proporcionar aún más anonimato. Además de las llamadas y la mensajería la
navegación web y cualquier otra aplicación también se aseguran a través de la conexión
VPN.
The Boeing Black Smartphone
Este dispositivo es un Hardware específicamente diseñado para aumentar la seguridad y
provee más servicios de seguridad que el FreedomPop’s 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 característica de funcionar
adecuadamente dificultaría en teoría el posible análisis forense.
• La verificación de los certificados se hace directamente desde el hardware en una
memoria de sólo lectura.
• El arranque del dispositivo está protegido con una comprobación de integridad
utilizando los certificados protegidos por hardware.
• Cifrado y almacenamiento de claves por hardware.
• Cifrado de disco completo.
• Módulos hardware diversos: Acceso Biométrico, Telefonía satelital, etc.

La mayoría de los detalles de este teléfono no se desvelan, esperando ganar seguridad por
oscuridad. Entendemos que al comprador final si se comunicarán los detalles de las
características de seguridad, y que tan solo se trata de otra capa más de seguridad y no un
error de base.
The Blackphone
El BlackPhone provee los servicios de llamadas, mensajería y navegación segura a través
de una conexión VPN. Además el SO Android está bastionado contra los posibles ataques
desde la red.
Todos los servicios de Google incluyendo la tienda Google Play no están en el dispositivo,
de forma que el teléfono solo se comporta como teléfono en un principio, evitando la
principal causa de posibles vulnerabilidades.
También provee un servicio adicional para controlar los permisos de las aplicaciones. En la
plataforma Android, cuando se instala una aplicación se conceden permisos que no se
vuelven a revisar y que en ocasiones son mayores de los realmente necesarios. Con este
control adicional añadimos privacidad evitando que las Apps accedan a datos nuestros que
no deberían necesitar.
Otro servicio permite detectar las redes inalámbricas que pueden ser comprometidas
(Cifrado débil, Rogue AP, etc.,) no permitiéndonos utilizar aquellas redes WiFi que él detecta
como no son seguras.
Las aplicaciones de comunicación se llaman: Silent Circle, Silent Phone y Silent Text. Y
están 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 teléfonos 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 aplicación de mensajería que funciona bajo la red Tor se llama ChatSecure, y proponen
varias aplicaciones de VozIP así como aplicaciones para la destrucción del teléfono de
forma rápida y otros servicios de seguridad.

Whispersystems
Se trata de dos aplicaciones, una de mensajería y otra de llamadas de voz cifradas. Utilizan
combinaciones de los estándares actuales y el código fuente es abierto en busca de obtener
seguridad y confianza.
Divide
Es una solución comercial que promueve el uso seguro del dispositivo para fines
corporativos sin impedir el uso recreativo del dispositivo. Sus principales características son:
• Separación del entorno empresarial del personal a través de control de acceso MAC,
SELinux y cifrado de los discos.
• Conexión segura a través de VPN.
• Una serie de aplicaciones de productividad bien diseñadas e integradas con los
entornos corporativos habituales.
Samsung KNOX Workspace
Es una respuesta al exitoso software Divide recientemente adquirido por Google, pero
aprovechándose de la utilización del hardware. Se basa en mecanismos hardware
(Samsung es fabricante) y el objetivo principal es permitir un uso personal y recreativo del
teléfono sin comprometer una parte segura y corporativa.
Esta es la propuesta de telefonía segura de Samsung que utilizada en conjunto con otras
herramientas puede ser proporcionar una solución completa de seguridad, de hecho esta
tecnología está aprobada por el Departamento de Defensa del Gobierno de los Estados
Unidos.
• Crea una VPN con la red corporativa.
• Permite una comprobación de integridad previa al arranque del dispositivo.
• Realiza una comprobación constante de integridad del núcleo del SO.
• Añade 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 teléfono.
Esta tecnología solo es compatible con algunos dispositivos de la compañía 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 versión 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 tendrán que asegurar el
lanzamiento del kernel de una forma similar a como lo hace Samsung además de
utilizar dm-verity. Google espera que en el futuro sea así.
• SandBoxing, cada aplicación se ejecuta como un usuario único además ahora
soporta SELinux de forma que los permisos están establecidos de forma fija y los
usuarios incluidos el administrador no los pueden modificar. El hecho de activar
SELinux parece reducir drásticamente la posibilidad de que se encuentren futuros
exploits, como afirma Sthephen Smalley en un artículo de la NSA [1].
• Control de Acceso, se impide el acceso al dispositivo y a los certificados
almacenados si no proporciona una contraseña o patrón 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 conexión a VPN con diferentes tecnologías entre ellas
IPSec.
• Protección contra Buffer Overflow, soporta tecnologías 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 análisis de Symantec Internet Security Threat Report y otras fuentes [2,3,4,5].
Google retira las aplicaciones dañinas pero no hace una revisión exhaustiva de estas, previa
a su publicación.
Por otro lado entre las críticas que se pueden hacer respecto a la arquitectura son pocas,
quizás las más importantes la comunicación entre procesos, que no es la original de Linux y
se ha desarrollado específicamente para Android[6,7]. Utiliza Binder() y es segura sólo si se
utiliza adecuadamente y la ausencia de un sistema de comprobación de certificados
revocados. El número de vulnerabilidades se reduce año a año, y en el último año se redujo
un 70% según el informe de Symantec.

Acceso Super Usuario (Root)
La filosofía de Android no contempla que el usuario del teléfono funcione con privilegios
elevados en ningún momento. La configuración de seguridad se realiza de fábrica y no se
debe modificar nunca, por tanto, es más seguro eliminar la posibilidad de ejecución con
privilegios elevados.
La comunidad de usuarios de Android ha querido exprimir al máximo las capacidades de los
teléfonos más allá de lo que proporcionaban los fabricantes, y para ello ha necesitado
buscar exploits de elevación 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 físicos del terminal y conexión
vía cable USB.
Para permitir el legítimo desarrollo de modificaciones del sistema operativo con fines
corporativos o de investigación, Google y diversos fabricantes de hardware como Sony o
Samsung han promovido versiones de los teléfonos Versión para Desarrollador que
permiten la instalación de Android Open Source Proyect (AOSP). Básicamente estos
terminales tienen desactivada la protección para cambiar el gestor de arranque, con lo que
se puede instalar una versión modificada y sin firmar del Sistema Operativo sin necesidad
de realizar ningún exploit.
La conclusión es que si queremos desarrollar una versión bastionizada de Android, al no ser
fabricantes de Hardware, perderemos la protección del gestor de arranque, lo que permitirá
modificar y comprometer el terminal en caso de que se tenga acceso físico este.

SOLUCIONES DE MENSAJERÍA Y LLAMADA SEGURA
Cualquier sistema de mensajería no seguro que controlemos nosotros mismos, lo podemos
hacer seguro desde el punto de vista de red (Confidencialidad, Integridad), si le añadimos
una VPN por encima. Existen multitud de soluciones VPN de diferentes compañías (como
Moncada), pero lo cierto es que el propio motor de VPN que incorpora Android es más que
suficiente, siempre y cuando tengamos suficiente control de los certificados, dado que
Android no controla los certificados revocados. Para la mensajería y las llamadas podemos
utilizar soluciones de código abierto como Xabber y CSipSimple. Habrá que tener especial
cuidado en configurar la autenticación de forma suficientemente segura.
También existe la posibilidad de chatear a través de la red Tor, añadiendo más
confidencialidad la conversación, puesto que dificultamos que puedan trazar el origen y el
destino de la comunicación.
Existen soluciones que directamente proporcionan los servicios seguros, por ejemplo la
aplicación de mensajería Telegram, ofrece de forma continua un premio de 200.0000$ al
que se sea capaz de romper su seguridad, dándonos una idea de la confianza que tienen en
sí mismos, aunque existen muchas dudas sobre la forma en que se realiza este desafío
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 podrían tildarse casi de paranoicas. Hermes propone un sistema de
mensajería con criptografía asimétrica donde cada mensaje es cifrado con 1024bits y
doblemente ocultado por estenografía dentro de una fotografía, además los mensajes en
claro no se almacenan en ningún momento más allá del momento de su visualización.
SOLUCIONES DE REDUCCIÓN 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, sería desactivar todos los servicios de Google. Aunque Google se
esfuerzan en que estos sean seguros y en principio no son vulnerables (en la última versión
a trabajado mucho en evitar la falsificación de sus certificados); no tienen ninguna utilidad a

la hora de utilizar el teléfono como mero sistema de comunicación. Distribuciones de
Android como CyanogenMod o AOSP vienen por defecto con los servicios y aplicaciones
mínimos instalados.
Además de las aplicaciones y los servicios de Google, también se pueden detener servicios
del SO que no son estrictamente necesarios. SecDroid es aplicación que añade seguridad
realizando lo siguiente:
• Detiene servicios que funcionan por defecto y podrían ser atacados desde la red o la
línea de comandos como como son ssh, ping o net cat.
• Modificar la pila TCP/IP para limitar los paquetes ICMPs aceptables y algunos
parámetros más.
Existe la posibilidad de modificar la configuración de las IPTables (Firewall) por defecto de
Android utilizando aplicaciones como DroidWall o directamente desde línea de comandos,
lógicamente esta modificación requiere permisos de administrador (root), que deberán ser
eliminados una vez revisada la configuración.
También 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 tráfico pase a través de
ellas para posteriormente controlarlo.
SOLUCIONES DE CONFIDENCIALIDAD EN COMUNICACIONES
La solución más sencilla para proteger la confidencialidad del dispositivo es cifrar todo el
tráfico emitido a través de una VPN hasta un punto que podamos controlar, y es lo que
realizan la mayoría de las soluciones comerciales de telefonía segura. Esto se puede hacer
de una forma muy sencilla con el software de base.
En otro contexto, que no debería aplicarse en nuestro escenario, existe una preocupación
mucho más importante sobre la privacidad. Se trata de la capacidad que tienen las
aplicaciones instaladas de acceder a información personal del usuario del dispositivo a
través de la API de Android. Soluciones como OpenPDroid y sus clones, realizan un filtrado
de todos los intentos de acceso a información 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 actualización. Estas
conexiones se realizan de forma segura en un principio utilizando conexiones SSL, pero
como mínimo pueden proporcionan información proveniente del patrón de tráfico generado.
La solución consiste en no tener instalada ninguna aplicación más allá de las necesarias.
SOLUCIONES PARA INTEGRIDAD DE LA PLATAFORMA ANDROID
Los teléfonos inteligentes actuales utilizan memorias flash y habitualmente montan
particiones ext4 que proporcionan cierta protección 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 violación de la integridad del
dispositivo. Todos los fabricantes realizan un chequeo del kernel que se va a cargar durante
la ejecución del BootLoader (secuencia de arranque), para comprobar que este está firmado
y además la zona de memoria de este BootLoader suele estar protegida contra escritura.
Lamentablemente dado que esta zona de memoria, permite actualizaciones esta protección
en general no es suficiente y es vulnerada habitualmente con la intención de instalar ROMs
modificadas.
Si estas protecciones llegaran a madurar lo suficiente, serían junto con el servicio de dm-
verity que extendería la protección a todo el sistema sin alargar los tiempos de arranque y
que está incluida en la última versión de Android, protección 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 más allá, y promete proteger la integridad del hardware,
auto destruyéndose si detecta que este ha sido manipulado.
SERVICIO DE CONTROL DE ACCESO
Android proporciona un servicio de control de acceso basado en contraseña (máx. 17
caracteres) o en un patrón de dibujo (9! combinaciones). Utilizando esta contraseña junto
con un salt se genera la clave que cifra la clave que cifra el disco. El número de intentos
consecutivos fallidos es de 5, lo que parece suficientemente seguro siempre que se siga una
correcta política de contraseñas de acceso.

SERVICIO DE CONFIDENCIALIDAD
Existen soluciones de cifrado de disco más fuerte que la
que proporciona por defecto Android (128bits AES)
algunas de software libre como Cryptonite y otras de
pago de cómo F-Secure o Divide que proporcionan
cifrados más potentes.
En realidad la debilidad del cifrado se encuentra en la
propia clave que tan solo se cifra con la entropía
proporcionada con la clave de usuario más un
Potencialmente puede ser atacado po
diccionario si no se utilizan claves suficientemente
fuertes. Patrones de desbloqueo del terminal sencillos
como una L, U, A, T, etc. no serían seguros.
CONCLUSIONES
Hemos visto que en la actualidad a pesar del origen que haya podido tener e
bastante seguro, y la mayor parte de las amenazas provienen del uso y del software que el
mismo usuario instala. Con una adecuada política de uso razonable del terminal (Control de
Acceso, Cifrado, Política de Claves, Aplicaciones instalada
seguridad aceptable utilizando aplicaciones de mensajería que aportan cierto nivel de
seguridad como Telegram o
Más interesante aún es crear un distribución del SO con un nivel de seguridad a
elevado. Basándose en AOSP o CM, realizando pequeñas modificaciones, utilizando las
políticas antes mencionadas y añadiendo una conexión IPSec con la red corporativa se
puede obtener un móvil de alta seguridad. Es más, existen soluciones comerciales
pueden adquirir a un precio razonable y que siguen esta misma filosofía como el
FreedomPop, el BlackPhone
Lamentablemente si creamos esta distribución de forma manual perderemos la capacidad
de controlar la integridad
SERVICIO DE CONFIDENCIALIDAD
Existen soluciones de cifrado de disco más fuerte que la
que proporciona por defecto Android (128bits AES)
algunas de software libre como Cryptonite y otras de
Secure o Divide que proporcionan
En realidad la debilidad del cifrado se encuentra en la
propia clave que tan solo se cifra con la entropía
proporcionada con la clave de usuario más 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 serían seguros.
Hemos visto que en la actualidad a pesar del origen que haya podido tener e
Acceso, Cifrado, Política de Claves, Aplicaciones instaladas) se puede obtener una
Telegram o mucho mejor Whisperingsystems o Hermes.
Más interesante aún es crear un distribución del SO con un nivel de seguridad a
puede obtener un móvil de alta seguridad. Es más, existen soluciones comerciales
BlackPhone o el Boeing Black SmartPhone.
de controlar la integridad del sistema operativo durante el arranque. Así que en principio
Ilustración
Hemos visto que en la actualidad a pesar del origen que haya podido tener el SO Android es
s) se puede obtener una
mucho mejor Whisperingsystems o Hermes.
Más interesante aún es crear un distribución del SO con un nivel de seguridad aún más
puede obtener un móvil de alta seguridad. Es más, existen soluciones comerciales que se
del sistema operativo durante el arranque. Así que en principio
Ilustración 1: Patrón de desbloqueo

sería algo más seguro adquirir un terminal seguro siempre que exista una relación de
confianza con los proveedores.
En el caso militar podría ser más interesante realizar una distribución propia e intentar paliar
esta falta de comprobación de integridad con políticas de uso aun más estrictas, como por
ejemplo realizando chequeos externos de la integridad del terminal desde un PC. En estos
momentos ciertos grupos específicos de las FAS ya están utilizando este tipo de
distribuciones, pero aun no es de uso generalizado.
El teléfono Opaco que se hace Brillante
Dado que la mayoría de los teléfonos inteligentes actuales están continuamente
conectándose con servicios de las compañías suministradoras de software, habitualmente
sin conocimiento del usuario; un móvil que sea completamente opaco y que realice
conexiones cifradas con un solo destino, se puede convertir de forma no esperada en un
dispositivo más visible que el resto.
Podemos utilizar relleno de tráfico para garantizar la Confidencialidad y evitar que se
averigüe 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 telefonía localiza los
terminales, lo que supone un grave problema de seguridad.
En este trabajo vamos a estudiar si es posible añadir el servicio de seguridad de ocultación
a un teléfono móvil seguro. Analizando el tráfico veremos si es viable la creación de dicho
servicio, y si es compatible con el aumento de la resistencia contra vulnerabilidades
manteniendo el comportamiento estándar del teléfono.

ANÁLISIS DE LOS PATRONES DE TRÁFICO
INTRODUCCIÓN
Los objetivos de este análisis son dos, por un lado determinar el grado de confidencialidad
que proporciona un teléfono inteligente bajo la plataforma Android y por otro determinar si es
posible ocultar un sistema de comunicación seguro bajo el comportamiento normal del
teléfono.
MATERIALES Y MÉTODOS
TERMINALES MÓVILES
Para el propósito de este estudio era necesario analizar dispositivos como los que se
encuentran en zona de operaciones. Afortunadamente esto es más sencillo de lo que en un
principio podría haber sido. Los dispositivos móviles que se encuentran a la venta en
Afganistán o el Líbano vienen directamente desde China con firmwares que soportan varios
de los idiomas y dialectos locales.
El análisis se realizará desde territorio nacional, porque suponemos que el comportamiento
del firmware del teléfono no depende del operador móvil 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 serán 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 análisis de tráfico el “Gold Standar” es utilizar un dispositivo de captura en el mismo
nivel I del protocolo de comunicación. En el caso para capturar de la interfaz de red
inalámbrica sólo se requiere una tarjeta de red capaz de funcionar en modo promiscuo. Se
puede utilizar un portátil conectado a la misma red con el software de captura wireshark. En
el caso de que queramos capturar tráfico de la red de telefonía 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 tráfico del terminal en un formato estándar
(pcap, tcpdump) que luego se puede evaluar con otras herramientas análisis. Estas
herramientas basan la captura en la creación de una VPN virtual a través de la cual
encaminan todo el tráfico.
La primera fase del estudio consistirá en comprobar que la herramienta tPacketCapture se
comporta de igual manera que un ordenador portátil con la distribución Linux para la
auditoria de redes inalámbricas WifiWay instalada y una tarjeta de red compatible.
Una vez comprobado esto, el resto de las capturas se realizará con App de captura de
tráfico y la interfaz inalámbrica deshabilitada, pues es la interfaz radio, la que realmente nos
interesa analizar y los terminales no se comportan exactamente igual cuando tienen
cobertura inalámbrica que cuando solo tienen cobertura radio.
Los análisis se realizarán con los dos terminales en reposo durante un día completo.
PROCEDIMIENTO DE ANÁLISIS DE LOS DATOS
Se realizará un listado de todos los destinos con los que se conecta el terminal y de si esta
conexión es o no cifrada. En las conexiones que no sean cifradas se investigará la clase de
información que se transmite en busca de alguna posible debilidad. Después se realizará un
análisis gráfico durante 24 horas de cuando conecta, con quien y donde.
Estos análisis se realizarán utilizando el reconocido analizador de protocolos WireShark,
utilizando las herramientas de análisis de conversaciones y de destinos y la funcionalidad de
localización geográfica y resolución de nombres de dominio.

RESULTADOS
COMPROBACIÓN DEL SISTEMA DE CAPTURA
Lo primero que vamos a hacer es comprobar que la herramienta tPacketCapture captura la
misma información que capturando directamente los datos de la red inalámbrica con
WifiWay.
Primero investigamos las interfaces de red que tenemos para que luego nos resulte más
sencillo analizar los datos. Desde la consola del propio terminal podemos visualizar
información de red y con el comando netcfg (En Android no están exactamente los mismos
comandos que en Linux). Averiguamos las interfaces de red que tenemos:
Ilustración 2: Interfaces de Red
Todos los paquetes debería tener el mismo origen o destino y este debiera ser la interfaz del
túnel VPN virtual, sin embargo algo raro sucede porque el sistema también 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 teléfono móvil de activar
la Wifi en función de la posición geográfica cuando se encuentra cerca de un lugar conocido.
Esto nos obliga a repetir el análisis con la funcionalidad desactivada.

Ilustración 3: Captura de Datos
Descargamos la última versión de WifiWay y la instalamos en un disco flash USB.
Configuramos la red inalámbrica con cifrado WEP. En teoría debería funcionar sin ninguna
clase de cifrado, pero después de realizar varias pruebas, descubrimos que por algún
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 ningún 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 más recomendada.
Durante las pruebas también descubrimos que debemos alejar el teléfono del ordenador
portátil que tiene la tarjeta de captura, de no hacerlo así se pierden paquetes por exceso de
señal.
Finalmente el procedimiento fue el siguiente:
• Intentamos iniciar las dos capturas simultáneamente.
• 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 fáciles 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
Ilustración 4: Comparación de Capturas de Tráfico
Se aprecia claramente los paquetes de fragmentan de forma diferente. En general en la Wifi
se transmiten paquetes más pequeños que los que salen de la interfaz virtual. Esto se debe
en parte al cifrado en bloques que proporciona WEP.
Esta fragmentación provoca que se desordenen también los paquetes. En este caso las
peticiones DNS que salen todas juntas a través de la interfaz VPN, posteriormente en
interfaz inalámbrica se ven dispersadas entre otros paquetes de peticiones http
fragmentados. Sin embargo, mirando con detenimiento comprobamos que el tiempo de
envío de los paquetes es prácticamente idéntico en ambas capturas.
Ilustración 5: Captura con Wifi

Aunque a nivel IP nos encontramos con informaciones diferentes de cara a nuestra
investigación lo que queremos saber, es si a nivel de transporte no perdemos ninguna
información. Para ello podemos utilizar la herramienta de WireShark, que analiza las
conversaciones TCP/UDP.
El número de conversaciones TCP, el origen el destino y la duración coinciden
completamente, aunque varía ligeramente el número de Bytes, transmitidos. Entendemos
que esto es debido a la variación del overhead debido a la fragmentación.
Parece razonable concluir que el procedimiento de captura utilizando la aplicación
tPacketCapture es válido a nivel de transporte aunque no lo es a nivel IP.
Ilustración 6: Captura con tPacketCapture

Estadísticas básicas
Se realizaron 2 capturas durante 24h con cada teléfono. El teléfono Mediatek con las
aplicaciones por defecto instaladas, y el teléfono XperiaZ de uso personal que tiene docenas
de aplicaciones instaladas pero solo un programa de mensajería (Whatsapp) funcionando.
Durante la captura de datos no se interacciona con los dispositivos.
DURACIÓNTRÁFICO
TOTAL
CONEXIONES
ENTRANTES
PAQUETES
UDP/DNS
PAQUETES
TCP
CAPTURATERMINAL
24h6199 pqs
21,6 Mbytes
01828437116/08/2014XperiaZ
24h1102 pqs
280 Kbytes
013896419/08/2014MediaTek
Tabla 2: Resumen de Capturas
Análisis de las Conexiones entrantes no iniciadas por el terminal
Queremos saber si el terminal recibe algún tipo de comunicación no iniciada por el mismo.
Esto es importante porque supondría la comprobación de que los terminales móviles no
están protegidos por la red telefónica y están 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 ningún paquete en ninguna de las
capturas, con lo que suponemos que esta situación no sucede habitualmente.
Análisis del tipo de tráfico a nivel de transporte (TCP/UDP)
Lo que queremos averiguar es que porcentaje del tráfico es TCP y UDP. Y dentro del tráfico
UDP que tipo de protocolo se utiliza.
El 99% tráfico UDP observado son peticiones DNS, exceptuando una petición NTP, siendo
el resto del tráfico únicamente TCP.
Análisis de puertos TCP y protocolos conocidos
La mayoría del tráfico utiliza los puertos de los protocolos http o https. Los servicios de
mensajería (Whatsapp y Gtalk) utilizan otros puertos estándar como 5222 y 5228. Unas
pocas aplicaciones utilizan puertos diferentes.

PUERTOCAPTURA
http(80)https(443)5228*5287**5222***
1935 paq
44%
1842 paq
42%
268 paq
6%
186 paq
4%
140 paq
3%
XperiaZ
16/08
264 paq
27%
423 paq
44%
277 paq
29%
--MediaTek
19/08
Tabla 3: 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
Análisis Temporal
WireShark nos proporciona directamente la posibilidad de dibujar una gráfica de los
paquetes transmitidos y recibidos en función del tiempo. Como las posibilidades de dibujo de
la versión actual de WireShark son algo limitadas, utilizamos el Preview de la versión 2 de
WireShark todavía en desarrollo que tiene un motor más potente de dibujo de gráficas. Lo
que mostramos es directamente el volumen de tráfico según la hora del día durante 24h.
Ilustración 7: Gráfico de captura Sony Xperia Z

Ilustración 8: Grafico catpura MediaTek
También nos interesa analizar los intervalos sin transmisión de datos a lo largo del día. Para
ellos utilizando una hoja de cálculo analizamos los intervalos mayores de 1min.
INTERVALO SIN DATOSCAPTURA
MEDIADESVIACIÓNMÁXIMO
6min5min34minXperiaZ
16/08
9min 30s5min 40s15minMediaTek
19/08
Tabla 4: Intervalos sin Datos
Lo que se apreció de este análisis es lo siguiente:
• Peticiones periódicas por parte del terminal, con una cadencia menor para el terminal
Sony que para el MediaTek, probablemente debido a un sistema de ahorro de
energía que reclama tener.
• Una considerable mayor cantidad de tráfico desde el móvil Sony, presumiblemente
debido a que el terminal tiene más aplicaciones instaladas, entre ellas una de
mensajería.
• Los móviles no llegan a estar en silencio un intervalo mayor de media hora nunca.

Análisis 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 TCPDESTINOS
SIFacebook.com
NOWhatsapp.net
SIXperialounge.sonymobile.com
NOAmazonaws.com
NOAgentchannel.api.n.shifen.com
NOMobile-gtalk.l.google.com
NOAndroid.Clients.google.com
SIGoogleapis.l.google.com
SIEdgecastcdn.net
NOAccu-weather.com.cdngc.net
SIPushct.n.shifen.com
SI y NOGoogleusercontent.com
SIDataflurry.com
TOTAL: 140 Conexiones a 12 Destinos
Tabla 5: Conversaciones XperiaZ
MediaTek
CIFRADO TCPDESTINOS
NOproxy.sogou.com
Si195.57.81.42 (Akamai)
NOgstatic.com
SIandroid.l.google.com
SI y NOclients.l.google.com
SImobile-gtalk.l.google.com
SI64.233.166.188 (Google)
SIfacebook.com
TOTAL: 42 Conexiones a 11 Destinos
Tabla 6: Conversaciones MediaTek

Analizamos los destinos uno por uno entre los que el tráfico no está cifrado, los destinos que
no deberían existir o los que por cualquier otro motivo nos parece sospechosos.
Proxy.sogou.com
Sogou.com es un proveedor de búsqueda chino. La conexión 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 parámetro y reciben
siempre la misma respuesta. Se realizan en total 12 peticiones a intervalos que varían
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=/
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 dirección 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 conexión provocado por un cambio de IP. El
último de estos mensajes sucede 3min después de empezar la grabación, y hay que tener
en cuenta que se realizó una prueba de conexión a la web www.meneame.net que se
terminó un minuto antes de empezar la grabación.
También podría 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 información personal. Por lo que sabemos de
la aplicación la conexión está cifrada a nivel de aplicación aunque no lo esté a nivel de
transporte.
WA.............Android-2.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 conexión con un WebService (JSON) en claro y se
utiliza una Cookie para su autenticación. Se conecta con los servidores Cloud de Amazon.
Aunque no se aprecia a simple vista información personal esta conexión es potencialmente
vulnerable.
La compañía que está finalmente detrás de esta conexión es http://www.appoxee.com.
Que es una compañía de marketing para aplicaciones móviles.
POST /api/ HTTP/1.1
Content-Length: 205
Host: saas.appoxee.com
{"action":"getApplicationConfiguration","auth":{"random":"8806c805bc7b8c1a9b0514c7550c5acb47b
","timestamp":14081808772,"AppSDKKey":"53bfcb25985de4.28229413","signature":"8edc0194a8a258e3
d7cd7e7ddfbc6e78"}}
HTTP/1.1 200 OK

(…)
{"result":{"AppSDKKey":"53bfcb25985de4.28229413","AppID":"103926","mailboxTitle":"","RTL":fal
se,"moreAppsEnabled":false,"feedbackEnabled":false,"android":{"projectId":"339763567478"}},"r
esponse":"Success"}
(…)
Agentchannel.api.n.shifen.com
Se envía tráfico JSON a un servidor de forma no cifrada. Tampoco se aprecia información
personal pero es también potencialmente vulnerable.
El servidor pertenece la compañía Chinaunicom, probablemente a sus servicios en la nube
aunque podría ser el propio operador telefónico.
........DevApp............p.........{"tiny_msghead":1,"channel_token":"1541413976285008409810
69679151011768069610696722180118055224","tinyheart":1,"period":1800,"connect_version":2,"chan
nel_type":3,"channel_id":"4222156819441981330"}........serveragent.head..p.........{"ret":0}.
.
mobile-gtalk.l.google.com
La única información legible que se encuentra son los intercambios de Certificados,
previsiblemente para iniciar una conversación cifrada. Parece una conexión 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 varía bastante entre
20min y 4h. Desconocemos su utilidad. Son conexiones relativamente simétricas donde se
envían y se reciben datos en similar cantidad.

gstatic.com
Parece que este tipo de conexión es la manera que tiene el navegador Chrome de recibir
actualizaciones de certificados revocados a través 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
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...crl-
setPK..........p...y.....
android.clients.google.com
Son descargas de aplicaciones (actualizaciones del móvil). No viajan con ningún tipo de
seguridad, supongo que porque se confía en que la propia aplicación está firmada
digitalmente. Potencialmente habría que estudiar si se puede realizar un ataque MAN-IN-
THE-MIDDLE.
En este caso se ve como se actualiza la aplicación 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&ex
pire=1408353779&ipbits=0&ip=0.0.0.0&cp=SmFub2R1Q0Q6NzYxODQwMTkwNjI5ODIxNTg2NDU&sparams=expire
,ipbits,ip,q:,cp&signature=7E11BE99B6E9DF229CA4735787F206D0E64AB433.DC6641916C92297EAB2A8E07E
9274119C5024297&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
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[CA..<...`#!L...@.|.......@.A.[C.s/...G.Q'F.tw......ah.
Accu-weather.com.cdngc.net
Se trata tan solo de una petición de información meteorológica que viaja sin cifrar. Aunque
pueda parecer inofensivo, quizás existan situaciones en que se pueda comprometer la
seguridad con partes meteorológicos falsos. En cualquier caso la propia petición de
información meteorológica ya nos puede proporcionar cierta información, 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 automática y periódica cierta información a un servidor
que pertenece a la empresa baidu.com empresa de la que no puedo averiguar nada porque
toda la información está en chino.
........DevApp............p.........{"tiny_msghead":1,"channel_token":"1541413976285008409810
69679151011768069610696722180118055224","tinyheart":1,"period":1800,"connect_version":2,"chan
nel_type":3,"channel_id":"4222156819441981330"}........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
User-Agent: Baidu-Frontia-Android
Accept-Encoding: gzip
stats=dXsIAAAAAAAAAI1STa%2BbMBD8Lz5T4g8MhNtTDz1X7a15slyzPKwXDLJNojTiv3ftfB1bIYR3PZ6d%0AGXMlZp
6m2ZHuSpY1jMqM2jk4Pmu%2FOmfdhzqBDzbhOC%2FIHaRsTzpScc6ZrFu2ryq2b5kQlGwFWQN4%0A1cPJGkhkg%2FXTWX
tckx%2Bzuxx2X%2Buaivunq8qq5Icdo6Us30packEPu2%2FDXvnvXSI67DwcQQf48gmX%0AQAoyzX0SSfJxrOegnJ4S%2
B5vr%2FYzCEKPdOmgT1%2BdUbAbjAZw62z6O2GVNU2PXLKsaQN%2BhDtDoE9qD%0ACzZektOWZlpzMw60q0UHsjO%2FO4
keHkQPbdpPpwZ7ZxtAmTWfEbKWQlJZVULUTCY6mFSwfyCL2cub%0Al2faJCfzEjOC%2FRhjwtL2FbODeJ79Z8p5coZ0TU
HiZUFKWhBtDISgbjVqGWwaahDFWYXDFvA6zh73%0Afq7gYtrNnHbJU8oWr4ORDUfpZTlaoyMKU9YNM%2Bl%2BXVNT4ZvN
7SVPfvN%2Fg7lnAwmSl4%2F7oQIfhrBo%0AJwhRTziHVbTlrOaNlJUoyN2Owt24hpfqEbRH7%2B1W%2FD9pk264of8kFd
v79l6QV%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, también hay peticiones GET constantes para mantener abierta la
conexión.
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
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 también una compañía de marketing, pero al menos tiene la decencia de cifrar sus
comunicaciones. De alguna manera el usuario debiera ser consciente de esta violación de
la privacidad. El volumen de datos es un tanto inquietante aunque probablemente se deba
al inicio de la conexión 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.

Análisis de los destinos de Conexión
Intentaremos determinar cuántos destinos de información existen, cual es el domino destino,
el puerto, los Kbytes transmitidos totales y el número de minutos entre conexiones
consecutivas.
No nos sirven las herramientas automáticas puesto que queremos averiguar la organización
que está detrás de cada conexión y no siempre basta con el nombre de host y debemos
investigar un poco más. Hay compañías 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 conexión
a nivel de aplicación, pero utilizando varias máquinas para permitir la alta disponibilidad, por
tanto de cara al estudio los consideraremos como uno solo destino.
Primer analizamos el número de empresas, el número de host diferentes los datos
transmitidos y la duración de la conexión:
Xperia Z
EMPRESA# HOSTS# DATOSDURACIÓN (media/máxima)
AMAZON CLOUD33 MB7h2h30min
CDNETWORKS24,92 KB23h16h
CHINAUNICOM310,22KB24h10h
EDGECAST216,91KB7h7h
FACEBOOK27,75KB8h8h30m
GOOGLE3118,61MB10h24h
INTERNAP16,18KB2,5s2,5s
SOFTLAYER12300KB10h24h
Tabla 7: Datos y Tiempo de conexion XperiaZ
MediaTek
EMPRESA# HOSTS# DATOSDURACIÓN (media /máxima)
AKAMI TECH13,3 KB10s10s
BJTELECOM924 KB1min1min
GOOGLE21228 KB24h10h
Tabla 8: Datos y tiempo de conexion MediaTek

Todas las empresas que hemos detectado excepto Facebook y Google son empresas de
servicios en la nube. Esto dificulta un poco más averiguar qué organización es el receptor
final de todos los datos.
Organizaciones y Situación geográfica
WireShark nos permite utilizar geo-localizar las conexiones instalando las correspondientes
bases de datos.
Ilustración 9: Mapa de conexiones del Xperia Z
Ilustración 10: Mapa de conexiones del MediaTek

Análisis de los procesos que generan la conexión
Hasta ahora hemos analizado el tráfico 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.geniewidget
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:lockscreen
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 9: 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 observación directa de todos los datos previamente presentados obtenemos:
• Por un lado existen conexiones legítimas, como la consulta meteorológica, que se
realizan de forma no seguras y que potencialmente podrían ser vulnerables a un
ataque MITM o de otro tipo. Las consecuencias podrían 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 estás conexiones también son preocupantes.
• En concreto en el caso del terminal Sony Xperia Z, el volumen de información
enviada y recibida es bastante relevante y además sabemos que algunas de estas
empresas son compañías de marketing que supuestamente venderán nuestros datos
lo que concuerda con los hallazgos encontrados por el equipo de la Universidad de
Pennsylvania en 2011[8].
• Prácticamente todas las conexiones se realizan con empresas de servicios en la
Nube situados en California (EEUU) o China.
Por otro lado, de la comparación de los resultados entre los dos terminales obtenemos:
• Que los dispositivos recién instalados de fábrica envían mucha menos información
que aquellos se están utilizando y tienen varias aplicaciones instaladas. Sería muy
interesante investigar cómo se comportan otros fabricantes de teléfonos o
distribuciones de software como CyanogenMod.
• Que el único tráfico generado que tienen en común ambos dispositivos, es el tráfico
destinado a los servidores de Google.
Por tanto se puede concluir desde el punto de vista de seguridad:
• Se debe filtrar totalmente todo el tráfico que no viaja hacia los servidores de Google.
Esta forma de comportamiento no llamará la atención a un potencial atacante que
estuviera observando nuestro tráfico.
• Se debe filtrar todo el tráfico que viaja sin protección SSL/TLS, incluida el que viaja a
los servidores de Google.
• Sería objeto de discusión si debemos filtrar el tráfico que viaja protegido hacia los
servidores de Google, pues de esta manera nos encontraríamos con el problema
descrito en la sección el teléfono opaco que se hace brillante.

PROPUESTA DE SERVICIO DE OCULTACIÓN
Como esperábamos los teléfonos inteligentes generan un patrón de tráfico distinguible. Por
otro lado un teléfono 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 teléfono destaque entre el
resto.
Sin embargo, dado que la única intersección de destinos de tráfico entre los dos teléfonos
son los servidores de Google. Por tanto, podemos estar tranquilos si eliminamos todas las
demás 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 podríamos
contratar servidores con direcciones IP próximas y generar un tráfico muy similar al de un
terminal sin modificar pero controlado por nosotros mismos. De esta forma la huella de
nuestro teléfono sería muy similar a la de un terminal recién salido de fábrica.
La conclusión es que si queremos que nuestro teléfono no destaque entre los demás 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 mensajería, el hecho de que
haya cientos de terminales comunicándose con distintos servidores alojados en empresas
de servicios en la nube, nos proporciona cierta ocultación y nos permite contratar con
cualquiera de las compañías más populares de servicios en la nube sin llamar la atención.
Incluso podríamos contratar varios y de esta forma simular el comportamiento de un teléfono
no modificado pero con el habitual spyware instalado.

ANÁLISIS DE COSTES
En el caso de que decidamos adquirir una solución comercial, la utilización de servicios de
mensajería y llamada segura tiene un coste relativamente bajo. Por ejemplo, Samsung
KNOX cuesta 40$ al año y el BlackPhone incluye el servicio de por vida a cambio un precio
de venta de terminal algo más elevado (629$) de lo esperable por el resto de sus
prestaciones. Lamentablemente, estas soluciones comerciales no dispondrían de un
servicio de ocultación como el que hemos descrito previamente; de forma que sería
claramente observable que todas las conexiones viajan hacía un mismo servidor, incluidas
también, las actualizaciones de Google.
El desarrollo propio sería algo más caro en principio, aunque podría amortizarse según el
número de terminales que se manejasen. Los costes más relevantes serían
fundamentalmente laborales. Al menos harían falta 150 horas/hombre* de trabajo para
desarrollar una solución aceptable. Después habría que añadir los costes de mantenimiento
asociados, que serían: el hosting del servidor, la generación de certificados, la instalación
del software en cada dispositivo y el mantenimiento preventivo de la solución. 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 solución propia se la puede permitir cualquier corporación de tamaño mediano o una
corporación con un enfoque fundamental en la seguridad. En el caso de las FAS no hay
ninguna duda de que es lo más 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 solución ideal es sin duda una colaboración entre las FAS y empresas de desarrollo
hardware, pero seguramente esto ya no sea tan económico y viable.
PD - Basado en mi experiencia profesional modificando el Kernel de Android.

CONCLUSIÓN
La telefonía móvil basada en terminales Android no es por defecto segura. Esto no se debe
a la falta de preocupación 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
revisión en profundidad. Según al artículo 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.
Además hay comportamientos que realizan algunos teléfonos por defecto entrañan serias
dudas éticas e incluso legales, dado que envían información 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 estándares más comúnmente
aceptados. Además se pueden adquirir soluciones comerciales aceptables por precios muy
razonables.
El caballo de batalla que aún 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 teléfono lo
hacía más visible a posibles espías instalados en las redes telefónicas. La conclusión es que
este efecto se puede evitar siempre y cuando se mantengan los servicios de Google
activos. Aunque lo más recomendable sería desactivar aquellos que no utilizan conexiones
SSL/TLS.

REFERENCIAS
Bibliografía
• 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 Telecomunicación, 2013,
ISBN: 978-84-936910-2-8
o 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]
• Artículos:
o The Case for SE Android Stephen Smalley sds@tycho.nsa.gov Trust
Mechanisms
(R2X) National Security Agency[1]
o 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.
o 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]
o Dissecting Android Malware: Characterization and Evolution Yajin Zhou,
Xuxian Jiang Department of Computer Science North Carolina State
University[4]
o Understanding Android Security WILLIAM ENCK, MACHIGAR ONGTANG,
AND PATRICK MCDANIEL Pennsylvania State University, IEEE security &
privacy, 2009[6]

o 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
o MockDroid: Trading Privacy for Application, Functionality on Smartphones,
Paper by A. R. Beresford, A. Rice, N. Skehin, R. Sohan
o Paranoid Android: Versatile Protection for Smartphones, Paper by G.
Portokalidis, P. Homburg, K. Anagostakis, H. Bos, Efﬁcient, Context-Aware
Privacy Leakage Conﬁnement for Android Applications without Firmware
Modding,Mu Zhang, Heng Yin, Department of EECS, Syracuse University
o 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 Market-
scale Mobile Malware Analysis. In Proceedings of the 6th ACM Conference on
Security and Privacy in Wireless and Mobile Networks, WiSec ’13, 2013.
o 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]
o Android Permissions Demystified, Adrienne Porter Felt, Erika Chin, Steve
Hanna, Dawn Song, David Wagner, University of California, Berkeley[7]

Web-grafía
• Fabricantes de teléfonos 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/vip-
perspectives/2010/12/11/geolocation-in-wireshark
o http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-
maths/
o http://thoughtcrime.org/blog/telegram-crypto-challenge/
o http://c-skills.blogspot.com/2011/04/yummy-yummy-gingerbreak.html
o http://www.csc.ncsu.edu/faculty/jiang/AnserverBot/
o http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu.html
• Wikipedia
o http://en.wikipedia.org/wiki/Socialist_millionaire
• Otros
o http://www.gsmarena.com

TacticalCombatSmartPhone_final

Recomendados

Recomendados

Más contenido relacionado

Similar a TacticalCombatSmartPhone_final

Similar a TacticalCombatSmartPhone_final (20)

TacticalCombatSmartPhone_final