1. Seguridad en Terminales Móviles: Symbian, Windows Mobile y
BlackBerry
Miguel Ángel Domínguez
Internet Security Auditors, S.L.

2. •
Smartphones
•
Riesgos
•
Bluetooth
•
SymbianOS
•
Windows Mobile
•
BlackBerry
•
Malware
•
Recomendaciones
•
Conclusiones
CONTENIDO
2

3. •
Funcionalidad Similar a las PDA + Servicios de Telefonía Móvil
•
Mayor conectividad: GPRS (Always on), Bluetooth
•
Y funcionalidades de comunicación:
➔
Email, Navegación Web, Aplicaciones Java, Intercambio de
ficheros (vCard, fotos, etc), juegos en red (N­Gage).
•
Sistemas Operativos
➔
Symbian, Windows Mobile, Palm OS, Linux, Blackberry OS
•
Mayores prestaciones – Mayores riesgos
SMARTPHONES
3

4. •
Bugs: Errores de implementación
•
Control de Acceso: Acceso Físico => Datos sensibles/privados
•
Destrucción de dispositivos
•
Robo o Pérdida
•
Fraude: Envío de SMS/MMS, llamadas, etc.
•
Si el dispositivo es comprometido la información también
•
Puntos de entrada
➔
Código ejecutable, Bluetooth, GPRS/GSM, IrDA, Browser,
SMS/MMS, WAP, E­mail
RIESGOS
4

5. •
PAN (Personal Area Network)
•
2,4 Ghz y 2,1 Mbps con EDR (Enhanced Data Rate)
•
Distancias de 10 metros aprox originalmente.
•
Aumento a 100 metros
➔
Ataques provenientes de dispositivos a distancias medias
➔
Antenas direccionales para aumentar el alcance
•
Hasta 7 dispositivos por piconet
•
Versión más utilizada actualmente: 1.1
Bluetooth
5

6. •
Definido por capas: parte SW/HW (HCI)
•
LMP: Controla el enlace. Seguridad
•
L2CAP: Multiplexa datos de capas superiores
en un único enlace físico (Segmentación y
Reensamblado)
•
HCI: Une un Host Bluetooth (Portátil), con un
controlador (token USB).
•
RFCOMM: Emulador Comm. Serie
•
Dirección Hardware (MAC): UID 48 bits.
•
Inquiry: Descubrimiento de dispositivos
•
Descubrimiento de Servicios: SDP
•
Profiles: Casos de Usabilidad (GAP, Fax,
Object Push, File Transfer, OBEX, etc.)
Bluetooth ­ Arquitectura
6
Aplicaciones
Logical Link Control and Adaption Protocol (L2CAP)
Host Controller Interface (HCI)
Link Manager Protocol
Baseband / Link Controller
Radio
TCS
OBEX WAP
SDP
RFCOMM
A
T
C
o
m
m
a
n
d
s
S
o
f
t
w
a
r
e
H
a
r
d
w
a
r
e

7. •
Autenticación, Cifrado y Autorización. No Integridad!!!
•
Autenticación Mutua basada en un PIN
•
3 Niveles de Seguridad:
➔
Sin Seguridad – Modo 1
➔
Seguridad a nivel de servicio – Modo 2
Mayoría de dispositivos. El servicio decide si se necesita seguridad. Una vez se
ha establecido el enlace en las capas bajas.
➔
Seguridad a nivel de enlace – Modo 3 (bonding)
En el establecimiento del enlace. Los desarrolladores no intervienen.
Bonding: proceso de autenticación con clave compartida
Cifrado: una vez se establece la autenticación. Los dispositivos pueden
requerir cifrado. Si uno no lo soporta no se utiliza.
Bluetooth ­ Seguridad
7

8. Si soporta todas estas características de seguridad,
¿Por qué se considera un protocolo con grandes
problemas de seguridad?
Bluetooth ­ ¿Seguridad?
8

9. •Dispositivo Oculto o Visible: (Discoverable Mode): Identificar la víctima
➔
Visible => Más fácil de atacar
➔
Oculto => Si conocemos la MAC (estuvo visible) podemos descubrir
dispositivos ocultos
➔
Las direcciones MAC no se cifran
➔
Herramientas: RedFang, Bluesniff, btscanner, JABWT
•Emparejamiento (Pairing) de dispositivos: Consistentes en una clave secreta
compartida (PIN). Se genera un clave de emparejamiento (link key). Existen
problemas en la implementación por parte de frabricantes => Robo de
Información, Llamadas, SMS, etc. => Consecuencias económicas
•BlueBug: Establecimiento de una conexión serie y utilizando comandos AT
•BlueJacking: Popular entre los usuarios para el envío de mensajes anónimos
(chats). Utiliza el protocolo de pairing => finalización del proceso implica acceso al
dispositivo. OBEX Push Attack
Bluetooth ­ Ataques
9

