Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
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).
Red SS7
Pila SS7
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)
Manipulación de SCCP
Alteraciones de MAP
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.
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
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)
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)
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.
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).
El procedimiento updateLocation
tampoco está autenticado.
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)
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.
Por esta razón es que se debe considerar este potencial escenario de ataque.
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.
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.
Recordemos que este protocol (ISUP) es el que emplea la pila SS7 para las redes
RDSI.
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
Esta tabla se refiere a parámetros del protocolo MAP asociados con las tres primeras
categorías que acabamos de presentar.
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.
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”.
http://www.darfe.es/joomla/index.php/descargas/summary/4-redes-y-
comunicaciones/39-curso-de-analisis-de-trafico
https://www.youtube.com/user/infoDarfe/videos
https://www.darfe.es/joomla/index.php/capturas
Etc.
Como podemos apreciar, hemos filtrado todas las tramas que contienen este
protocolo.
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
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.
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.
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.
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
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
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
#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 GW 172.17.33.10/32,172.33.12/32
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)
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
a2 ** 02 01 01 30 2c 02 01 47 30 27 (MAP anyTimeinterrogation)
-----> Component: returnResultLast
a2 ** 02 01 01 30 ** 02 01 46 30 (MAP provideSubscriberInfo)
-----> Component: returnResultLast
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)
-----> Component: invoke
a2 ** 02 01 01 30 1a 02 01 2d 30 15 (MAP sendRoutingInfoForSM)
-----> Component: returnResultLast
a2 ** 02 01 01 30 0e 02 01 02 30 09 04 07 (MAP updateLocation)
-----> Component: returnResultLast
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)
-----> Component: invoke (invokeID: 1)
a1 ** 02 01 02 02 01 07 30 (MAP InsertSubscriberData)
-----> Component: invoke (invokeID: 2)
a1 ** 02 01 03 02 01 07 30 (MAP InsertSubscriberData)
-----> Component: invoke (invokeID: 3)
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)
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)
Ejemplo 2:
Para mejorarla un poco, podríamos empezar a ajustar su diseño, por
Alejandro Corletti Estrada Pág 52
Análisis de vulnerabilidades SS7/Sigtran empleando Wireshark (y/o tshark) y Snort
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)
-----> Component: invoke
a2 ** 02 01 01 30 1a 02 01 2d 30 15 (MAP sendRoutingInfoForSM)
-----> Component: returnResultLast
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;)
1"; pcre:"/\xa2.{1}\x02\x01\x01\x30.{1}\x02\x01\x46\x30/";
sid:1000011;)
¿Qué le estamos diciendo ahora?
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:
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.
https://wiki.wireshark.org/Mate
Done;
7.2. Tshark.
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
#capinfos -u prueba1.pcap
File name: prueba1.pcap
Capture duration: 6,313000 seconds
#capinfos -c totales-MAP.pcap
File name: totales-MAP.pcap
Number of packets: 435 k
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
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.
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.
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
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
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).