Un blog de Seguridad Informática, desde un punto de vista tecnológico

mobile security

Cuando las ballenas vuelan (episodio II) – Creando un entorno de análisis GSM usando Docker (parte 2)

Esta es la segunda parte de la serie (parte 1) y se empezará a explicar un escenario de análisis GSM usando los contenedores creados en la primera.

Obtener la clave de cifrado GSM con OsmocomBB

Una de las cosas que se puede hacer con OsmocomBB es acceder a la clave de sesión de cifrado simétrico GSM (Kc).

Nota: Tal y como se explicó en la anterior entrada, para seguir estos pasos son necesarios un teléfono compatible con OsmocomBB y un cable/adaptador USB-serie.

El primer paso será arrancar un contenedor de la imagen xenial-osmocombb dándole acceso al dispositivo que representa al adaptador USB-serie:

docker run --device=/dev/ttyUSB0 --rm -it --name test-osmocombb pachulo/xenial-osmocombb

Este comando creará un contenedor efímero (--rm), de nombre test-osmocombb y ejecutará un terminal interactivo en el mismo (-it).

Activar la emisión de señales (Tx)

Por cuestiones de seguridad (en algunos países está prohibido emitir en el espectro GSM sin licencia), OsmocomBB está configurado por defecto para tan sólo permitir la recepción de señales. Para obtener un firmware que sea capaz de emitir (para registrarse en la red del operador, por ejemplo) habrá que realizar las siguientes acciones.

Seguir las instrucciones del archivo /osmocom-bb/src/target/firmware/Makefile:

# Uncomment this line if you want to enable Tx (Transmit) Support.
#CFLAGS += -DCONFIG_TX_ENABLE

Y descomentar el FLAG con un comando como este:

sed -i 's/#CFLAGS += -DCONFIG_TX_ENABLE/CFLAGS += -DCONFIG_TX_ENABLE/g' /osmocom-bb/src/target/firmware/Makefile

Y después volver a compilar OsmocomBB con el siguiente comando:

cd /osmocom-bb/src && \
make distclean && \
make

osmocon

Una vez finalizado el anterior paso y desde la sesión del contenedor, se ejecutará osmocon con unas opciones parecidas a estas, teniendo en cuenta que según el teléfono usado puede ser otro firmware el que haya que cargar:

cd /osmocom-bb/src/host/osmocon && \
./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin

Nota: Las diferentes opciones de osmocon, así como los firmware disponibles para cada teléfono, están explicadas en la documentación.

Una vez ejecutado el comando, con el teléfono conectado al ordenador mediante el cable/adaptador USB-serie, se deberá pulsar el botón de encendido del teléfono brevemente para que cargue el firmware de OsmocomBB y no el original.

Si todo ha ido bien, en la consola se debería ver algo como:

Received PROMPT1 from phone, responding with CMD [16/147]
read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin): file_size=58484, hdr_len=4, dnload_len=58491
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 43 C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/58491)
handle_write(): 4096 bytes (8192/58491)
handle_write(): 4096 bytes (12288/58491)
handle_write(): 4096 bytes (16384/58491)
handle_write(): 4096 bytes (20480/58491)
handle_write(): 4096 bytes (24576/58491)
handle_write(): 4096 bytes (28672/58491)
handle_write(): 4096 bytes (32768/58491)
handle_write(): 4096 bytes (36864/58491)
handle_write(): 4096 bytes (40960/58491)
handle_write(): 4096 bytes (45056/58491)
handle_write(): 4096 bytes (49152/58491)
handle_write(): 4096 bytes (53248/58491)
handle_write(): 4096 bytes (57344/58491)
handle_write(): 1147 bytes (58491/58491)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 03 .
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!
battery_compal_e88_init: starting up



OsmocomBB Layer 1 (revision osmocon_v0.0.0-1773-g0cdf4b0)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: ee0c2c2ab8021437
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9

...

Y en la pantalla del teléfono:

Layer 1
osmocom-bb

mobile

El siguiente paso es abrir otra sesión en el contenedor:

docker exec -ti test-osmocombb /bin/bash

Y ejecutar el comando mobile para que se conecte al teléfono y haga las funciones de capa 2-3:

cd /osmocom-bb/src/host/layer23/src/mobile && \
./mobile -i 127.0.0.1

Y permita la gestión del mismo. Para ello habrá que abrir una tercera sesión dentro del contenedor:

docker exec -ti test-osmocombb /bin/bash

Y conectarse, mediante telnet, al puerto abierto por mobile:

telnet 127.0.0.1 4247

Con lo que se obtendrá acceso a la interfaz de control de OsmocomBB:

Welcome to the OsmocomBB control interface
OsmocomBB> ?
  show      Show running system information
  list      Print command list
  exit      Exit current mode and down to previous mode
  help      Description of the interactive help system
  enable    Turn on privileged mode command
  terminal  Set terminal line parameters
  who       Display who is on vty
  monitor   Monitor...
  no        Negate a command or set its defaults

Nota: La documentación del comando mobile está disponible aquí.

Y desde la que, una vez activado el modo privilegiado con el comando enable:

