La vulnerabilità critica in FreePBX consente un accesso remoto senza autenticazione

Dopo che la vulnerabilità in FreePBX è stata scoperta, è stata immediatamente sfruttata attivamente nell’ecosistema della telefonia IP. La comunità ha notato compromissioni di massa il 21 agosto 2025, e da allora sintomi identici e tracce di manomissioni hanno iniziato a comparire sui forum. I ricercatori di watchTowr Labs hanno confermato che si tratta di un attacco remoto senza autenticazione correlato al modulo Endpoint commerciale e a un errore nell’elaborazione del class autoloader.

Al problema è stato assegnato l’identificatore CVE-2025-57819. FreePBX è un’interfaccia web per Asterisk utilizzata da tutti, dagli appassionati di home office ai fornitori di servizi e ai sistemi aziendali, quindi l’impatto si estende oltre i pannelli interni, consentendo l’accesso a chiamate, segreteria telefonica e registrazioni delle chiamate.

Il primo campanello d’allarme, il 25 agosto, è stato il crash di massa dell’interfaccia con un errore PHP relativo a una classe Symfony mancante. Il giorno successivo, uno degli amministratori ha mostrato un file .clean.sh improvvisamente apparso sul server. Lo script ha analizzato i log in “/var/log/*”, ha cancellato selettivamente le righe in cui potevano esserci riferimenti a web shell e nomi di servizi, per poi cancellarsi. Tale pulizia dei log è un tipico segnale di post-exploitation, quando gli aggressori cancellano le tracce e complicano l’analisi dell’incidente.

WatchTowr ha implementato un sensore FreePBX completamente monitorato e ne ha confrontato il comportamento prima e dopo le correzioni. È emerso che l’accesso diretto al codice vulnerabile si trova all’interno del modulo Endpoint e che il bundle di routing /admin/ajax.php e il meccanismo di caricamento automatico delle classi svolgono un ruolo cruciale. Il codice sorgente di FreePBX prevede un controllo class_exists per il valore del parametro del modulo e, con il valore di caricamento automatico PHP predefinito, questa chiamata passa una stringa all’utente fpbx_framework_autoloader.

Se si invia un modulo del tipo “FreePBXmodulesendpointajax“, l’autoloader raccoglie il percorso “/admin/modules/endpoint/ajax.php” e include semplicemente il file corrispondente, prima che la sessione venga verificata. In questo modo, il codice del modulo viene avviato senza login, ma a quel punto entra in gioco l’errore di validazione in Endpoint: l’iniezione SQL nei parametri del gestore ajax consente di manipolare il database di FreePBX.

In pratica, gli aggressori hanno prima creato un amministratore nascosto “ampuser” – ciò è confermato dalle richieste honeypot catturate, in cui un’operazione INSERT è stata iniettata nella tabella ampusers nel parametro brand. Quindi, per passare dall’accesso al database all’esecuzione di comandi, hanno aggiunto un record alla tabella cron_jobs con la pianificazione standard “* * * * *”, specificando il payload nel campo command – in questo modo, il codice è stato eseguito una volta al minuto per conto delle utilità di sistema di FreePBX. Questa catena watchTowr è stata riprodotta in laboratorio e, per verificare le tracce, è stato pubblicato un generatore di artefatti di rilevamento, che alternativamente tenta di registrare la web shell tramite cron o di aggiungere un nuovo utente.

Gli sviluppatori di FreePBX hanno risposto prontamente e hanno raccomandato di chiudere temporaneamente l’interfaccia di amministrazione tramite elenchi IP o un firewall e di installare aggiornamenti non pianificati per il modulo Endpoint. Per FreePBX 16/17, è stato suggerito il comando “fwconsole ma downloadinstall endpoint –edge”, per PBXAct 16 – “–tag 16.0.88.19”, per PBXAct 17 – “–tag 17.0.2.31”.

Nella descrizione dell’incidente, il team di FreePBX ha specificamente osservato che, a partire dal 21 agosto 2025, una persona sconosciuta ha iniziato ad accedere ai sistemi versione 16 e 17 accessibili da Internet senza un adeguato filtraggio e, dopo il login iniziale e una serie di passaggi sono stati concessi i diritti di root. Allo stesso tempo, watchTowr sottolinea che la correzione modulare risolve l’SQL injection, ma la causa principale, ovvero il caricamento automatico nel kernel, richiede ancora una riconsiderazione, poiché la connessione pre-autenticazione dei singoli file “.php” all’interno di “admin/modules” rimane una via accessibile.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.