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

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 (acorletti@darFe.es - acorletti@hotmail.com)
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

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
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. Información filtrada o mal securizada (fugas de información) (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/VLRS2G 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.

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

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

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)
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
request (al HLR), el cual
responde con
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}x02x01x01x30x1ax02x01x2d/";
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}x02x01x01x30.{1}x02x01x46x30/";
sid:1000010;)
provideSubscriberInfo_resp ip $HLR-HSS any -> !$HOME_NET
any (msg: "MAP - provideSubscriberInfo_resp - Ataque Nro

1"; pcre:"/xa2.{1}x02x01x01x30.{1}x02x01x46x30/";
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}x02x01.{1}x02x01x70x30/"; sid:1000031;)
insertSubscriberData_req ip !$HOME_NET any -> $MSC any (msg:
"MAP - insertSubscriberData_req - Ataque Nro 3A";
pcre:"/xa1.{1}x02x01.{1}x02x01x70x30/"; sid:1000032;)
# DeleteSubscriberData_req ip any any -> any any (msg: "MAP -
DeleteSubscriberData_req - Ataque Nro 3B";
pcre:"/xa1.{1}x02x01x01x02x01x08x30/";
sid:1000033;)
DeleteSubscriberData_req ip !$HOME_NET any -> $MSC any (msg:
"MAP - DeleteSubscriberData_req - Ataque Nro 3B";
pcre:"/xa1.{1}x02x01x01x02x01x08x30/";
sid:1000034;)
#cancelLocation_req ip any any -> any any (msg: "MAP -
cancelLocation_req - Ataque Nro 3C";
pcre:"/xa1.{1}x02x01x01x02x01x03xa3/";
sid:1000035;)
cancelLocation_req ip !$HOME_NET any -> $MSC any (msg: "MAP
- cancelLocation_req - Ataque Nro 3C";
pcre:"/xa1.{1}x02x01x01x02x01x03xa3/";
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

(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)
2 of 4)
1 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)

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de Alejandro Corletti Estrada

Más de Alejandro Corletti Estrada (20)

Último

Último (8)

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