10. •Escaneo PSM (Protocol/Service Mux): Port scanning para bluetooth
➔
No todos los puertos PSM se registran con SDP.
➔
Localizar funcionalidades ocultas
➔
Técnica para ocultar puertas traseras
➔
Herramientas: bt_audit para PSM y canales RFCOMM
•OBEX (Object Exchange): Protocolo sesión (binary HTTP). Todo tipo de objetos.
➔
OpenOBEX: Implementación OpenSource de OBEX
➔
Vulnerabilidad BlueSnarfing: Conexión al dispositivo sin alertar al propietario
y acceso a datos almacenados. IMEI => Clonación teléfonos ilegales)
➔
Muchos dispositivos Nokia y Ericsson Vulnerables
Bluetooth ­ Ataques
10
http://www.cve.mitre.org/cgi­bin/cvename.cgi?name=CAN­2004­0143
Multiple vulnerabilities in Nokia 6310(i) Mobile phones allow remote attackers to cause a
denial of service (reset) via malformed Bluetooth OBject EXchange (OBEX) messages,
probably triggering buffer overflows.

11. •Backdoors: Pairing sin registro + utilización de recursos
•Malware: medio para instalación y propagación de virus, gusanos y troyanos
•Debilidades de Criptografía: Noticia del 3 de Junio de 2005
“Bluetooth puede haber quedado seriamente tocado después de que dos investigadores
israelíes hayan publicado la forma de entrometerse en la comunicación "segura" de
dispositivos de este tipo. En palabras de Bruce Schneier, no se trata de una mera
ruptura teórica, sino que se trata de un ataque práctico. El sistema engaña al
dispositivo víctima haciéndole creer que ha perdido la clave, forzando así al
comienzo de una nueva comunicación siempre que se desee.”
•DoS: Ej. BlueSmack (Ping of Death a la pila bluetooth)
•Ingeniería Social: Falta de concienciación y desconocimiento de la tecnología
•Auditoría – Bloover: Búsqueda de vulnerabilidades en dispositivos
Bluetooth ­ Ataques
11

12. •
Activar Bluetooth sólo cuando sea necesario
•
Dejar el dispositivo en modo oculto
•
Sólo aceptar conexiones de dispositivos conocidos
•
Aplicar todas las actualizaciones de seguridad (fabricante)
•
No aceptar mensajes anónimos
•
Cruzar los dedos!!!
Bluetooth – Buenas Prácticas
12

13. •
Evolución plataforma EPOC – Psion
•
Symbian – Empresa: spinoff Psion, Nokia, Ericsson y Motorola
(actualmente panasonic, samsung y Siemens).
➔
Desarrollar una plataforma para productos de consumo basados en telefonía
con capacidades de cómputo – Smartphone
➔
Cambio en la orientación EPOC => Symbian OS
•
Core de teléfs Nokia basados en Series60 y SonyEricsson con UIQ.
•
Algunos smartphones:
Motorola A1000, A925
Sony Ericsson P900, P910, P800
Nokia 7610, 6600, N­Gage, 36xx, 6620, 9290 communic.
SymbianOS
13

14. SymbianOS ­ Arquitectura
14
PUNTOS DE ENTRADA
•
Integración protocolos WAN:
TCP/IPv4/v6 y WAP
•
Protocolos PAN: Bluetooth,
IrDA
•
Mensajería: SMB, MMS, EMS;
POP3, IMAP4, SMTP, etc.
•
Desarrollo en lenguajes C++,
Java (median CLDC y MIDP),
OPL (propietario), VB, C#
•
CLDC 1.1 (Connected Limited
Device Configuration):
Configuración J2ME con
librerías para utilización con el
perfil MIDP (Movile Information
Device Profile).
Virus, Troyanos, Gusanos,
Hackers

15. •
Criptografía: DES, 3DES, AES, RSA, DH, MD5, SHA1, ....
•
Comunicaciones: TLS/SSL, WTLS y IPSec
•
Gestión de Certificados – Certificados X.509
➔
Repositorios certificados Usuario y CA
➔
CA's en ROM
➔
Validación de certificados (chains, OCSP)
•
Autenticación de Software – Firma de Código
➔
Symbian signed: Ficheros SIS (Software Installer files)
➔
Java Verified: MIDlets (Java MIDP Applications)
➔
La mayoría de aplicaciones interesantes no están firmadas
SymbianOS ­ Seguridad
15

