La inseguridad de la pila de telecomunicaciones que salió a la luz después de Salt Typhoon
(soatok.blog)- Tras la intrusión de Salt Typhoon, durante el proceso de revisión de software de telecomunicaciones de código abierto, se descubrió un desbordamiento de búfer sin autenticación en la biblioteca XMLRPC incluida con FreeSWITCH
- La vulnerabilidad se origina en código que escribe con
sprintf()un Request URI provisto por el atacante en una variable de pila de 4096 bytes, y, aparte de las limitaciones del navegador, podrían ser posibles solicitudes de más de 4096 caracteres - SignalWire respondió que en febrero de 2025 se publicaron 3 PR de corrección en GitHub, pero señaló que la nueva versión de la comunidad de FreeSWITCH no está planeada hasta el verano de 2025
- En Shodan había alrededor de 8,300 resultados para FreeSWITCH, y los operadores sin una etiqueta de lanzamiento se ven obligados a responder por su cuenta, ya sea compilando desde el código fuente o bloqueando con firewall
- Este caso muestra que el riesgo en la seguridad de las telecomunicaciones crece no solo por la vulnerabilidad en sí, sino también por la gestión de vulnerabilidades y la respuesta de lanzamiento, y aun después de que se asignó CVE-2025-44087 el 30 de abril de 2025, no hubo una versión nueva de FreeSWITCH
Qué llevó a revisar FreeSWITCH después de Salt Typhoon
- A finales de 2024, el punto de partida fue la noticia de que el grupo Salt Typhoon, presuntamente vinculado al gobierno chino, había comprometido a T-Mobile y a otras telecos
- No era posible investigar directamente redes de operadores móviles, pero en GitHub había muchos proyectos de código abierto relacionados con telecomunicaciones
- Había experiencia previa trabajando con empresas que usaban Asterisk y FreeSWITCH, pero no analizando en profundidad PBX, SIP ni codificación de audio
- En el sector de las telecomunicaciones existe la tradición de excelentes programadores en C, comunidades veteranas de hackers e ingenieros provenientes de Bell Labs, así que se asumía que las vulnerabilidades simples ya habrían sido encontradas
- Sin embargo, la vulnerabilidad apareció casi de inmediato al abrir el código fuente de FreeSWITCH
Desbordamiento de búfer en el manejador de solicitudes HTTP de XMLRPC
- El manejador de solicitudes HTTP de la biblioteca XMLRPC incluida con FreeSWITCH escribe el URI en un búfer de pila de tamaño fijo
z[4096] - El código problemático tiene la forma
sprintf(z, "Index of %s" CRLF, uri);, y comouriproviene de la parte path del Request URI, puede ser controlado por un atacante - Muchos navegadores no manejan bien URLs de más de 2048 caracteres, pero los RFC relevantes generalmente permiten alrededor de 8 KB y Cloudflare admite hasta 32 KB
- Es razonable considerar que un atacante puede enviar un Request URI de más de 4096 caracteres, y esa condición lleva a un desbordamiento de búfer sin autenticación en la biblioteca XMLRPC
- No se aborda cómo escalar esto hasta ejecución remota de código
Forma de corrección y parches publicados
- La dirección de la corrección es usar
snprintf()en lugar desprintf() - Esto corresponde a una práctica básica de programación defensiva en C
- SignalWire indicó que el problema se corrigió recientemente y presentó los siguientes PR
- Como los parches ya estaban publicados en GitHub, se consideró posible escribir una publicación pública al respecto
Proceso de divulgación de la vulnerabilidad y vacío de lanzamientos
- El 27 de enero de 2025, se enviaron los detalles de la vulnerabilidad a la dirección de correo indicada en la política de seguridad de FreeSWITCH
- El 7 de febrero de 2025, se envió un correo de seguimiento para confirmar si habían recibido el reporte
- Ese mismo día, Andrey Volk respondió que la vulnerabilidad había sido corregida recientemente y recomendó revisar los PR relacionados
- Al preguntar por el calendario de una versión etiquetada que incluyera la corrección de seguridad, la respuesta fue que la versión de la comunidad de FreeSWITCH no está planeada hasta el verano de 2025
- Como resultado, los usuarios que no pagan por FreeSWITCH Advantage podrían seguir expuestos hasta la próxima versión regular
Alcance de la exposición e impacto para operadores
- En ese momento, en Shodan había alrededor de 8,300 resultados para FreeSWITCH
- Como es difícil asumir que todas esas instancias pagan soporte empresarial, se estima que miles de pilas de telecomunicaciones en todo el mundo podrían permanecer vulnerables hasta el verano
- Aunque el parche esté publicado en GitHub, sin una etiqueta de lanzamiento a los operadores comunes les resulta difícil actualizar fácilmente
- En lugar de esperar una versión de SignalWire, los operadores de FreeSWITCH deberían considerar las siguientes medidas
- Recompilar directamente desde el código fuente
- Bloquear el acceso HTTP público a la pila de FreeSWITCH a nivel de firewall
Problema estructural de la seguridad en telecomunicaciones
- En conversaciones con personas del sector, la reacción fue que incluso la velocidad de respuesta de FreeSWITCH se considera relativamente rápida
- En diciembre de 2024 también reaparecieron advertencias sobre una vulnerabilidad de SS7 que ha existido durante 17 años en la red telefónica
- Después de esta experiencia, no se revisaron más Asterisk ni otros programas adicionales
- La conclusión es que hoy en día la seguridad en telecomunicaciones está en mal estado
- Una causa importante parece ser que casi no existe incentivo económico para hacer seguros estos sistemas
Estado posterior
- En una actualización del 30 de abril de 2025, al desbordamiento de búfer reportado se le asignó CVE-2025-44087
- Incluso en ese momento, FreeSWITCH seguía sin etiquetas ni lanzamientos
1 comentarios
Opiniones de Hacker News
El autor reconoce que no tiene ninguna experiencia con infraestructura de nivel operador, pero sus sospechas en general son acertadas.
En la práctica he hecho bastante pentesting e investigación de seguridad en 4G/5G para varios operadores importantes y, aunque hay diferencias entre operadores y proveedores de equipos, sigue siendo casi un show de terror absoluto.
Hasta hace muy poco, la seguridad era básicamente seguridad por oscuridad, y aunque los estándares 4G/5G empezaron a abordar esto, todavía quedan agujeros lo bastante grandes como para preocupar seriamente.
No es exagerado pensar que un actor de amenazas de nivel medio o superior que quiera establecer una cabeza de playa en un operador puede lograrlo; lo he demostrado varias veces profesionalmente.
Ciertos proveedores de equipos de Asia Oriental tienen stacks de software de tan baja calidad que casi podrían clasificarse como APT, y la seguridad prácticamente no existe.
Hay razones válidas por las que los países occidentales los prohibieron, y el software de los proveedores occidentales de equipos es mucho más maduro, pero aun así está varios años por detrás de lo que consideraríamos buenas prácticas modernas de seguridad.
GCHQ consideró que la calidad del código era imposible de revisar y que ni siquiera se podía garantizar que el código fuente entregado fuera el mismo que se ejecutaba en los equipos reales.
Esto se debía a que Huawei podía actualizarlos directamente, y tengo entendido que esos equipos fueron prohibidos después de 2020: https://www.washingtonpost.com/world/national-security/brita...
Quisiera comprar uno en AliExpress y revisarlo; ¿este enlace sería un buen punto de partida?
https://vulners.com/search/types/huawei
Realmente no entiendo por qué en 2025 los estándares de telefonía móvil siguen usando claves precompartidas.
RSA y Diffie-Hellman[1] existen desde hace décadas y el sistema de autoridades certificadoras también lleva mucho tiempo, pero las tarjetas SIM todavía se emiten con una clave precompartida que solo conocen la tarjeta y el operador, y luego tanto la autenticación como el cifrado se basan en esa clave.
Si el operador es hackeado y se filtran las claves, no hay nada que hacer.
Peor aún, el fabricante de la SIM tiene que enviarle esa clave al operador, y si el fabricante está en otro país puede estar sujeto a exigencias de un gobierno extranjero, así que hay muchas oportunidades para hackear al fabricante o robar la clave durante la transmisión.
Esto se siente como una vulnerabilidad NOBUS, y si un fabricante de SIM o un proveedor de equipos de red core se colude con la NSA para entregar las claves, potencialmente se podría interceptar el tráfico móvil de todo el mundo.
[1] Sé que estos algoritmos ya no son la mejor práctica y que las curvas elípticas son mejores, pero incluso RSA sería mejor que lo actual.
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
“Según documentos ultrasecretos de la NSA proporcionados por Edward Snowden, espías estadounidenses y británicos hackearon las redes informáticas internas del mayor fabricante de tarjetas SIM del mundo y robaron las claves de cifrado usadas para proteger la privacidad de las comunicaciones de teléfonos móviles en todo el planeta”.
https://theintercept.com/2015/02/19/great-sim-heist/
No sé si eso sigue siendo así, pero antes era difícil considerar al celular un medio de comunicación seguro.
Probablemente convenga conversar mediante comunicaciones de datos cifradas de extremo a extremo.
Los algoritmos de clave simétrica también tienen la ventaja de ser seguros frente a la computación cuántica.
Aun así, para 2025 esperaría que al menos hubiera soporte para ECC, y hoy la mayoría de las smart cards debería poder soportarlo de base.
Si no puedes confiar en el fabricante de la SIM, en la práctica no hay solución.
Incluso con un esquema asimétrico, la ruta de ataque solo cambia un poco; si no puedes confiar en el software que corre en la tarjeta, ¿cómo sabes que no filtra el texto en claro mediante la elección de números aleatorios en algoritmos no deterministas?
La idea de que meter RSA en un sistema simétrico lo vuelve más seguro tiene una base débil; más bien es casi lo contrario.
La expresión “vulnerabilidad NOBUS” también es especialmente rara, porque la raíz de confianza de este tipo de sistemas es el operador.
Ni siquiera hace falta preguntar si un operador estadounidense se “coludió” con las agencias de inteligencia de EE. UU.; hay que asumir que ya es así.
Los estafadores son grandes clientes de los operadores, y cuando los atrapan y los bloquean, vuelven, pagan el alta de una nueva línea y repiten el mismo proceso.
Gracias a los estafadores también se pueden vender funciones adicionales, así que dejar el problema sin resolver vuelve a generar ingresos.
No sorprende en absoluto que, como concluye el post, Freeswitch no vaya a cambiar su calendario de lanzamientos comunitarios
Antes Freeswitch tenía un fuerte espíritu de comunidad, pero el ambiente cambió después de que se comercializara de forma más agresiva hace unos años
Desde entonces, para acceder a cosas que deberían ser públicas había que pasar por un proceso de “registro” y, si no recuerdo mal, algo como los repositorios APT quedó oculto detrás de ese muro de registro
No quiero registrarme con una empresa comercial para acceder a contenido de una comunidad de software libre
Porque todos sabemos que, en la industria tecnológica, cuando le das información a una empresa comercial, los vendedores terminan molestándote con upselling y cross-selling, y metiéndote en listas de correo no solicitadas
He visto a otras partes de la comunidad VoIP reajustar su generosidad hacia el open source y, sinceramente, es difícil culparlas
El equipo de Matrix.org también habló de algo parecido en una de sus charlas de FOSDEM’25: el problema de los proveedores comerciales que se suben gratis al desarrollo
Sería muy de agradecer que además actualizaran gratis los repositorios APT, pero eso es justamente eso: algo “de agradecer”
Si dependes de su código y no quieres pagar costos de soporte, puedes compilar tú mismo los paquetes APT
No tengo muy claro qué espíritu comunitario deberíamos esperar de un proyecto mantenido así por una sola empresa
Considerando a los actores de amenazas extranjeros, las alianzas occidentales como Five Eyes y la presión por seguir subiendo los números, lo razonable es asumir que en línea no existe el anonimato real
Si te quieren, tienen los medios para atraparte
En la práctica no es tan distinto de la era previa a internet
Si no quieres que te intercepten, tienes que cifrar de una forma que las grandes agencias de seguridad no puedan acceder fácilmente por medios electrónicos
Es decir, métodos como notas físicas, comunicación oral o gestos
Además, cuando un actor estatal efectivamente asigna recursos para usar los datos, debes estar preparado para asumir las consecuencias de lo que dijiste e hiciste en línea
Solo con el artículo no me termina de convencer la conclusión de que “la seguridad de las telecomunicaciones actuales es un desastre”
Porque parece más bien que eligieron Freeswitch arbitrariamente y encontraron un buffer overflow
Puede que el “stack de telecomunicaciones” sea vulnerable o no, pero la evidencia presentada aquí es muy débil
Se sabe que los ataques de Salt Typhoon explotaron vulnerabilidades de Cisco, pero los analistas también han planteado la posibilidad de que los atacantes usaran credenciales legítimas: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
Así que no tiene relación con Freeswitch
Oracle SBC a menudo es inestable incluso con su comportamiento básico, y seguro que también hay bugs de denegación de servicio que no lograron aislar correctamente en el desastre de implementación de TRouter que Teams sacó esta semana
Ni hablar del caos de MF Tandem, o de que casi todos los operadores dejan fluir por internet tráfico SIP UDP sin cifrar en bruto
Es posible construir sistemas seguros en este campo, pero la realidad es que la mayoría de los grandes operadores manejan plataformas propietarias e imposibles de modificar de compañías o proyectos muertos hace mucho, como Nortel y Metaswitch, además de montañas de deuda técnica aún peores que el equipo viejo y sin parches que compone sus redes
La frase “todo es un desastre y no hay incentivos para arreglarlo” es solo un resumen
Sinceramente, esas conversaciones son muy difíciles de seguir si no conoces la jerga, y como yo tampoco entiendo lo suficiente este campo, no quise intentar explicarlo torpemente y lo dejé en eso
Jamás esperé que mi blog apareciera en Hacker News
Es código que parsea protocolos de red complejos con varias generaciones de legado, suele escribirse en secreto y por lo general está en C/C++
Seguro que no puede ser vulnerable. Claro que no
Protocolos como SS7 se diseñaron sin el concepto de hackers o actores maliciosos
Puedes ponerles firewalls encima, pero chocan con las funciones deseadas y, aun cuando no lo hacen, requieren inversión adicional
DIAMETER es mejor, pero sigue teniendo muchos agujeros
En los últimos años, la seguridad en telecomunicaciones se ha vuelto una prioridad y ha habido mejoras, pero hay que envolver décadas de hardware, software, firmware y diseños de red heredados
No creo que nadie esté ejecutando Freeswitch estándar tal cual en una red de telecomunicaciones, pero el tipo de problemas de Freeswitch, como producto de telecomunicaciones antiguo en el que no se buscó seguridad tanto como se esperaría, está por todas partes
Está muy bien que el autor haya revisado código en su tiempo libre, encontrado un bug y lo haya reportado, y no quiero desalentarlo en absoluto
Pero el hecho de que un mantenedor de una pieza de software no se haya inclinado ante el autor siguiendo las mejores prácticas de la industria de seguridad es una base débil para decir que “la seguridad de las telecomunicaciones actuales es un desastre”
Si alguien te trae un bug en tu código, pero no afirma que esté siendo explotado activamente ni aporta un PoC para comprobar que sea explotable, ¿por qué no tratarlo simplemente como un bug común?
Lo corriges ahora y lo incluyes en el próximo lanzamiento
¿Que la gente puede ver los cambios? Sí, también puede ver todos los demás cambios
Si pueden encontrar el exploit, mucha suerte; el reportante no lo encontró
Lo mismo pasa en las distribuciones de Linux
Se reportan bugs de seguridad y, a veces, el autor upstream no solo es terco, sino que literalmente ya falleció
Si quieres cambiarlo según tu propio calendario, puedes hacer tú mismo el lanzamiento
Un ámbito donde Freeswitch parece usarse bastante es en las instalaciones de BigBlueButton de escuelas y universidades
Es un sistema de aulas virtuales, y seguramente muchas lo usan sin contrato de soporte; me preocupa más ese caso que los operadores de telecomunicaciones
Me pregunto cuánta gente usará realmente el módulo XML RPC
No se carga por defecto
Corrección: según Shodan, son 468
También me pregunto si
senddirectorydocumenten el módulo XML RPC realmente se usacurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";¿Alguna idea de cómo dispararlo?
Creo que sería más probable que hagan un lanzamiento de seguridad si aparece al menos una PoC que provoque un segfault
El hacking realmente interesante ocurre con la inyección de CAMEL MAP
Controla todo tipo de cosas buenas: SMS, USSD y, la joya de la corona, los servicios de ubicación
Muchas empresas de “SMS masivos” en islas ricas del Caribe o lugares como Indonesia hacen mucho más que enviar spam
Así que es vieja, y 2G fue diseñado en los años 90
No sé muy bien qué espera la gente
Honestamente, ya es suerte que funcione
Los operadores grandes no ejecutan FreeSwitch ni Asterisk en el core
Claro que Motorola está discontinuando ese producto, pero existe en campo
El que yo mantengo está fuertemente protegido por firewall, pero sospecho que no todos lo están
La mayoría de las empresas con PBX que quieren hacer algo más que enrutamiento básico de llamadas y conexión a la PSTN seguramente usan herramientas de terceros
Y muchas de esas herramientas están construidas sobre FreeSWITCH, Asterisk o algo parecido
Recomiendo mucho la presentación de P1 Security sobre seguridad en comunicaciones móviles: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
Es material antiguo, pero no hay razones para creer que haya mejorado
Porque no hay ningún incentivo para mejorarlo
Además, las vulnerabilidades de seguridad de software son solo una parte del problema; la otra es que los operadores están felices de externalizar el control y el acceso crítico al postor más barato: https://berthub.eu/articles/posts/5g-elephant-in-the-room/