Quattro vulnerabilità chiuse su una piattaforma che comanda impianti veri.
Una scansione aveva trovato quattro vulnerabilità sulla piattaforma con cui un gruppo del settore geotermico monitora gli impianti dei clienti. La richiesta era passare a PHP 8.4. Abbiamo dimostrato perché non si poteva e chiuso le vulnerabilità per un'altra strada, senza toccare la logica dell'applicazione.
Un gruppo che progetta e installa impianti geotermici e di climatizzazione monitora gli impianti dei clienti con una piattaforma web su CakePHP 2.9.5. Dovevamo chiudere tre CVE di PHP e una di jQuery con tempi e budget stretti. Abbiamo verificato che il framework non può girare su PHP 8, portato il sito sull'ultima versione di PHP 7.4 correggendo il gestore che serviva davvero il dominio, aggiornato jQuery nelle viste e proposto una migrazione vera come progetto separato.
Contesto
Il gruppo progetta e installa impianti geotermici e di climatizzazione, e con una piattaforma web segue gli impianti dei clienti: termostati, pompe di calore, ventilazione, contabilizzazione dell'energia, programmazione di riscaldamento e acqua sanitaria, allarmi e grafici, con integrazioni per Google Home e Alexa. Per il gruppo gestiamo anche l'account AWS, i siti e la posta.
Il problema
Una scansione aveva segnalato CVE-2022-37454, CVE-2022-31629 e CVE-2017-8923 su PHP e CVE-2020-11022 su jQuery. L'applicazione è scritta su CakePHP 2.9.5, un framework fermo da anni, e la richiesta iniziale era di portarla a PHP 8.4. Tempi e budget erano stretti, e un errore su un sistema che parla con impianti di riscaldamento ha conseguenze fisiche.
Cosa abbiamo fatto
- 01
Capire cosa gira davvero
Abbiamo analizzato il codice da un backup completo del server: CakePHP 2.9.5, MySQL, jQuery, Bootstrap, amCharts, un server OAuth2 su misura e il provisioning VPN degli impianti. Nel backup c'erano anche credenziali in chiaro, che abbiamo indicato come prime da ruotare.
- 02
PHP 8 non era la risposta
Il compilatore di PHP 8.3, passato su 425 file, ha fatto fallire 13 file del framework: parole diventate riservate, sintassi e funzioni rimosse. CakePHP 2 su PHP 8 non si avvia. Abbiamo messo il risultato in un referto e chiuso le tre CVE di PHP con PHP 7.4.33, l'ultima versione della serie, senza toccare il codice applicativo.
- 03
La versione che serve le pagine
Da riga di comando il server rispondeva già PHP 7.4.33, ma l'header della risposta HTTP diceva 7.2.34: il dominio era servito da un altro gestore PHP-FPM. Abbiamo corretto il gestore dal pannello e verificato di nuovo sulla risposta del sito, non sul server.
- 04
jQuery in sette viste
Le pagine caricavano jQuery 3.4.1 attraverso l'helper di CakePHP, che aggiunge da solo l'estensione del file. Abbiamo aggiornato a jQuery 3.7.1 i riferimenti in sette viste, dal layout principale alle pagine di accesso e di recupero della password.
- 05
Un piano per dopo
Abbiamo proposto una mitigazione a tempo, con firewall applicativo e hardening, e una migrazione verso un framework mantenuto come progetto separato. Il controller principale ha 5.357 righe, 58 query SQL scritte a mano e 21 metodi quasi identici per i grafici: è da lì che si parte.
Com'è andata
Le quattro CVE sono chiuse e la piattaforma funziona come prima. Al cliente è andata una chiusura formale limitata a quanto fatto, e al gruppo il referto tecnico per decidere quando affrontare la migrazione.
Strumenti
Domande frequenti
Un'applicazione CakePHP 2 si può portare su PHP 8?
Non senza riscriverla: il framework non supporta PHP 8 e alcuni suoi file non si compilano. La via rapida è l'ultima versione di PHP 7.4 con mitigazioni; quella definitiva è una migrazione a un framework mantenuto.
Perché controllare la versione di PHP dall'header HTTP?
Perché sullo stesso server convivono spesso più versioni di PHP: quella della riga di comando non è per forza quella che serve il sito.
PHP 7.4 è sicuro?
Chiude queste quattro CVE, ma è fuori supporto: ogni nuova vulnerabilità va mitigata a mano. Per questo lo consideriamo una soluzione a tempo, non un punto d'arrivo.