16. •
Desarrollador/vendedor obtiene un ACS Published ID (certificado
digital) de Verisign, previa autenticación. ­> Pago a Verisign
•
La aplicación se envía a Symbian – Empresa
•
Symbian pasa el código a un evaluador independiente que lo
analiza y prueba según criterios de Symbian ­> Pago al evaluador
•
Se elimina el ACS Published ID y Verisign firma el código con un
certificado enlazado al incluido en el dispositivo (Symbian Root)
SymbianOS – Seguridad ­ SymbianSigned
16

17. •
Smart Clients (Apss Nativas y J2ME) vs WAP
•
Posibilidad de determinar el nivel de cifrado según necesidades de aplicación
•
Seguridad extremo­extremo (TLS/SSL)
•
HTTPS y acceso a la pila Bluetooth y mensajería con MIDP v2.0
•
J2ME con acceso a libs criptográficas OpenSource (BouncyCastle, IAIK, etc).
•
Mayor riesgo a ataques debido a vulnerabilidades por desarrollos deficientes
•
J2ME Security Model – CLDC/MIDPv1 Sandbox
•
Versión limitada para satisfacer recursos de memoria y procesamiento
•
Compilación y Ejecución (KVM): Verificación de clases separada en dos fases:
1era fase a cargo del desarrollador – preverificación, 2a fase por el KVM)
•
No Security Manager: Sin política de seguridad – Limitación de funciones en el
lenguaje (JNI, Reflection, etc.)
•
Sin TLS/SSL
SymbianOS – Seguridad – Aplicaciones Java
17

18. •
J2ME MIDP v2.0
•
Mejoras en el modelo de seguridad
•
2 dominios de seguridad: Untrested (sandbox – MIDP1.0) y Trusted (firmas
digitales) – vinculado a un dominio de protección en la instalación
•
Dominios de protección: Conj. de permisos que se dan a un MIDlet – Mayor
granularidad y modos de interacción relacionados.
•
Interaction Modes: Cada dominio de protección tiene una política de
seguridad para controlar como se asignan los permisos. Solicitud a través de
ficheros JAD (Java Application Descriptor).
•
Java Verified: UTI (Unified Testing Initiative)
➔
Sun, Motorola, Nokia, Ericsson, Siemens
➔
Evaluación
➔
Firma UTI
SymbianOS – Seguridad – Aplicaciones Java
18

19. •
Platsec (Platform Security): Primer intento serio de diseñar una
plataforma de seguridad para Symbian. Introducido en SymbianOS v9
•
Dos controles:
➔
Detectar accesos no autorizados al hardware, software o datos
➔
Prevenir que los programas actúen de forma no aceptable (malware)
•
Como lo conseguimos:
•
Capabilities: Protegen las APIs (40%). Sólo aplicaciones de confianza pueden
utilizar ciertas funcionalidades (coms. que suponen un coste para el usuario).
•
Autorización: Acceso API protegida – Permiso? ­ SymbianSigned
•
Basic capabilities (usuario no consultado)
•
Extended capabilities (acceso a bajo nivel).
•
Unsigned­Sandbox capabilities (No firmadas): El usuario será consultado
cuando se requiera acceso a APIs protegidas (Blanket grant, One Shot Grant).
SymbianOS – Seguridad – Platsec
19

20. •
Tecnología Microsoft Windows CE
➔
Windows Mobile 2003 Second Edition – Windows CE 4.2 – Ozone
➔
Windows Mobile 2005 – Windows CE 5.0 – Magneto
•
Fabricantes en general menos conocidos en España:
O2 – iMate Smartphone 2
Qtek 8010, 8080
Orange SPV E200, C500
Motorola Mpx200, Mpx220
TSM520 ­> Movistar
•
Programación
➔
.NET CF (Compact Framework): Visual C# .NET, Visual Basic .NET
➔
J2ME: algunos modelos como el Mpx220 de Motorola
Windows Mobile Smartphone
20

21. •
Arquitectura Windows (Registro, MFC, NetBios, etc.)
•
Ventaja: No partimos de un sistema operativo desde cero
•
Inconveniente: Propagación de errores en programación y diseño
•
Modelo se Seguridad:
➔
Ejecución de Aplicaciones
➔
Configuración del dispositivo
➔
Acceso Remoto (ActiveSync y RAPI): Sincronización y Gestión Remota
•
Protocolos:
➔
Autenticación: TLS/SSL, WTLS, NTLM
➔
Acceso Remoto: PAP, CHAP, MS­CHAP, MSCHAPv2
➔
VPN: PPTP, L2TP/IPSec
•
Criptografía: CriptoAPI (DES, 3DES, MD5, SHA­1, RSA,...)
Windows Mobile Smartphone ­ Seguridad
21

