-
Vulnerabilidad del stack de telecomunicaciones
- Contexto: A finales del año pasado, ocurrió un incidente en el que un grupo llamado "Salt Typhoon" hackeó a T-Mobile y a otras empresas de telecomunicaciones. Este incidente llevó a revisar la seguridad del software open source relacionado con telecomunicaciones.
-
Desbordamiento de búfer en la biblioteca XMLRPC de FreeSWITCH
-
Problema: En la biblioteca XMLRPC de FreeSWITCH, el manejador de solicitudes HTTP escribe un URI de longitud arbitraria en una variable de pila de 4096 bytes. Esto constituye una vulnerabilidad de desbordamiento de búfer, ya que un atacante puede enviar un URI de más de 4096 caracteres.
-
Solución: Se debe aplicar programación defensiva en C usando
snprintf().
-
-
Intento de divulgación de la vulnerabilidad por parte de Soatok
-
2025-01-27: Se enviaron los detalles de la vulnerabilidad a la dirección de correo especificada en la política de seguridad de FreeSWITCH.
-
2025-02-07: Se envió un correo de seguimiento para confirmar si habían recibido el reporte.
-
Respuesta: Andrey Volk respondió que la vulnerabilidad había sido corregida recientemente. Sin embargo, no se etiquetó una nueva versión con el parche de seguridad.
-
-
Problemas ocurridos
- Un empleado de SignalWire indicó que los usuarios que no compraran FreeSWITCH Advantage permanecerían vulnerables hasta el verano. Esto significa que miles de stacks de telecomunicaciones podrían seguir en estado vulnerable.
-
Problema sistémico de la seguridad en telecomunicaciones
-
Causa del problema: Faltan incentivos económicos para invertir en la seguridad de los sistemas de telecomunicaciones. Esa es la razón por la que la seguridad en telecomunicaciones sigue siendo débil incluso hoy.
-
Posibilidades a futuro: Podría surgir un competidor de FreeSWITCH desarrollado en Rust, o una voluntad política para invertir en la seguridad de la infraestructura de telecomunicaciones de Estados Unidos.
-
-
Reflexión final
- Aunque este es un problema técnico en apariencia simple, detrás podría haber un problema mayor. La respuesta de SignalWire fue decepcionante, pero aun así respondieron dentro de 90 días y corrigieron el problema en GitHub. También se pueden considerar medidas como bloquear a nivel de firewall el acceso HTTP público al stack de FreeSWITCH.
1 comentarios
Opinión de Hacker News
El autor reconoce que no tiene experiencia en infraestructura a nivel de operadora, pero sus sospechas son esencialmente correctas
En 2025 sigue sin entenderse por qué los estándares de telefonía móvil todavía usan claves precompartidas
La conclusión de la publicación del blog de que Freeswitch no se aparta del calendario de lanzamientos de la comunidad no resulta nada sorprendente
Entre actores de amenaza extranjeros, Five Eyes/otros acuerdos occidentales y la exigencia de aumentar ingresos, es razonable asumir que no existe anonimato real en línea
Un área donde Freeswitch suele usarse sin contrato de soporte son las instalaciones de BigBlueButton en escuelas y universidades
No está completamente convencido de la afirmación de que "la seguridad en telecomunicaciones es pésima hoy en día"
Se pregunta cuánta gente usa el módulo XML RPC
Con la inyección de CAMEL MAP ocurren hackeos realmente buenos
Las grandes operadoras no ejecutan FreeSwitch ni Asterisk en el core
Recomienda encarecidamente revisar las presentaciones de P1 Security sobre seguridad en comunicaciones móviles