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

mobile security

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!