Análisis de múltiples vulnerabilidades en diferentes productos BTS de código abierto

Fondo

Por:simone margaritelli
C
Zimperium zLabs

Durante las últimas semanas, hemos estado investigando múltiples aspectos de la seguridad GSM, como las vulnerabilidades de los protocolos y la auditoría de fuentes de los productos de software de código abierto más comunes del mundo que ejecutan redes GSM. En esta publicación, compartiremos los detalles sobre múltiples vulnerabilidades en dicho software que permiten a un atacante comprometer una estación BTS, bloquearla o apoderarse de su módulo transceptor de forma remota.

Una BTS (estación transceptora base) está compuesta por un software y un equipo de radio que permite que las estaciones móviles (teléfonos celulares) se conecten a las redes GSM, UMTS y LTE. Son el equivalente a puntos de acceso inalámbricos para redes Wi-Fi y manejan el “Um”[1] capa/interfaz como se muestra en la Figura 1.

Figura 1

Figura 1: Una estación móvil que se conecta a una BTS ( Documentación de GNURadio OpenBTS ).

El software de nivel inferior detrás de cualquier BTS es el transceptor, que es la interfaz directa al hardware de radio. Es responsable de la sintonización de frecuencia y el manejo de la modulación/demodulación de datos GMSK (Gaussian Minimal Shift Keying). En resumen, digitaliza las ondas de radio. Toda la comunicación y sincronización con el resto de las unidades lógicas del BTS se maneja a través de tres sockets UDP como se muestra en la Figura 2.

Figura 2

Figura 2: El módulo transceptor y los tres conectores UDP utilizados para comunicarse con el resto del BTS.

Él reloj socket se utiliza para la sincronización de tiempo. Él dominio El BTS utiliza el zócalo para enviar comandos al módulo transceptor. Finalmente, el datos El zócalo se utiliza para transmitir «ráfagas» GSM (paquetes de datos) desde el BTS a la radio y recibir respuestas.

Él UDPSocket class es utilizada por el transceptor para manejar los tres canales en la Figura 2.

Nuestra investigación muestra que todo el software BTS más comúnmente disponible comparte la misma (o una muy similar) base de código de transceptor. Por lo tanto, todos ellos se ven afectados por las mismas vulnerabilidades. Los siguientes informes son válidos para todos los productos enumerados a continuación.

Dichas vulnerabilidades permitirían que una parte malintencionada controlara de forma remota el módulo transceptor, comprometiendo así las funcionalidades de BTS, haciéndose pasar por un BTS paralelo que se comunica con él.

gráfico-1

Además, es posible que el atacante envíe ráfagas de datos GSM al propio transceptor y realice una amplia gama de ataques, como la separación de IMSI, la degradación del cifrado, la denegación de servicio, etc. contra suscriptores móviles.

Para ser aceptados por el módulo transceptor, los paquetes UDP enviados al socket del canal de datos deben respetar el siguiente formato:

Formato de paquetes UDP enviados al socket del canal de datos para ser aceptados por el módulo transceptor

Una vez que el transceptor recibe estos paquetes, los decodifica y modula utilizando GMSK (modulación por desplazamiento mínimo gaussiano). Eventualmente, las ráfagas se transmitirán a las estaciones móviles conectadas de acuerdo con su contenido.

Incluso si los siguientes productos son solo GSM y UMTS, el transceptor (que es un componente independiente) en sí mismo es universal. Lo más probable es que otro software BTS (propietario) utilice la misma base de código para servir también a la conectividad LTE.

Productos afectados

  • YateBTS
  • OpenBTS
  • OpenBTS-UMTS
  • Osmo-TRX/Osmo-BTS
  • Otros productos que comparten la misma base de código de transceptor.

Vendedores

Problema 1: enlace de servicio demasiado expuesto

Resumen

Hay un error en la biblioteca de red de los productos antes mencionados que hace que los sockets UDP del transceptor se unan a INADDR_ANY en lugar del valor configurado por el usuario (127.0.0.1 por defecto). Esto permite que cualquier atacante con conectividad IP al sistema BTS reciba y envíe paquetes desde/hacia el transceptor. Además, el acceso a los servicios expuestos en estos sockets de red UDP no está protegido por ningún mecanismo de autenticación.

