- Lors de l’examen de l’open source télécom après la compromission Salt Typhoon, un débordement de tampon sans authentification a été découvert dans la bibliothèque XMLRPC intégrée à FreeSWITCH
- La vulnérabilité provient d’un code qui écrit l’URI de requête fourni par l’attaquant dans une variable de pile de 4 096 octets avec
sprintf(); indépendamment des limites des navigateurs, des requêtes de plus de 4 096 caractères peuvent être possibles - SignalWire a répondu que trois PR de correction avaient été publiées sur GitHub en février 2025, mais a indiqué qu’aucune nouvelle version de FreeSWITCH Community n’était prévue avant l’été 2025
- Shodan affichait environ 8 300 résultats pour FreeSWITCH, et les opérateurs dépourvus de tag de version doivent réagir eux-mêmes en compilant depuis les sources ou en bloquant via pare-feu
- Ce cas montre que les risques pour la sécurité des télécoms ne viennent pas seulement des vulnérabilités elles-mêmes, mais aussi de la gestion des vulnérabilités et de la réponse en matière de releases ; même après l’attribution de CVE-2025-44087 le 30 avril 2025, aucune release FreeSWITCH n’était disponible
Pourquoi examiner FreeSWITCH après Salt Typhoon
- Fin 2024, le point de départ a été l’annonce selon laquelle le groupe Salt Typhoon, présenté comme lié au gouvernement chinois, avait compromis T-Mobile et d’autres opérateurs télécoms
- Il n’était pas possible d’enquêter directement sur les réseaux des opérateurs mobiles, mais GitHub hébergeait de nombreux projets open source liés aux télécoms
- Il y avait eu par le passé une expérience de travail avec des entreprises utilisant Asterisk et FreeSWITCH, mais pas d’analyse approfondie des PBX, de SIP ou de l’encodage audio
- Dans le domaine des télécoms, la présence d’excellents programmeurs C, d’anciennes communautés de hackers et d’une tradition d’ingénieurs issus des Bell Labs laissait penser que les vulnérabilités simples auraient déjà été découvertes
- Pourtant, une vulnérabilité a été trouvée juste après l’ouverture du code source de FreeSWITCH
Débordement de tampon dans le gestionnaire de requêtes HTTP XMLRPC
- Le gestionnaire de requêtes HTTP de la bibliothèque XMLRPC intégrée à FreeSWITCH écrit l’URI dans un tampon de pile de taille fixe
z[4096] - Le code problématique est de la forme
sprintf(z, "Index of %s" CRLF, uri);, eturiprovenant de la partie path de la Request URI, il est contrôlable par l’attaquant - Les navigateurs courants prennent souvent mal en charge les URL de plus de 2 048 caractères, mais les RFC concernées autorisent pour la plupart environ 8 Ko, et Cloudflare prend en charge jusqu’à 32 Ko
- Il est raisonnable de considérer qu’un attaquant peut envoyer une Request URI de plus de 4 096 caractères, condition qui conduit à un débordement de tampon sans authentification dans la bibliothèque XMLRPC
- L’extension vers une exécution de code à distance n’est pas abordée
Méthode de correction et patchs publiés
- La correction consiste à utiliser
snprintf()au lieu desprintf() - Cela relève des pratiques de base de la programmation défensive en C
- SignalWire a indiqué que le problème avait été corrigé récemment et a fourni les PR suivantes
- Comme les patchs étaient déjà publics sur GitHub, la publication d’un billet public a été jugée possible
Processus de divulgation et absence de release
- Le 27 janvier 2025, les détails de la vulnérabilité ont été envoyés à l’adresse e-mail indiquée dans la politique de sécurité de FreeSWITCH
- Le 7 février 2025, un e-mail de relance a été envoyé pour vérifier si le rapport avait bien été reçu
- Le même jour, Andrey Volk a répondu que la vulnérabilité avait été corrigée récemment et a renvoyé vers les PR concernées
- Interrogé sur le calendrier d’un tag de release incluant les nouveaux correctifs de sécurité, il a été répondu qu’aucune release de FreeSWITCH Community n’était prévue avant l’été 2025
- En conséquence, les utilisateurs qui ne paient pas FreeSWITCH Advantage peuvent rester vulnérables jusqu’à la prochaine release régulière
Ampleur de l’exposition et impact pour les opérateurs
- À l’époque, Shodan affichait environ 8 300 résultats pour FreeSWITCH
- Comme il est difficile de penser que toutes ces instances paient un support entreprise, des milliers de piles télécoms dans le monde pourraient rester vulnérables jusqu’à l’été
- Même si le patch est public sur GitHub, l’absence de tag de release rend la mise à jour difficile pour les opérateurs ordinaires
- Les opérateurs FreeSWITCH devraient envisager les mesures suivantes au lieu d’attendre une release de SignalWire
- recompiler directement depuis les sources
- bloquer au niveau du pare-feu l’accès HTTP public à la pile FreeSWITCH
Problème structurel de la sécurité des télécoms
- Lors d’une discussion avec une connaissance du secteur télécom, la réaction a été que la réponse de FreeSWITCH était même plutôt rapide
- En décembre 2024, une alerte a de nouveau été émise au sujet d’une vulnérabilité SS7 présente dans le réseau téléphonique depuis 17 ans
- Après cette expérience, aucun examen supplémentaire d’Asterisk ou d’autres logiciels n’a été mené
- En conclusion, la sécurité des télécoms est aujourd’hui dans un mauvais état
- Le fait qu’il y ait peu d’incitations financières à sécuriser ces systèmes semble être une cause majeure
État ultérieur
- Dans la mise à jour du 30 avril 2025, CVE-2025-44087 a été attribuée au débordement de tampon signalé
- Au même moment, FreeSWITCH ne disposait toujours d’aucun tag ni d’aucune release
1 commentaires
Avis de Hacker News
L’auteur reconnaît n’avoir aucune expérience des infrastructures de niveau opérateur télécom, mais ses soupçons sont globalement fondés
Pour avoir réalisé pas mal de tests d’intrusion et de recherches en sécurité sur la 4G/5G auprès de plusieurs grands opérateurs, même si cela varie selon les opérateurs et les fournisseurs d’équipements, cela reste proche d’un véritable spectacle d’horreur
Jusqu’à très récemment, la sécurité se résumait pratiquement à de la sécurité par l’obscurité ; les standards 4G/5G ont commencé à traiter le sujet, mais il reste encore des failles suffisamment énormes pour être très préoccupantes
Il n’est pas exagéré de considérer qu’un acteur malveillant d’un niveau intermédiaire ou supérieur voulant établir une tête de pont chez un opérateur peut y parvenir, et je l’ai démontré plusieurs fois dans un cadre professionnel
Certains fournisseurs d’équipements d’un pays d’Asie de l’Est ont des piles logicielles d’une qualité si faible qu’on pourrait presque les classer comme APT, et la sécurité y est pratiquement inexistante
Il y a de bonnes raisons pour lesquelles les pays occidentaux les ont interdits ; les logiciels des fournisseurs occidentaux sont beaucoup plus matures, mais restent tout de même en retard de plusieurs années par rapport à ce que nous considérerions comme des bonnes pratiques modernes de sécurité
Le GCHQ a estimé que la qualité du code était à un niveau impossible à auditer, et qu’il n’était même pas possible de garantir que le code source fourni était bien celui exécuté sur les équipements réels
C’était parce que Huawei pouvait les mettre à jour directement ; il me semble que ces équipements sont interdits depuis 2020 : https://www.washingtonpost.com/world/national-security/brita...
J’aimerais en acheter un sur AliExpress pour l’examiner ; ce lien serait-il un bon point de départ ?
https://vulners.com/search/types/huawei
Je ne comprends vraiment pas pourquoi, en 2025, les standards de téléphonie mobile utilisent encore des clés prépartagées
RSA et Diffie-Hellman[1] existent depuis des décennies, et les infrastructures d’autorités de certification aussi, mais les cartes SIM sont toujours émises avec une clé prépartagée connue uniquement de la carte et de l’opérateur, puis toute l’authentification et le chiffrement reposent sur cette clé
Si l’opérateur est piraté et que la clé fuit, il n’y a plus rien à faire
Pire encore, cette clé doit être envoyée par le fabricant de cartes SIM à l’opérateur ; si le fabricant se trouve dans un autre pays, il peut être soumis aux exigences d’un gouvernement étranger, ce qui crée largement des occasions de piratage du fabricant ou d’interception pendant le transfert
Cela ressemble à une vulnérabilité NOBUS : si un fabricant de SIM ou un fournisseur d’équipements de cœur de réseau collabore avec la NSA et transmet les clés, il devient potentiellement possible d’écouter le trafic mobile du monde entier
[1] Je sais que ces algorithmes ne sont plus considérés comme des bonnes pratiques et que les courbes elliptiques sont préférables, mais même RSA serait mieux que la situation actuelle
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
« Selon des documents top secret de la NSA fournis par Edward Snowden, des espions américains et britanniques ont piraté le réseau informatique interne du plus grand fabricant mondial de cartes SIM et volé les clés de chiffrement utilisées pour protéger la confidentialité des communications mobiles dans le monde entier »
https://theintercept.com/2015/02/19/great-sim-heist/
Je ne sais pas si c’est encore le cas aujourd’hui, mais à l’époque, il était difficile de considérer le téléphone mobile comme un moyen de communication sûr
Il faut probablement plutôt discuter via des communications de données chiffrées de bout en bout entre terminaux
Les algorithmes à clé symétrique ont aussi l’avantage d’être résistants au quantique
Cela dit, en 2025, j’aimerais qu’au minimum ECC soit pris en charge, et la plupart des cartes à puce devraient désormais pouvoir le faire de base
Si l’on ne peut pas faire confiance aux fabricants de cartes SIM, il n’y a en pratique pas de solution
Même avec une approche asymétrique, le vecteur d’attaque ne fait que changer un peu : si l’on ne fait pas confiance au logiciel qui tourne sur la carte, comment savoir qu’un algorithme non déterministe ne fait pas fuiter le texte en clair via le choix des nombres aléatoires ?
L’idée qu’ajouter RSA à un système symétrique le rendrait plus sûr est peu fondée, et c’est plutôt l’inverse
L’expression « vulnérabilité NOBUS » est particulièrement étrange, puisque la racine de confiance de ce type de système est l’opérateur
Il n’est même pas nécessaire de se demander si un opérateur américain a « collaboré » avec les agences de renseignement américaines : il faut déjà partir du principe que oui
Les escrocs sont de gros clients des opérateurs : quand ils se font attraper et bloquer, ils reviennent, paient les frais d’ouverture d’une nouvelle ligne, et recommencent le même processus
Les escrocs permettent aussi de vendre davantage de fonctionnalités additionnelles, si bien que ne pas résoudre le problème rapporte encore de l’argent
Comme le conclut l’article de blog, il n’est pas du tout surprenant que Freeswitch ne change pas son calendrier de publication communautaire.
L’ancien Freeswitch avait un fort esprit communautaire, mais l’ambiance a changé il y a quelques années après une commercialisation plus agressive.
Depuis, il fallait passer par une procédure d’« inscription » pour accéder à ce qui devrait être public et, de mémoire, il me semble que quelque chose comme les dépôts APT avait été caché derrière ce mur d’inscription.
Je n’ai pas envie de m’inscrire auprès d’une entreprise commerciale pour accéder à du contenu communautaire de logiciel libre.
Parce que tout le monde sait que, dans la tech, quand on donne des informations à une entreprise commerciale, ses commerciaux viennent vous harceler avec de l’upsell et du cross-sell, et vous ajoutent à des listes de diffusion non sollicitées.
J’ai aussi vu d’autres pans de la communauté VoIP réajuster leur générosité envers l’open source et, honnêtement, il est difficile de leur en vouloir.
L’équipe Matrix.org a évoqué un problème similaire dans l’une de ses présentations à FOSDEM’25 : des fournisseurs commerciaux qui profitent du développement sans contribuer.
Ce serait vraiment appréciable qu’ils mettent aussi gratuitement à jour les dépôts APT, mais ce n’est justement que cela : quelque chose dont on pourrait leur être reconnaissant.
Si vous dépendez de leur code sans vouloir payer les coûts de support, vous pouvez construire vous-même les paquets APT.
Je ne sais pas très bien quel esprit communautaire on devrait attendre d’un projet maintenu de cette façon par une seule entreprise.
Vu les acteurs étrangers de la menace, les alliances occidentales comme les Five Eyes et la pression permanente pour faire monter les chiffres, il est raisonnable de considérer qu’il n’existe pas de véritable anonymat en ligne.
S’ils vous veulent, ils ont aussi les moyens de vous attraper.
En réalité, ce n’est pas très différent de l’époque d’avant Internet.
Si vous ne voulez pas être intercepté, il faut chiffrer d’une manière qui ne soit pas facilement accessible électroniquement aux grandes agences de sécurité.
Des bouts de papier physiques, le bouche-à-oreille, des gestes, ce genre de choses.
Il faut aussi être prêt à assumer les conséquences de ce qu’on dit et fait en ligne lorsqu’un acteur étatique décide effectivement d’allouer les ressources nécessaires pour exploiter ces données.
À la seule lecture de l’article, je ne suis pas entièrement convaincu par la conclusion selon laquelle « la sécurité des télécoms aujourd’hui est un désastre ».
Cela ressemble plutôt au fait d’avoir choisi Freeswitch plus ou moins au hasard et d’y avoir trouvé un buffer overflow.
La « pile télécom » est peut-être vulnérable, ou peut-être pas, mais les éléments présentés ici sont très faibles.
L’attaque Salt Typhoon aurait exploité des vulnérabilités Cisco, mais des analystes ont aussi avancé que les attaquants avaient peut-être utilisé des identifiants légitimes : https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
Cela n’a donc rien à voir avec Freeswitch.
L’Oracle SBC est souvent instable rien que dans son comportement de base, et il y a forcément des bugs de déni de service mal isolés dans le bazar d’implémentation de TRouter que Teams livre cette semaine.
Ne parlons même pas du chaos des MF Tandem, ni du fait que presque tous les opérateurs laissent circuler sur Internet du trafic SIP UDP brut et non chiffré.
Il est possible de construire des systèmes sûrs dans ce domaine, mais la réalité est que la plupart des grands opérateurs exploitent des montagnes de dette technique pires encore que les vieux équipements non patchés qui composent leurs réseaux, avec des plateformes propriétaires et impossibles à modifier issues d’entreprises ou de projets morts depuis longtemps, comme Nortel ou Metaswitch.
« Tout est cassé et personne n’a d’incitation à réparer » n’est qu’un résumé.
Honnêtement, ces conversations sont très difficiles à suivre si l’on ne connaît pas le jargon, et je ne comprends pas assez bien ce domaine pour vouloir essayer de l’expliquer maladroitement, donc je me suis limité à cela.
Je ne m’attendais absolument pas à ce que mon blog se retrouve sur Hacker News.
C’est du code qui parse des protocoles réseau complexes avec plusieurs générations de legacy, souvent écrit à huis clos, et généralement en C/C++.
Bien sûr que cela ne peut pas être vulnérable. Évidemment.
Des protocoles comme SS7 ont été conçus sans la notion de hackers ou d’acteurs malveillants.
On peut ajouter des pare-feu par-dessus, mais cela entre en conflit avec les fonctionnalités voulues et, même quand ce n’est pas le cas, cela demande des investissements supplémentaires.
DIAMETER est meilleur, mais reste plein de trous.
Ces dernières années, la sécurité télécom est devenue une priorité et les choses s’améliorent, mais il faut envelopper des décennies de matériel, de logiciels, de firmware et de conceptions réseau hérités.
Je ne pense pas que quiconque fasse tourner un Freeswitch standard tel quel dans un réseau télécom, mais les types de problèmes présents dans Freeswitch — un vieux produit télécom dans lequel on n’a pas autant cherché la sécurité qu’on l’aurait espéré — se retrouvent partout.
C’est très bien que l’auteur ait regardé le code sur son temps libre, trouvé des bugs et les ait signalés, et je ne voudrais absolument pas décourager cela.
Mais le fait qu’un mainteneur d’un seul logiciel ne se soit pas plié aux attentes de l’auteur selon les bonnes pratiques de l’industrie de la sécurité est un fondement bien faible pour affirmer que « la sécurité des télécoms aujourd’hui est un désastre ».
Si quelqu’un vous apporte un bug dans votre code sans prétendre qu’il est activement exploité, et sans fournir de PoC permettant d’en confirmer l’exploitabilité, pourquoi ne pas le traiter comme un bug ordinaire ?
On le corrige maintenant et on l’inclut dans la prochaine release.
Les gens peuvent voir les changements ? Oui, comme ils peuvent voir tous les autres changements.
S’ils arrivent à trouver un exploit, tant mieux pour eux ; la personne qui l’a signalé n’en a pas trouvé.
La même chose arrive dans les distributions Linux.
Des bugs de sécurité sont signalés, et parfois l’auteur upstream n’est pas simplement têtu, il est littéralement décédé.
Si vous voulez que cela change selon votre propre calendrier, publiez vous-même une release.
Le domaine où Freeswitch me semble susceptible d’être assez souvent utilisé, ce sont les installations BigBlueButton dans les écoles et les universités.
C’est un système de classe virtuelle, et il est sans doute souvent utilisé sans contrat de support ; cela m’inquiète davantage que les opérateurs télécoms.
Je me demande combien de personnes utilisent réellement le module XML RPC
Il n’est pas chargé par défaut
Correction : 468 selon Shodan
Je me demande aussi si
senddirectorydocumentest réellement utilisé dans le module XML RPCcurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";Des idées sur la façon de le déclencher ?
Je pense qu’il y aurait plus de chances d’avoir une release de sécurité s’il existait au moins un PoC provoquant un segfault
Le vrai hack intéressant se passe avec l’injection CAMEL MAP
Elle permet de contrôler toutes sortes de choses intéressantes : SMS, USSD et, joyau de la couronne, les services de localisation
Beaucoup d’acteurs de « SMS en masse » dans des îles riches des Caraïbes ou dans des endroits comme l’Indonésie font bien plus que de l’envoi de spam
Elle est donc ancienne, et la 2G a été conçue dans les années 1990
Je ne sais pas trop à quoi les gens s’attendent
Franchement, on peut déjà s’estimer heureux que ça fonctionne
Les grands opérateurs télécoms ne font pas tourner FreeSwitch ou Asterisk dans leur cœur de réseau
Bien sûr, Motorola est en train d’arrêter ce produit, mais il est encore présent sur le terrain
Celui dont je m’occupe est fortement protégé par un pare-feu, mais je doute que ce soit le cas de tous
La plupart des entreprises disposant d’un PBX et voulant faire plus que du routage d’appels de base et de la connexion PSTN utilisent probablement des outils tiers
Et une bonne partie de ces outils sont construits sur FreeSWITCH, Asterisk ou équivalent
Je recommande vivement la présentation de P1 Security sur la sécurité des télécoms mobiles : https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
C’est ancien, mais il n’y a aucune raison de penser que les choses se sont améliorées
Parce qu’il n’y a aucun incitatif à les améliorer
En plus, les failles de sécurité logicielle ne sont qu’une partie du problème ; l’autre, c’est que les opérateurs télécoms externalisent volontiers le contrôle et l’accès critique au moins-disant : https://berthub.eu/articles/posts/5g-elephant-in-the-room/