- Im Zuge der Überprüfung von Telekommunikations-Open-Source nach dem Salt-Typhoon-Vorfall wurde in der mit FreeSWITCH gebündelten XMLRPC-Bibliothek ein unauthenticated buffer overflow entdeckt
- Die Schwachstelle entsteht in Code, der eine vom Angreifer gelieferte Request-URI per
sprintf()in die 4096 Byte große Stack-Variable schreibt; unabhängig von Browser-Beschränkungen könnten Requests mit mehr als 4096 Zeichen möglich sein - SignalWire antwortete, dass im Februar 2025 drei Fix-PRs auf GitHub veröffentlicht wurden, erklärte aber zugleich, dass für die FreeSWITCH Community bis Sommer 2025 kein neues Release geplant ist
- In Shodan gab es etwa 8.300 Suchtreffer für FreeSWITCH, und Betreiber ohne Release-Tag müssen direkt per Source-Build oder Firewall-Blockierung reagieren
- Der Fall zeigt, dass sich die Risiken der Telekommunikationssicherheit nicht nur aus der Schwachstelle selbst ergeben, sondern auch durch Vulnerability-Management und Release-Reaktion verschärft werden; selbst nach der Zuweisung von CVE-2025-44087 am 30. April 2025 gab es kein FreeSWITCH-Release
Warum nach Salt Typhoon ein Blick auf FreeSWITCH fiel
- Ausgangspunkt war Ende 2024 die Meldung, dass die mutmaßlich mit der chinesischen Regierung verbundene Gruppe Salt Typhoon T-Mobile und andere Telekommunikationsanbieter kompromittiert hatte
- Zwar ließ sich ein Mobilfunknetz nicht direkt untersuchen, aber auf GitHub gab es viele Open-Source-Projekte mit Telekommunikationsbezug
- Es gab zwar frühere Arbeitserfahrungen mit Unternehmen, die Asterisk und FreeSWITCH einsetzen, aber keine tiefgehende Analyse von PBX, SIP oder Audio-Encoding
- Im Telekommunikationsbereich gibt es hervorragende C-Programmierer, eine alte Hacker-Community und die Tradition von Ingenieuren aus den Bell Labs, daher lag die Vermutung nahe, dass einfache Schwachstellen längst gefunden worden wären
- Doch direkt nach dem Öffnen des FreeSWITCH-Sourcecodes wurde eine Schwachstelle gefunden
Buffer Overflow im XMLRPC-HTTP-Request-Handler
- Der HTTP-Request-Handler der mit FreeSWITCH gebündelten XMLRPC-Bibliothek schreibt die URI in den Stack-Puffer fester Größe
z[4096] - Der problematische Code hat die Form
sprintf(z, "Index of %s" CRLF, uri);, unduristammt aus dem Path-Teil der Request-URI und ist daher vom Angreifer kontrollierbar - Gewöhnliche Browser unterstützen URLs mit mehr als 2048 Zeichen oft nicht gut, die relevanten RFCs erlauben aber meist etwa 8 KB, und Cloudflare unterstützt bis zu 32 KB
- Es ist daher plausibel, dass ein Angreifer eine Request-URI mit mehr als 4096 Zeichen senden kann, was in der XMLRPC-Bibliothek zu einem unauthenticated buffer overflow führt
- Eine mögliche Eskalation bis hin zu Remote Code Execution wird hier nicht behandelt
Art des Fixes und veröffentlichte Patches
- Der Fix besteht darin, statt
sprintf()snprintf()zu verwenden - Das entspricht grundlegender defensiver C-Programmierpraxis
- SignalWire erklärte, das Problem sei kürzlich behoben worden, und verwies auf folgende PRs
- Da die Patches bereits öffentlich auf GitHub verfügbar waren, wurde eine Veröffentlichung des Beitrags als vertretbar angesehen
Ablauf der Offenlegung und fehlendes Release
- Am 27. Januar 2025 wurden die Details der Schwachstelle an die in der FreeSWITCH-Sicherheitsrichtlinie genannte E-Mail-Adresse geschickt
- Am 7. Februar 2025 folgte eine weitere E-Mail mit der Nachfrage, ob der Bericht eingegangen sei
- Am selben Tag antwortete Andrey Volk, die Schwachstelle sei kürzlich behoben worden, und man solle sich die entsprechenden PRs ansehen
- Auf die Frage nach einem Release-Tag mit den Security-Fixes kam die Antwort, dass für die FreeSWITCH-Community-Releases bis Sommer 2025 nichts geplant ist
- Dadurch könnten Nutzer, die nicht für FreeSWITCH Advantage zahlen, bis zum regulären Release verwundbar bleiben
Ausmaß der Exponierung und Auswirkungen für Betreiber
- Zum damaligen Zeitpunkt zeigte Shodan etwa 8.300 Treffer für FreeSWITCH
- Da kaum anzunehmen ist, dass alle diese Instanzen Enterprise-Support bezahlen, könnten weltweit Tausende Telekommunikations-Stacks bis zum Sommer verwundbar bleiben
- Selbst wenn der Patch auf GitHub öffentlich ist, ist ein Update für normale Betreiber ohne Release-Tag nicht einfach
- Betreiber von FreeSWITCH sollten daher statt auf ein SignalWire-Release zu warten folgende Maßnahmen erwägen
- direkt aus dem Sourcecode neu bauen
- auf Firewall-Ebene den öffentlichen HTTP-Zugriff auf den FreeSWITCH-Stack blockieren
Strukturelle Probleme der Telekommunikationssicherheit
- In Gesprächen mit Kontakten aus der Telekommunikationsbranche hieß es sogar, dass die Reaktionsgeschwindigkeit von FreeSWITCH noch vergleichsweise schnell sei
- Auch im Dezember 2024 wurden erneut Warnungen zu einer seit 17 Jahren bestehenden SS7-Schwachstelle im Telefonnetz laut
- Nach dieser Erfahrung wurden Asterisk oder andere Software nicht weiter untersucht
- Das Fazit lautet, dass Telekommunikationssicherheit heute in einem schlechten Zustand ist
- Ein wesentlicher Grund scheint zu sein, dass es kaum finanzielle Anreize gibt, diese Systeme sicher zu machen
Späterer Stand
- In einem Update vom 30. April 2025 wurde dem gemeldeten Buffer Overflow CVE-2025-44087 zugewiesen
- Auch zu diesem Zeitpunkt gab es noch keinen Tag und kein Release von FreeSWITCH
1 Kommentare
Meinungen auf Hacker News
Der Autor räumt ein, keinerlei Erfahrung mit Carrier-Grade-Infrastruktur zu haben, aber der Verdacht an sich trifft im Großen und Ganzen zu.
Ich habe tatsächlich ziemlich viel 4G/5G-Penetrationstesting und Sicherheitsforschung bei mehreren großen Telekommunikationsanbietern gemacht, und auch wenn es Unterschiede zwischen Carriern und Ausrüstern gibt, ist es immer noch nahezu eine komplette Horrorshow.
Bis vor sehr kurzer Zeit bestand Sicherheit praktisch nur aus Security by Obscurity; die 4G/5G-Standards haben begonnen, das anzugehen, aber es bleiben immer noch riesige Lücken, die ernsthaft beunruhigend sind.
Es ist keine Übertreibung zu sagen, dass ein Bedrohungsakteur oberhalb eines mittleren Niveaus, der bei einem Carrier einen Brückenkopf aufbauen will, das schaffen kann; ich habe das beruflich mehrfach demonstriert.
Bei Ausrüstern aus einem bestimmten ostasiatischen Land ist die Qualität des Software-Stacks so niedrig, dass man sie fast als APT einstufen könnte, und Sicherheit existiert praktisch nicht.
Es gibt gute Gründe, warum westliche Länder sie verboten haben; die Software westlicher Ausrüster ist deutlich ausgereifter, liegt aber trotzdem mehrere Jahre hinter dem zurück, was wir als moderne Security Best Practices ansehen würden.
GCHQ kam zu dem Schluss, dass die Codequalität auf einem Niveau lag, das eine Prüfung unmöglich machte, und dass nicht einmal garantiert werden konnte, ob der bereitgestellte Quellcode tatsächlich der Code war, der auf den Geräten lief.
Der Grund war, dass Huawei selbst Updates einspielen konnte; meines Wissens ist diese Ausrüstung seit 2020 verboten: https://www.washingtonpost.com/world/national-security/brita...
Ich würde gern eines bei AliExpress kaufen und mir ansehen; wäre dieser Link ein brauchbarer Ausgangspunkt?
https://vulners.com/search/types/huawei
Ich kann wirklich nicht verstehen, warum Mobilfunkstandards im Jahr 2025 immer noch vorab geteilte Schlüssel verwenden.
RSA und Diffie-Hellman[1] gibt es seit Jahrzehnten, und auch CA-Infrastrukturen gibt es schon lange, aber SIM-Karten werden weiterhin mit einem vorab geteilten Schlüssel ausgeliefert, den nur die Karte und der Carrier kennen; danach basieren Authentifizierung und Verschlüsselung vollständig auf diesem Schlüssel.
Wenn der Carrier gehackt wird und die Schlüssel abfließen, kann man nichts mehr tun.
Schlimmer noch: Der SIM-Kartenhersteller muss diesen Schlüssel an den Carrier schicken, und wenn der Hersteller in einem anderen Land sitzt, kann er Forderungen einer ausländischen Regierung ausgesetzt sein; damit gibt es reichlich Gelegenheiten für einen Hack des Herstellers oder für Abfangen während der Übertragung.
Das fühlt sich wie eine NOBUS-Schwachstelle an: Wenn ein SIM-Hersteller oder ein Core-Netz-Ausrüster mit der NSA paktiert und die Schlüssel weitergibt, ließe sich potenziell Mobilfunkverkehr weltweit abhören.
[1] Mir ist klar, dass diese Algorithmen heute nicht mehr Best Practice sind und elliptische Kurven besser sind, aber selbst RSA wäre besser als der heutige Zustand.
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
„Laut streng geheimen NSA-Dokumenten, die Edward Snowden bereitgestellt hat, hackten amerikanische und britische Spione die internen Computernetze des weltgrößten SIM-Kartenherstellers und stahlen Verschlüsselungsschlüssel, die zum Schutz der Privatsphäre der Mobilfunkkommunikation weltweit verwendet werden.“
https://theintercept.com/2015/02/19/great-sim-heist/
Ich weiß nicht, ob das heute noch so ist, aber früher war ein Mobiltelefon kaum als sicheres Kommunikationsmittel anzusehen.
Vermutlich sollte man Gespräche eher über Ende-zu-Ende-verschlüsselte Datenkommunikation zwischen den Endgeräten führen.
Symmetrische Algorithmen haben außerdem den Vorteil, quantensicher zu sein.
Trotzdem würde ich mir 2025 zumindest ECC-Unterstützung wünschen, und inzwischen sollten die meisten Smartcards das standardmäßig unterstützen können.
Wenn man dem SIM-Kartenanbieter nicht vertrauen kann, gibt es praktisch keine Lösung.
Auch bei asymmetrischen Verfahren ändern sich die Angriffspfade nur etwas; wenn man der auf der Karte laufenden Software nicht traut, woher will man wissen, dass sie bei einem nichtdeterministischen Algorithmus nicht über die Wahl der Zufallszahlen den Klartext leakt?
Die Vorstellung, dass ein symmetrisches System durch RSA sicherer wird, ist schwach begründet; eher ist das Gegenteil der Fall.
Auch der Ausdruck „NOBUS-Schwachstelle“ ist hier besonders seltsam, denn die Vertrauenswurzel in einem solchen System ist der Carrier.
Man muss gar nicht erst fragen, ob ein US-Carrier mit US-Nachrichtendiensten „paktiert“; man sollte bereits davon ausgehen.
Betrüger sind große Kunden der Carrier, und wenn sie erwischt und gesperrt werden, kommen sie zurück, zahlen Aktivierungsgebühren für neue Anschlüsse und wiederholen denselben Ablauf.
Dank der Betrüger lassen sich außerdem Zusatzfunktionen upsellen, sodass man nochmals daran verdient, das Problem nicht zu lösen.
Dass Freeswitch, wie im Fazit des Blogposts beschrieben, seinen Community-Release-Zeitplan nicht ändert, überrascht mich überhaupt nicht.
Früher hatte Freeswitch einen starken Community-Geist, aber nachdem es vor einigen Jahren aggressiver kommerzialisiert wurde, änderte sich die Stimmung.
Danach musste man einen „Registrierungs“-Prozess durchlaufen, um auf Dinge zuzugreifen, die eigentlich öffentlich sein sollten; meiner Erinnerung nach wurden Dinge wie APT-Repositories hinter einer Registrierungswand versteckt.
Ich möchte mich nicht bei einem kommerziellen Unternehmen registrieren, nur um auf Inhalte einer Free-Software-Community zuzugreifen.
Denn in der Tech-Branche wissen alle, dass man, sobald man einem kommerziellen Unternehmen Informationen gibt, von Sales-Leuten mit Upselling und Cross-Selling belästigt und auf unerwünschte Mailinglisten gesetzt wird.
Ich habe auch in anderen Teilen der VoIP-Community gesehen, wie die Großzügigkeit gegenüber Open Source neu austariert wurde, und ehrlich gesagt ist es schwer, ihnen das vorzuwerfen.
Auch das Matrix.org-Team sprach in einem seiner FOSDEM’25-Vorträge in ähnlicher Weise darüber, dass kommerzielle Anbieter bei der Entwicklung Trittbrett fahren.
Es wäre wirklich nett, wenn sie auch das APT-Repository kostenlos aktualisieren würden, aber genau das wäre es eben: eine „nette Geste“.
Wenn man von ihrem Code abhängt, aber nicht für Support zahlen will, kann man die APT-Pakete selbst bauen.
Ich bin mir nicht sicher, welchen Community-Geist man bei einem Projekt erwarten sollte, das auf diese Weise von einem einzelnen Unternehmen gewartet wird.
Angesichts ausländischer Bedrohungsakteure, westlicher Bündnisse wie Five Eyes und des Drucks, die Zahlen ständig zu steigern, ist es plausibel anzunehmen, dass es online keine echte Anonymität gibt.
Wenn sie dich haben wollen, haben sie auch die Mittel dazu.
In der Praxis ist das nicht wesentlich anders als in der Zeit vor dem Internet.
Wenn du nicht abgefangen werden willst, musst du auf eine Weise verschlüsseln, auf die große Sicherheitsbehörden elektronisch nicht leicht zugreifen können.
Also etwa physische Zettel, mündliche Weitergabe oder Handzeichen.
Außerdem muss man bereit sein, die Konsequenzen dessen zu tragen, was man online sagt und tut, sobald ein staatlicher Akteur tatsächlich Ressourcen dafür bereitstellt, diese Daten zu nutzen.
Allein anhand des Artikels überzeugt mich die Schlussfolgerung „Telekommunikationssicherheit ist heute ein Chaos“ nicht vollständig.
Es wirkt eher so, als habe man Freeswitch willkürlich ausgewählt und einen Buffer Overflow gefunden.
Der „Telekommunikations-Stack“ kann verwundbar sein oder auch nicht, aber die hier vorgelegten Belege sind sehr schwach.
Von den Salt-Typhoon-Angriffen heißt es, sie hätten Cisco-Schwachstellen ausgenutzt, aber Analysten haben auch die Möglichkeit genannt, dass die Angreifer legitime Zugangsdaten verwendet haben: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
Das hat also nichts mit Freeswitch zu tun.
Oracle SBC ist schon im Standardverhalten oft instabil, und in dem Chaos einer TRouter-Implementierung, das Teams diese Woche ausliefert, gibt es mit Sicherheit Denial-of-Service-Bugs, die nicht sauber isoliert wurden.
Von dem Durcheinander rund um MF Tandem oder davon, dass fast jeder Carrier rohen, unverschlüsselten UDP-SIP-Traffic direkt ins Internet bläst, wollen wir gar nicht erst anfangen.
Es ist möglich, in diesem Bereich sichere Systeme zu bauen, aber die Realität ist, dass die meisten großen Carrier proprietäre, nicht modifizierbare Plattformen längst toter Unternehmen oder Projekte wie Nortel und Metaswitch betreiben, dazu Haufen technischer Schulden, die noch schlimmer sind als die alte, ungepatchte Hardware, aus der ihre Netze bestehen.
„Alles ist kaputt, und es gibt keinen Anreiz, es zu reparieren“ war nur eine Zusammenfassung.
Ehrlich gesagt sind diese Gespräche sehr schwer nachzuvollziehen, wenn man die Fachbegriffe nicht kennt, und ich verstehe dieses Gebiet selbst nicht gut genug, um eine unbeholfene Erklärung zu versuchen; deshalb habe ich es dabei belassen.
Ich hätte nie erwartet, dass mein Blog auf Hacker News auftaucht.
Das ist Code, der komplexe Netzwerkprotokolle mit mehreren Generationen Legacy parst, oft im Verborgenen geschrieben wird und meistens C/C++ ist.
Das kann ja unmöglich verwundbar sein. Klar.
Protokolle wie SS7 wurden ohne ein Konzept von Hackern oder böswilligen Akteuren entworfen.
Man kann Firewalls darüberlegen, aber das kollidiert mit gewünschten Funktionen, und selbst wenn nicht, erfordert es zusätzliche Investitionen.
DIAMETER ist besser, hat aber immer noch viele Lücken.
In den letzten Jahren ist Telekommunikationssicherheit zwar zu einer Priorität geworden und verbessert sich, aber man muss Jahrzehnte an Legacy-Hardware, -Software, -Firmware und Netzwerkdesign ummanteln.
Ich glaube nicht, dass irgendjemand in einem Telekommunikationsnetz Standard-Freeswitch unverändert betreibt, aber die Art von Problemen, die Freeswitch als altes Telekommunikationsprodukt hat, bei dem Sicherheit nicht so gründlich gesucht wurde, wie man es sich wünschen würde, findet man überall.
Es ist großartig, dass der Autor sich in seiner Freizeit den Code angesehen, einen Bug gefunden und gemeldet hat, und ich möchte das keineswegs verhindern.
Aber allein daraus, dass ein Maintainer einer einzelnen Software sich nicht gemäß den Best Practices der Security-Branche vor dem Autor verbeugt hat, zu folgern, „Telekommunikationssicherheit ist heute ein Chaos“, ist schwach belegt.
Wenn jemand mit einem Bug in deinem Code zu dir kommt, aber weder behauptet, dass er aktiv ausgenutzt wird, noch ein PoC liefert, um die Ausnutzbarkeit zu bestätigen: Warum sollte man ihn dann nicht einfach wie einen normalen Bug behandeln?
Man fixt ihn jetzt und nimmt ihn ins nächste Release auf.
Dass Leute die Änderungen sehen können? Ja, andere Änderungen können sie auch sehen.
Wenn jemand einen Exploit finden kann, dann viel Glück; der Meldende hat keinen gefunden.
In Linux-Distributionen passiert dasselbe.
Sicherheitsbugs werden gemeldet, und manchmal ist der Upstream-Autor nicht nur stur, sondern buchstäblich verstorben.
Wenn man es nach dem eigenen Zeitplan ändern will, kann man selbst ein Release machen.
Ein Bereich, in dem Freeswitch recht häufig zum Einsatz kommen dürfte, sind BigBlueButton-Installationen an Schulen und Universitäten.
Das ist ein virtuelles Klassenzimmersystem und wird vermutlich oft ohne Supportvertrag betrieben; darüber mache ich mir mehr Sorgen als über Carrier.
Ich frage mich, wie viele Leute das XML-RPC-Modul tatsächlich nutzen
Es wird standardmäßig nicht geladen
Korrektur: Laut Shodan sind es 468
Ich frage mich auch, ob
senddirectorydocumentim XML-RPC-Modul tatsächlich irgendwo genutzt wirdcurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";Hat jemand eine Idee, wie man es triggern könnte?
Wenn wenigstens ein PoC herauskäme, der einen Segfault verursacht, wäre die Chance auf ein Security-Release wohl größer
Das wirklich gute Hacking passiert bei der CAMEL-MAP-Injection
Damit steuert man alle möglichen interessanten Dinge: SMS, USSD und als Kronjuwel sogar Location Services
Viele „Bulk-SMS“-Anbieter auf wohlhabenden Karibikinseln oder an Orten wie Indonesien machen weit mehr als nur Spam zu verschicken
Sie ist also alt, und 2G wurde in den 1990ern entworfen
Ich weiß nicht so recht, was die Leute erwarten
Ehrlich gesagt kann man froh sein, dass es überhaupt funktioniert
Große Carrier betreiben im Core kein FreeSwitch oder Asterisk
Motorola stellt dieses Produkt zwar ein, aber im Feld existiert es noch
Das System, das ich betreue, ist stark per Firewall abgeschottet, aber ich vermute, dass das nicht überall so ist
Die meisten Unternehmen mit PBX, die mehr tun wollen als grundlegendes Call Routing und PSTN-Anbindung, dürften Third-Party-Tools einsetzen
Und viele dieser Tools sind auf FreeSWITCH, Asterisk oder Ähnlichem aufgebaut
Ich empfehle den Vortrag von P1 Security zur Sicherheit von Mobilfunknetzen ausdrücklich: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
Das Material ist alt, aber es gibt keinen Grund zu glauben, dass es besser geworden ist
Denn es gibt keinerlei Anreiz zur Verbesserung
Außerdem sind Software-Sicherheitslücken nur ein Teil des Problems; die andere Seite ist, dass Carrier Kontrolle und zentralen Zugang bereitwillig an den billigsten Anbieter auslagern: https://berthub.eu/articles/posts/5g-elephant-in-the-room/