OsmocomBB> enable
OsmocomBB# ?
 help       Description of the interactive help system
  list       Print command list
  write      Write running configuration to memory, network, or terminal
  show       Show running system information
  exit       Exit current mode and down to previous mode
  disable    Turn off privileged mode command
  configure  Configuration from vty interface
  copy       Copy configuration
  terminal   Set terminal line parameters
  who        Display who is on vty
  monitor    Monitor...
  no         Negate a command or set its defaults
  off        Turn mobiles off (shutdown) and exit
  sim        SIM actions
  network    Network ...
  call       Make a call
  sms        Send an SMS
  service    Send a Supplementary Service request
  test       Manually trigger cell re-selection
  delete     Delete

Será posible desbloquear la SIM con el PIN:

OsmocomBB# sim pin 1 1234

Y, después de esperar unos segundos a que se produzca el registro en la red del operador:

% (MS 1)
% Trying to registering with network...

% (MS 1)
% On Network, normal service: Spain, Orange

Ya se podrá obtener información como el IMSI (International Mobile Subscriber Identity), el ICCID (Integrated Circuit Card IDentifier) y la clave Kc:

OsmocomBB# show subscriber 1
Mobile Subscriber of MS '1':
IMSI: 2140345XXXXXXXX
ICCID: 89340141716XXXXXXXX
Service Provider Name: Orange
SMS Service Center Address: +34656000311
Status: U1_UPDATED IMSI attached TMSI 0x7081xxxxx
LAI: MCC 214 MNC 03 LAC 0xXXXX (Spain, Orange)
Key: sequence 0 23 7d cf ff ff ff ff ff
Registered PLMN: MCC 214 MNC 03 (Spain, Orange)
Access barred cells: no
Access classes: C0

...

Así como los datos de la celda a la que está conectado:

OsmocomBB# show ms
MS '1' is up, service is normal
 IMEI: 000000000000000
   IMEISV: 0000000000000000
   IMEI generation: fixed
 automatic network selection state: A2 on PLMN
                                    MCC=214 MNC=03 (Spain, Orange)
 cell selection state: C3 camped normally
                       ARFCN=993 MCC=214 MNC=03 LAC=0x0XXX CELLID=0x0XXX
                       (Spain, Orange)
 radio ressource layer state: idle
 mobility management layer state: MM idle, normal service

...

Analizar y decodificar el Common Control CHannel de un ARFCN con OsmocomBB y Wireshark

Para poder hacer esto habrá que arrancar el contenedor de la siguiente manera:

docker run --device=/dev/ttyUSB0 --net=host --rm -it --name test-osmocombb pachulo/xenial-osmocombb

Cargar el mismo firmware que para el ejemplo anterior:

cd /osmocom-bb/src/host/osmocon && \
./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin

Pero ejecutar en este caso la aplicación ccch_scan (en vez de mobile):

docker exec -ti test-osmocombb /bin/bash

Indicando en el parámetro ARFCN (Absolute Radio-Frequency Channel Number) el que se quiera sintonizar:

cd /osmocom-bb/src/host/layer23/src/misc &&; \
./ccch_scan --arfcn 993 --gsmtap-ip 127.0.0.1

A partir de entonces, si se ejecuta Wireshark para sniffar el tráfico de red de la interfaz loopback, se visualizarán los mensajes decodificados del CCCH del ARFCN sintonizado.

Capturar el tráfico de la interfaz aérea de GSM con GR-GSM

Con la información obtenida en el paso anterior, ya se puede intentar sintonizar el canal al cual está conectado nuestro teléfono. Para ello es necesario ejecutar un contenedor gr-gsm:

docker run --device=/dev/bus/usb/002 --net=host --cap-add=NET_ADMIN --rm --name test-gr-gsm -it -v `pwd`/files:/root/files pachulo/xenial-gr-gsm

Nota: En este caso no hará falta hacer passthrough de la GPU, ya que todo el software que se necesita para este escenario funciona por línea de comandos.

Obtener el error de sintonización del RTL-SDR

Antes que nada, habrá que calcular que error tiene nuestro RTL-SDR a la hora de sintonizar una frecuencia (medido en ppm). Para ello se utilizará el software Kalibrate para, primero, escanear el espectro GSM:

root@latitude:/# kal -s EGSM -v
Found 1 device(s):
 0: Generic RTL2832U OEM

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 270833.002142 Hz
kal: Scanning for E-GSM-900 base stations.
channel detect threshold: 18835.181650
E-GSM-900:
 chan: 9 (936.8MHz + 2.826kHz) power: 52243.45

...

 chan: 993 (928.8MHz + 309Hz) power: 43248.09

Nota: Si al escanear el espectro no se encuentra ningún canal: a) estamos en una zona sin cobertura 2G b) el error de sintonización del cristal del RTL-SDR es tan grande que Kalibrate no es capaz de sintonizar ninguna. En caso de b) es posible ejecutar kal con un error inicial, usando la opción “-e”.

Y después calcular el error sintonizando con uno de los canales detectados:

root@latitude:/# kal -c 993
Found 1 device(s):
 0: Generic RTL2832U OEM

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 270833.002142 Hz
kal: Calculating clock frequency offset.

...

average absolute error: 23.051 ppm

Siendo el medio de este dispositivo 23.051 ppm.

Hay que tener en cuenta que este valor puede cambiar con la temperatura, así que vale la pena ejecutar lo siguiente durante unos 10 minutos antes de realizar el cálculo:

