análisis de ataques/vulnerabilidades ss7/sigtran empleando

Análisis de vulnerabilidades SS7/Sigtran empleando Wireshark (y/o tshark) y Snort

Alejandro Corletti Estrada Pág 1

Análisis de ataques/vulnerabilidades SS7/Sigtran empleando Wireshark (y/o tshark) y Snort

Madrid, marzo de 2018.

Por: Alejandro Corletti Estrada ([email protected] - [email protected])

INDICE

1. Objetivo de este documento.

2. Presentación.

3. Introducción a SS7/Sigtran.

3.1. Señalización SS7.

3.2. Sigtran.

4. Presentación de los diferentes tipos de ataques.

4.1. Análisis de IR 82 GSM (Security SS7 implementation on SS7 network.

4.2. Clasificación de los diferentes tipos de ataques.

4.3. Análisis de detalle.

5. Análisis de capturas de tráfico: patrones a buscar, empleo de Wireshark.

6. Análisis de capturas de tráfico empleando Snort.

6.1. El Archivo de configuración.

6.2. Salidas.

6.3. Las SS7.rules.

7. Otras herramientas adicionales.

7.1. MATE (Meta Analysis and Tracing Engine) para Wireshark.

7.2. Tshark.

7.3. Unificar tramas (mergecap).

7.4. Información de capturas (capinfos).

8. Conclusiones.

REFERENCIAS

mailto:[email protected]

mailto:[email protected]



1. Objetivo de este documento.

Presentar una metodología de trabajo eminentemente técnica que permita: detectar, identificar y evaluar ataques en redes SS7/Sigtran por medio del “análisis de tráfico” basado en las herramientas “Wireshark” (y/o tshark) y “Snort”.

2. Presentación.

Desde hace ya algunos años (podríamos decir que en fechas cercanas a 2010), se ha empezado a escuchar que este sistema de señalización (verdadero corazón de toda la red mundial de voz y cierto tipo de datos) presenta serios problemas de seguridad. La explotación de los mismos abre un abanico a todo tipo de ataques, en la actualidad ya se están ejecutando en varias operadoras telefónicas, robando dinero de cuentas bancarias, interceptando llamadas telefónicas, localizando la posición de teléfonos móviles, realizando diferentes tipos de fraudes en voz y navegación, ejecutando negaciones de servicio, etc.

En estas líneas, no vamos a desarrollar el SS7 (Sistema de Señalización 7), ni tampoco Sigtran (Señalización de Transporte), haremos únicamente una muy breve presentación de los mismos para poder comprender el problema.

Cabe mencionar que el “análisis de tráfico” es la ÚNICA metodología que tenemos para poder comprender y evaluar este tipo de anomalías en nuestros flujos de señalización. Nos atrevemos a hacer esta afirmación, sustentados en una serie de documentos y normas que iremos presentando en este documento.

Nos encontramos ante un problema grave a nivel mundial y que necesariamente se extenderá al menos durante los próximos diez años, pues esta señalización sólo será reemplazada cuando todas las troncales mundiales empleen SIP y/o DIAMETER, que son los protocolos de voz sobre IP, es decir cuando la conectividad de extremo a extremo para todos los servicios de voz sea paquetizada por medio de la pila TCP/IP.



3. Introducción a SS7/Sigtran.

3.1. Señalización.

El propósito básico de la señalización es establecer un lenguaje de intercambio de información de control que permita que dos líneas telefónicas ubicadas en cualquier parte de la red telefónica se comuniquen entre sí.

En concreto cubre todos los aspectos relacionados a:

Establecimiento.

Mantenimiento

Cierre

De una comunicación (hoy en día, sea de voz o datos).

SS7 entra en producción en los años 80’ como una red “cerrada” de los operadores telefónicos, definido como Señalización por canal común. Establece los procedimientos y protocolos para intercambio de información entre las entidades residentes de una red de señalización {telefonía fija (PSTN) – red de paquetes (PDTN) – telefonía móvil (PLMN)} para supervisión, control, acceso, gestión y enrutamientos de servicios de voz o datos Transmitido en los canales digitales de los enlaces PCM (Modulación por Pulsos Codificada - Pulse Code Modulation). Si queremos entrar un poco más en detalle, existen dos tipos de Señalización:

De acceso (o de abonado)

o DSS (Digital Subscriber Signaling) → datos (canal D de RDSI)

o PSTN (abonado analógico) por frecuencias independientes

Troncal

o CAS (Señalización por canal asociado)

o CCS (Señalización por canal común) Esto es SS7

La base de este sistema, tal cual mencionamos PCM, se sustenta en los primeros pasos sobre digitalización de la “voz analógica”, donde en nuestra parte del planeta se adoptó como “ancho de banda aceptable” para una rango vocal el valor de 4000 Hercios (o Hertz) y según el teorema del muestreo se tomaron dos veces su ancho de banda en “muestras”, es decir 8000 muestras/segundo, las que finalmente se “codificaron” con 8 bit, obteniendo lo que se denominó “canal básico de voz digitalizado” = 64.000 bits/segs = 64 Kbps.

Este canal básico, se fue integrando en lo que se llaman “Jerarquías digitales”, de las cuáles la primera de ellas (en su versión Plesiócrona o PDH) fue la famosa trama E1 (reitero que para nuestra parte del mundo



occidental, pues existen otras) Esta trama, no es más que la suma de 32 canales de 64 Kbps agrupadas en “ranuras de tiempo” (o Slots). De estos 32 slots, 30 son canales donde baja “voz”, el primero es para “sincronismo” y en el caso de SS7 sólo se emplea el “Time Slot 16” en este canal viaja TODA la señalización SS7 por medio del empleo de dos grupos de 4 bits (denominados ABCD) los cuáles van señalizando únicamente dos canales de voz por trama, de los 30 de cada E1. Como, una vez que la trama E1 se “inyecta” en la red troncal, la misma tiene una duración total de 125 µs (Micro segundos), cada 8 tramas pasa 1 milisegundo, por lo tanto, cada 2 milisegundos pasan 16 tramas con los cuáles vuelve a señalizar los dos canales de la primer trama E1. A continuación se presenta un ejemplo de este formato:

Formato básico de una trama E1

Formato de time slot 16

La red SS7 se basa en una pila de protocolos de 7 niveles que responde al modelo ISO/OSI (no accesible desde la pila TCP/IP). Este modelo de capas permite mover información por medio de tres tipos de nodos, llamados:

SP (Signaling Point).

SSP (Signaling Switching Point).

STP (Signaling Transfer Point) → Router o GW, no genera mensajes, solo encamina, hace mediciones de transferencia.

SCP (Signaling Control Point) provee acceso a Aplicaciones (Ej BBDD, etc).



Red SS7

SS7 cono mencionamos, nace en los 80` dentro de un marco “cerrado”, únicamente accesible por las operadoras de telefonía…………. El problema nace con la “Inteligencia” que empezamos a ponerle a nuestras redes (NGIN: Next Generation Intelligent Network). Concretamente esta “inteligencia” de forma resumida, comienza tal vez con las primeras redes RDSI (Red digital de Servicios Integrados) y se implanta un protocolo llamado ISUP (que presentaremos más adelante) en la pila de SS7, cuando comienzan las primeras redes móviles se incorpora una capa más, bajo la forma de BSSAP (que también presentaremos a continuación) y finalmente el protocolo MAP (Mobile Application Part) para todos los aspectos de perfiles, mensajería, sistemas de doble autenticación, movilidad, roaming, servicios no estructurados, etc. A continuación se presenta una imagen donde aparecen estos nuevos aspectos que en definitiva se ofrecen por medio de Servidores o aplicaciones de software (cosa nueva en la jerarquía SS7).

Red SS7 y NGIN

A medida que se incorporan estos nuevos protocolos, la infraestructura de SS7 bajo el modelo de siete capas ISO/OSI comienza a hacerse



inoperable, y de esta forma nace “Sigtran”, el cual incorpora la pila TCP/IP por debajo de esta familia SS7….. y entramos en el mundo IP (con lo bueno…… y también lo malo….) Aquí concretamente empiezan nuestros problemas y vulnerabilidades potencialmente accesibles desde cualquier lugar del mundo a través del enrutamiento IP. A continuación presentamos un par de imágenes de los modelos de capas.

Pila SS7

Pila OSI - Pila SS7 – Pila Sigtran

Como mencionamos al principio, este no es un texto sobre SS7/sitgtran, sino una breve presentación de ambos, por lo tanto los únicos aspectos que deseamos destacar son:

En la pila SS7 (central) podemos apreciar un modelo que responde a las siete capas de la pila OSI (izquierda). Reiteramos que NO tiene ninguna comunicación con el mundo TCP/IP. Los protocolos que más nos interesan de este modelo son: SCCP, TCAP, MAP, CAP (Camel) e ISUP.



En la pila Sigtran (derecha) debemos destacar SCTP que es el protocolo que reemplaza TCP o UDP en el nivel de transporte incorporando las ventajas de ambos (Cabe aclarar que hoy en día también se emplea como transporte para otros protocolos de aplicación de la pila TCP/IP; por ejemplo http)

El nivel “Phisical” de la pila Sigtran, no es más que los niveles 1,2 y 3 de la pila TCP/IP.

Sólo a título descriptivo, presentamos a continuación estos protocolos.

MTP Layer 1: (Message Transfer Part nivel 1)



SCCP: (Signaling Connection Control Part)

ISUP: (ISDN User Part) mensajes de señalización ISDN (canal D)

TUP: (Telephone User Part) mensajes de señalización telefónica

TCAP: (Transaction Capability Application Part)

➢ MAP: (Mobile Application Part) Empleado por MSC, SGSN y GGSN

➢ INAP: (Intelligent Network Application Protocol)

➢ AIN: (Advenced Intelligent Network)

➢ CAP: (/CAMEL Application Protocol [Customizable

Applications for Mobile Enhanced Logic]) Roaming.

➢ WIN: (Wireless Intelligent Networking)

BSSAP: (Base Station System Application Protocol) Emplean los sistemas nativos de GSM con MSC y BSS, prove dos clases de funciones:

➢ DTAP: (Direct Transfer Application Part) gestión de llamadas y gestión de movilidad.

➢ BSS-MAP: Diálogo entre MSC-BSS y Handover.

IS-41 WIN: (ANSI-41) Gestión de la movilidad en telefonía móvil (ANSI/TIA/EIA-41.5-D, Wireless Intelligent Networking (WIN) extensions ANSI/TIA/EIA-751, ANSI/TIA/EIA-764, ANSI/TIA/EIA-771, ANSI/TIA/EIA-826 [Prepaid])

Veamos una primer captura de tráfico sobre la pila Sigtran para que empecemos a comprender este sistema de “empaquetado”.



Captura de tráfico (en verde protocolos de la pila TCP/IP, en azul protocolos de la pila

Sigtran) Por último para nuestro trabajo de análisis, no podemos dejar de lado al menos llos esquemas básicos de direccionamiento que emplean estos protocolos.

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 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úmeros de teléfono de los abonados. pero en este caso representan nodos de la red, no personas.

SubSystemNumber (SSN): 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.

Todos ellos se encuentran recogidos en el siguiente enlace de la 3GPP "TS 23.003: Numbering, addressing and identification", con una mejor descripción y el formato de cada uno.

Para aclarar un poco más la relación de cada uno de ellos con su protocolo correspondiente, presentamos una asociación de los mismos por medio de una imagen.



4. Presentación de los diferentes tipos de ataques.

Para iniciar esta sección, lo haremos a través de un documento que presenta

GSMA (Asociación GSM) por tratar el tema co sumo detalle, si bien debemos

tener en cuenta que el mismo sólo aplica a la red móvil. Más adelante en nuestro

documento abordaremos también la red fija.

4.1. Análisis de IR 82 GSM (Security SS7 implementation on SS7 network

guidelines - Version 3.0 21 - March 2016)i.

Los ataques pueden ser ejecutados principalmente por:

Manipulación de SCCP

Alteraciones de MAP

NOTA: Tengamos en cuenta que por tratarse de un documento publicado por GSMA no trata ISUP, ni TUP (red fija) Identifica 55 operaciones de riesgo, y las clasifica en 5 categorías: • Categoría 1: Mensajes que sólo deberían ocurrir en la “Home Net”

• Categoría 2: Mensajes que NO son de la “Home Net”

• Categoría 3: Mensajes que normalmente deberían ser recibidos desde un suscriptor que está en una “External Net” y exclusivamente desde esa “External Net”

• Categoría 4: Operaciones con SMS

• Categoría 5: CAMEL

Nos presenta una tabla asociando estas categorías con su posibles soluciones:

Los mensajes de Categoría 1 se pueden filtrar por técnicas relativamente simples en el borde de la red. Esto se puede hacer evaluando el tipo de mensaje y verificando si el mensaje se ha enviado o no desde una "Extenal Net". Los mensajes de la Categoría 2 no pueden filtrarse en el borde de la red.



Un operador debe correlacionar los estados del suscriptor y verificar si el suscriptor está en una "External Net" o no antes de que se pueda bloquear. Los mensajes de categoría 3, deben utilizar enfoques más sofisticados. Estos son mensajes que tienen un uso legítimo en la red y simplemente no se pueden filtrar. Un sistema de protección necesita analizar el flujo de mensajes de la red y ser capaz de buscar cambios en el comportamiento de los elementos de red y suscriptores. Por ejemplo, mirando la ubicación previa de los suscriptores.

4.2. Clasificación de los diferentes tipos de ataques.

Para el análisis de estos ataques, nos basaremos en las diferentes referencias que existen en Internet:

Engel, Tii

Langlois, P. iii

Nohl, K. iv

Vauboin, P.-O. v

Según estas referencias el atacante debe estar:

1) Conectado a la red SS7 de alguna manera.

2) En capacidad de generar mensajes arbitrarios SS7 a voluntad, y

3) En capacidad de imitar un nodo en la red SS7 proporcionando capacidades SS7.

Se pueden agrupar en cuatro categorías:

1) Información filtrada o mal securizada (fugas de información).

2) Fuzzing de protocolos (D.o.S, Resource Exhaustion, etc.).

3) Reconocimiento y enumeración de la red (mapa y escaneo de nodos, puertos, etc.).

4) Inyección de paquetes (SendRoutingInfo, ProvideSubscriberLocation, etc).

4.3. Análisis de detalle

A continuación presentamos quince tipos de ataques diferentes que hemos clasificado de esta forma para poder “segregar” todo lo posible los patrones de tráfico y los orígenes y destinos de los mismos. Esta clasificación no trata



de ser exhaustiva y por supuesto que puede ser debatida y hasta refutada pensando que, es posible agrupar algunos de ellos o hasta desglosarlos aún más.

Nuestra sana intención de presentarlo de esta forma, es únicamente la mencionada: poder evaluar diferentes flujos y parámetros, pero desde ya aceptamos cualquier tipo de críticas al aspecto, es únicamente un puto de vista más.

1. Búsqueda de información sobre celdas-HLR-VLR/MSC

a. El servicio MAP.

anyTimeInterrogation (ATI) puede consultar al HLR del suscriptor por su Cell-Id e IMEI (phone serial number, can be used to look up phone type) (Textual en el documento: "31c3-ss7-locate-track-manipulate.pdf", pág 13 de Tobias Engel) desde la HOME NET hasta la VISITED NET

Algunas redes actualmente lo bloquean.

b. Instead, query the MSC/VLR directly (Es decir, consulta directa al MSC/VLR en vez del HLR) Dentro de la misma HOME NET (pág 16)

c. Una vez conocido el IMSI del suscriber, el intruso puede consultar

directamente por el "Cell ID" del mismo, en este caso el parámetro de MAP es: "provideSuscriberInfo Request" y si el MSC/VLR responde, lo hará con "provideSuscriberInfo Response" (ver captura de tráfico en pág 18 del mencionado documento).



El parámetro: returnResultLast (2) anyTimeInterrogation (ATI) no debería responder a cualquiera que lo interrogue, si lo hace, le ofrece el GT, el VLR-number, la locationNumber y el Address digits (todos campos de MAP). (podemos verlo en el doc: "31c3-ss7-locate-track-manipulate.pdf", pág 14). SOLUCIÓN: Analizar la posibilidad de implementar bloqueos ATI a IPs o SCTP o TCAP indebidos).

SOLUCION en una Operadora Alemana: • The Operator started filtering all network-internal messages at the

network’s borders • This (combined with SMS home routing, which the operator has in place)

essentially eliminated the simple form of tracking as seen before • Attack traffic dropped more than 80%:

2. Location Services (LCS) (empleo de la Localización de emergencia) Nuevamente sobre MAP, se realizan dos pasos:

a. El intruso envía sendRoutinginfoForSM request (al HLR), el cual responde con sendRoutinginfoForSM response

b. segundo envío: provideSuscriberLocation request (ahora al MSC/VLR, el que consulta a la antena), el cual responde con



provideSuscriberLocation response (verlo en pág 25 del citado documento).

El enrutamiento de mensajes MAP ocurre en la capa SCCP (esto es muy importante!!! ANALIZAR SCCP!!!! en los campos Called Party Digits y Calling Party Digits) Las solicitudes se dirigen a la "Dirección de la parte llamada" (por ejemplo, la dirección de un VLR). Las respuestas se enviarán de vuelta a la "Dirección de la parte llamante" de la solicitud.

(Ver captura tráfico en pág 26 del citado documento)



Problema: SCCP no sabe nada sobre MAP o qué entidades deberían poder usar qué servicios de MAP SOLUCIÓN: Hacer que el remitente Ponga otra copia de su "Dirección de la parte llamante" en un campo adicional en la capa MAP, para que pueda verificarse (Esto creo que está muy bien, pues se puede verificar esta dirección desde MAP, verificar que sea correcta:

Si no lo es genera un error Si lo es, sigue adelante y envía

la respuesta con el campo correcto en SCCP (Called Party Digits y Calling Party Digits)

El enrutamiento seguirá ocurriendo a las direcciones de la capa de red (Ver pág 27 del citado documento).



3. Denial of Service

No solo es posible leer los datos del suscriptor, sino que también se pueden modificar, ya que la mayoría de los VLR/MSC de la red no realizan verificaciones de plausibilidad. Una vez que el intruso conoce la dirección del MSC/VLR puede enviar por medio de MAP, los siguientes parámetros:

o insertSubscriberData req o deleteSubscriberData req o cancelLocation req

SOLUCIÓN: Controlar cada aspecto de lo que un suscriptor tiene permitido hacer:

o habilitar o deshabilitar las llamadas/SMS o datos entrantes y/o salientes

o o eliminar al suscriptor del VLR en su conjunto. 4. CAMEL “Customised Applications for Mobile networks Enhanced Logic”

Especificado en 3GPP TS 23.078, es como una superposición sobre la lógica de MAP habitual. Define un conjunto de eventos para los cuales el VLR debe



contactar a la entidad CAMEL en la red doméstica del suscriptor (gsmSCF = "GSM Service Control Function") El gsmSCF luego decide si la acción deseada puede continuar sin modificarse o modificarse o será abortada. Ejemplo:

El suscriptor alemán está en itinerancia (roaming) en Francia. German HLR le dice a French VLR "notifique a mi gsmSCF en la dirección +4917, cuando el suscriptor quiera hacer una llamada".

El suscriptor desea hacer una llamada telefónica, pero marca el número en formato nacional alemán (0317654 ...) MSC pregunta a gsmSCF en la red doméstica qué hacer con la llamada, gsmSCF reescribe el número a formato internacional (+49317654 ...) y le dice a MSC que continúe con el nuevo número.

Interceptando llamadas con CAMEL Una función básica de CAMEL es cuando un suscriptor de la red A (Alemania), visita la red B (Bélgica), analicémoslo:

a. el suscriptor estando en B, llama a un número de la red B (pero sin poner el código internacional por delante, pues está llamando a su "propia red".

b. la MSC/VLR (de la red en la que se encuentra, en esta caso red B) consulta a la gsmSCF (de la red A) y la misma lo reescribe en su formato internacional (en este caso le agregaría +49) y le dice al MSC que continúe con la llamada.



c. Para la interceptación de esta llamada, en primer lugar, el intruso "sobre escribe" la dirección del gsmSCF con su "falso gsmSCF". Esto se hace con el

parámetro: insertSubscriberData req (de MAP).

d. el MSC (en este caso nuevamente de la red A) le responderá al "falso gsmSCF", el parámetro es “initialDP”.

e. El intruso sobre escribe ahora el número, por ejemplo +210987...,

registrándolo como su propio proxy (e.g. an Asterisk PBX).

f. MSC configurará la llamada a +210987..., quedando un MitM hacia el

teléfono original (pudiendo grabar toda la conversación). (Todo esto figura en las páginas 31 a 37 del citado documento)

5. HLR Location Update Cuando un suscriptor viaja a otra región o país, el VLR/MSC envía una solicitud de actualización de MAP a la HLR del suscriptor (el parámetro es: updateLocation req). El HLR envía una copia de los datos del suscriptor al VLR/MSC y guarda la dirección del VLR / MSC (el parámetro es: insertSubscirberData req).



Ahora, cuando alguien quiere llamar o enviar un mensaje de texto al suscriptor desde cualquier red, se le solicita al HLR la información de enrutamiento (desde la red origen, por ejemplo el SMSC envía al HLR sendRoutingInfoForSM req y el HLR responde con: sendRoutingInfoForSM resp) y

le entrega la dirección del VLR / MSC. Finalmente si desde esa red se envía la llamada o el SMS lo hará directamente hacia la MSC/VLR que se le acaba de indicar por el HLR a través del parámetro: mt-forwardSM req. HLR: Stealing Subscribers (robo de suscriptores) El procedimiento updateLocation tampoco está autenticado. Un atacante puede simplemente simular que un suscriptor está en su "red" al enviar la updateLocation con su Global Title al HLR del suscriptor (Los parámetros son: updateLocation req, al que el HLR responderá con insertSubscirberData req y recordemos que guardando esta dirección en el HLR). Ahora, las llamadas y SMS para ese suscriptor se enrutan al atacante. Ejemplo: el banco del suscriptor envía texto con mTAN. El atacante intercepta el mensaje y transfiere dinero a su propia cuenta.



(Todo esto figura en las páginas 38 a 42 del citado documento) También podemos analizarlo desde el documento citado de Philip Langlois:



6. HLR Supplemantary Services (Servicios suplementarios).

Los códigos USSD (Unstructured Supplementary Service Data) se pueden ejecutar por otros suscriptores. Algunos operadores ofrecen transferencia o prepagos a través de tarjetas de crédito. Los reenvíos de llamadas pueden ser configurados/borrados. Un atacante podría reenviar las llamadas de un suscriptor a un número de tarifa premium controlado por él y luego llamar al número del suscriptor, facturando todas las llamadas de tasa premium al suscriptor Switch SIM activa en caso de Multi-SIM. Las solicitudes pueden enviarse incluso sin un previo updateLocation, porque el HLR no verifica si el suscriptor está en la red que está enviando la solicitud.

Todos estos parámetros también forman parte de MAP y el campo es USSD String)

(Todo esto figura en las páginas 43 y 44 del citado documento de Tobías Engel)

7. Hybrid Attacks: TMSI De-anonymization (Desanonización de TMSI)



Un atacante puede averiguar los números de teléfono de los suscriptores a su alrededor:

- La paginación de suscriptores (por ejemplo, para notificarlos de una llamada entrante) sucede sin cifrar.

- TMSI (Temporary Mobile Subscriber Identifier) se usa normalmente para paginación de modo que la identidad real del suscriptor (IMSI) no tenga que ser enviada por la interfaz aire sin cifrar. (El parámetro enviado desde el MSC/VLR al ME es: PagingRequest y contiene el TMSI).

El atacante captura TMSI en el aire (Por ejemplo con OsmocomBB)

Se le puede pedir al MSC que envíe el IMSI si se conoce el TMSI (el parámetro es: sendIdentification req, a lo que la MSC/VLR responderá con sendIdentification resp, conteniendo el IMSI). Con updateLocation, el atacante puede descubrir el MSISDN que pertenece al IMSI.

8. Hybrid Attacks: Intercept Calls (Interceptación de llamadas) También se puede pedir al MSC la clave de sesión del suscriptor (en este caso el intruso envía el parámetro: sendIdentification req con el TMSI al MSC/VLR, ante lo que este le responde con: sendIdentification resp que contiene las session keys). Si el atacante captura una llamada encriptada GSM o UMTS, puede descifrarla

usando la clave de sesión (session keys). Prestad atención que este ataque podemos clasificarlo como “pasivo” pues no necesita emplear ni solicitar el IMSI (como en el caso anterior).

9. LTE (Long term evolution)



LTE usa el protocolo Diameter en el core de red.

SS7 se está convirtiendo en un protocolo heredado, pero:

- Una gran parte del diseño SS7 ha sido portado a Diameter, incluidos sus defectos.

- Por ejemplo, todavía no hay una autenticación de extremo a extremo para los suscriptores.

- GSM / UMTS (y con ellos SS7) estará disponible durante mucho tiempo (probablemente alrededor de 20 años).

Para poder tener conexiones de GSM/UMTS a LTE, hay interfaces que mapean la mayor parte de la funcionalidad de SS7 (incluidos sus defectos) en Diameter.

10. Ataques vía protocolo SCTP (fuente: “bh-eu-07-langlois-ppt-apr19.pdf”vi)

Lo que hemos podido averiguar al respecto se basa principalmente en escaneos SCTP.

11. Ataques en combinación con DIAMETER. (Fuente:

diameter_research.pdfvii)

NOTA: Este documento “diameter_research.pdf” debe ser tenido en cuenta también para evaluar IMS y VoLTE pues está fundamentalmente centrado en esta red. Muchas de las actuales redes y funciones de FTTH y VoLTE que podrían funcionar básicamente con Diameter (sin necesidad de SS7) aún necesitan convivir y dialogar con SS7 por aspectos heredados, y es probable que sigamos así bastante tiempo. Por esta razón es que se debe considerar este potencial escenario de ataque.



También hay formas de obtener IMSI de un suscriptor a través de una red Diameter. Esto requiere el número de abonado móvil (MSISDN) y la dirección de un nodo de borde en la red de señalización de Diameter. Un escenario de ataque que utiliza una vulnerabilidad conocida es la siguiente. Un atacante, que actúa como SMS Center (SMS-C), envía un mensaje SSR (Send-Routing-Info-for-SM-Request) especialmente diseñado hacia el Home Subsciber Server (HSS). Si tiene éxito, el atacante recibe el IMSI del usuario relevante en respuesta. En un segundo escenario, el atacante puede hacerse pasar por un servidor de aplicaciones y enviar un mensaje UDR (User-Data-Request) especialmente diseñado al HSS. Los datos recibidos en respuesta del HSS contendrán el IMSI del usuario. Otra forma de forzar la divulgación de IMSI es atacar al nodo IWF (Interworking Function) responsable de la compatibilidad entre la red de Diameter y las redes de generaciones anteriores. En este caso, una solicitud SRI4SM de MAP SS7 se traduce (o se traslada) a la solicitud de SRR de Diameter equivalente. En respuesta, el atacante recibe el IMSI solicitado.

Una vez que el atacante obtiene las direcciones IMSI más de un suscriptor de los nodos de la red móvil que brindan servicio al suscriptor, tiene la información que necesita para lanzar otros ataques.

12. Ataques ISUP (Fuente: FRHACK2009_Attacking-SS7_Langlois.pdfviii)



Recordemos que este protocol (ISUP) es el que emplea la pila SS7 para las redes RDSI.

Flujo de iniciación de llamada ISUP:



13. Informacion filtrada o mal securizada (fugas de informacion) (Fuente: Final

Research Report.pdfix)

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. Reúne toda 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 que nodos son (MSCs/VLRS 2G y 3G de Ericsson), su Global Title Y también su localización.

14. Fuzzing de protocolos (Fuente: Hacking en redes SS7 ~ Security By

Default.pdfx)

El Fuzzing esta 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. 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 que mensaje o que situación ha sido la causante.

15. Ataques internos a SS7 (Fuente: Hacking en redes SS7 ~ Security By Default.pdf, ídem referencia anterior)

En el mencionado reporte se presentan una serie de posibilidades que se pueden ejecutar desde los segmentos de red que tienen visibilidad con la infraestructura Sigtran/SS7, merece la pena considerarlo como un vector de ataque pues está en capacidad de realizar cualquiera de los anteriores.

Referencia final de esta sección.

Un documento que merece la pena también considerar es la Tesis de xi Jensen,

K. que nos presenta una tabla muy útil sobre varias técnicas que se han recomendado para proporcionar algunas mitigaciones a las vulnerabilidades de SS7. Estas técnicas no están pensadas específicamente para detener ataques, pero brindan otra capa de seguridad. Esta tabla se refiere a parámetros del protocolo MAP asociados con las tres primeras categorías que acabamos de presentar.



Imagen extraída del documento referenciado “Jensen.K”

Los mensajes de Categoría 1 se pueden filtrar por técnicas relativamente simples en el borde de la red. Esto se puede hacer evaluando el tipo de mensaje y verificando si el mensaje se ha enviado o no desde una "Extenal Net". Los mensajes de la Categoría 2 no pueden filtrarse en el borde de la red. Un operador debe correlacionar los estados del suscriptor y verificar si el suscriptor está en una "External Net" o no antes de que se pueda bloquear. Los mensajes de categoría 3, deben utilizar enfoques más sofisticados. Estos son mensajes que tienen un uso legítimo en la red y simplemente no se pueden filtrar. Un sistema de protección necesita analizar el flujo de mensajes de la red y ser capaz de buscar cambios en el comportamiento de los elementos de red y suscriptores. Por ejemplo, mirando la ubicación previa de los suscriptores.



5. Análisis de capturas de tráfico: patrones a buscar, empleo de Wireshark.

En estos párrafos damos por sentado que el lector ya posee una experiencia previa de trabajo con “capturas de tráfico” y en particular también en el uso de la herramienta “Wireshark”. Sobre estos temas, ya hemos desarrollado otras publicaciones y videos que están a vuestra entera disposición para descarga y estudio en las siguientes ubicaciones:

Curso de análisis de tráfico:

Sección: "Descargas" → "Tecnologías de la Información" → "Redes y Comunicaciones" en nuestra Web: www.darFe.es

O directamente en la siguiente URL:

http://www.darfe.es/joomla/index.php/descargas/summary/4-redes-y-comunicaciones/39-curso-de-analisis-de-trafico

Tenemos también una secuencia de “seis videos” sobre el tema de "Análisis de Tráfico" empleando Wireshark en nuestro “canal Youtube":

https://www.youtube.com/user/infoDarfe/videos También, si deseas practicar más aún, tenemos varios ejemplos de “capturas de tráfico” realizadas y clasificadas por protocolos, que también puedes descargar gratuitamente en:

https://www.darfe.es/joomla/index.php/capturas En definitiva, te invitamos a que si aún no has comenzado tu trabajo sobre “análisis de tráfico” te remitas a las direcciones y publicaciones mencionadas, y reiteramos, en los párrafos siguientes damos por conocidos estos aspectos básicos.

A continuación, desarrollaremos el estado en el que nos encontramos sobre análisis de SS7/Sigtran para comenzar a “concienciar” acerca de la importancia que revista ser capaces de evaluar o analizar estos flujos desde el punto de vista de la seguridad de una red de señalización.

Hay un documento importante que debemos tener en cuenta para esta

evaluación: FS.11 - SS7 Interconnect Security Monitoring Guidelinesxii.

http://www.darfe.es/



https://www.youtube.com/user/infoDarfe/videos

https://www.darfe.es/joomla/index.php/capturas



Cuando trabajamos con capturas de tráfico SS7/Sigtran, podemos evaluar concretamente este tipo de patrones de tráfico que desarrollamos en las secciones anteriores. En nuestro caso trabajaremos con “Wireshark” que os invitamos a que instaléis en alguna máquina virtual, si es una distribución Linux, Debian, “Kali” mejor, que mejor, pues también nos facilitará el trabajo con varias herramientas adicionales que ya trae preinstaladas. Comencemos nuestro trabajo sobre “capturas de tráfico”.

Recordemos algunos párrafos:

En primer lugar, el operador debe:

✓ Comprender que SS7 ya no es seguro y deben separarse de otras redes SS7 para proteger su propia red y sus suscriptores.

✓ Tener el control de sus propios elementos SS7. Lo que significa que un operador puede separar su red interna, o red doméstica, de todas las demás redes externas.

✓ En segundo lugar, el operador debe ser capaz de capturar el tráfico que ingresa al borde definido de la red. Posibilitando determinar desde dónde se originó un mensaje, externa o internamente.

El document: “FS.11 - SS7 Interconnect Security Monitoring Guidelines - Version 1.0” (19 November 2015). En su Punto 2.2. Cómo monitorizar:

El objetivo de la monitorización es evaluar si se está produciendo actividad SS7 sospechosa/maliciosa. Cómo lograr esto, variará entre los operadores y las capacidades de cada operador, así como sus objetivos. El esfuerzo de monitoreo puede variar de:

✓ Muestreo de una parte del tráfico de interconexión durante un período de tiempo limitado, buscando problemas conocidos, para determinar si el problema está ocurriendo, o

✓ Monitoreando todo el tráfico de interconexión de forma continua, tanto entrante como saliente, para determinar el alcance máximo del problema y buscando posibles nuevos ataques.



Como se puede apreciar en la imagen anterior, hemos comenzado a “buscar” diferentes tipos de “ocurrencias” dentro de la captura global. En este caso particular, hemos seleccionado del menú “Editar”, la opción “find Packet”.

Una vez seleccionada esta opción, nos aparecerá en la parte superior de Wireshark la barra de “Find”, en ella podemos apreciar en la imagen anterior que se ha decidido buscar el parámetro “ProcessUnstructuredSS” que es uno de los pertenecientes al protocolo “MAP”, a su vez hemos decidido que lo busque como “String” y dentro de la ventana “Packet list” (Podría haber sido también en las ventanas “Packet details o Packet Bytes”).

En la captura anterior, hemos resaltado cómo podemos identificar determinados parámetros que nos pueden ayudar a identificar varias cosas:

Protocolos que se están empleando (Ej: GSM MAP).

Parámetros empleados en esa trama (ProcessUnstructuredSS).

Direcciones origen, destino a cualquier nivel (IP, SCCP, IMSI, TMSI, MSISDN, etc).

Solicitudes y respuestas (Invoke= Request).

Secuencia hexadecimal que circuló por la red.



Etc.

Sobre la base de las capturas realizadas, con “tcpdump” o “Wireshark” podemos ir “exportando” los tipos de capturas que queramos, e ir desmenuzando un alto volumen de tráfico hasta llegar a los flujos que deseemos.

La otra ventaja que nos ofrece trabajar con esta herramienta, es poder identificar los patrones de tráfico que podemos considerar sospechosos (tal cual nos lo indica el “FS.11 - SS7: si se está produciendo actividad SS7 sospechosa/maliciosa.”).

Como apreciamos en la imagen anterior, tenemos toda la información de los patrones que nos hacen referencia todos los documentos de seguridad SS7/Sigtran que hemos presentado, tanto en texto como en hexadecimal.

Iremos avanzando poco a poco con la identificación de estos parámetros, pero para irnos adelantando un poco en el tema, y tal cual acabamos de ver en la imagen anterior, en primer lugar si deseamos comenzar a estudiar los ataques en el orden que presentamos nuestra clasificación de quince de ellos, por ejemplo podemos centrarnos inicialmente en las tramas que contengan protocolo “MAP”, para ello sencillamente colocamos en el filtro de visualización: “gsm_map”.

Como podemos apreciar, hemos filtrado todas las tramas que contienen este protocolo.

Comencemos a aplicar estos conceptos a los casos concretos que nos preocupan, por ejemplo, volvamos a nuestro ataque Nro 1 de la lista de nuestra clasificación (de los 15 de ellos que hemos presentado).

Este ataque: 1. Búsqueda de información sobre celdas-HLR-VLR/MSC Recordemos que en este caso, el análisis inicial del ataque deberíamos centrarlo en encontrar dentro del protocolo MAP el parámetro: anyTimeInterrogation (ATI), pero “solamente cuando el HLR, envía su respuesta hacia “fuera de la



HOME_NET” (no olvidemos que la SOLUCIÓN, justamente es bloquear esta respuesta hacia fuera de la HOME_NET).

Por lo tanto el inicio de nuestro primer análisis podría ser justamente lo que se presenta en la imagen que sigue.

Como podemos apreciar en la imagen anterior:

Hemos colocado un “filtro de visualización” para que sólo nos muestre protocolo “gsm_map”.

Hemos hecho una búsqueda, para que sólo nos presente aquellas tramas “MAP” que contengan el parámetro “anyTimeInterrogation”.

En este caso concreto se trata de una respuesta, que lo podemos apreciar en el campo Component: “returnResultLast”.

Este último parámetro, nos da pie para avanzar y comenzar a presentar lo que poco más adelante ejecutaremos con el IDS “Snort”. Cuando empezamos aprestarle atención a la tercer ventana de Wireshark, esta es la que nos ofrece la información en “hexadecimal”, es decir la traducción primaria de los “bits” que realmente circularon por el canal de comunicación. En el caso del protocolo MAP, podemos identificar que se trata de una respuesta (es decir justamente el parámetro que buscamos “anyTimeInterrogation_resp”), pues tal cual hemos remarcado en rojo, este valor en hexadecimal queda identificado por el valor hexadecimal “a2”. Cuando se trata de un Request (o solicitud) en MAP, esta campo tiene valor hexadecimal “a1”. Estos valores en hexa, veremos más adelante que son fundamentales si se desea trabajar con “Snort”.

Pero tengamos en cuenta que esto sólo podemos catalogarlo como “anómalo” sí y solo sí el “HLR, envía su respuesta hacia fuera de la HOME_NET”, por lo tanto estos filtros que estamos empleando no son suficientes, pues esto no lo vemos en el protocolo “MAP”, sino que debemos bajar a un protocolo de nivel más bajo en nuestra pila. En este caso concreto lo tenemos relativamente fácil pues



contamos con el protocolo SCCP cuyo esquema de direccionamiento presentamos en secciones anteriores y justamente es quien nos puede indicar con total claridad desde quién y hacia quién dirigirá ese tráfico. Este detalle se presenta en la captura que sigue.

En esta captura hemos borrado las direcciones (o teléfonos) pues se trata de tráfico real de una operadora telefónica. nuevamente, hemos resaltado en rojo los parámetros que nos ofrecen información para evaluar este potencial ataque, que en este caso son:

Despliegue de los campos del protocolo SCCP (que es SS7 puro).

Called Party Address: es decir quién está solicitando esta información.

SubSystem Number (SSN): presentado en secciones anteriores, que nos indica claramente de qué elemento se trata. En este caso podemos ver que es un gsmSCF.

Calling Party Address: es decir con quién desea comunicarse.

SubSystem Number (SSN): presentado en secciones anteriores, que nos indica claramente de qué elemento se trata. En este caso podemos ver que el destino es un HLR.

Volviendo al análisis de nuestro ataque Nro 1, recordemos que el “sentido” de estos parámetros es “solamente cuando el HLR, envía su respuesta hacia “fuera de la HOME_NET”, por lo tanto, es evidente que en la captura de tráfico de la imagen previa, es estrictamente al revés (se trata de un SSN=gsmSCF hacia un SSN=HLR), pero aquí tenemos una información que nos será de mucha utilidad:



Podemos aplicar un filtro de visualización, justamente sobre protocolo SCCP e incluir los campos “SSN”.

Veamos cómo hacerlo. PASO 1: En primer lugar, comencemos a quedarnos con los datos que nos

interesan procesar y descartar lo que, en esta caso concreto (ataque Nro 1) no nos interesa. El parámetro que necesitamos estudiar sin lugar a dudas es: “anyTimeInterrogation”, para ello entonces podemos comenzar aplicando un “filtro de visualización”, para que únicamente nos muestre las tramas que contengan este parámetro. Wireshark tiene precargado cientos de protocolos de comunicaciones, y para cada uno de ellos la mayoría de los parámetros que el mismo soporta. En nuestro caso de estudio, el protocolo “gsm_map” posee nada más y nada menos que 2.287 parámetros, y cada uno de ellos a su vez admite “n” cantidad de valores. A continuación presentamos una imagen de cómo configurarlo.

Como podemos ver en la imagen anterior, en la parte superior tenemos esta barra que es justamente para aplicar los “filtros de visualización” (dentro de la ventana blanca se lee: “Apply a display filter”). Si seleccionamos “Expresion” (tal cual se aprecia recuadrado en “rojo”), se despliega la ventana cuya imagen presentamos a continuación, que en nuestro caso fuimos bajando por las diferentes familias de protocolos que Wireshark nos ofrece hasta llegar a “gsm_map”.



Como se puede ver en la imagen anterior, de los 2.287 parámetros, en nuestro caso estamos buscando “anyTimeInterrogation”, que es uno de los valores del verdadero parámetro en sí de MAP que se llama: gsm_old.Value, y que para el valor “anyTimeInterrogation”, se corresponde con el número “71”.

NOTA importante: Recordemos que MAP es uno de nuestros principales protocolos a la hora de las vulnerabilidades “SS7/Sigtran”, por lo tanto movernos dentro del mismo será fundamental para nuestro análisis. En este caso concreto, el parámetro “gsm_old.Value” nos ofrece mucha información, por ejemplo adelantándonos a otros patrones de ataques, dentro de este campo, tenemos también:

gsm_old.localValue == 2 -----------> updateLocation gsm_old.localValue == 3 -----------> cancelLocation gsm_old.localValue == 7 -----------> insertSubscriberData gsm_old.localValue == 8 -----------> deleteSubscriberData



gsm_old.localValue == 19 -----------> ProcessUnstructuredSS-Data gsm_old.localValue == 22 -----------> sendRoutingInfo gsm_old.localValue == 45 -----------> sendRoutingInfoForSM gsm_old.localValue == 60 -----------> ProcessUnstructuredSS-Request gsm_old.localValue == 70 -----------> provideSubscriberInfo gsm_old.localValue == 71 -----------> anyTimeInterrogation gsm_old.localValue == 83 -----------> provideSuscriberLocation

Con estos valores para gsm_map, prácticamente estamos cubriendo todos los patrones de ataques que presentamos en este texto para las redes móviles.

Entonces, hasta ahora hemos logrado aplicar un filtro de visualización para que Wireshark nos muestre únicamente las tramas que contengan el parámetro “anyTimeInterrogation”, ahora la forma más práctica de seguir avanzando es “guardar” esta selección en la que sabemos que podemos seguir analizando específicamente este valor.

Para hacerlo y quedarnos únicamente las tramas que contengan este parámetro podemos realizarlo tal cual se representa en la imagen que sigue.

Como se puede apreciar en la imagen anterior, esta opción es “File” → “Export Specified Packets…” y desde allí seleccionamos el directorio y nombre deseado (en nuestro caso “captura_anyTimeInetrrogation”), y es muy importante que seleccionemos dentro de “packet Range” → “Displayed”, para que nos quedemos únicamente con los paquetes que contengan este parámetro, descartando el resto (podemos ver en la imagen que



quedarán guardados únicamente 507 paquetes de los 435017 originales).

PASO 2: Ahora, trabajando con esta nueva captura guardada, continuaremos

filtrando la búsqueda para que sólo no presente las tramas SCCP que tienen como origen un HLR (tal cual nos indica el ataque Nro 1). Para ello, de la misma forma que trabajamos con el filtro de visualización para “gsm_map”, el protocolo “SCCP” también está precargado y posee otro sinnúmero de opciones de configuración para el filtrado, como podemos ver en la imagen siguiente.

Una vez más, hemos remarcado en “rojo” los parámetros que nos interesan para seguir evaluando el ataque Nro 1. En este caso, tal cual venimos comentando, nos interesa identificar concretamente cuando “desde” un HLR se envió este parámetro, por lo tanto, tal cual se aprecia en la imagen anterior, debemos seleccionar “sccp.called.ssn == 6” que es el SubSystem Number (de SCCP) que identifica un HLR. Otra NOTA importante: Al igual que MAP, en este caso es muy probable que en nuestros posteriores análisis también tengamos que identificar otro tipo de elementos o protocolos de la red SS7/Sigtran. Es aquí donde debemos buscarlos y a continuación presentamos una lista de los principales para nuestro trabajo (los valores que siguen son para “sccp.calling.ssn” pero son idénticos si los deseamos aplicar para “sccp.called.ssn”).



Filtros para sccp: sccp.calling.nai == 0x4 (International Number) sccp.calling.ssn == 3 (ISUP) sccp.calling.ssn == 5 (MAP) sccp.calling.ssn == 6 (HLR) sccp.calling.ssn == 7 (VLR) sccp.calling.ssn == 8 (MSC) sccp.calling.ssn == 9 (EIC/EIR) sccp.calling.ssn == 10 (AuC) sccp.calling.ssn == 145 (GMLC MAP) sccp.calling.ssn == 146 (CAP) sccp.calling.ssn == 147 (gsmSCF (MAP) or IM-SSF (MAP) or Presence Network Agent) sccp.calling.ssn == 149 SGSN (MAP) sccp.calling.ssn == 150 GGSN (MAP) sccp.calling.ssn == 250 BSC (BSSAP-LE) sccp.calling.ssn == 251 MSC (BSSAP-LE)

En definitiva, el filtro que nos interesaría aplicar sería una “concatenación” de lo que venimos presentando, que concretamente quedaría como:

(gsm_old.localValue == 71) and (sccp.calling.ssn == 6)

En la imagen que sigue podemos verlo gráficamente.

Como podemos apreciar, luego de aplicar este filtro no se nos ha mostrado NINGUNA trama, por lo tanto esto implica que de la “muestra” de tramas evaluadas NO HA EXISTIDO el ataque Nro 1, pues ningún HLR ha enviado el parámetro “anyTimeInterrogation”, en nuestro caso hacia ningún tipo de destino.

Más detalle sobre SCCP.

Como estuvimos presentando, otro protocolo que controla Wireshark es “SCCP” que, para nosotros, tal cual mencionamos al principio de todo, es muy importante, pues por ejemplo como acabamos de ver, nos permite identificar las “calling y called part” que son los verdaderos orígenes y destinos de las llamadas en SS7 puro. De esta forma podemos identificar llamadas que provienen desde el exterior, por ejemplo con el siguiente filtro de visualización:

sccp.calling.digits matches 34 and not sccp.called.digits matches 34



En el filtro anterior, le estaríamos indicando concretamente a Wireshark que nos muestre todas las tramas cuyo origen sea fuera de España (34) y cuyo destino fuera en España, pero lo importante es que se lo decimos a nivel SCCP, es decir por debajo de Sigtran, por lo tanto se tratarán de los verdaderos dispositivos de la red SS7 pura que establecen este diálogo.

Hemos querido recalcar este parámetro, pues como ya se habrá notado, venimos haciendo mucho hincapié en el concepto de “Home_Net” y “External_Net”. Estos dos conceptos son fundamentales para cualquier área que opere los “nodos” de la red SS7, pues como cualquiera puede fácilmente deducir, si no se sabe qué trama se corresponde a un origen y/o destino de “mi” arquitectura SS7 y cuál a uno “ajeno” a la misma, pues poco podré evaluar la ocurrencia de una ataque o no.

Esto que parece excesivamente trivial, en la realidad del día a día no es tan así, pues no olvidemos que estas arquitecturas nacieron en los 80’ como algo cerrado y así fueron creciendo bajo estos conceptos. Los operadores de estas redes, suelen ser personas que llevan muchos años en el área y es muy complicado romper esta “inercia de pensamiento”. Con muchísima más frecuencia de la que creemos, nos vamos a encontrar, que no hay mapas de red, no hay inventarios claros, ni ubicaciones, ni esquemas de direccionamiento IP unívocos, etc. Con esto, ya tendríamos bastante problema, pero a su vez hay otro peor.

En muchas de las arquitecturas SS7, se emplea NAT (Network Address Translation), por lo tanto, si queremos buscar patrones de tráfico “internos” (Home_Net) y/o “externos” (External_Net) a través del direccionamiento IP, en estos casos TODAS las tramas tendrán una dirección IP privada (fuente o destino) dentro de este rango, haciendo prácticamente imposible saber a nivel de red, es decir por su dirección IP, si esa trama viene o va hacia fuera de nuestra arquitectura (o Home_Net).

En algunos casos (casi podríamos llamar “privilegiados”), el “punto de entrada” a la Home_Net es uno solo (por ejemplo un STP), ante lo cual, se puede inferir que si una trama proviene del exterior (External_Net) lo hará desde esa única dirección IP, pero reiteramos, esta que debería ser una situación NORMAL desde el punto de vista de la seguridad de una red SS7/Sigran, es una situación casi “privilegiada” pues no es normal que esto ocurra.

En cualquiera de las situaciones expuestas, tenemos como aliado al protocolos SCCP, por medio del cual podemos encontrar una salida airosa al análisis de estas tramas.

En las imágenes que siguen, podemos apreciar por medio el análisis y filtrado de estos parámetros. En primer lugar veamos el encapsulado de SS7 en Sigtran y prestemos atención a “SCCP” (Signaling Connection Control Part).



En la imagen que sigue, desplegamos los campos de la parte llamante y llamada a través de una trama que proviene de un VLR de Brasil (Called part), hacia un HLR (calling part) de otro País (que ocultaremos intencionadamente).

Todos estos campos y nodos origen y destino, podemos filtrarlos perfectamente con “Wireshark” a través de los filtros de visualización que presentamos recientemente en la:

Otra NOTA importante:………... Filtros para sccp:

sccp.calling.nai == 0x4 (International Number) sccp.calling.ssn == 3 (ISUP) ………



Resumen de esta sección.

Hemos presentado inicialmente la importancia que tiene el hecho de estar en capacidad de “analizar tráfico” SS7/Sigtran, pues se trata de los flujos de información que circulan por nuestra red de señalización, por lo tanto obligatoriamente por allí pasarán, o no, los ataques a la misma.

Comenzamos a trabajar con la herramienta “Wireshark” para este tipo de análisis, pero siempre tomando como referencia los patrones de un ataque real, que en nuestro caso lo hemos hecho sobre la base de esta clasificación propia a través del que habíamos presentado como “ataque Nro 1”.

Abordamos secuencialmente cada una de las acciones y pasos que podemos ir realizando para “desmenuzar”, filtrar y obtener resultados concretos sobre estos parámetros y flujos de ataque, hasta llegar a verificar que este primer ataque NO se encontraba en nuestra “muestra” de tráfico.

Esta última conclusión, no podemos dejarla pasar por alto. En primer lugar porque es una evidencia irrefutable, pero en segundo lugar porque no podemos confiarnos en ella, pues es sólo una “muestra”, lo que nos debe llevar a la conclusión que tenemos otra tarea adicional que es perfeccionar, ajustar, maximizar u optimizar las muestras que tomamos, en cuanto a los segmentos de escucha, los “filtros de captura” (que no hemos desarrollado aquí pero que son bastante sencillos de aplicar, tanto con wireshark, tshark o tcpdump), los horarios que lo hacemos, las direcciones IP, etc… este es un muy buen desafío a encarar, pero ya depende de cada red particular de señalización.

Por último, dejar el mensaje y la enseñanza que este mismo proceder, podemos aplicarlo de la misma forma al resto de los patrones y/o parámetros de ataque que venimos presentando. En esta sección finalizamos con este primer ataque, pues como comúnmente se dice “para muestra basta un botón”.



6. Análisis de capturas de tráfico empleando Snort.

Una vez presentado el trabajo inicial que podemos ir realizando con Wireshark, pasemos al empleo de la segunda herramienta “Snort”.

Nuestro consejo, tal cual lo expresamos en la sección 5. de este documento, es que trabajéis con una “máquina virtual” e instalando en la misma un sistema operativo Linux, de ser posible con la distribución “Debian” de “Kali”.

Una vez instalado la interfaz gráfica es la que estamos viendo a la izquierda.

Por nuestra parte, en el caso del trabajo con Snort, nos resulta práctico, tener abiertas dos consolas. Otro aspecto es que “Snort” no viene instalado en “Kali” por lo que debemos instalarlo con el comando “apt-get install snort”, como se puede ver en esta imagen.

La propuesta de trabajo con dos consolas, como iremos viendo más adelante, nos facilita poder ir

ejecutando “Snort” y viendo sus resultados simultáneamente. Para ello, nos resulta cómodo estar posicionado en la ventana superior sobre la ruta donde tenemos las configuraciones y reglas y en la ventana inferior, la ruta hacia donde decidamos enviar las “salidas”, en nuestro caso, tal cual se aprecia en esta imagen, el directorio de trabajo será: “/var/tmp/snort” y el de las salidas: “/var/log/snort”, tal cual lo vemos en esta imagen.

En nuestro caso, llevamos ya veinte años trabajando con este espectacular IDS y, en virtud de la enorme potencia que ofrece, recomendamos que si el lector decide hacer uso del mismo, lo haga a consciencia y para ello, recurra a la mejor fuente de información que se encuentra suficientemente completa y actualizada en su web de origen y en particular en su manual “Snort Users Manual”, que lo podemos descargar en: https://www.snort.org/documents

https://www.snort.org/documents



Este IDS/IPS (Intrusion Detection/Prevention System) de código abierto, nos ofrece la posibilidad de trabajar “On Line” y también “Off Line”, por lo tanto, podemos elegir la metodología que mejor se ajuste a nuestra operación.

Desde el punto de vista de la sencillez en nuestro caso, tal vez la mejor opción sea trabajar “Off Line” (por supuesto, que si contamos con la posibilidad de instalarlo como sonda en algún segmento de la red SS7/Sigtran y “espejar” tráfico hacia ella, o colocarla con un “Splitter” es otra posibilidad “On Line”, y hasta mucho mejor opción). En el caso de operarla “Off Line”, podemos solicitar los diferentes tipos de “capturas de tráfico” que nos hagan falta, por ejemplo:

Por zonas.

Por direcciones IP.

Por tipo de elemento (STP, MSC, HLR, etc.).

Por interfaz (externa, interna, servicio, etc.).

Siempre considerando que debemos ser estrictos en poner de manifiesto que esta actividad es básica y fundamental en una red SS7 (y todo operador de estos nodos “DEBE” estar en capacidad de realizar estas capturas, tal cual indican las normas internacionales).

Para avanzar con este texto, vamos a presentar una forma de trabajo “Off Line” sobre la base de capturas de tráfico tomadas en un segmento de SS7/Sigtran.

No vamos a desarrollar un curso de Snort, solamente presentaremos los conceptos básicos para comprender esta propuesta de trabajo. Damos por sentado que ya lo tenemos funcionando nuestra máquina virtual “Kali” por lo tanto, nos centraremos en tres conceptos:

Archivo de configuración.

SS7.rules

Salidas

6.1. El Archivo de configuración.

Dentro de las muchas opciones que nos ofrece Snort, una de ellas es justamente poder emplearlo como “IDS”, para ello, el primer paso es poder ejecutarlo llamando a su fichero de configuración, como iremos viendo en este punto, concretamente esto se realiza con la opción “-c” indicando dónde se encuentra este fichero.

El fichero de configuración, cuando se instala Snort ya nos trae un modelo pre configurado (snort.conf) que podemos emplearlo casi de inmediato con algún pequeño ajuste. En nuestro caso de las muchísimas opciones que ofrece, como veremos de inmediato, sólo nos interesan aspectos muy básicos. Este fichero de configuración consiste en cuatro componentes básicos:

El Sniffer.

Los preprocesadores.



El motor de detección.

Las salidas.

Como ya mencionamos, no entraremos en el detalle de este fichero, pues no se trata aquí de un curso de Snort, sólo nos centraremos en los detalles que necesitamos específicamente para nuestro trabajo.

Si se desea profundizar un poco más metodológicamente sobre este software, tenemos un artículo publicado en nuestra Web (www.darFe.es), en la Sección:

"Descargas" → "Tecnologías de la Información" → "Seguridad"

Que podemos acceder mediante la siguiente URL:

http://www.darfe.es/joomla/index.php/descargas/viewdownload/5-seguridad/45-metodologia-nessus-snort

Pensando en analizar anomalías de tráfico SS7/Sigtran, debemos tener presentes nuevamente nuestra clasificación de los “15 tipos de ataques”. Recordemos que en todos ellos era necesario identificar con total certeza el origen y destino de las tramas, pues no olvidemos que un parámetro cualquiera, por ejemplo: anyTimeInterrogation (ATI), podemos catalogarlo como potencial ataque “solamente cuando el HLR, envía su respuesta hacia “fuera de la HOME_NET”.

Bajo esta idea entonces, un punto de partida para la configuración de nuestro IDS, es poder indicarle con la mayor precisión posible, todos los elementos que son “HLRs”, “MSCs”, “SMS-Cs”, etc.

Esta configuración forma parte de la primera sección de “snort.conf” y se lo hace definiendo cuáles son las “variables” que vamos a utilizar. En nuestro caso son justamente las direcciones IP de cada uno de los dispositivos que conforman nuestra arquitectura SS7/Sigtan.

A continuación presentamos una serie de ejemplos sobre cómo podría ser esta sección de nuestro fichero “snort.conf”.

# Setup the network addresses you are protecting ipvar HOME_NET 10.2.16.64/26,10.2.17.128/25,10.2.19.192/29,10.2.19.200/29,10.2.19.64/29,172.30.16.128/28,172.30.16.160/28,172.31.10.128/28,172.31.4.0/24,172.31.22.160/28

ipvar EXTERNAL_NET any (o también podemos poner !HOME_NET)

#var SS7 (es sólo nuestro comentario para aclarar que se trata de SS7) ipvar MSC 10.3.1.0/27,10.4.1.0/27,10.5.1.0/27 ipvar HLR-HSS 10.30.1.0/27,10.31.1.0/26 ipvar SMS-C 172.17.31.10/32,172.17.31.11/32,172.17.31.12/32 ipvar GW 172.17.33.10/32,172.33.12/32

http://www.darfe.es/





portvar STP_ports 2905:2913

var RULE_PATH /var/tmp/snort (es el PATH que nosotros hemos elegido para las reglas que diseñaremos sobre SS7)

6.2. Salidas

La segunda sección del fichero “snort.conf” que nos interesa definir adecuadamente es la de “Salidas”. A continuación presentamos una serie de ejemplos sobre cómo podría ser esta sección, pues Snort soporta varios tipos de ellas.

output alert_csv: alert.csv (Si deseamos obtener salidas que luego nos faciliten su explotación, por ejemplo, por medio de plantillas de cálculo).

output log_null (Salida estándar en formato “Log”, o no)

output log_tcpdump: SMS.cap (Salida estándar en formato “tcpdump”)

# Salida en formato "pcap" para Ataque 1 detectado

(Podemos definir nuestro propio formato de Salida sobre la base de una determinada regla, se verá con más claridad luego que presentemos las “reglas de Snort”).

ruletype provideSubscriberInfo_resp {

type alert

output log_tcpdump: Atq1-provideSubscriberInfo_resp.cap

}


ruletype provideSubscriberLocation_resp {

type alert

output log_tcpdump: Atq2-provideSubscriberLocation_resp.cap

}

# Salida en formato "pcap" para Ataque 3A detectado

ruletype insertSubscriberData_req {

type alert

output log_tcpdump: Atq3A-insertSubscriberData_req.cap

}



# Salida en formato "pcap" para Ataque 3B detectado

ruletype DeleteSubscriberData_req {

type alert

output log_tcpdump: Atq3B-DeleteSubscriberData_req.cap

}

# Salida en formato "pcap" para Ataque 3C detectado

ruletype cancelLocation_req {

type alert

output log_tcpdump: Atq3C-cancelLocation_req.cap

}

Por último, debemos indicarle dónde deberá ir a buscar las reglas que nosotros definamos para SS7 (que se desarrollará en el punto siguiente).

include $RULE_PATH/ss7.rules

6.3. Las SS7.rules.

Al instalar Snort, trae cientos (o miles) de reglas clasificadas por familias, las cuáles en el uso estándar de esta herramienta, siempre se aconseja que se mantengan actualizadas, pues diariamente se van publicando y ajustando nuevas reglas.

En nuestro caso, la tarea es diferente, pues no nos interesa para nada analizar las reglas para “http”, “telnet”, “ssh”, etc. Nosotros debemos centrarnos específicamente en SS7/Sigtran. Para ello Snort, con su potente flexibilidad y parametrización, nos ofrece la posibilidad de crear nuestras propias reglas personalizadas a lo que deseemos y según nuestra opinión, esta tal vez sea una de las más grandes cualidades que posee este software. En esta sección especialmente recomendamos un detallado estudio del “Snort Users Manual” pues es casi infinita la cantidad de posibilidades que nos ofrece.

Antes de entrar de lleno en estas reglas, es importante que volvamos un poco atrás, sobre los temas ya vistos con Wireshark y, manteniendo nuestra coherencia respecto a la secuencia de análisis, retomemos el “ataque Nro 1” sobre el parámetro “antTimeInterrogation (ATI)”.



Cuando comenzamos con este parámetro, justamente presentamos la imagen anterior e hicimos hincapié en ese valor hexadecimal “a2”que está remarcado en rojo en la parte inferior de la captura (es decir en la ventana inferior, de valores “hexadecimales” de Wireshark). En esa ocasión mencionamos que cuando la trama a nivel “gsm_map” es un “request” (invoke) este valor se corresponde con “a1” y cuando es un “response” (returnResultLast), se corresponde con “a2” (como en la imagen).

A su vez, también en la imagen anterior, podemos apreciar que hemos remarcado igualmente en rojo, y en la misma ventana inferior, TODOS los valores en hexadecimal. Esto lo hemos hecho, pues en virtud del estudio de los mismos será nuestro punto de partida para el diseño de nuestras propias reglas SS7, que es lo siguiente a tratar.

A continuación presentamos algunos ejemplos más, para ir desarrollando hacia dónde queremos llegar.

Siguiendo con los parámetros que son motivos de ataques, según



presentamos en el punto 5. En la imagen anterior, podemos apreciar que estamos aplicando un “filtro de visualización” para que sólo nos presente el parámetro MAP: “providerSubscriberInfo”, tal cual mencionamos en el párrafo previo, en este caso se trata de un “Invoke”, es decir “request” y por ende su valor inicial es “a2” (todo esto lo hemos remarcado en rojo).

Si queremos analizar lo mismo, pero para un “providerSubscriberInfo response” podemos apreciarlo en la imagen siguiente.

Independientemente de este primer valor “a1” o “a2” del protocolo “gsm_map” avancemos un poco más prestando atención al resto de los valores hexadecimales (que reiteramos, son la representación más cercana y a bajo nivel de los “bits” que verdaderamente circularon por esa infraestructura de red).

Para reafirmar este último concepto vamos a presentar una imagen más, pero esta vez sobre otro de los parámetros motivos de nuestro listado de ataques, en la siguiente imagen, podemos ver una trama que contiene “sendRoutingInfo response”.



Nuevamente sobre la imagen anterior, prestemos atención a los valores hexadecimales de la ventana inferior que hemos remarcado en rojo.

Si analizamos de esta forma cada uno de los parámetros que nos interesa analizar, podremos ir creando los “patrones de tráfico hexadecimal” que identifican unívocamente la ocurrencia de este parámetro. Es decir, estaremos trabajando al más bajo nivel del modelo de capas, con lo cual no existe NADA que se nos pueda pasar por alto, pues cualquier otro tipo de análisis por medio de los diferentes protocolos, estará siempre “empaquetado” en niveles superiores a este que estamos “mirando” nosotros.

El dominio de la información que circula a nivel de “bits” nos abre el juego a cualquier tipo de “detección”, y ahora sí que podemos empezar a crear las reglas que deseemos con Snort.

A continuación, presentamos algunos de los parámetros que hemos llegado a identificar con un alto grado de certeza.

Del trabajo realizado hasta ahora, podemos presentar los siguientes “patrones de tráfico hexadecimal”:

a2 ** 02 01 01 30 2c 02 01 47 30 27 (MAP anyTimeinterrogation)

-----> Component: returnResultLast

NOTA: Estas asociaciones, son el enfoque inicial de varias horas de estudio, pero no pretenden ser 100% exactas, ni mucho menos completas (Hacen falta aún cientos de horas de trabajo).

Una de las líneas futuras de investigación a la que nos encantaría que los lectores se sumen, es justamente esta:

de patrones de tráfico

Creación y ajuste de nuevas reglas ss7/Sigtran (ss7.rules)



(MAP anyTimeinterrogation) NO tenemos capturas a2 ** 02 01 01 30 ** 02 01 46 30 (MAP provideSubscriberInfo)


a1 ** 02 01 01 02 01 46 30 10 80 (MAP provideSubscriberInfo)

-----> Component: invoke

02 01 01 02 01 2e 30 48 84 (MAP mo-forwardSM) a1 ** 8b 02 01 00 02 01 2c (MAP mt-forwardSM) a1 6a 02 01 01 02 01 16 30 62 (MAP sendRoutingInfo) a1 ** 02 01 01 02 01 2d 30 15 (MAP sendRoutingInfoForSM)


a2 ** 02 01 01 30 1a 02 01 2d 30 15 (MAP sendRoutingInfoForSM)


a2 ** 02 01 01 30 0e 02 01 02 30 09 04 07 (MAP updateLocation)


a1 ** 02 01 01 02 01 02 30 26 04 08 (MAP updateLocation)

-----> Component: invoke (invokeID: 1)

a1 ** 02 01 01 02 01 07 30 (MAP InsertSubscriberData)






a2 ** 02 01 01 30 25 02 01 07 30 (MAP InsertSubscriberData)

-----> Component: returnResultLast (InvokeID: 1)

a2 ** 02 01 02 30 09 02 01 07 30 (MAP InsertSubscriberData)

-----> Component: returnResultLast (InvokeID: 2) a2 0e 02 01 05 30 09 02 01 07 30 (MAP InsertSubscriberData)

-----> Component: returnResultLast (InvokeID:5) a1 ** 02 01 01 02 01 08 30 (MAP deleteSubscriberData)

-----> Component: invoke (invokeID: 1) a1 ** 02 01 01 02 01 03 a3 0d (MAP cancelLocation)

-----> Component: invoke (invokeID: 1) (cancelLocation) a1 .{2,4} 02 01 00 02 01 00 30 (CAMEL-v2 o MAP initialDP)



-----> Component: invoke (invokeID: 1) (cancelLocation (3))

Con el reconocimiento de estos valores hexadecimales, podemos comenzar con la creación de nuestras propias reglas de detección para Snort, las cuales las llamaremos “ss7.rules” (tal cual hemos presentado en nuestro modelo de fichero de configuración: “snort.conf”).

No entraremos en explicaciones de cómo son las reglas de Snort (nuevamente aconsejamos la lectura del “Snort Users Manual”), sólo mencionamos que una regla de Snort debe tener un “encabezado”(parte previa a los paréntesis) y un “cuerpo” (encerrado entre paréntesis).

Comencemos a “crear” nuevas reglas.

Ejemplo 1:

Vamos a aplicar uno de los patrones en hexadecimal que acabamos de presentar, por ejemplo:

a1 6a 02 01 01 02 01 16 30 62 (MAP sendRoutingInfo)

Si quisiéramos iniciar con una regla que pueda detectar la ocurrencia de estos patrones en hexadecimal, podríamos empezar por:

alert ip any any -> any any (msg:"MAP - sendRoutingInfo"; content:"|a16a020101020116|"; priority:1; sid:1000001; rev:1;)

¿Qué le estamos diciendo aquí?

1) Que genere una alerta: alert 2) Para todo lo que siga al protocolo ip: ip 3) Cuyo origen sea cualquier ip/red: any 4) Cuyo origen sea cualquier puerto: any 5) Que solo vaya en un sentido “->” (aunque en este caso no tenga

lógica, pues todo “any”) 6) Cuyo destino sea cualquier ip/red: any 7) Cuyo destino sea cualquier puerto: any 8) Que si existiera alguna ocurrencia, es decir si aplicara esta regla a

alguna trama, nos genere un mensaje cuyo contenido sea: MAP – sendRoutingInfo

9) Que la regla “salte” únicamente cuando encuentre esta secuencia en hexadecimal: content:"|a16a020101020116|".

10) Que le dé máxima prioridad: priority:1 11) Que el identificador de esta regla sea: sid:1000001 (Snort aconseja

que cuando se crean reglas locales, empleemos un ID superior a 1.000.000) 12) Que es la primera revisión de la misma: rev:1

Por supuesto que estamos presentando una regla extremadamente básica para poder empezar.

Ejemplo 2:

Para mejorarla un poco, podríamos empezar a ajustar su diseño, por



ejemplo con alguno de sus “any”.

Si retomamos el tema de nuestros ataques, por ejemplo el ataque Nro 2. Location Services (LCS) (empleo de la Localización de emergencia).

Nuevamente sobre MAP, se realizan dos pasos:

a. El intruso envía sendRoutinginfoForSM request (al HLR), el cual responde con sendRoutinginfoForSM response

En este caso concreto, vemos que este parámetro podemos comenzar a analizarlo en su “request” y su “response”. Una propuesta puede ser evaluar si tenemos en nuestras capturas de tráfico alguna trama de Respuesta, inicialmente que contenga “sendRoutinginfo”.

Ante esta hipótesis, es evidente que debe enviarla el HLR hacia una “External Net”, para ajustar esta configuración sobre la regla anterior, podemos entonces hacerlo de la siguiente forma:

alert ip $HLR-HSS any -> !$HOME_NET any (msg:"MAP - sendRoutingInfo"; content:"|a16a020101020116|"; priority:1; sid:1000001; rev:1;)

¿Qué le estamos diciendo ahora?

1) Que sólo se active esta regla cuando la IP/red coincida con la variable que hemos definido en el punto anterior (dentro de nuestro ejemplo del fichero “snort.conf”) como var HLR-HSS, y por eso la invocamos con el signo “$” por delante: $HLR-HSS

2) Que sólo se active esta regla cuando la IP/red, NO coincida (“!”) con la variable que hemos definido en el punto anterior (dentro de nuestro ejemplo del fichero “snort.conf”) como var HOME_NET: !$HOME_NET

Ejemplo 3:

Si seguimos prestando atención al ataque Nro 2 presentado en el ejemplo anterior, veremos que en realidad, no estamos buscando el parámetro “sendRoutinginfo”, sino que debemos ser más precisos aún y buscar “sendRoutingInfoForSM” (SM viene por “Short Messages”), si volvemos a los “patrones hexadecimales” que presentamos anteriormente podemos ver lo siguiente (para request y response):

a1 ** 02 01 01 02 01 2d 30 15 (MAP sendRoutingInfoForSM)


a2 ** 02 01 01 30 1a 02 01 2d 30 15 (MAP sendRoutingInfoForSM)


Cuando representamos (en nuestro texto) un valor hexadecimal con “**”



intentamos reflejar que este par hexadecimal puede adoptar cualquier valor, pues así lo hemos comprobado en el estudio de varias ocurrencias de este parámetro.

En el cuerpo de una regla de Snort, si trabajamos con valores hexadecimales “puros”, estos deben ir encerrados entre barras verticales “ | ….. |” y los mismos NO soportan el “comodín” “**”.

Afortunadamente esta maravillosa herramienta nos ofrece una solución, el empleo de expresiones “pcre” (Perl Compatible Regular Expressions).

Por lo tanto, siguiendo con nuestro ajuste de regla, esta puede ahora quedarnos como:

alert ip $HLR-HSS any -> !$HOME_NET any (msg:"MAP - sendRoutingInfo"; pcre:"/\xa2.{1}\x02\x01\x01\x30\x1a\x02\x01\x2d/"; priority:1; sid:1000001; rev:1;)


Que en vez de analizar un “content” específico, aplique una expresión “pcre” con valores hexadecimales: “\x” y que, luego del valor “a2” considere un y sólo un “carácter ASCII” representado por un par de números hexa “.{1}” (si hubiéramos querido exactamente dos, deberíamos haber puesto “.{2}”, si fuera cualquier valor entre 1 a 5 caracteres: “.{1-5}” etc).

Ejemplo 4:

Para no seguir alargando más cada uno de los aspectos a considerar en cuanta a creación de reglas de Snort (cuestión que insistimos debería estudiarse seriamente desde el “Snort Users Manual”), pasemos a analizar ya con más profundidad las reglas reales sobre las que estamos trabajando sobre tráfico SS7/Sigtran.

# Categoria de Ataque 1: un HLR responde a EXT_NET con "provideSubscriberInfo resp"

# La primera regla comentada "#" permite verificar que exista o no trafico "provideSubscriberInfo_resp"

# si hace falta verificarlo, se debe quitar el comentario "#"

# La segunda regla (sin comentar) es la que detecta la ocurrencia de este ataque 1

#provideSubscriberInfo_resp ip any any -> any any (msg: "MAP - provideSubscriberInfo_resp - Ataque Nro 1""; pcre:"/\xa2.{1}\x02\x01\x01\x30.{1}\x02\x01\x46\x30/"; sid:1000010;)

provideSubscriberInfo_resp ip $HLR-HSS any -> !$HOME_NET any (msg: "MAP - provideSubscriberInfo_resp - Ataque Nro



1"; pcre:"/\xa2.{1}\x02\x01\x01\x30.{1}\x02\x01\x46\x30/"; sid:1000011;)


Como podemos apreciar, ya estamos creando reglas que guardan relación con nuestro estudio y presentación de las quince categorías de ataques. En este caso estamos generando un mensaje claro: msg: "MAP - provideSubscriberInfo_resp - Ataque Nro 1".

Pero el aspecto que queremos destacar es que esta nueva regla ya no empieza con “alert” como los ejemplos anteriores, esta vez su primer palabra es “provideSubscriberInfo_resp”.

Si volvemos atrás, cuando presentamos el fichero de configuración “snort.conf”, en la sección de “salidas”, al final de ella, comentamos que las mismas se pueden “personalizar” y concretamente en nuestro fichero “snort.conf” de ejemplo expusimos la siguiente salida:


(Podemos definir nuestro propio formato de Salida sobre la base de una determinada regla, se verá con más claridad luego que presentemos las “reglas de Snort”).

ruletype provideSubscriberInfo_resp {

type alert

output log_tcpdump: Atq1-provideSubscriberInfo_resp.cap

}

En este Ejemplo 4, estamos justamente, relacionando esta regla con una salida específica que nosotros mismos hemos creado y denominado “provideSubscriberInfo_resp”, que deseamos que la misma se comporte como “tipo alert”: type alert y que su salida sea en formato “log_tcpdump” (es decir “.cap”) y con el nombre: Atq1-

provideSubscriberInfo_resp.cap.

Ejemplo 5:

Presentamos a continuación otras reglas más que responden al mismo formato anterior y que son las que estamos empleando en redes SS7/Sigtran en producción con muy buenos resultados.

# Categoria de Ataque 2: un MSC responde a EXT_NET con

"provideSubscriberLocation resp"

# Para este ataque no hemos conseguido aun ninguna captura de trafico que contenga este parametro



# Categoria de Ataque 3 (DoS): desde EXT_NET hacia MSC con cualquiera de los siguietes parametros "insertSubscriberData req", "DeleteSubscriberData req" o "cancelLocation req"

# En todos los casos, la primera regla comentada "#" permite verificar que exista trafico "provideSubscriberInfo resp"

# si hace falta verificarlo, se debe quitar el comentario "#"

# La segunda regla (sin comentar) es la que detecta la ocurrencia de este ataque 1

# insertSubscriberData_req ip any any -> any any (msg: "MAP - insertSubscriberData_req - Ataque Nro 3A"; pcre:"/\xa1.{1}\x02\x01.{1}\x02\x01\x70\x30/"; sid:1000031;)

insertSubscriberData_req ip !$HOME_NET any -> $MSC any (msg: "MAP - insertSubscriberData_req - Ataque Nro 3A"; pcre:"/\xa1.{1}\x02\x01.{1}\x02\x01\x70\x30/"; sid:1000032;)

# DeleteSubscriberData_req ip any any -> any any (msg: "MAP - DeleteSubscriberData_req - Ataque Nro 3B"; pcre:"/\xa1.{1}\x02\x01\x01\x02\x01\x08\x30/"; sid:1000033;)

DeleteSubscriberData_req ip !$HOME_NET any -> $MSC any (msg: "MAP - DeleteSubscriberData_req - Ataque Nro 3B"; pcre:"/\xa1.{1}\x02\x01\x01\x02\x01\x08\x30/"; sid:1000034;)

#cancelLocation_req ip any any -> any any (msg: "MAP - cancelLocation_req - Ataque Nro 3C"; pcre:"/\xa1.{1}\x02\x01\x01\x02\x01\x03\xa3/"; sid:1000035;)

cancelLocation_req ip !$HOME_NET any -> $MSC any (msg: "MAP - cancelLocation_req - Ataque Nro 3C"; pcre:"/\xa1.{1}\x02\x01\x01\x02\x01\x03\xa3/"; sid:1000035;)

Por último, para no extendernos más, presentamos cómo se puede lanzar Snort para hacer uso de este ejemplo de configuración “snort.conf” y las “ss7.rules” que acabamos de presentar.



El formato para lanzarlo desde una consola sería:

# snort -c snort.conf -r captura_a_emplear.pcap

A continuación presentamos una captura de pantalla de nuestra máquina virtual “Kali” donde se puede apreciar la ejecución y los resultados de la misma.

Como podemos apreciar en la imagen anterior, en la consola superior de la misma, se presenta el comando concreto que se acaba de ejecutar, y en la ventana inferior los resultados de las salidas con el formato que nosotros hemos decidido asignarle.

En esta ventana inferior, se puede ver claramente que se ha generado el fichero “alert” vacío (por nuestra configuración de log_null), y a continuación, cada una de las salidas en formato “.cap” de los tres ataques cuyas reglas acabamos de presentar.

Los que poseen un tamaño de 24 bytes, solo contienen el título, es decir están vacíos (no se ha encontrado este patrón de ataque), pero concretamente los ficheros:

Atq1-provideSubscriberInfo_resp.cap

Atq3C-canelLocation_req.cap

Estos dos sí tienen tramas que han sido almacenadas por cumplir con nuestro patrón de búsqueda.



No podemos afirmar que no existan falsos positivos, pero sí es cierto que tenemos ahora una serie mínima de tramas de las 435.017 de nuestro fichero de trabajo inicial sobre el que ensamblamos todas las “pequeñas capturas iniciales” (capturas_completas.pcap) de 161,7 MB de tamaño.

Concretamente, si abrimos con Wireshark, ambos resultados del lanzamiento de Snort en la máquina virtual, las tramas generadas luego de aplicarle nuestras ss7.rules son:

Como el título de la imagen anterior lo indica, se trata del resultado final sobre el Ataque Nro 1, y contiene solamente dos tramas.

Como el título de la imagen anterior lo indica, se trata del resultado final sobre el Ataque Nro 3C, y contiene solamente cinco tramas.



7. Otras herramientas adicionales.

A Continuación presentamos algunas herramientas que nos han sido útiles en este trabajo.

7.1. MATE (Meta Analysis and Tracing Engine) para Wireshark.

MATE es un plugin de Wireshark que extrae datos del árbol de tramas y luego, usando esa información, intenta agrupar las mismas en función de cómo se haya configurado este módulo. El lenguaje que emplea es el "canónico" del modelo de capas, llamando "PDU" (Unidad de datos de Protocolo) a los conjuntos de información de cada nivel a tratar, generando un "árbol" de PDUs con los campos que hayamos filtrado, ofreciendo bastantes opciones que nos pueden ser de utilidad.

Toda la información que nos hace falta sobre MATE la podemos encontrar en:

https://wiki.wireshark.org/Mate

Concretamente MATE, se basa en un fichero en el que podemos configurar de forma sencilla los diferentes campos que nos interesa agrupar de las tramas de cualquier tipo de capturas.

En la URL que figura arriba, dentro de la documentación que nos ofrece, nos presenta un ejemplo de fichero denominado “tcp.mate”, el cual podemos ver a a continuación.

Pdu tcp_pdu Proto tcp Transport ip { Extract addr From ip.addr; Extract port From tcp.port; Extract tcp_start From tcp.flags.syn; Extract tcp_stop From tcp.flags.reset; Extract tcp_stop From tcp.flags.fin; }; Gop tcp_ses On tcp_pdu Match (addr, addr, port, port) { Start (tcp_start=1); Stop (tcp_stop=1); }; Done;

En el mismo, se está generando una nueva “PDU” cuyo nombre es “tcp_pdu” que trabajará sobre el protocolo “TCP” e interpretará todo que se “transporte” por arriba del protocolo “IP”, desde allí solicita “extraer” los campos “ip-addr”, “tcp.port”, “tcp.flags.syn”, etc. Y luego los “agrupa” por medio de un “Grupo de Pdu (Gop)” llamado “tcp.ses”. Nuevamente no es nuestra intención desarrollar un curso sobre MATE

https://wiki.wireshark.org/Mate



(por favor, si deseáis profundizar en ella, tenéis toda la documentación en la URL que se indicó al principio). En estas líneas, solamente deseamos presentar la misma, poner algún ejemplo de cómo la hemos empleado, y sobre todo despertar el interés del lector sobre la misma.

En nuestro caso por ejemplo deseamos trabajar con el protocolo “SCCP” y “GSM_MAP”, para ello, entonces debemos generar nuestro propio fichero de configuración con los campos que deseemos agrupar, para ello podemos hacerlo inicialmente como se presenta a continuación.

Pdu ip_pdu Proto ip Transport ip { Extract ip_fuente From ip.src; Extract ip_destino From ip.dst; }; Pdu sccp_pdu Proto sccp Transport ip { Extract sccp_clg_dig From sccp.calling.digits; Extract sccp_clg_ssn From sccp.calling.ssn; Extract sccp_cld_dig From sccp.called.digits; Extract sccp_cld_ssn From sccp.called.ssn; Extract gsm_map_UpdateLocation From gsm_old.localValue; Extract gsm_map_msisdn From gsm_map.ch.msisdn; Extract gsm_map_locationnumber.digits

From gsm_map.locationnumber.digits; }; Done;

Lo primero que deseamos remarcar, es que este plugin emplea el mismo

formato que el “filtro de visualización” de Wireshark, por lo tanto, cualquier

parámetro que deseemos configurar, podemos buscarlo en “Expresion”

desde los filtros de “Wireshark” y copiar su formato.

Más allá de volver a explicar lo que estamos haciendo, veamos los resultados

que obtendríamos con este fichero de configuración, que hemos llamado

“sccp.mate”.

Para lanzar este plugin, podemos hacerlo por línea de comandos, o desde la

misma interfaz gráfica de Wireshark, veamos el primer caso.

#wireshark -o "mate.config: sccp.mate" -r prueba2.pcap

Con el comando anterior, le decimos que ejecute Wireshark, sobre escribiendo su configuración predeterminada (“-o”) empleando la configuración de mate que figura en el fichero “sccp.mate” y esto lo realice leyendo (“-r”) la captura “prueba2.cap”.

Una vez ejecutada esta línea de comandos, se abrirá la interfaz gráfica de Wireshark y nos ofrecerá nuevos campos, tal cual podemos apreciar en la imagen siguiente.



Como se ve en la imagen anterior remarcado en rojo, aparece ahora este nuevo grupo de parámetros, para cada trama que le aplique, en el cual nos presenta la información que acabamos de solicitar en nuestro fichero “sccp.mate”. Hemos borrado los dígitos del País.

Todos los campos presentados en esta imagen ya han sido desarrollados en puntos anteriores, invitamos al lector a que repase estos conceptos dentro de este mismo texto.

No merece la pena seguir desarrollando más conceptos y posibilidades que nos ofrece MATE pues, la idea que intentamos presentar en estas breves líneas finales es la de considerar también otras herramientas que en su conjunto nos ofrecen más capacidades de filtrado, visualización, selección, etc. Es el lector el que tiene la libertad de acción para poder aprovecharlas de la mejor forma que considere oportuna, integrarlas a lo ya visto, aprovecharlas para tener otro punto de vista o potenciarlas programando con ellas diferentes acciones para mejorar este trabajo.

7.2. Tshark.

En los casos en los que puede sernos de utilidad NO usar la interfaz gráfica de Wireshark, y en particular por la potencia que nos ofrece la línea de comandos para poder ejecutar sencillos programas, este software (Wireshark) nos ofrece también este comando “tshark” que opera bajo la misma lógica y nos permite hacer uso de casi todas las opciones y filtros de Wireshark.

Hay mucha información al respecto en Internet, como también son



suficientemente claras sus opciones si escribimos “#tshark -help”

Sin que esto sea un curso de “tshark”, en estas líneas únicamente deseamos

poner de manifiesto la importancia de tener en cuenta este comando, pues

como veremos a continuación nos ofrece una posibilidad de análisis casi

ilimitada. Si esta capacidad la sumamos a sencillos “scripts”, por ejemplo

en programación “bash”, los resultados pueden ser excelentes y la única

frontera será la creatividad e imaginación de quien los desarrolle.

Presentamos a continuación algunos sencillos ejemplos, donde podemos

apreciar la aplicación de los mismos filtros que hemos empleado en la sección

de “Wireshark” de este mismo documento.

sh-3.2# tshark -r prueba1.pcap

1 0.000000 5707 → 5672 GSM SMS 306 invoke forwardSM

2 1.716000 5710 → 5703 GSM MAP 186 invoke readyForSM

3 1.777000 5707 → 5732 GSM MAP 186 invoke readyForSM

4 2.464000 5707 → 5710 GSM SMS 270 invoke forwardSM (Short Message fragment 4 of 4)







11……………(continúa hasta la última trama) Como podemos apreciar en el comando anterior “lee” la captura “prueba1.pcap”. A continuación, presentamos la aplicación del mismo filtro de visualización que empleamos en la sección de “Wireshark”, cuyo resultado nos presenta con total claridad , cuáles son las tramas que incluyen esta búsqueda (en esta caso estamos filtrando. “gsm_old.localValue==” que implica “updateLocation”). #tshark -Y gsm_old.localValue==2 -r prueba1.pcap

18 5.218000 5748 → 5707 GSM MAP 210 invoke updateLocation

70 5.832000 5707 → 5748 GSM MAP 150 returnResultLast updateLocation









A continuación, podemos ver otro ejemplo donde “concatenamos” más de un filtro de visualización y cuyo resultado es una única ocurrencia del mismo.



#tshark -Y "(gsm_old.localValue==2) and (sccp.calling.ssn==6)" -r prueba1.pcap

70 5.832000 5707 → 5748 GSM MAP 150 returnResultLast updateLocation

A continuación, repetimos el mismo ejemplo que pusimos en “Wireshark” para identificar tramas que provengan de cualquier “External Net” fuera de España, analizando su dirección “SCCP”. #tshark -Y "sccp.calling.digits matches 34 and not sccp.called.digits matches 34" -r prueba1.pcap

84 6.151000 5703 → 5732 GSM MAP 194 invoke updateGprsLocation

89 6.207000 5703 → 5732 GSM MAP 154 returnResultLast insertSubscriberData

Por último, podemos ver que el filtro anterior, al igual que con Wireshark, podemos enviarlo a una salida “-w” (write), en nuestro caso la hemos llamado “resultado_sccp-34.pcap”.

#tshark -Y "sccp.calling.digits matches 34 and not sccp.called.digits matches 34" -r prueba1.pcap -w resultado_sccp-34.pcap

Si abrimos la misma con Wireshark podemos verificar que se ha guardado con este formato y que por supuesto son perfectamente compatibles.

7.3. Unificar tramas (mergecap).

Un comando importante que ya hemos mencionado y recalcamos aquí es, si se reciben varias capturas “mergecap”, con este, se pueden unificar para tratar todas ellas como una. El formato básico que podemos aplicar para unir varias capturas "pcap" es:

#mergecap *.pcap -w nombre_salida.pcap



7.4. Información de capturas (capinfos).

Este comando, que viene integrado generalmente en las diferentes distribuciones Linux, y en definitiva forma parte de la familia “tcpdump” o de las “libpcap”, como su nombre lo indica, nos ofrece información de los ficheros en formato” “.cap” (y sus variantes: .pcap, .pcapng, etc.).

En nuestro caso nos resulta bastante práctico para realizar un primer golpe de vista de cualquier captura que tengamos, y en particular, para saber a qué tipo de distribución de protocolos se corresponde la misma.

Veamos algunos ejemplos sencillos.

#capinfos -u prueba1.pcap

File name: prueba1.pcap

Capture duration: 6,313000 seconds

Nos indica rápidamente la duración de una captura completa.

#capinfos -i prueba1.pcap

File name: prueba1.pcap

Data bit rate: 29 kbps

Nos indica rápidamente la velocidad con que se capturaron los datos.

#capinfos -c totales-MAP.pcap

File name: totales-MAP.pcap

Number of packets: 435 k

Nos indica rápidamente la cantidad de paquetes de esa captura.

Para más detalle de todas las opciones que ofrece este comando, se puede escribir el mismo sin opciones y se desplegarán todas ellas

(#capinfos)



8. Conclusiones A lo largo de este texto, hemos intentado presentar el problema que en estos momentos tenemos con SS7/Sigtran en todas las operadoras de telefonía del mundo. Analizamos los textos e investigaciones sobre los diferentes tipos de ataques que en la práctica ya existen y que pueden causar una alto impacto en estas arquitecturas. Dejemos bien claro que la única forma de tratar estas vulnerabilidades, es comprendiendo y analizando los flujos de “bits” que circulan por estas redes de señalización, sin este trabajo, estaríamos operando a ciegas. Fuimos elaborando una metodología de trabajo que nos permita identificar y detectar las potenciales ocurrencias de estos “patrones de tráfico”, y poder entonces adoptar las medidas que mejor se ajusten a nuestra arquitectura. Presentamos diferentes técnicas y herramientas para realizar este trabajo y avanzamos con ejemplo concretos sobre tráfico real SS7/Sigtran. Ofrecimos soluciones a este problema de forma entendible y sobre todo empleando TODAS las herramientas bajo licencias “Open Source”, para que no tengamos que recurrir a aplicaciones o software de pago. Quisimos difundir el trabajo en el estado en que se encuentra, sabiendo perfectamente que es únicamente un punto de partida, robusto, pero en un estado inicial. Tomamos esta decisión pues somos conscientes que como en todo desarrollo basado en “Open Source”, la suma de esfuerzos es lo que verdaderamente lo potencia, así que preferimos compartirlo ya mismo como una invitación a nuevos desarrolladores y aportes que nos permitan madurar y llevar a producción esta forma de trabajo. Como cierre de este documento, queremos expresar, que para nosotros la mayor satisfacción sería encontrar eco de esta metodología y poder verla “crecer” con los aportes de todo aquel que quiera subirse a este carro.

Madrid, marzo de 2018

Análisis de vulnerabilidades SS7/Sigtran empleando Wireshark y Snort

Alejandro Corletti Estrda Pág 66

REFERENCIAS

i GSMA - IR 82 v3.0.pdf - Security SS7 implementation on SS7 network guidelines

Version 3.0 21 March 2016 ii

Engel, T. Locating Mobile Phones using Signaling System #7. [Online]. Available:

https://events.ccc.de/, Accessed 07.11.2015

Engel, T. December 2014. SS7: Locate. Track. Manipulate. [Online]. Available:

https://media.ccc.de, Accessed 22.10.2015.

31c3-ss7-locate-track-manipulate.pdf - SS7: Locate. Track. Manipulate. Tobias

Engel <[email protected]> iii

Langlois, P. 2010. Getting in the SS7 kingdom: hard technology and and

disturbingly easy hacks to ge (Engel)t entry points in the walled garden. [Online].

Available: http://www.hackitoergosum.org/2010/ HES2010-planglois-Attacking-

SS7.pdf, Accessed: 25.11.2015.

iv Nohl, K. December 2014. Mobile self-defence. [Online]. Available: https:

//media.ccc.de, Accessed 22.10.2015.

1783_101228.27C3.GSM-Sniffing.Nohl_Munaut.pdf - GSM Sniffing -

Karsten Nohl

v Vauboin, P.-O. & Oliveira, A. D. April 2014. Worldwide attacks on SS7 network.

vi Langlois, P. - bh-eu-07-langlois-ppt-apr19.pdf - SCTPscan - Finding entry points

to SS7 Networks & Telecommunication Backbones

vii diameter_research.pdf - NEXT GENERATION NETWORKS, NEXT LEVEL

CYBERSECURITY PROBLEMS (2017).

viii FRHACK2009_Attacking-SS7_Langlois.pdf

ix Kamwendo, B. - Research Report.pdf - University of the Withwatersrand –

Johannesburg

x

Hacking en redes SS7 ~ Security By Default.pdf - www.Securitybydefault.com

https://events.ccc.de/

Análisis de vulnerabilidades SS7/Sigtran empleando Wireshark y Snort

Alejandro Corletti Estrda Pág 67

xi

Jensen, K. Junio 2016. Improving SS7 Security Using Machine Learning

Techniques. Master’s Thesis. Master of Science in Information Security

(KJensen_2016.pdf).

xii

GSMA - FS.11 - SS7 Interconnect Security Monitoring Guidelines - Version 1.0

(19 November 2015).

Guide to 3G security v130 Draft-Changed to cover MAP-SEC

3GPP TS 29.002 V15.2.0 (2017-12) 3rd Generation Partnership Project; Technical

Specification Group Core Network and Terminals; Mobile Application Part (MAP)

specification (Release 15)

ETSI TS 100 974 V7.15.0 (2004-03) - Digital cellular telecommunications system

(Phase 2+); Mobile Application Part (MAP) specification (3GPP TS 09.02 version

7.15.0 Release 1998)

ETSI TS 129 002 V14.4.0 (2018-01) - Digital cellular telecommunications system

(Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Mobile

Application Part (MAP) specification (3GPP TS 29.002 version 14.4.0 Release 14)

GSMA - RIFS62_03 CR1005 to FS11 v3_2 DRAFT v0_2.docx - SS7 Interconnect

Security Monitoring and Firewall Guidelines CR1005 to Version 3.2 DRAFT v0.2

análisis de ataques/vulnerabilidades ss7/sigtran empleando

Documents