Nell’ultimo anno si è assistito alla comparsa di problematiche software riguardanti sistemi operativi e librerie software estremamente diffusi.
Problematiche dagli effetti potenzialmente devastanti, spesso catalogate come remotely exploitable. Questa condizione indica come un attaccante possa approfittare di queste carenze senza necessariamente essere fisicamente vicino al sistema, bensì avendone solo visibilità dalla rete o logica.
In questo articolo provo a chiarire meglio alcune differenze importanti tra termini specifici, troppo spesso utilizzati in modo intercambiabile (e improprio) con l’obiettivo di fare scalpore o acchiappare click su Internet.
Partiamo da un paio di verità assolute che trovo importante ricordare.
La prima è la citazione di un pensiero del luminare di CyberSecurity Gene Spafford: “Il solo sistema veramente sicuro è quello spento, disconnesso, chiuso in una gabbia di titanio, in un bunker di cemento pieno di gas nervino e sorvegliato da guardie armate molto ben pagate. Anche in quel caso, non ci scommetterei la vita.”
La seconda verità, decisamente di più semplice enunciazione, ribadisce più semplicemente che “nessun software è perfetto”.
Definiti questi punti di partenza, proviamo a chiarire l’importante differenza tra un bug, una vulnerabilità e un exploit; terminando con chiarire l’importanza delle condizioni necessarie per poter trarre vantaggio da questi elementi.
Ben lontano dal mondo dell’entomologia da cui il termine ha origine, il bug o baco di software è definibile come un’imperfezione del codice dovuto ad un errore del codice commesso in fase di sviluppo. Tale errore si manifesta soltanto al verificarsi di alcune condizioni.
Curiosità nota non a tutti e decisamente a chi si ostina a chiamare questo errore buco di software è la genesi di questo termine nel campo informatico: deriva infatti dai tempi in cui il software era codificato su schede perforate e gli elaboratori erano enormi armadi spesso nei sotterranei di un palazzo; in questi armadi metallici le varie componenti erano tutt’altro che miniaturizzate e lo spazio permetteva - in talune condizioni - il proliferare di bestiole che arrivavano a cibarsi di schede perforate come un bruco di ciberebbe di una croccante mela matura. Proprio in questi contesti nacque l’espressione baco del software che resiste imperterrita da oltre mezzo secolo nel colorito (e un tantino nerd) mondo degli sviluppatori.
Affinché da un bug si generi una vulnerabilità però, devono sussistere alcune condizioni importanti.
La prima è che accada - almeno una volta - la sequenza di eventi che porta il bug a mostrarsi al mondo, generando gli effetti nefasti dell’errore commesso inizialmente dallo sviluppatore. Non solo è profondamente sbagliato usare il termine bug e vulnerabilità in modo intercambiabile, ma persino un bug noto non è sinonimo di vulnerabilità.
Per comprendere meglio questa sfumatura, proviamo ad esaminare come è riportata una vulnerabilità - prendendo spunto dall’organismo americano MITRE di analisi delle minacce. Tra le innumerevoli attività del MITRE c’è infatti la gestione e l’aggiornamento di un database di vulnerabilità chiamato CVE (Common Vulnerabilities and Exposures).
Di seguito riporto un esempio di come una vulnerabilità venga rappresentata al grande pubblico:
Appare subito chiaro che la descrizione del contesto racconta molto di più rispetto ai possibili modi di sfruttare il bug senza però fare esempi sul come in pratica: ad esempio, ci informa che il modello Omada ER605 del produttore TP-Link ha un problema di buffer overflow: questo significa che a causa di un errore di sviluppo la memoria del dispositivo accetta più dati di quanti potrebbe contenerne; ci dice che non è necessario essere autenticati per scrivere in questa memoria; ci sottolinea come lo sfruttamento di questa crepa possa avvenire anche da remoto, con la qualificazione di Remote Code Execution.
Il report di una vulnerabilità non dice mai come sfruttarla, per diverse valide ragioni.
In primis, se lo facesse metterebbe a rischio quanti non hanno ancora fatto in tempo a rimediare, qualora fosse possibile ad esempio con l’applicazione di un aggiornamento software del produttore o di una patch.
In secondo luogo, il compito di rendere una vulnerabilità sfruttabile è di competenza di chi scrive un exploit.
L’exploit rappresenta un codice e/o una procedura che se eseguita causa l’errore che sfrutta il bug lasciato nel codice dello sviluppatore.
Riassumendo: bug, vulnerabilità ed exploit sono tre entità separate, semmai conseguenti ma certamente non sinonimi.
La pratica di analisi delle caratteristiche delle vulnerabilità, delle procedure di rimedio, dell’eventuale disponibilità di una patch da parte del produttore costituisce un processo parte delle misure di sicurezza informatica di ogni azienda - chiamato Vulnerability Management ed è uno degli obiettivi più sfidanti di una buona politica di cybersecurity aziendale.
