Introducción
Hace 6 años,
Tobias Engel publicaba en la 25C3 un método para localizar a cualquier víctima de la red móvil (GSM) utilizando para ello mensajes de protocolos de la red SS7. Durante el seguimiento de esta edición del Chaos Communication Congress (31C3), hemos podido disfrutar de varias conferencias acerca de las vulnerabilidades de la red SS7;
Karsten Nohl,
Tobias Engel y
Laurent Ghigonis con Alexandre De Oliveira (del equipo de Philippe Langlois) nos han presentado distintos puntos de vista sobre la seguridad de esta red mostrando sus vulnerabilidades; algunas teóricas y otras explotadas.
Por otro lado, si bien GSM, UMTS y LTE son nombres de redes de telecomunicaciones bien conocidos por todo el mundo, creo que SS7 no goza de la misma fama y posiblemente esto ha impedido a algunos de los interesados en la seguridad seguir con todo detalle estas presentaciones.
¿Qué es exactamente SS7?
No es la intención de este artículo describir técnicamente la compleja red SS7 ni cada uno de los protocolos que la componen, sino el comentar los conocimientos necesarios para entender los anteriores ataques.
Cuando hablamos de SS7, estamos recordando y paseando por la historia de las telecomunicaciones; Su historia es muy larga, nos estamos remontando a los años 1970, cuando AT&T desarrollaba su precursor, sistema de señalización 6 y 5 años más tarde desarrollaba el sistema de señalización 7, que permitiría enlaces de señalización de 64.000 bps. La organización ITU-T (International Telecommunication Union - Telecommunication Standardization) lo adoptó como estándar en 1980, por lo que se encargaría de definir los estándares internacionales (Q.7XX para SS7) para garantizar la interconexión de estas redes a escala mundial.
Podemos pensar en SS7 como un conjunto de protocolos que, por nombrar alguna de sus funciones más importantes, permiten establecer dinámicamente los circuitos para realizar una llamada ya que establecen la señalización necesaria para que las redes involucradas puedan consultar entre ellas información sobre los abonados, como saber dónde se encuentra cada parte de la llamada, dar servicios de valor añadido a los usuarios, entre otras muchas funciones.
A día de hoy, estos protocolos se utilizan en todas las redes de telecomunicación conocidas: red telefónica pública conmutada (PSTN), la red digital de servicios integrados (RDSI), redes inteligentes (IN), y las redes móviles (PLMN).
Protocolos de SS7 y Sigtran
Antes de echar un vistazo rápido al conjunto de protocolos SS7, es importante tener en cuenta "Sigtran" (derivado de signaling transport);
En un principio la señalización se transportaba utilizando un conjunto de protocolos llamados MTP (Message Transfer Part) divididos en 3 capas:
Nivel 1 - Signalling Data Link (representa la capa física, normalmente -en Europa- utiliza un timeslot en un interfaz E1, capa 1 también del modelo OSI)
Nivel 2 - Signalling Link (proporciona un medio fiable de transferencia de señalización entre dos puntos de señalización -PointCodes- conectados directamente, corresponde con la capa 2 del modelo OSI )
Nivel 3 - Signalling Network (capa OSI 3 - el propósito principal es enrutar mensajes entre nodos de la red SS7 de una manera fiable)
Pero con la llegada de las Redes "Next Generation Networks" o NGN, se convirtió en un requisito indispensable la convergencia de todas la redes, así que SS7 actualizó los protocolos de transporte que acabamos de ver y pasó a adoptar el protocolo IP. Esta actualización, llamada Sigtran, sólo afectó a las capas de la pila de protocolos más bajas, las capas superiores (capa 4) han permanecido inalteradas:
ISUP (ISDN User Part): es responsable de establecer dinámicamente los circuitos utilizados para las llamadas. Como podéis ver por su nombre, en un principio estuvo estrechamente ligado a la red RDSI (ISDN: Integrated Services Digital Network)
MAP (Mobile Application Part): capa de aplicación que permite a los nodos de las redes móviles GSM y UMTS comunicarse para proporcionar servicios a los usuarios de estas redes.
¿Qué necesitamos saber de la red SS7?
Con el fin de preparar lo que podría ser una auditoría de seguridad o un ataque a nuestra red SS7, vamos a necesitar tener muy claro qué necesitaremos de cada protocolo o capa para poder llevar a cabo nuestras malignas intenciones:
- MSISDN: Mobile Station Integrated Services Digital Network, compuesto por el código de país (España es 34) y el número de teléfono del abonado (National Destination Code mas el Subscriber Number).
- IMSI: International Mobile Subscriber Identity, el identificador único de cada tarjeta SIM en la red móvil (formado por el Mobile Country Code, el Mobile Network Code y el Mobile Subscription Identification Number).
- IMEI: International Mobile Equipment Identity, el identificador de cada terminal móvil (se puede consultar en todos los móviles marcando *#06# en el marcador -dialer-).
- GoblalTitlle: Es la dirección SCCP de cada nodo en la red SS7, utilizando el mismo formato que los número de teléfono de los abonados pero en este caso representan nodos de la red, no personas.
- SubSystemNumber: indica a cada nodo de la red con qué otro tipo de nodo va a establecer enlace/comunicación. Cada tipo de nodo tiene su propio número; 6 HLR (MAP), 7 VLR (MAP), 8 MSC (MAP) ....
- PointCode: es el identificador de la capa 3 de MTP que se asigna a cada nodo de la red.
Hacking en SS7: ¿Cómo? ¿Dónde?
En el pasado, la idea de una operadora de telecomunicaciones era análoga a la idea de un gobierno o un país. De esta manera, nadie vio ninguna objeción a la hora de interconectar todas las redes SS7 con el nivel de seguridad que proporciona SS7, era algo más que necesario puesto que permitiría realizar llamadas a cualquier parte del mundo.
¡Muy chulo! pero ... ¿Quién pensó en la seguridad?. La red SS7 se ha diseñado con el supuesto de confianza; todos los jugadores/operadores son legítimos y vienen en son de paz. Las cosas han evolucionado mucho, no sólo hemos pasado de los interfaces E1 a enlaces IP, sino que se ha liberalizado el mercado de las telecomunicaciones; han aparecido los operadores virtuales (OMV), así como licencias de test o desarrollo temporales y un gran mercado sobre el transporte de tráfico internacional. Esta situación es la que heredamos hoy, y en la que no todo el mundo tiene buenas intenciones, pero cuando nos demos cuenta, ya estarán conectados a nuestra red SS7.
Esta facilidad para conectarse a la red SS7 es relativa, ya que existe una regulación en todos los países que marca de alguna manera quién, cómo y qué pasos debe dar para establecerse como una operadora y poder dar servicios a los usuarios. El problema más gordo viene cuando alguno de estos países, potencialmente pueda estar interesado en obtener información de sus residentes en el extranjero o incluso espiar a personas de otros países (para no ser muy apocalíptico no voy a citar muchos ejemplos de actualidad reciente, pero esto pasa en el mundo real, ¿verdad Ángela M.?).
Ataques sobre la red SS7
Los distintos ataques que voy a comentar los he agrupado en 4 categorías:
- Información filtrada o mal securizada (fugas de información)
- Fuzzing de protocolos (D.o.S, Resource Exhaustion, etc.)
- Reconocimiento y enumeración de la red (mapa y escaneo de nodos, puertos, etc.)
- Inyección de paquetes (SendRoutingInfo, ProvideSubscriberLocation, etc)
Para revisar cada uno de ellos en detalle y poder mostrar ejemplos reales, he utilizado dos máquinas virtuales corriendo Ubuntu y una pila de protocolos SS7, simulando dos nodos de una red real. La configuración de las máquinas que he utilizado es; la máquina con IP 192.168.56.101 tiene el PointCode 2 y la otra máquina con IP 192.168.56.102 el PointCode 1. Al arrancar la aplicación SS7 en ambas máquinas, podemos ver en una captura de wireshark cómo se establece la asociación M3UA:
Las cuatro primeras líneas corresponden al SCTP handshake (4-way handshake) que protege al protocolo SCTP de posibles ataques de Denegación de Servicio (una mejora respecto al protocolo TCP en el que todos conocemos los ataques D.o.S tipo SYN flood y similares) al establecer el servidor/nodo una Cookie en el mensaje "INIT ACK" y este no hará el más mínimo caso al cliente hasta que reciba esta Cookie de vuelta en el mensaje "Cookie Echo", entonces se cierra la asociación con el mensaje "Cookie Ack", habiendo protegido los recursos del servidor durante la transacción.
En un escenario real, los objetivos serán los nodos de la red móvil (HLR, MSC, STP, etc.), sobre los que un posible atacante podría enviar mensajes válidos con el fin de obtener información sensible, como nuestra localización, nuestra identidad en la red (IMSI) o modificar nuestros datos almacenados en la base de datos.
- Información filtrada o mal securizada.
Todos alguna vez hemos oído o recibido alguna sesión de trabajo sobre la importancia de custodiar la información sensible de nuestra compañía, esto se vuelve crítico cuando hablamos del documento
IR 21. Este documento recoge las "especificaciones técnicas" de cada operadora y es entregado a cada operadora con la que establece un acuerdo de interconexión. Recoge información sensible sobre la arquitectura de red, tipo de red, versiones de protocolos, direcciones IP de los nodos, global title de los nodos, etc.
Simplemente probad a buscar en vuestro buscador favorito "IR21 filetype:pdf" o búsquedas similares, encontrareis más de un documento !!.
Como podéis observar en la imagen (fragmento de un IR21), no sólo podemos ver el fabricante de los nodos y qué nodos son (MSCs híbridas 2G y 3G de Ericsson) y su Global Title, también su localización.
Si tuviese que elegir entre casarme con la "
Ingeniería Inversa" o con el "
Fuzzing de Protocolos" ... simplemente no podría elegir. El Fuzzing está demostrando últimamente la gran cantidad de vulnerabilidades y defectos de programación que se pueden encontrar de manera automática y el potencial de las herramientas (PROTOS, codenomicon, scapy, etc.) que emplean este método para estudiar la seguridad o robustez del software. En el caso de SS7, podemos empezar a jugar con dos herramientas;
scapy y
zzuf. No es la intención de este artículo explicar qué es Fuzzing o los distintos tipos de Fuzzers que existen (interesados ver
este tutorial de InfoSec), pero claramente al lanzar estas herramientas contra nuestras pilas de SS7, podemos ver cómo la aplicación se vuelve pesada así como los mensajes erróneos enviados al servidor. Podremos centrarnos en el protocolo que nos interese investigar (SCTP, M3UA, SCCP, etc.) y una vez aislado el mensaje, reenviarlo a nuestra otra máquina para comprobar nuestro éxito:
Utilizando estas dos herramientas, es recomendable adaptar o desarrollar una monitorización específica para la aplicación que se encarga de arrancar la pila de protocolos SS7, ya que es muy posible que en cualquier momento le ocurra algo a la aplicación inesperado y tendremos que estudiar qué mensaje o qué situación ha sido la causante.
Desde el más clásico nmap hasta módulos Python que implementan SCTP pasando por sctpscan, nos permitirán lanzar escaneos de Ip's utilizando SCTP como transporte, para descubrir todo lo necesarios sobre la topología de la red.
Ejemplo de Nmap:
root@~# nmap -sY 192.168.56.101
Starting Nmap 5.21 ( http://nmap.org ) at 2015-01-24 15:53 CET
Nmap scan report for 192.168.56.101
Host is up (0.00030s latency).
Not shown: 41 closed ports
PORT STATE SERVICE
2905/sctp open m3ua
MAC Address: 00:00:00:00:00:00 ()
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
root@~#
Ejemplo de sctpscan:
root@~# ./sctpscan.py 192.168.56.101
Scanning 192.168.56.101
Cant bind mirror port 2905, use 10000 instead
Cant bind default port 10000, use kernel attributed source port
SCTP Port Open: 192.168.56.101 2905
Results: 1 opened, 112 closed, 0 filtered
root@~#
En la captura de Wireshark vemos el 4-way handshake del puerto abierto (2905), entre todos los demás intentos:
Para cuando el posible atacante hubiese identificado los nodos de la red, el siguiente paso será poder crear su propia asociación con el nodo (en caso de no existir) para poder enviar los mensajes MAP, ya que es en este nivel donde se manejan datos de usuarios, tal y como vimos en el esquema (IMSI, IMEI y MSISDN).
Podemos crear nuestro propio socket SCTP mediante un script (Python) o utilizar los clientes disponibles en la pila de protocolos SS7, lo más importante será confirmar que el nodo que está al otro lado utiliza la misma versión del protocolo que nosotros y construir nuestros paquetes binarios de tal modo que obtengamos la información que nos interesa de nuestra victima. Una vez creada la asociación SCTP, tendremos que ir subiendo de capa, reconociendo los nodos, hasta llegar a localizar el nodo objetivo que buscamos.
Utilizando la pila de protocolos SS7 de
Dialogic, podemos ver la lista de mensajes ya formados, listos para utilizar con la MAP Test Utility y Responder:
Es decir, sin necesidad de forjar nuestro propio paquete binario desde cero, podemos probar y jugar con varios mensajes clave SS7 que habéis leído estas navidades: Send Routing Info, SendIMSI y Forward MT Short Message, simulando el ataque descrito anteriormente en nuestro ordenador.
A continuación podemos ver el resultado de enviar un "SendRoutingInfo" para el MSISDN 34666111222, y la respuesta con el IMSI del supuesto abonado:
Siguiendo estos pasos se pueden llevar a cabo los ataques que parece han conmocionado a todo el mundo (
Washington Post), y desde luego, no es para menos.
Conclusión
Es imposible resumir la historia de las telecomunicaciones así como detallar todos los aspectos técnicos de los protocolos que forman las redes SS7, pero espero que este rápido repaso de SS7 y la enumeración de los principales vectores de ataque a esta red haya abierto el apetito para ahora sí, abrir los enlaces a las slides de las conferencias y entender un poco mejor cómo nos pueden haber estado robando nuestra privacidad desde hace algún tiempo.
Contribución por Pedro Cabrera