root@latitude:/# rtl_test 
Found 1 device(s):
 0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...

Capturar el downlink

Una vez realizados estos pasos ya se podrá pasar a capturar el tráfico del ARFCN de la celda donde está conectado nuestro teléfono (993 en nuestro caso) y guardando los resultados (en forma de bursts GSM) en el fichero test-burst.file con la herramienta grgsm_capture.py:

grgsm_capture.py --arfcn=993 --ppm=23 --burst-file=test-burst.file

Ahora será el momento de enviar un SMS al número de teléfono asignado a la tarjeta SIM del teléfono OsmocomBB:

OsmocomBB#
% (MS 1)
% SMS from +3466XXXXXXX: 'Testpurposes'

Una vez recibido, ya se podrá detener la captura y pasar a decodificar el canal BCCH (Broadcast Control CHannel) usando el fichero de bursts como entrada de la herramienta grgsm_decode:

grgsm_decode --arfcn=993 --ppm=23 --burst-file=test-burst.file --timeslot=0 --mode=BCCH

En este momento, si se pone a capturar el tráfico de red con Wireshark en la interfaz loopback, se podrán visualizar los datos decodificados:

Nota: Se recomienda ejecutar Wireshark con el siguiente comando para ver el tráfico decodificado:

wireshark -k -f udp -Y gsmtap -i lo

El siguiente paso es verificar que hemos capturado el tráfico hacía nuestro teléfono, por lo que se puede aplicar un filtro de Wireshark para ver si se ha producido alguna comunicación con el TMSI (Temporary Mobile Subscriber Identity) asignado (y obtenido con OsmocomBB) gsm_a.tmsi == 0x7081e5c3:

En este caso vemos dos paquetes del tipo “Paging Request Type 1” con destino nuestro terminal.

Nota: Hay que tener en cuenta que con el RTL-SDR sólo se está capturando el tráfico que va de la red del operador (las Base Transceiver Stations básicamente) a las Mobile Stations (los teléfonos).

Una vez hecho esto, habrá que examinar los paquetes de tipo “Immediate Assignment” para encontrar los que contienen el campo “Channel Description“. En este atributo se podrá observar a que timeslot y canal se asignan los terminales cuando necesitan un canal dedicado:

En nuestro ejemplo es el timeslot 1 y el canal SDCCH8 (Stand-alone Dedicated Control CHannel con 8 sub-slots).

Con esta información ya se podrá pasar a decodificar el canal con el siguiente comando:

grgsm_decode --arfcn=993 --ppm=23 --burst-file=test-burst.file --timeslot=1 --mode=SDCCH8

Aunque como la mayoría del tráfico de este canal va cifrado se decodificaran muy pocos paquetes. De todas formas ya se pueden averiguar dos cosas:

1. Que el dispositivo al que se está respondiendo es el nuestro, verificando el TMSI del paquete “Paging Response“:

2. El algoritmo de cifrado usado, ya que se comunica antes de empezar a cifrar el tráfico. A5/1 en el caso de nuestra comunicación:

Por último, para descifrar el tráfico que ha recibido nuestro teléfono se puede especificar la Kc (obtenida con OsmocomBB) como parámetro de grgsm_decode:

grgsm_decode --burst-file=test-burst.file --arfcn=993 --ppm=23 --timeslot=1 --mode=SDCCH8 --kc=237dcfffffffffff

Con lo que se podrá ver los datos en claro, incluyendo el SMS que se ha enviado:

Bonus

Configurar OsmocomBB para que el teléfono no “salte” de celda

Uno de los problemas que puede plantearse a la hora de realizar este escenario es que el teléfono vaya saltando de una celda a otra, ya que si las potencias de transmisión son parecidas, cada cierto tiempo escaneará el espectro GSM y se conectará a la que emita con más fuerza. Esto puede dificultar la captura del tráfico con un dispositivo RTL-SDR, ya que este solo puede capturar un ancho de banda limitado (aprox. 2MHz).

Para cambiar este comportamiento habrá que escribir la configuración del teléfono en un fichero con el siguiente comando de la consola OsmocomBB:

OsmocomBB# write file
Configuration saved to /root/.osmocom/bb/mobile.cfg

Para a continuación apagarlo, modificar la siguiente linea de la configuración:

< no stick
---
> stick <ARFCN>

Substituyendo <ARFCN> por el de la celda a la que se quiera conectar de forma fija y volver a arrancar el teléfono con el firmware OsmocomBB.

SIMTester

En este apartado se va explicar como sería posible realizar análisis de seguridad de tarjetas SIM con SIMTester usando un teléfono compatible con OsmocomBB como lector.

Primero habrá que arrancar un nuevo contenedor OsmocomBB:

docker run --device=/dev/ttyUSB0 --rm -it --name test-simtester pachulo/xenial-osmocombb

Utilizar el teléfono como lector requiere un firmware especial, pero antes de poder crearlo habrá que instalar el JDK de Java 8:

apt update && \
apt install -y openjdk-8-jdk

Ahora habrá que compilar la rama luca/libosmosim de OsmocomBB, pero antes se tendrá realizar una pequeña modificación, ya que parece que los Makefile tienen la ruta del JDK hardcodeada.:

cd /osmocom-bb/src && \
git checkout luca/libosmosim && \
sed -i 's/\/home\/gsmmap\/jdk1.7.0_45/\/usr\/lib\/jvm\/java-8-openjdk-amd64/g' host/layer23/src/libosmosim/Makefile* && \
make

Una vez finalizada la compilación ejecutaremos osmocon para cargar el firmware cuando se encienda el teléfono:

cd /osmocom-bb/src/host/osmocon && \
./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin

Una vez hecho esto, en otro terminal dentro del contenedor:

docker exec -ti test-simtester /bin/bash

Ya se podrá descargar el software:

wget https://opensource.srlabs.de/attachments/download/117/SIMtester_v1.8.1.zip &&; \
unzip SIMtester_v1.8.1.zip

Y ejecutarlo, aunque antes habrá que asegurarse de que el archivo libosmosim.so esté disponible en el java.library.path:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/osmocom-bb/src/host/layer23/src/libosmosim/.libs/ && \
cd /SIMtester/binaries/v1.8.1 && \
java -jar SIMTester.jar -tf OsmocomBB

Pero, aunque parece que el programa se conecta correctamente al teléfono, no aparecen resultados:

########################################
 SIMTester v1.8.1, 2016-02-04
 Lukas Kuzmiak (lukas@srlabs.de) 
 Security Research Labs, Berlin, 2017
########################################

Using OsmocomBB mobile as SIM card reader
Terminals connected: 1
de.srlabs.simlib.osmocardprovider.OsmoCardTerminal@5b2133b1

Using terminal: OsmoCardTerminal
Card connected: de.srlabs.simlib.osmocardprovider.OsmoCard@33c7353a

Cuando las ballenas vuelan (episodio II) – Creando un entorno de análisis GSM usando Docker (parte 1)

Esta serie de entradas surge inspiradas por ésta entrada de Fox Glove SecurityWhen Whales Fly – Building a Wireless Pentest Environment using Docker donde se explica cómo utilizar contenedores Docker para hacer más fácil el uso de algunas herramientas de pentesting WiFi. En este caso lo que se ha querido “contenizar” son herramientas para analizar comunicaciones GSM.

Aunque en esa entrada hay un excelente resumen sobre contenedores, Docker, imágenes y la filosofía de trabajo, aquí se rescatan algunos aspectos importantes para quien no sepa de que va el tema:

  • A nivel usuario, Docker (o LXC) no deja de comportarse como una especie de hypervisor, aunque son conceptos diferentes. Una analogía que me ayudó a entender la diferencia en el aislamiento que proporcionan es: cuando se virtualiza con un hypervisor “clásico” las máquinas virtuales son como casa individuales; los contenedores, en cambio, se parecen más a los apartamentos de un mismo edificio (Containers are not VMs).
  • Docker es el motor sobre el que corren los contenedores y estos comparten recursos, a través del kernel, con el host y con los otros contenedores.
  • Docker permite ejecutar versiones específicas de aplicaciones sin la penalización de rendimiento que suponen las máquinas virtuales.
  • Las imágenes Docker serían el equivalente a los binarios tradicionales en los SO, a partir de ellas se pueden crear contenedores (el equivalente a los procesos en los SO tradicionales).
  • Los contenedores pueden ser efímeros o perdurar tanto como quiera el usuario.
  • Los contenedores se pueden ejecutar de forma interactiva o como servicios.

Toda la información sobre Docker puede encontrarse en su propia sección de documentación:

Software Defined Radio

Contenedor base

El primer paso ha sido crear un contenedor con las herramientas básicas para trabajar con SDRs (Software Defined Radio), como por ejemplo los basados en hardware RTL, y con soporte para ejecutar aplicaciones gráficas aceleradas por hardware. El motivo para crear este contenedor base es poder aprovecharlo a la hora de trabajar con aplicaciones para otros protocolos de radio.

Nota: RTL-SDR es un tipo de SDR muy barato que utiliza dongles USB basados en el chip RTL2832U pensados para ver la TV y escuchar la radio. Mediante los esfuerzos combinados de Antti Palosaari, Eric Fry y Osmocom se descubrió que era posible acceder directamente a los datos de la señal I/Q de estos dispositivos, lo que permitió convertirlos en SDRs mediante un nuevo driver.

El código para crear la imagen Docker está en este repositorio:

Así como ésta ya compilada en Docker Hub:

docker pull pachulo/xenial-gnuradio-rtl-toolkit

Como se puede ver en el Dockerfile la imagen:

Una vez compilada la imagen o descargada de Docker Hub, ya podremos realizar las primeras pruebas: por ejemplo, para comprobar que podemos acceder al dispositivo RTL desde el contenedor, podemos ejecutar el comando rtl_test dentro de un contenedor efímero:

docker run --rm --device=/dev/bus/usb/002 --entrypoint rtl_test pachulo/xenial-gnuradio-rtl-toolkit

Nota: una forma fácil de averiguar en que HUB USB hemos conectado nuestro dispositivo es ejecutar el comando dmesg justo después de conectarlo. Para el ejemplo de arriba me he guiado por esta información:

...
[10891.158562] usb 2-1.3: new high-speed USB device number 14 using ehci-pci
[10891.279033] usb 2-1.3: New USB device found, idVendor=0bda, idProduct=2838
[10891.279039] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10891.279041] usb 2-1.3: Product: RTL2838UHIDIR
[10891.279043] usb 2-1.3: Manufacturer: Realtek
[10891.279045] usb 2-1.3: SerialNumber: 00000001
...