22. •
PKI: Repositorios de certificados para diferentes propósitos (Certificados
raíz para SSL, Certificados de usuario, verificación de aplicaciones
firmadas, ...).Perfiles de firmantes:
➔
Fabricantes: Privileged Root, Unprivileged Root
➔
operadores: Privileged Root, Unprivileged Root
➔
desarrolladores: certificados M2M (Mobile2Market – programa de
certificación de aplicaciones para Windows Mobile)
➔
Revocación Certificados: Basada en el hash del certificado. Se guarda una
lista de revocación en el dispositivo (actualización por parte del operador).
•
Control de Acceso basado en Roles y Políticas
➔
Políticas: Configuración los parámetros de seguridad aplicados
➔
Roles: Identifican los niveles de acceso. Junto con los certificados permiten
la aplicación de las políticas.
Windows Mobile Smartphone ­ Seguridad
22

23. •
Basado en código firmado – Authenticode
•
Perimeter Security y Runtime Security: Seguridad durante la
instalación y ejecución respectivamente.
•
2 modelos de seguridad: One­tier , Two­tier
•
One­tier (Pocket PC)
➔
Sin distinción entre aplicaciones privilegiadas y no privilegiadas
➔
Distinción entre aplic firmadas y no firmadas. Las aplicaciones firmadas se
ejecutan como trusted
➔
Aplicaciones NO firmadas: Se comprueba la política de seguridad ¿
Se pueden ejecutar aplicaciones no firmadas?
Se debe preguntar al usuario para confirmar la ejecución?
Ejecución como trusted
Windows Mobile Smartphone ­ Seguridad
23

24. •
Two­tier (Mayoría de Smartphones)
➔
Distinción entre aplic firmadas privilegiadas, firmadas no privilegiadas y NO
firmadas
➔
Como se ejecutan:
Privilegiadas: Se ejecutan como Trusted (acceso total)
No privilegiadas: Se ejecutan como Normal (acceso limitado)
Distinción en función del certificado con que se firmó la aplicación
➔
Utiliza los diferentes repositorios de certificados
➔
Aplicaciones NO firmadas: Se comprueba la política de seguridad para decidir
que hacer. Si se acepta la aplicación se ejecuta en modo NO privilegiado.
•
Configuraciones de Seguridad
➔
políticas de seguridad – parámetros de comportamiento
Se puede ejecutar? Se debe preguntar (prompt) al usuario? El dispositivo es one­tier o two­
tier? Qué derechos tienen las peticiones remotas?
Windows Mobile Smartphone ­ Seguridad
24

25. •
Configuraciones de Seguridad (cont.)
➔
Requerimientos de seguridad determinados normalmente por el
operador(balanceo compatibilidad – seguridad).
➔
Algunas configuraciones:
Sin Seguridad (Unrestricted): No son necesarias firmas de código.
No se consulta al usuario.
Consultar (Prompt ­Standard, one­tier y two­tier): El usuario debe
decidir cuando la aplicación no es confiable. Opción más utilizada.
Firmados M2M: Necesidad de firmas para ejecutarse. Aplicaciones
desarrolladas por terceros
Bloqueado (Restricted): Sólo pueden acceder fabricantes u
operadores. Poco viable comercialmente.
Windows Mobile Smartphone ­ Seguridad
25

26. •
RIM (Research in Motion)
•
Orientado a empresas y
autónomos
•
Extender los SI de la
empresa a empleados
móviles (correo, datos
corporativos,...)
•
Dispositivos basados en
Java y C++
•
Necesidad de alta
seguridad para no
comprometer los activos
y la continuidad del
negocio.
BlackBerry OS
26

27. •
Blackberry: Wireless Handheld, Handheld Software, Desktop Software y
BES (Blackberry Enterprise Server)
•
Gestión centralizada de dispositivos (Adms. establecen params de
seguridad para todos los usuarios utilizando BES).
➔
Políticas con parámetros de seguridad
➔
Comandos IT: Kill (borrar datos), Establecer o Resetear contraseñas
➔
Rápida reacción a robos y pérdidas
•
Mensajería: Exchange, Domino, Groupwise
➔
BES como middleware entre servidores de mensajería y dispositivos.
➔
Mensajes comprimidos y cifrados
•
MDS (Mobile Data Service) de BES: Acceso a datos y aplicaciones en
Intranet o Internet con HTTP, HTTPS, WTLS
BlackBerry OS ­ Arquitectura
27