Los tres zócalos del transceptor vinculados a 0.0.0.0

Figura 3: Los tres zócalos del transceptor vinculados a 0.0.0.0

Impacto

Un atacante con conectividad IP podría enviar tráfico UDP para ejercer cualquier funcionalidad proporcionada. Esto podría permitir la toma de control remoto, el secuestro de tráfico GSM, la divulgación de información diversa, DoS o algo peor.

Detalles

La causa raíz de esta vulnerabilidad (y la razón por la que se puede acceder de forma remota a las siguientes vulnerabilidades) se puede encontrar en el UDPSocket constructor y el UDPSocket::open método en el archivo fuente CommonLibs/Sockets.cpp. Este archivo fuente está presente en todos los productos afectados. El siguiente extracto muestra el código vulnerable.

256 UDPSocket::UDPSocket(unsigned short wSrcPort,
 257 const char * wDestIP, unsigned short wDestPort )
 258 :DatagramSocket()
 259 
 ...
 266 void UDPSocket::destination( unsigned short wDestPort, const char * wDestIP )
 267 

En el fragmento anterior, podemos ver que la dirección de enlace deseada se guarda en el mDestination variable miembro de la clase, pero así es como la UDPSocket::open se implementa el método:

271 address.sin_family = AF_INET;
 272 address.sin_addr.s_addr = INADDR_ANY;
 273 address.sin_port = htons(localPort);
 274 if (bind(mSocketFD,(struct sockaddr*)&address,length)<0) {

A pesar de que el UDPSocket class proporciona un argumento de constructor para especificar la dirección a la que vincular el servidor, esta información se ignora. como se muestra en línea 272el zócalo está vinculado a INADDR_ANY en lugar de usar el mDestination variable de dirección.

Problema 2: Desbordamiento de búfer basado en pila remota

Resumen

Un atacante puede desbordar un búfer de pila enviando un paquete UDP de gran tamaño al canal de control.

Impacto

Un atacante puede lograr la ejecución remota de código (RCE) o provocar una condición de denegación de servicio (DoS).

Detalles

El canal de control es manejado por el Transceiver::driveControl método en el Transceiver.cpp archivo fuente. Siguen las primeras líneas.

694 void Transceiver::driveControl(size_t chan)
695 {
696   int MAX_PACKET_LENGTH = 100;
697   
698   // check control socket
699   char buffer[MAX_PACKET_LENGTH];
700   int msgLen = -1;
701   buffer[0] = ' ';
702    
703   msgLen = mCtrlSockets[chan]->read(buffer);

Tenga en cuenta que el búfer de paquetes, que reside en la pila del método, se define en 100 bytes (desde MAX_PACKET_LENGTH).

Si analizamos el DatagramSocket::read método (el DatagramSocket clase es la clase padre de UDPSocket) declarado en el Sockets.cpp archivo fuente, vemos lo siguiente.

194 int DatagramSocket::read(char* buffer)
195 {
196   socklen_t temp_len = sizeof(mSource);
197   int length = recvfrom(mSocketFD, (void*)buffer, MAX_UDP_LENGTH, 0,

Aquí vemos que MAX_UDP_LENGTH se leen bytes en lugar de MAX_PACKET_LENGTH. Este valor se define en el Sockets.h archivo de la siguiente manera.

#define MAX_UDP_LENGTH 1500 /* (or 8000 for OpenBTS-UMTS) */

Por lo tanto, es posible provocar un desbordamiento de pila en el proceso del transceptor simplemente enviando un paquete UDP de más de 100 bytes. La Figura 4 muestra el resultado de una sesión de depuración cuando esto ocurre.

bts-fig-4

Figura 4: falla de segmentación causada por un paquete UDP grande.

Mitigación

  1. RCE se puede mitigar cuando se aplican los indicadores apropiados en tiempo de compilación. La historia muestra que estas mitigaciones pueden pasarse por alto dada la vulnerabilidad correcta o la cadena de vulnerabilidades (por ejemplo, con una fuga de información). Además, dado que este software es compilado por varias partes, es probable que algunas de estas compilaciones no contengan suficientes mitigaciones (ASLR, Stack canaries, etc.).
  2. Si no hay impacto o uso de la interfaz del transceptor, recomendamos bloquear este puerto de las conexiones externas en el firewall.

Problema 3: control remoto no autenticado

Resumen

El canal de control no implementa ningún tipo de autenticación. Dado que está expuesto a la red externa debido al Problema 1, cualquier parte malintencionada puede utilizar este hecho para controlar el módulo transceptor de forma remota.

Impacto

Un atacante podría…

  • …deniegue el servicio apagando el módulo.
  • … interferencia de frecuencias al sintonizar la radio TX en la frecuencia incorrecta.
  • … secuestrar la identidad de BTS de forma remota usando el SETBSIC comando para cambiar la identidad BTS a otra.

Detalles

El canal de control implementa un texto simple sobre protocolo UDP manejado por el Transceiver::driveControl método en el Transceiver.cpp archivo fuente. Algunas de las características que expone este protocolo incluyen (recuerde, no hay autenticación):

  • Encender o apagar el módulo TRX: CMD POWERON / CMD POWEROFF
  • Sintonizando el TRX a otras frecuencias: CMD RXTUNE frequency / CMD TXTUNE frequency
  • Configuración de la identidad de la celda GSM: CMD SETBSIC value

Un atacante puede ejecutar dichos comandos (y otros) simplemente enviando paquetes UDP al puerto 5701 del servidor La especificación completa del protocolo se puede encontrar dentro del TRXManager/README.TRXManager expediente.

Conclusiones, mitigaciones adicionales y recomendaciones:

Hemos demostrado cómo la falta total de cualquier forma de autenticación y los errores de código hacen que los productos BTS antes mencionados sean vulnerables a una amplia gama de ataques.

Recomendamos encarecidamente a los proveedores que apliquen las siguientes mitigaciones para fabricar sus productos más seguro:

  1. Actualice su software BTS cuando haya un parche disponible.
  2. Vincule los sockets utilizados para el control y el intercambio de datos solo a la interfaz local (127.0.0.1).
  3. Cortafuegos: bloquee el tráfico procedente de redes externas a los puertos 5701 (puerto de control) y 5702 (puerto de datos) u otros puertos que utilice su software BTS.
  4. Asegúrese de aplicar mitigaciones de tiempo de compilación (ASLR + DEP)
  5. Implemente un sistema de autenticación para que dichos canales nieguen a un atacante sin privilegios que haya iniciado sesión en la misma máquina o en la misma red comunicarse con los puertos de control BTS.
  6. Corrija el manejo del búfer usando los tamaños correctos.
  7. Realice auditorías de código adicionales.

Para los profesionales de seguridad y movilidad preocupados por las implicaciones de ataques similares a dispositivos corporativos o BYOD, considere aprovechar una solución de prevención de amenazas móviles como Zimperium zips para detectar la manipulación activa por parte de un tercero no autorizado.

Cronograma de divulgación

  • 26 de abril de 2016: correo electrónico de divulgación inicial enviado a los proveedores.
  • 29 de abril de 2016: Contacto de OsmoBB
  • 30 abril 2016 : OsmoBB: seguimiento
  • 6 de mayo de 2016: Notificación inicial a Zimperium Handset Alliance (ZHA).
  • 06 de mayo de 2016: OpenBTS: errores corregidos [1] [2]
  • 07 de junio de 2016: Seguimiento con proveedores
  • 07 junio 2016: OsmoBB: error corregido
  • 06 de julio de 2016: Publicación para los socios de ZHA
  • 6 de julio de 2016: OpenBTS: Corrección de desbordamiento revertido (!!) [3]
  • 13 de julio de 2016: OpenBTS: Corrección de enlace revertido (!!) [4]
  • 10 de agosto de 2016: Comentó en ambos «¿Por qué está reintroduciendo deliberadamente graves problemas de seguridad en su software?» (OpenBTS)
  • 15 de agosto de 2016: OpenBTS – Seguimiento, sin respuesta
  • 23 de agosto de 2016: divulgación pública

Deja un comentario