În iunie 2025, Cisco a dezvăluit CVE-2025-20282, o vulnerabilitate de gravitate maximă în cadrul Identity Services Engine. Cauza principală a fost lipsa unei verificări de validare a fișierelor în momentul încărcării, ceea ce ar fi putut permite unui atacator neautentificat să plaseze un fișier special creat într-un director cu privilegii și să-l execute cu drepturi de root. Deficiența se afla în amonte de procesul de detectare, adică în etapa în care sistemul accepta fișierele înainte ca vreun motor de scanare să fie rulat.
Acest tipar nu este specific unui singur produs. Numărul de motoare dintr-un stack este rareori factorul limitativ. Un fișier trebuie analizat înainte de a putea fi evaluat, iar formatele moderne imbrică conținutul în moduri pe care analiza nu le acoperă întotdeauna.
De ce rezultatul scanării a ieșit normal
Scanarea bazată pe semnături funcționează prin compararea octeților. Un motor de scanare deține o bază de date cu hash-uri și modele de octeți extrase din programe malware cunoscute, iar un fișier trebuie să conțină octeți care să se potrivească pentru a fi detectat. Există câteva aspecte care împiedică acest lucru în cazul conținutului imbricat.
- Scanarea citește fișierul părinte, nu obiectele din interiorul acestuia. O scanare tratează fișierul pe care îl are în față ca pe un singur obiect binar și îl compară cu baza de date de semnături. Conținutul imbricat este stocat sub formă comprimată sau codificată, astfel încât un executabil aflat în interiorul unui flux de date al unui document nu are aproape nicio secvență de octeți în comun cu același executabil de pe disc. Modelul pe care îl caută baza de date lipsește din fișierul stocat și devine comparabil abia după ce fluxul respectiv este decomprimat.
- Un fișier care nu poate fi scanat pare unul curat. O structură defectuoasă întrerupe procesul de analiză. Motorul nu poate finaliza evaluarea, așa că fișierul este omis în loc să fie blocat, iar un rezultat care înseamnă „nu a putut fi evaluat” este transmis mai departe, fiind imposibil de distins de un rezultat care înseamnă „nu s-a găsit nimic”.
- Formatele pot induce în eroare chiar prin modul în care sunt concepute. Un fișier poliglot respectă două specificații de format în același timp, astfel încât un analizor sintactic îl recunoaște ca atare, în timp ce fișierul se comportă cu totul altfel.
- Recursivitatea are limite. Containerele imbricate sunt limitate de praguri de adâncime și de limite de timp pentru scanare, din motive întemeiate, întrucât recursivitatea nelimitată reprezintă în sine un risc de tip „denial-of-service”. O încărcătură plasată sub această limită nu este niciodată evaluată, iar plasarea ei la un nivel mai adânc decât cel la care ajunge motorul necesită mult mai puțin efort decât depășirea acestei limite.
Rezultatul este o concluzie care spune mai puțin decât pare la prima vedere. Un rezultat „curat” înseamnă că nu s-a găsit nicio potrivire cu un model cunoscut în porțiunea de fișier pe care motorul a reușit să o analizeze. Acesta nu oferă nicio informație despre componentele din interiorul fișierului și nici despre straturile pe care motorul nu le-a deschis niciodată.

Fiecare strat are o funcție. Unul lipsea
Scanarea bazată pe semnături nu funcționează niciodată izolat. Sistemele moderne de securitate a fișierelor sunt adesea structurate pe straturi, iar straturile din jurul acesteia au rolul de a acoperi ceea ce nu poate fi detectat prin compararea cu tiparele.
Identificarea tipului de fișier determină tipul real al unui fișier pe baza antetului său, și nu pe baza extensiei declarate. Este un proces rapid și superficial prin natura sa, conceput pentru a stabili unde trebuie plasat un fișier, mai degrabă decât ce conține acesta. Analiza dinamică observă comportamentul fișierului într-un mediu controlat. Este instrumentul potrivit pentru amenințările necunoscute și este cea mai eficientă atunci când este aplicată selectiv, și nu tuturor fișierelor.