GR-GSM

Basado en la anterior se ha creado una imagen con gr-gsm, un software basado en GNURadio y cuyo objetivo es (según su propio autor):

The aim is to provide set of tools for receiving information transmitted by GSM equipment/devices.

En el siguiente enlace su pueden obtener los ficheros para compilar la imagen Docker:

Así como ésta ya compilada en Docker Hub:

docker pull pachulo/xenial-gr-gsm

Tal y como se puede observar en el Dockerfile, para crear la imagen se compila el software desde el código fuente y se copian un par de archivos para su correcto funcionamiento.

Antes de poder utilizar la imagen habrá que explicar un par de cosas sobre ejecutar aplicaciones basadas en X11 dentro de contenedores.

Aplicaciones gráficas dentro de contenedores

Ejecutar aplicaciones con GUI dentro de contenedores es un problema que ya se ha abordado anteriormente y para el que existen varias soluciones. Y si queremos obtener aceleración por hardware para utilizar aplicaciones OpenGL (como por ejemplo GNURadio) la cosa se complica un poco más, tal y como se explica en HW accelerated GUI apps on Docker.

Además de todo esto, si el sistema utiliza una tarjeta gráfica NVIDIA con el driver privativo, hará falta instalar en el host nvidia-docker, una utilidad de NVIDIA para crear y ejecutar imágenes Docker con acceso a sus GPUs (el porqué es necesaria la utilidad está explicado en su wiki).

La solución que se ha utilizado para este caso es la siguiente:

  • Antes de crear el contenedor:
  • Y al crearlo:
    • Se monta el nuevo fichero Xauthority dentro del contenedor.
    • Se configura la variable de entorno XAUTH en el contenedor para que apunte al nuevo fichero Xauthority.
    • Se pasa la variable de entorno DISPLAY al contenedor con el mismo valor que la del host.
    • Se monta el fichero que hará de socket X dentro del contenedor.
    • Se monta el fichero de caracteres que representa a la tarjeta gráfica dentro del contenedor (de esto se encarga nvidia-docker para GPUs NVIDIA).

Ya que creo que ofrece suficiente aislamiento: el contenedor solo tendrá acceso de lectura-escritura al socket X y al fichero Xauthority y solo se podrá acceder al servidor X11 con la cookie creada para el nuevo fichero Xauthority, además de funcionar con la aceleración por hardware.

Nota: El contenedor creado funciona en mi máquina Ubuntu, que utiliza una tarjeta NVIDIA y el driver privativo, con nvidia-docker pero lo suyo sería ver si en otros sistemas basados en Linux con gráficas Intel y ATI también funciona (utilizando los drivers basados en MESA en esos casos, tal y como se explica aquí). Los usuarios de Windows y MacOS pueden probar alguna de las cosas que se comentan en este issue de Docker.

gr-gsm livemon

Una vez compilada o descargada la imagen y instalado nvidia-docker en el host ya se podrá realizar alguna prueba, como por ejemplo sintonizar el canal de broadcast (BCCH) de estaciones base próximas con la aplicación grgsm_livemon, ejecutando el siguiente script:

# Video support
XAUTH=/tmp/.docker.xauth
touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
XSOCK=/tmp/.X11-unix

# Launch container
nvidia-docker run \
 --volume $XAUTH:$XAUTH \
 --env XAUTHORITY=$XAUTH \
 --env DISPLAY \
 --volume $XSOCK:$XSOCK \
 --env="QT_X11_NO_MITSHM=1" \
 --device=/dev/bus/usb/002 \
 --rm \
 --entrypoint grgsm_livemon \
 pachulo/xenial-gr-gsm

Si todo ha ido bien, se tendría que abrir una ventana como esta:

OsmocomBB

Otra de las imágenes que se ha creado ha sido una con OsmocomBB listo para usar. Toda la información sobre OsmocomBB se puede encontrar en su wiki, pero básicamente:

OsmocomBB is an Free Software / Open Source GSM Baseband software implementation. It
intends to completely replace the need for a proprietary GSM baseband software, such as
– drivers for the GSM analog and digital baseband (integrated and external) peripherals
– the GSM phone-side protocol stack, from layer 1 up to layer 3
In short: By using OsmocomBB on a compatible phone, you will be able
to make and receive phone calls, send and receive SMS, etc. based on Free Software only.

En el siguiente enlace su pueden obtener los ficheros para compilar la imagen Docker:

Así como ésta ya compilada en Docker Hub:

docker pull pachulo/xenial-osmocombb

Nota: Para poder utilizar esta imagen hará falta un teléfono compatible y un cable/adaptador USB-serie.

Cargar firmware y ejecutar la aplicación mobile

Una vez descargada (o compilada) la imagen y conectado el teléfono con el adaptador USB-serie, podemos arrancar un contenedor con la misma:

docker run --device=/dev/ttyUSB0 --rm -it --name test-osmocombb pachulo/xenial-osmocombb

Podemos probar a cargar un firmware en el teléfono ejecutando el comando osmocon dentro del contenedor:

cd /osmocom-bb/src/host/osmocon && ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin

Y haciendo una pulsación corta del botón de encendido del teléfono.

Si el firmware se ha cargado de forma correcta, el siguiente paso será conectarse al contenedor desde otro terminal:

docker exec -ti test-osmocombb /bin/bash

Y ejecutar “mobile”, la implementación de la funcionalidad de un teléfono móvil normal que correrá en el contenedor:

cd /osmocom-bb/src/host/layer23/src/mobile && ./mobile -i 127.0.0.1

Que permitirá conectarse, desde otro terminal:

docker exec -ti test-osmocombb /bin/bash

E interactuar con el teléfono a través de telnet:

telnet 127.0.0.1 4247

Kraken

Otra de las herramientas que se utilizan para el análisis de seguridad de redes GSM es Kraken, un software que:

… allows the ‘cracking’ of A5/1 keys used to secure GSM 2G calls and SMS.

Nota: Para poder ejecutar esta herramienta será necesario un disco de 2TB para almacenar las rainbow tables (y unos 1.8TB de espacio de disco en otro sitio para descargarlas y poder volcarlas luego). Todo el proceso está explicado en Passive GSM interception Part 1. Para el volcado de las tablas se puede utilizar el contenedor.

Los ficheros para compilar la imagen están aquí:

Así como ésta ya compilada en Docker Hub:

docker pull pachulo/xenial-kraken

Y para  arrancar el contenedor se podrá hacer con un comando similar a este:

docker run -ti --rm \
--device=/dev/disk/by-id/wwn-0x5000c50091dc385d-part2:/dev/xvdc2 \
-v /media/$USER/DRIZZLECHAIR/kraken/indexes/:/kraken/indexes/ pachulo/xenial-kraken

 

Conclusión

En las siguientes partes de la seríe se demostrará cómo ejecutar algunos escenarios de análisis y ataque en GSM utilizando estos contenedores.


Detección de IMSI catchers: también desde la red del operador

Hace aproximadamente un mes, investigadores de las empresas SBA Research y T-Mobile Austria publicaron un interesante white paper sobre la detección de IMSI catchers titulado “The Messenger Shoots Back: Network Operator Based IMSI Catcher Detection“.

El IMSI (International Mobile Subscriber Identity) es el identificador único que se utiliza para distinguir a los usuarios de redes móviles de forma inequívoca y, en la mayoría de estándares (GSM, UMTSLTE), se almacena en la tarjeta SIM (Subscriber Identity Module).

Los IMSI catchers es el nombre que reciben los dispositivos maliciosos utilizados para localizar usuarios móviles a través de su IMSI, aunque también se pueden configurar para realizar ataques man-in-the-middle y interceptar las comunicaciones de las víctimas.

El título del paper hace referencia a un cambio de paradigma a la hora de intentar detectar ataques realizados con estos dispositivos; en vez de plantear la detección desde la perspectiva del “cliente” (los dispositivos móviles), han estudiado la viabilidad de detectarlos desde las redes de los operadoras.

Aquí el resumen del paper:

An IMSI Catcher, also known as Stingray or rogue cell,
is a device that can be used to not only locate cellular phones, but
also to intercept communication content like phone calls, SMS or data
transmission unbeknown to the user. They are readily available as
commercial products as well as do-it-yourself projects running open-
source software, and are obtained and used by law enforcement agencies
and criminals alike. Multiple countermeasures have been proposed recently
to detect such devices from the user’s point of view, but they are limited
to the nearby vicinity of the user.
In this paper we are the first to present and discuss multiple detection
capabilities from the network operator’s point of view, and evaluate
them on a real-world cellular network in cooperation with an European
mobile network operator with over four million subscribers. Moreover, we
draw a comprehensive picture on current threats against mobile phone
devices and networks, including 2G, 3G and 4G IMSI Catchers and
present detection and mitigation strategies under the unique large-scale
circumstances of a real European carrier. One of the major challenges
from the operator’s point of view is that cellular networks were specifically
designed to reduce global signaling traffic and to manage as many
transactions regionally as possible. Hence, contrary to popular belief,
network operators by default do not have a global view or their network.
Our proposed solution can be readily added to existing network monitoring
infrastructures and includes among other things plausibility checks of
location update trails, monitoring of device-specific round trip times
and an offline detection scheme to detect cipher downgrade attacks, as
commonly used by commercial IMSI Catchers.

Tras la introducción, el paper detalla el funcionamiento de las redes móviles, cuyo diseño pensado para minimizar el tráfico de control (o señalizacion) no ayuda a la hora de poder centralizar la información sobre los usuarios ni, por lo tanto, detectar ataques realizados con IMSI catchers.

Tras esto, pasa a enumerar las principales capacidades de estos dispositivos:

  • Tracking: El objetivo básico de este modo es recoger los IMSIs (identificadores) de los usuarios.
  • Capturing: En este caso se realiza un man-in-the-middle de todas las comunicaciones móviles. Para ello, normalmente, se necesitará hacer downgrade a un estándar móvil roto a nivel criptográfico (2G básicamente) al dispositivo de la víctima, ya sea utilizando jamming o características de los propios estándares.
  • Passive monitoring: Aquí ya se ha identificado a la víctima y simplemente se monitoriza su ubicación y/o tráfico.

