Un server può funzionare perfettamente e non mostrare alcun errore evidente.
Il sito si apre.
Le API rispondono.
Gli utenti effettuano il login.
Eppure il sistema potrebbe utilizzare componenti software che non ricevono più aggiornamenti o che contengono vulnerabilità conosciute.
È uno dei problemi più comuni nella gestione della sicurezza informatica.
Cosa significa "software obsoleto"?
Un componente può essere considerato obsoleto per diversi motivi.
Ad esempio:
- utilizza una versione molto vecchia;
- non riceve più aggiornamenti;
- è fuori supporto;
- contiene vulnerabilità note;
- utilizza una tecnologia che l'organizzazione non dovrebbe più mantenere.
Non significa necessariamente che il software sia già vulnerabile in modo sfruttabile.
Ma aumenta la necessità di verificarne lo stato.
Un esempio molto semplice
Immaginiamo un server che esponga:
Web server
Versione 2.x
e che quella versione sia ormai fuori supporto.
Anche se oggi non viene rilevata una vulnerabilità specifica, il mantenimento di quella versione può creare problemi nel tempo.
Quando viene scoperta una nuova vulnerabilità, potrebbe non essere più disponibile una patch per quella release.
Quindi l'obsolescenza è anche un problema di manutenibilità della sicurezza.
Perché le versioni sono importanti?
Le vulnerabilità note sono spesso associate a specifiche versioni software.
Per esempio:
Software X
1.0 → vulnerabile
1.1 → vulnerabile
1.2 → corretta
Se viene rilevata la versione 1.0, uno scanner può cercare vulnerabilità compatibili con quella versione.
Ma qui bisogna fare attenzione.
Il numero di versione non è una prova assoluta
Un'applicazione potrebbe mostrare:
Server: ExampleServer/1.0
ma avere ricevuto una patch di sicurezza distribuita dal sistema operativo senza modificare la stringa di versione principale.
Questo è particolarmente comune in alcune distribuzioni Linux, che possono applicare correzioni di sicurezza tramite backport.
Quindi:
versione rilevata
non equivale sempre a:
vulnerabilità confermata
È una distinzione molto importante per evitare falsi positivi.
Come viene rilevata una versione?
Da un punto di vista esterno, una versione può essere esposta attraverso diversi elementi.
Per esempio:
Server: nginx/1.24.0
oppure:
X-Powered-By: PHP/8.x
oppure ancora attraverso:
- banner di servizi;
- pagine di errore;
- file pubblici;
- JavaScript;
- metadata;
- comportamenti caratteristici del software.
Non tutte le applicazioni espongono queste informazioni.
Conviene nascondere sempre la versione?
Ridurre le informazioni tecniche esposte può essere una buona pratica di hardening.
Per esempio, evitare di mostrare inutilmente:
Server: nginx/1.24.0
può ridurre alcune informazioni disponibili a chi osserva il sistema.
Ma nascondere la versione non risolve una vulnerabilità.
Se il software è vulnerabile, cambiare un header non lo rende automaticamente sicuro.
È molto più importante mantenere aggiornati i componenti.
Software aggiornato non significa sistema sicuro
Anche questo è importante.
Supponiamo che tutti i componenti siano aggiornati:
Web server ✓
PHP ✓
Database ✓
Framework ✓
CMS ✓
Il sistema può comunque contenere vulnerabilità applicative.
Gli aggiornamenti sono una parte della sicurezza, non la sicurezza completa.
Le dipendenze sono importanti quanto il software principale
Un'applicazione moderna può dipendere da decine o centinaia di componenti.
Per esempio:
Applicazione
├── Framework
├── Librerie PHP
├── Librerie JavaScript
├── Moduli
├── Plugin
└── Servizi esterni
Una vulnerabilità può trovarsi in una dipendenza che lo sviluppatore non considera direttamente come parte dell'applicazione.
Per questo la gestione delle dipendenze è una parte importante della sicurezza del software.
Cosa controllare
Per ogni componente esposto è utile conoscere:
- nome del software;
- versione;
- stato di supporto;
- data dell'ultimo aggiornamento;
- vulnerabilità note;
- presenza di patch;
- eventuali mitigazioni;
- ruolo del componente nell'architettura.
Una semplice inventario può diventare:
Componente Versione Supporto
-----------------------------------------
Web server 2.x Attivo
PHP 8.x Attivo
Framework 5.x Attivo
Plugin X 1.x Fine supporto
Questo permette di individuare più facilmente i componenti che richiedono attenzione.
Perché l'esposizione Internet conta?
Un software obsoleto installato su un computer non raggiungibile dall'esterno e lo stesso software esposto direttamente su Internet non rappresentano necessariamente lo stesso scenario di rischio.
La superficie di esposizione è quindi un elemento importante.
Per questo è utile combinare:
Software
+
Versione
+
Vulnerabilità note
+
Esposizione
+
Contesto
anziché considerare soltanto la versione.
Una checklist pratica
Per mantenere sotto controllo il software:
- [ ] conosco tutti i componenti esposti;
- [ ] conosco le versioni utilizzate;
- [ ] verifico lo stato di supporto;
- [ ] controllo le vulnerabilità note;
- [ ] applico gli aggiornamenti di sicurezza;
- [ ] controllo le dipendenze;
- [ ] rimuovo software non più necessario;
- [ ] verifico i componenti esposti direttamente a Internet;
- [ ] distinguo tra versione rilevata e vulnerabilità confermata.
Software obsoleto e MiHakero
La sicurezza esterna può aiutare a individuare segnali che meritano una verifica.
Una versione apparentemente obsoleta, un componente non più supportato o un software associato a vulnerabilità conosciute possono diventare elementi importanti all'interno di un report.
Ma il valore non sta nel semplice messaggio:
"Aggiorna tutto."
Sta nel collegare ciò che è esposto, ciò che è noto e ciò che richiede realmente attenzione.
Perché mantenere aggiornato il software non è soltanto una buona pratica.
È uno dei modi più semplici per ridurre nel tempo una parte importante della superficie di rischio.