28. BlackBerry OS ­ Arquitectura
28

29. •
Cifrado simétrico (3DES, AES)
•
MDS Proxy: BES en nombre del dispositivo
•
MDS Extremo­a­Extremo: HTTPS extremo­extremo. Mayor seguridad
BlackBerry OS ­ Seguridad
29

30. •
S/MIME: cifrado y firmas digitales a nivel de mensaje. Certificados
digitales.
•
Seguridad de la información
➔
Control de Contraseña: por defecto a los 10 intentos fallidos la memoria del
dispositivo se borra. Seguridad extrema!!!
➔
Cifrado de datos en el dispositivo con AES­256
•
Firewall: Sólo comunicaciones provenientes de dispositivos (previa
autenticación con clave cript.) y del servidor de mensajería.
•
Aplicaciones J2ME
•
De nuevo firma digital de aplicaciones
•
La diferencia: Firmas como pistas de auditoría pero RIM no realiza revisiones
de código.
•
Gestionado por Adms: Bloquear la descarga de soft, Recursos que se pueden
utilizar, Distribución de Soft.
BlackBerry OS ­ Seguridad
30

31. •
Deshabilitar Bluetooth
•
Deshabilitar la mensajería PIN
•
BES es un punto crítico => Hacer un hardening de la plataforma
•
Añadir la gestión de la seguridad a las políticas y procedimientos de la
organización.
•
Implementar las políticas y procedimientos mediante la gestión
centralizada de BES
➔
Contraseñas robustas
➔
Expiración de contraseñas
➔
Timeouts de inactividad
•
Formar a los usuarios en una utilización responsable de los dispositivos
•
Impedir la instalación de software de terceros por parte de los usuarios.
•
Revisar el soft de terceros y gestionar la distribución centralizada.
BlackBerry OS ­ Seguridad – Buenas Prácticas
31

32. Garantía de una arquitectura de alta
seguridad y de que RIM está
apostando por la seguridad en
Blackberry
•
FIPS140­2 (Federal Information Processing Standards)
•
Requisitos del DoD EEUU sobre S/MIME y PKI
•
Auditoría de Seguridad Independiente (@Stake)
BlackBerry OS – Seguridad Certificada
32

33. •
Junio 2004 – Cabir.a (caribe): 1er código malicioso que ataca teléfonos
móviles. MMS, Bluetooth, Ingeniería Social
•
Warhol Worm: la telefonía móvil proporciona el medio para crear worms
con un tiempo de propagación muy rápido (15m a 1h), causando gran
daño antes de poder reaccionar (ComWarrior – MMS y Bluetooth)
In the future, everybody will have 15 minutes of fame"
-Andy Warhol
•
Abril 2005 – Cabir.k (Mabir): Evolución/Mutación – Mayor daño
•
WinCE4.Duts: PoC. Keylogger, control remoto, ocultación de procesos.
•
Pocket IE: Más limitado que IE por lo que se reduce el riesgo, aunque la
funcionalidades irán en aumento en respuesta a requerimientos del
mercado.
➔
Acceso y ejecución de ficheros locales, ofuscación de URL, DoS con una
página HTML simple.
Malware
33

34. •
Antivirus
➔
F­Secure, Kaspersky, Trendmicro, Symantec, ....
➔
Actualización periódica del antivirus y Escaneos planificados
•
Comunicaciones
➔
Firewalls Personales
➔
VPNs (entornos empresariales)
•
Concienciación del Usuario
➔
No instalar código del que se desconoce el origen – código firmado
➔
No abrir mensajes de correo o MMS de desconocidos
➔
Evitar la utilización de Bluetooth
•
Datos
➔
Proteger los datos sensibles del dispositivo ­> Cifrado
➔
Realizar backup de los datos periódicamente
Recomendaciones Generales
34

35. •
Un smartphone es equivalente a un micro­laptop
•
Alta competencia: proveedores de sistemas operativos no invierten el
tiempo suficiente para diseñar plataformas seguras y libres de errores.
•
Symbian v9 y Windows Mobile 2005: Nueva mentalidad
•
Blackberry ha sabido ver la necesidad de la seguridad
•
Falta de productos de seguridad: antivirus en fase beta
•
Usuario: Falta de conciencia del potencial de la tecnología y los peligros
Conclusiones
35

36. Gracias por su asistencia!
36
Con
tact
o
mdominguez@isecauditors.com
www.isecauditors.com