Para las pruebas han utilizado 22 modelos diferentes de terminales, observando su comportamiento después de recibir ataques típicos realizados por IMSI catchers. Con estos resultados y el acceso a datos reales de la red de T-Mobile Austria proporcionados por ellos mismos, han intentado implementar estrategias de detección que puedan ser aplicables a una red móvil real, siendo las conclusiones a nivel general:

  • Para los IMSI catchers que hacen tracking se han encontrado que es el ataque más difícil de detectar desde el punto de vista del operador, ya que apenas produce tráfico en la red legítima.
  • Para los que hacen capturing, en cambio, han encontrado métodos que podrían ser bastante fiables a la hora de detectar este tipo de ataques, como por ejemplo agrupar geográfica y temporalmente anomalías en el uso de los diferentes algoritmos de cifrado que permite GSM por parte de los terminales. Por ejemplo: si se detecta que a una hora determinada varios terminales localizados en la misma área fueron forzados a utilizar conexiones GSM cifradas con el algoritmo A5/1 (criptograficamente roto).

En cualquier caso, la detección se realizaría una vez finalizado el ataque y sería siempre complementaria a la que el usuario haya podido realizar desde su terminal.

Precisamente en la penúltima sección del paper se habla de algunos esfuerzos para detectar este tipo de amenazas desde el punto de vista del “cliente” que, aunque no del todo fiables, se han materializado en diversas implementaciones; estas son las que yo conozco:

  • CatcherCatcher: Primera prueba de concepto de la gente de SRLabs para la detección de IMSI catchers utilizando terminales con un Base Band Processor compatible con OsmocomBB. Estos son los comportamientos que analizan para detectar IMSI catchers.
  • SnoopSnitch: Segunda iteración de SRLabs, en forma de aplicación Android que necesita de permisos de Root y un terminal que utilice un Base Band Processor de Qualcomm. Sirve de base para la obtención de los datos de GSMmap y en el documento IMSI Catcher Score detallan la heurística que utilizan para detectar los IMSI Catchers.
  • Android IMSI-Catcher Detector: Esfuerzo de la comunidad para crear una solución compatible con cualquier terminal Android y que no requiera permisos de Root. Tiene unos objetivos muy ambiciosos pero aún está en estado Alpha. Su wiki contiene muchísima información sobre IMSI catchers y sobre cómo detectarlos.
  • IMSI-Catch Me If You Can: IMSI-Catcher-Catchers (Presentación): Presentado por la misma SBA Research hace un par de años. Incluye dos soluciones (código fuente):
    • mobile ICC: Aplicación Android que no necesita permisos de Root. Permite acceder a información sobre parámetros de las estaciones base, como por ejemplo: correlación geográfica, las capacidades anunciadas, etc… y otros datos, para intentar detectar IMSI catchers.
    • stationary ICC: Diseñado para funcionar sobre una RaspberryPi con un módem GSM Telit GT864 sin SIM. Permite detectar algunos comportamientos típicos de IMSI catchers escuchando los canales de broadcast (BCCH) y de control (CCCH) de las estaciones base.
  • FakeBTS: Proyecto de Pedro Cabrera que utiliza un enfoque similar al stationary ICC, pero usando terminales compatibles con OsmocomBB o SDRs. También permite realizar baselines de las BTS visibles.

En otro punto también se detallan otros ataques que se pueden realizar contra usuarios móviles de forma directa o conjuntamente con IMSI catchers :

  • Los basados en debilidades del protocolo de backbone SS7: consulta de IMSIs y recuperación de claves de cifrado de sesión.
  • Que afectan a la SIMs: clonado y rooting de las mismas.
  • Envío de SMSs sin autenticar (incluso en algunos terminales 3G).
  • Presidential alert messages son un tipo de mensajes de texto broadcast especiales que los terminales no pueden ignorar.
  • Obtención de la localización GPS por parte de la red móvil.
  • Obtención de la localización por triangulación por parte de la red móvil.

Las conclusiones finales, aunque demuestran que los IMSI catchers aún representan un gran problema para las actuales infraestructuras de telefonía móvil, dejan abierto un camino donde las operadoras, además de los usuarios, podrían llegar a detectar ataques realizados con estos dispositivos, aunque para que fuera realmente efectivo deberían realizarse algunos cambios en los sistemas de monitorización de sus redes.

Gran trabajo y investigación de SBA Research para tratar de mejorar la detección de unos dispositivos cuyo uso estaba, hasta hace unos años, reservado a fuerzas de seguridad y actores estatales pero que a día de hoy están al alcance de prácticamente cualquier atacante.


IV Jornada STIC CCN-CERT

La semana pasada, concretamente el martes 14 de diciembre, tuvo lugar la IV Jornada STIC CCN-CERT. Con TB·Security tuvimos la oportunidad de participar activamente en la jornada, entre otra cosas, con una charla sobre análisis de aplicaciones para dispositivos Blackberry, tratando especialmente el análisis de aplicaciones spyware. Durante la charla se explicaron los conceptos básicos relacionados con el entorno Blackberry y la ejecución de aplicaciones, aspectos concretos de spyware para dichos entornos, y se expusó como afrontar el análisis (estático y dinámico) de aplicaciones. Finalmente se mostraron los resultados del análisis de demos de aplicaciones spyware para Blackberry. Por cierto, cualquier feedback sobre la ponencia es bienvenido!

