Nel giugno 2025, Cisco ha reso nota la vulnerabilità CVE-2025-20282, una vulnerabilità di massima gravità presente nel proprio Identity Services Engine. La causa principale era l’assenza di un controllo di validazione dei file in fase di caricamento, che avrebbe potuto consentire a un aggressore non autenticato di inserire un file appositamente modificato in una directory con privilegi e di eseguirlo come root. Il problema si trovava a monte del processo di rilevamento, ovvero nella fase in cui il sistema accettava i dati prima che venisse eseguito qualsiasi motore di scansione.
Questo schema non è esclusivo di un singolo prodotto. Il numero di motori presenti in uno stack raramente costituisce un vincolo. Un file deve essere analizzato prima di poter essere valutato, e i formati moderni annidano i contenuti in modi che l'analisi non sempre riesce a raggiungere.
Perché l'esame non ha evidenziato nulla
La scansione basata sulle firme funziona tramite il confronto dei byte. Un motore dispone di un database di hash e sequenze di byte ricavati da malware noti, e affinché un file venga individuato deve presentare byte corrispondenti. Alcuni fattori impediscono che ciò avvenga nel caso di contenuti annidati.
- La scansione legge il file principale, non gli oggetti al suo interno. Una scansione considera il file che ha davanti come un unico oggetto binario e lo confronta con il database delle firme. I contenuti annidati sono conservati in forma compressa o codificata, quindi un eseguibile contenuto in un flusso di dati di un documento non condivide quasi nessuna sequenza di byte con lo stesso eseguibile presente sul disco. Il pattern che il database sta cercando è assente dal file così come è memorizzato, e diventa riconoscibile solo una volta che quel flusso viene decompresso.
- Un file non scansionabile appare come un file pulito. Una struttura non corretta interrompe l'analisi. Il motore non riesce a completare la valutazione, quindi il file viene saltato anziché bloccato, e un risultato che significa "impossibile valutare" viene trasmesso a valle senza che sia possibile distinguerlo da un risultato che significa "nulla trovato".
- I formati possono anche essere fuorvianti per come sono concepiti. Un file poliglotta soddisfa contemporaneamente due specifiche di formato, per cui un parser lo riconosce come tale mentre il file si comporta in modo completamente diverso.
- La ricorsione ha dei limiti. I contenitori annidati sono soggetti a limiti di profondità e a timeout di scansione, e a ragione, poiché una ricorsione illimitata costituisce di per sé un rischio di attacco denial-of-service. Un payload posizionato al di sotto di tale limite non viene mai valutato, e collocarlo a una profondità superiore a quella raggiungibile dal motore richiede uno sforzo di gran lunga inferiore rispetto a quello necessario per aggirarlo.
Il risultato è un verdetto che dice meno di quanto sembri. Un risultato "pulito" significa che non è stato trovato alcun pattern noto nella porzione di file che il motore è riuscito ad analizzare. Non fornisce alcuna indicazione sui componenti all'interno del file, né sugli strati che il motore non ha mai aperto.
Ogni strato ha un compito. Ne mancava uno
La scansione basata sulle firme non opera mai da sola. Le moderne architetture di sicurezza dei file sono spesso strutturate a più livelli, e i livelli che la circondano servono a coprire ciò che il riconoscimento dei pattern non è in grado di rilevare.
L'identificazione del tipo di file determina il tipo effettivo di un file in base alla sua intestazione, anziché all'estensione dichiarata. Si tratta di un processo veloce e superficiale per sua natura, progettato per stabilire dove collocare un file piuttosto che per analizzarne il contenuto. L'analisi dinamica osserva il comportamento del file in un ambiente controllato. È lo strumento ideale per le minacce sconosciute ed è più efficace se applicata in modo selettivo piuttosto che a tutti i file.
Ogni livello svolge la propria funzione, ma quando un payload non viene mai separato dal file che lo contiene, o si trova al di sotto di un limite di profondità, quel contenuto non raggiunge mai nessuno di questi livelli, quindi l’aggiunta di ulteriori livelli non serve a compensare. Il punto cieco si propaga maggiormente nei formati che non dispongono affatto di un percorso di sanificazione: file di database, dati GIS, file di modelli di intelligenza artificiale. Questi formati non possono essere ricostruiti, quindi il livello che normalmente intercetterebbe una minaccia sconosciuta è, per definizione, indisponibile.
Il tassello mancante è un livello il cui unico compito è quello di stabilire innanzitutto la realtà strutturale di riferimento: analizzare un file in base alle specifiche del suo formato, estrarne ogni componente incorporato e rendere tali componenti disponibili singolarmente a tutte le fasi successive del processo. Questo è il problema che File Structure Validation è stato progettato per risolvere.
In che modo la convalida della struttura dei file colma il divario
La convalida della struttura dei file viene eseguita prima che entri in funzione il resto dello stack. Verifica la conformità di un file alle specifiche di formato relative a oltre 160 tipi di file, inclusi formati GIS, di database e di modelli di intelligenza artificiale, lo scompone nei suoi componenti e applica le politiche a ciascuno di essi.
Gli oggetti vengono indirizzati al motore in grado di valutarli: Metascan™ Multiscanning, Adaptive Sandbox , Proactive DLP™ Technology o OPSWAT Alin AI. Il file originale viene quindi inoltrato alla tecnologia Deep CDR™ per la sanificazione, ove applicabile.
Ciò che conta in questo contesto è l’effetto sulla scansione. Il confronto delle firme rimane il modo più veloce ed economico per identificare il malware noto, e la convalida della struttura dei file non sostituisce in alcun modo tale processo. Cambia piuttosto ciò che viene fornito ai motori. Il payload arriva come file autonomo, già decompresso e già classificato, quindi il motore effettua il confronto con l’oggetto stesso anziché con un frammento compresso nascosto all’interno di un file padre. Ai motori di rilevamento vengono forniti esattamente i byte che i loro database sono stati progettati per riconoscere, e a quel punto fanno ciò che hanno sempre fatto bene.
Vedi nel file
Il modo più chiaro per dimostrarlo è un file che supera la scansione pur contenendo un payload. Abbiamo creato un proof of concept in cui un payload dannoso è nascosto all’interno di un file PDF innocuo. L’esempio è stato quindi sottoposto a una serie di motori anti-malware, che hanno restituito un risultato negativo.
Il passo successivo consiste nell'eseguire la scansione di questo file in MetaDefender Core™ con la funzione “File Structure Validation” abilitata. Dopo aver estratto i componenti annidati del file padre, la funzione “File Structure Validation” invia gli oggetti risultanti ai motori a valle per un’ulteriore analisi.
I motori anti-malware Metascan™ Multiscanning hanno segnalato un verdetto di “Infected”. Gli stessi database di firme che non avevano rilevato alcuna minaccia hanno segnalato un’infezione non appena il payload è stato presentato come file a sé stante.
Da dove cominciare
Una scansione "pulita" indica ciò che un motore è in grado di analizzare. Se il file contenga o meno elementi pericolosi è una questione a sé stante, e risolverla rappresenta un problema strutturale che deve essere affrontato prima che il motore di rilevamento venga avviato per la prima volta.
Che ciò comporti la sola convalida della struttura dei file o che questa sia affiancata dalla sanificazione e dall'analisi dinamica dipende dai tipi di file, dai flussi di lavoro e dai requisiti di integrità. Contattateci per capire quale combinazione sia più adatta al vostro ambiente.
