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


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


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


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

  • Requisitos

Para poder utilizar la aplicación darshak necesitamos:

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



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

  • Uso de la aplicación

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




· Fecha (Date): Timestamp del momento en el que se detecta el evento/alarma.
· Tipo de Red (Network type): indica el tipo de red que estamos utilizando en el momento del evento, si es 2G o 3G.
· Evento (Event): indica si se trata de llamada saliente o entrante, mensaje saliente o entrante.
· Autenticación (Authentication): mostrará una bola verde si todo ha ido bien o roja en caso de no haberse autenticado el evento. Es decir, si hemos realizado una llamada y la red no nos ha solicitado autenticarnos, entonces veremos la bola roja.
· Cifrado (Encryption): De igual modo que antes, si el evento ha sido cifrado veremos la bola verde, pero si el evento ha tenido lugar en plano, bola roja.
· Eliminar (Remove): Eliminar el evento de la aplicación.


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

  • Vamos a poner la aplicación a prueba

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


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






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



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


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

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



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


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


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


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




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


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


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


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

  • Para terminar.

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


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



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


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


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


  • Conclusiones.

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


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


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

Contribución gracias a Pedro Cabrera para SbD