Para aquellos que no pudieron asistir aprovechamos para publicar las diapositivas que se utilizaron durante la ponencia.

Para aquellos que si pudieron asistir, recordar que falló la última parte de la demostración (que vergüenza, que vergüenza! :)), en la que se intentó mostrar uno de los resultados del análisis de la aplicación Kisses, utilizada para el descubrimiento de programas y procesos ocultos en Blackberry. Concretamente falló la plantilla que llevabamos preparada del 010 Editor para ilustrar el parsing del fichero de firmas, una vez descifrado. Para no dejar las cosas a medias, aprovechamos para incluir una captura de pantalla de la plantilla, ahora si, ejecutada correctamente:

La plantilla de 010 editor es la siguiente:

//--------------------------------------
//--- 010 Editor v3.1.3 Binary Template
//
// File: KissessSignaturesTemplate.bt
// Author: juan vazquez
// Revision: 0.1
// Purpose: Kissess signatures db decrypted file parser
//--------------------------------------

typedef struct {
    SetBackColor(cRed);
    char    magic[6];
    SetBackColor(cRed-0x40);
    short   num_signatures;
    SetBackColor(cRed-0x60);
    short   version;
    SetBackColor(cRed-0x80);
    quad    date;
} HEADER;

typedef struct {
    SetBackColor(cGreen);
    ubyte   size_signature;
    SetBackColor(cBlue-0x20);
    ubyte   size_id_signature;
    SetBackColor(cLtBlue);
    byte    id_signature[size_id_signature];
    SetBackColor(cPurple);
    ubyte   size_signature_content;
    SetBackColor(cLtPurple);
    byte    signature_content[size_signature_content];
} SIGNATURE;

BigEndian();
// Header
HEADER header;
// Signatures
local short i = 0;
while (i < header.num_signatures) {
    SIGNATURE sign;
    i++;
}
// Hash
SetBackColor(cGray);
byte file_hash[20];

Como ya comentamos, la plantilla se tiene que aplicar sobre el fichero de firmas de Kisses una vez descifrado. EL fichero de firmas se puede descifrar con el siguiente ruby (el algoritmo, clave e IV se obtienen a partir del análisis que se comentó durante la ponencia):

require 'openssl'

module AESCrypt

  # Decrypts a block of data (encrypted_data) given an encryption key
  # and an initialization vector (iv).  Keys, iv's, and the data
  # returned are all binary strings.  Cipher_type should be
  # "AES-256-CBC", "AES-256-ECB", or any of the cipher types
  # supported by OpenSSL.  Pass nil for the iv if the encryption type
  # doesn't use iv's (like ECB).
  #:return: => String
  #:arg: encrypted_data => String
  #:arg: key => String
  #:arg: iv => String
  #:arg: cipher_type => String

  def AESCrypt.decrypt(encrypted_data, key, iv, cipher_type)
    aes = OpenSSL::Cipher::Cipher.new(cipher_type)
    aes.decrypt
    aes.key = key
    aes.iv = iv if iv != nil
    aes.update(encrypted_data) + aes.final
  end

  # Encrypts a block of data given an encryption key and an
  # initialization vector (iv).  Keys, iv's, and the data returned
  # are all binary strings.  Cipher_type should be "AES-256-CBC",
  # "AES-256-ECB", or any of the cipher types supported by OpenSSL.
  # Pass nil for the iv if the encryption type doesn't use iv's (like
  # ECB).
  #:return: => String
  #:arg: data => String
  #:arg: key => String
  #:arg: iv => String
  #:arg: cipher_type => String

  def AESCrypt.encrypt(data, key, iv, cipher_type)
    aes = OpenSSL::Cipher::Cipher.new(cipher_type)
    aes.encrypt
    aes.key = key
    aes.iv = iv if iv != nil
    aes.update(data) + aes.final
  end

end

class SignaturesDecryptor

	include AESCrypt

	attr_accessor :filename
	attr_accessor :key
	attr_accessor :iv
	attr_accessor :cipher_type

	def initialize(filename = "")
		@filename = filename
		@key = [-117, 109, -121, 50, 44, 127, -61, -37, -27, 110, 36, -28, 66, -85, -9, -102]
		@iv = [109, -76, -62, 45, -121, 12, 16, -8, -26, -89, 92, 112, -37, 9, 36, 7]
		@cipher_type =  "AES-128-CBC"
	end

	def decrypt_signatures
		if @filename.empty?
			return ""
		end
		decrypted = ""
		File.open(filename, "rb") do |signatures|
			decrypted = AESCrypt.decrypt(signatures.read, @key.pack("c16"), @iv.pack("c16"), @cipher_type)
		end
		decrypted
	end
end

sd = SignaturesDecryptor.new("signatures.db")

File.open("signatures_decrypted.db", "wb") do |result|
	result.write(sd.decrypt_signatures)
end

El módulo AESCrypt me lo agencié de un blog (creo) que ahora no soy capaz de recordar, así que no puedo hacer referencia, sorry 😦

Ya para acabar, comentar que bajo mi punto de vista la organización del evento fué fantástica, hubieron charlas muy interesantes y, almenos yo, disfruté de un gran día en una muy grata compañía! 🙂

Saludos!