Fiecare strat își îndeplinește rolul, dar atunci când o încărcătură utilă nu este niciodată separată de fișierul care o transportă sau se află sub o limită de adâncime, acel conținut nu ajunge niciodată la vreunul dintre aceste straturi, astfel încât adăugarea de straturi suplimentare nu are niciun efect compensatoriu. Punctul mort se propagă cel mai departe în formatele care nu dispun deloc de o cale de curățare: fișiere de baze de date, date GIS, fișiere de modele AI. Aceste formate nu pot fi reconstruite, astfel încât stratul care ar detecta în mod normal o amenințare necunoscută este, prin definiție, indisponibil.
Piesa care lipsește este un strat al cărui rol este acela de a stabili mai întâi adevărul structural de referință: analizarea unui fișier în conformitate cu specificațiile sale de format, extragerea tuturor componentelor încorporate și punerea la dispoziție a acestor componente, individual, pentru toate etapele ulterioare. Aceasta este problema pe care „Validarea structurii fișierului” a fost concepută să o rezolve.
Cum validarea structurii fișierelor acoperă această lacună
Validarea structurii fișierului se execută înainte ca restul stivei să intre în funcțiune. Aceasta validează un fișier în raport cu specificațiile de format pentru peste 160 de tipuri de fișiere, inclusiv formate GIS, de baze de date și de modele de IA, îl descompune în componentele sale și aplică politica corespunzătoare fiecăreia dintre acestea.
Obiectele sunt redirecționate către motorul adecvat pentru evaluarea lor: Metascan™ Multiscanning, Adaptive Sandbox , tehnologia Proactive DLP™ sau OPSWAT Alin AI. Fișierul sursă este transmis mai departe către tehnologia Deep CDR™ pentru curățare, acolo unde este cazul.
Ceea ce contează aici este efectul asupra procesului de scanare. Compararea semnăturilor rămâne cea mai rapidă și mai economică metodă de identificare a programelor malware cunoscute, iar validarea structurii fișierului nu înlocuiește deloc această operațiune. Ea modifică ceea ce li se transmite motoarelor de scanare. Sarcina utilă ajunge sub forma unui fișier independent, deja dezarhivat și clasificat, astfel încât motorul compară obiectul în sine, în loc să compare un fragment comprimat ascuns în interiorul unui fișier părinte. Motoarelor de detectare li se furnizează exact acei octeți pe care bazele lor de date au fost concepute să îi recunoască, moment în care acestea fac ceea ce au făcut întotdeauna bine.
Vezi în fișier
Cea mai clară modalitate de a demonstra acest lucru este un fișier care trece de scanare și conține totuși o încărcătură dăunătoare. Am creat un exemplu de concept în care o încărcătură dăunătoare este ascunsă într-un fișier PDF inofensiv. Exemplul a fost apoi testat cu o serie de motoare anti-malware, care au indicat că fișierul este curat.

Următorul pas constă în scanarea acestui fișier în MetaDefender Core™, cu funcția „Validarea structurii fișierului” activată. După extragerea componentelor imbricate ale fișierului părinte, funcția „Validarea structurii fișierului” trimite obiectele rezultate către motoarele din aval pentru o analiză ulterioară.


Motoarele anti-malware Metascan™ Multiscanning au afișat verdictul „Infecție”. Aceleași baze de date cu semnături care nu au semnalat nicio amenințare au indicat o infecție odată ce încărcătura a fost prezentată ca un fișier de sine stătător.


De unde să începi
O scanare curată reprezintă o evaluare a ceea ce ar putea analiza un motor de scanare. Dacă fișierul conține ceva periculos este o altă problemă, iar rezolvarea acesteia reprezintă o problemă structurală care trebuie soluționată înainte ca primul motor de detectare să fie pus în funcțiune.
Faptul că aceasta înseamnă validarea structurii fișierelor ca atare sau împreună cu curățarea și analiza dinamică depinde de tipurile de fișiere, de fluxurile de lucru și de cerințele dumneavoastră privind integritatea. Discutați cu noi pentru a afla ce combinație se potrivește cel mai bine mediului dumneavoastră.

