-
Die Verwundbarkeit von Telekommunikations-Stacks
- Hintergrund: Ende letzten Jahres wurde eine Gruppe namens „Salt Typhoon“ für einen Hack bei T-Mobile und anderen Telekommunikationsunternehmen verantwortlich gemacht. Dieser Vorfall gab den Anstoß, die Sicherheit von Open-Source-Software im Telekommunikationsbereich zu überprüfen.
-
Buffer Overflow in der XMLRPC-Bibliothek von FreeSWITCH
-
Problem: In der XMLRPC-Bibliothek von FreeSWITCH schreibt der HTTP-Request-Handler eine URI beliebiger Länge in eine 4096-Byte-Stack-Variable. Dadurch entsteht eine Schwachstelle, bei der ein Angreifer eine URI mit mehr als 4096 Zeichen senden und so einen Buffer Overflow auslösen kann.
-
Lösung: Es sollte defensives C-Programming mit
snprintf()angewendet werden.
-
-
Soatoks Versuch der Offenlegung der Schwachstelle
-
2025-01-27: Die Details der Schwachstelle wurden an die in der Sicherheitsrichtlinie von FreeSWITCH angegebene E-Mail-Adresse gesendet.
-
2025-02-07: Es wurde eine Follow-up-E-Mail gesendet, um zu prüfen, ob der Bericht eingegangen ist.
-
Antwort: Andrey Volk antwortete, dass die Schwachstelle kürzlich behoben worden sei. Allerdings wurde keine neue Version mit dem Sicherheitsfix getaggt.
-
-
Das entstandene Problem
- Ein Mitarbeiter von SignalWire erklärte, dass Nutzer, die FreeSWITCH Advantage nicht gekauft haben, bis zum Sommer verwundbar bleiben würden. Das bedeutet, dass Tausende von Telekommunikations-Stacks in einem verwundbaren Zustand verbleiben könnten.
-
Systemisches Problem der Telekommunikationssicherheit
-
Ursache des Problems: Es gibt zu geringe wirtschaftliche Anreize, in die Sicherheit von Telekommunikationssystemen zu investieren. Das ist ein Grund, warum die Telekommunikationssicherheit auch heute noch schwach ist.
-
Mögliche Zukunft: Es könnte ein konkurrierendes Produkt zu FreeSWITCH in Rust entwickelt werden, oder es könnte politischer Wille entstehen, in die Sicherheit der US-Telekommunikationsinfrastruktur zu investieren.
-
-
Abschließende Gedanken
- Dieses Problem ist zwar technisch gesehen einfach, doch dahinter könnte ein größeres Problem liegen. Die Reaktion von SignalWire war enttäuschend, dennoch erfolgte innerhalb von 90 Tagen eine Antwort, und der Fehler wurde auf GitHub behoben. Es könnten Maßnahmen erwogen werden, etwa den öffentlichen HTTP-Zugriff auf den FreeSWITCH-Stack auf Firewall-Ebene zu blockieren.
1 Kommentare
Hacker-News-Kommentar
Der Verfasser räumt ein, keine Erfahrung mit Infrastruktur auf Carrier-Niveau zu haben, aber sein Verdacht ist im Kern richtig
Es ist unverständlich, dass selbst 2025 in Mobilfunkstandards noch Pre-Shared Keys verwendet werden
Dass Freeswitch laut dem Fazit des Blogposts nicht von seinem Community-Release-Zeitplan abrückt, ist überhaupt nicht überraschend
Angesichts ausländischer Bedrohungsakteure, Five Eyes/anderer westlicher Abkommen und des Drucks zur Umsatzsteigerung ist es fair anzunehmen, dass es im Internet keine echte Anonymität gibt
Ein Bereich, in dem Freeswitch häufig ohne Support-Vertrag eingesetzt wird, sind BigBlueButton-Installationen an Schulen und Universitäten
Ich bin nicht völlig überzeugt von der Behauptung, dass "Telekommunikationssicherheit heute furchtbar ist"
Ich frage mich, wie viele Leute das XML-RPC-Modul verwenden
Mit CAMEL-MAP-Injection lassen sich wirklich gute Hacks durchführen
Große Carrier betreiben FreeSwitch oder Asterisk nicht im Kernnetz
Ich empfehle dringend, sich die Präsentationen von P1 Security zur Sicherheit mobiler Telekommunikation anzusehen