Sangoma Technologies warnt vor einer aktiv ausgenutzten Schwachstelle in FreePBX, der populären Asterisk-basierten Open-Source-PBX. Die Lücke CVE-2025-57819 ist mit CVSS 10.0 maximal bewertet und betrifft vor allem Installationen, deren Admin-Konsole aus dem Internet erreichbar ist.
Zero-Day in der FreePBX-Adminoberfläche: Ablauf und Angriffsvektor
Laut Herstellerbeobachtungen richten Angreifer seit dem 21. August 2025 Kampagnen gegen öffentlich exponierte FreePBX-Adminoberflächen. Auslöser ist eine Kombination aus unzureichender Eingabesäuberung und logischen Schwächen in der Authentisierung. Das ermöglicht einen Administrator-Bypass, Manipulation der Datenbank und in der Folge Remote Code Execution (RCE).
Betroffene Versionen und Angriffsoberfläche
Bestätigt sind Angriffe auf FreePBX 16 und 17. Besonders gefährdet sind Instanzen mit offen publizierter Admin-Konsole. Sangoma hat kurzfristig ein Update für das EDGE-Modul ausgeliefert und weitere Patches bereitgestellt. Betreibern wird geraten, den Zugriff konsequent zu beschränken (Allowlist/VPN) und externe Erreichbarkeit zu unterbinden.
Technischer Kontext und Risikoanalyse: Von Admin-Bypass zu RCE
Durch das Ausnutzen der Validierungs- und Autorisierungsfehler erhalten Angreifer unbefugten Zugriff auf das Admin-Interface. Praktisch erlaubt dies Konfigurationsänderungen in der PBX, das Anlegen oder Ersetzen von Konten, die Manipulation von SIP-Trunks und Routing-Regeln sowie – je nach Umgebung – die Ausführung beliebiger Befehle als asterisk mit möglicher Privilegienausweitung bis root.
Die Folgen reichen von Toll Fraud (betrügerische Auslandsgespräche) über Dienstunterbrechungen und Abfluss sensibler Call Detail Records (CDR) bis hin zu einem Sprungbrett für laterale Bewegungen im Netzwerk. Das Muster entspricht etablierten MITRE-ATT&CK-Techniken wie Exploit Public-Facing Application (T1190), Valid Accounts (T1078) und Privilege Escalation (z. B. T1068).
Patches und empfohlene Schutzmaßnahmen für FreePBX
1) Unverzüglich patchen: Auf die neuesten, unterstützten FreePBX-Versionen und Module aktualisieren; verfügbare Korrekturen im Module Admin prüfen und umgehend einspielen.
2) Zugriff hart beschränken: Firewall aktivieren, Admin-Zugriff auf vertrauenswürdige IPs/Sites per Allowlist begrenzen; bevorzugt ausschließlich per VPN; externe Veröffentlichung der Admin-Konsole vermeiden.
3) Perimeter härten: Zusätzliche HTTP-Auth vorschalten, Reverse-Proxy einsetzen, GeoIP-Restriktionen prüfen und Telemetrie auf Anomalien schärfen.
4) Angriffsfläche verkleinern: Nicht benötigte Module deaktivieren, Gast-/Altkonten entfernen, Least Privilege strikt durchsetzen und regelmäßige, geprüfte Konfigurations-Backups pflegen.
Indikatoren eines Angriffs (IOCs) und schnelle Erstprüfung
Betreiber mit exponierter Admin-Konsole sollten eine Sofortprüfung durchführen: /var/log/httpd/* oder /var/log/nginx/* auf verdächtige POST-Requests gegen Admin-Endpunkte und ungewöhnliche Quell-IP-Adressen untersuchen.
In /var/log/asterisk/full nach atypischen Befehlen und Konfigurationsänderungen suchen; auf Änderungen an SIP-Trunks, Routing-Tabellen und auffälligen ausgehenden Call-Spikes achten.
Neue Admin-Konten, geänderte Berechtigungen, manipulierte cron-Jobs sowie neue oder geänderte PHP-Skripte in FreePBX-Webverzeichnissen prüfen. Unerwartete ausgehende Verbindungen der PBX zu unbekannten IPs sind ein weiteres Warnsignal.
Berichte aus der Praxis: Ausmaß und Missbrauch
Mehrere Organisationen melden bereits Kompromittierungen. Ein FreePBX-Forenbeitrag beschreibt einen Vorfall, der rund 3000 SIP-Erweiterungen und 500 Trunks betraf und zu einer vollständigen Sperrung des Admin-Zugriffs sowie einer Wiederherstellung führte. Ein Administrator auf Reddit berichtet von Befehlsausführung unter dem Benutzer asterisk, was die Fortsetzung des Angriffs erheblich erleichterte.
Unternehmen sollten Hersteller-Patches sofort einspielen, die Admin-Konsole konsequent hinter VPN und IP-Allowlists verbergen, Logging/Auditing aktivieren und Alarme für ungewöhnliche ausgehende Anrufe einrichten. Bei Verdachtsfällen ist ein strukturierter Incident-Response-Prozess angeraten: betroffenen Host isolieren, Forensik, Zugangsdaten zurücksetzen, Konfigurationsintegrität verifizieren und kontrolliert aus vertrauenswürdigen Backups wiederherstellen.
