2025 júniusában a Cisco nyilvánosságra hozta a CVE-2025-20282 jelű, maximális súlyosságú sebezhetőséget az Identity Services Engine termékében. A probléma alapvető oka az volt, hogy a feltöltési ponton hiányzott a fájlok érvényességének ellenőrzése, ami lehetővé tette volna egy hitelesítetlen támadó számára, hogy egy speciálisan kialakított fájlt helyezzen el egy kiváltságos könyvtárban, és azt root jogosultsággal futtassa. A hiba az észlelés előtti szakaszban jelentkezett, méghozzá abban a fázisban, amikor a rendszer elfogadta a fájlt, mielőtt bármilyen ellenőrző motor elindult volna.
Ez a minta nem egy adott termékre jellemző. A halomban található motorok száma ritkán jelent korlátot. Egy fájlt elemezni kell, mielőtt értékelni lehetne, és a modern formátumok olyan módon ágyazzák be a tartalmat, hogy az elemzés nem mindig éri el azt.
Miért nem mutatott ki semmit a vizsgálat?
Az aláírásalapú vizsgálat a bájtok összehasonlításán alapul. A motor egy adatbázist tart fenn, amely ismert kártevő programokból származó hash-értékeket és bájtmintákat tartalmaz, és ahhoz, hogy egy fájlt észleljen, annak tartalmaznia kell az adatbázisban szereplő bájtokat. Néhány tényező azonban megakadályozza, hogy ez bekövetkezzen a beágyazott tartalom esetében.
- A vizsgálat a szülőfájlt olvassa be, nem pedig a benne található objektumokat. A vizsgálat az előtte lévő fájlt egyetlen bináris objektumként kezeli, és azt hasonlítja össze a szignatúra-adatbázissal. A beágyazott tartalom tömörített vagy kódolt formában van tárolva, így egy dokumentumfolyamban található futtatható fájl szinte egyáltalán nem tartalmaz azonos bájtsorozatot a lemezen található azonos futtatható fájllal. Az adatbázis által keresett minta hiányzik a tárolt fájlból, és csak akkor válik összehasonlíthatóvá, ha a folyamot kicsomagolják.
- A beolvashatatlan fájl úgy néz ki, mint egy hibátlan fájl. Ahibás szerkezet megszakítja az elemzést. A motor nem tudja befejezni az értékelést, ezért a fájlt nem blokkolja, hanem kihagyja, és a „nem sikerült értékelni” jelentésű eredmény továbbhalad a rendszerben, megkülönböztethetetlenül a „nem talált semmit” jelentésű eredménytől.
- A formátumok tervezésüknél fogva is félrevezetőek lehetnek. Egy többformátumú fájl egyszerre felel meg két formátumleírásnak, így az egyik elemző ezt állítja róla, miközben a fájl valójában teljesen másként viselkedik.
- A rekurziónak vannak korlátai. A beágyazott konténerek mélységi korlátok és vizsgálati időkorlátok hatálya alá tartoznak, és erre jó okuk van, hiszen a korlátlan rekurzió önmagában is szolgáltatásmegtagadási kockázatot jelent. Az e határ alatt elhelyezett hasznos adat soha nem kerül kiértékelésre, és a motor hatókörénél mélyebbre elhelyezni azt sokkal kevesebb erőfeszítést igényel, mint annak kijátszása.
Az eredmény egy olyan ítélet, amely kevesebbet mond, mint amilyennek látszik. A „tiszta” eredmény azt jelenti, hogy a motor által feldolgozott fájlrészben nem találtak egyező ismert mintát. Ez nem mond semmit a fájlban található elemekről, és nem mond semmit azokról a rétegekről sem, amelyeket a motor soha nem nyitott meg.
Minden rétegnek megvan a maga feladata. Egy hiányzott.
A szignatúra-alapú vizsgálat soha nem áll egyedül. A modern fájlbiztonsági rendszerek gyakran tervezésüknél fogva réteges felépítésűek, és a körülötte elhelyezkedő rétegek arra szolgálnak, hogy kiegészítsék a mintázat-összehasonlítás által lefedhetetlen területeket.
A fájltípus-azonosítás a fájl valódi típusát a fejlécéből határozza meg, nem pedig a megadott kiterjesztés alapján. Ez a módszer gyors és kifejezetten felületes jellegű, mivel célja annak eldöntése, hová kerüljön a fájl, nem pedig annak tartalmának meghatározása. A dinamikus elemzés a fájl viselkedését ellenőrzött környezetben figyeli meg. Ez a megfelelő eszköz az ismeretlen fenyegetések ellen, és akkor a leghatékonyabb, ha nem minden fájlra, hanem szelektíven alkalmazzák.
Minden réteg elvégzi a feladatát, de ha a hasznos adat soha nem válik el a hordozó fájltól, vagy egy mélységi határ alatt helyezkedik el, akkor az a tartalom soha nem éri el ezeket a rétegeket, így a további rétegek semmivel sem tudják ezt kompenzálni. A „vakfolt” legmesszebb terjed azokban a formátumokban, amelyek egyáltalán nem rendelkeznek tisztítási útvonalakkal: adatbázis-fájlok, GIS-adatok, mesterséges intelligencia-modellfájlok. Ezeket a formátumokat nem lehet újjáépíteni, így az a réteg, amely normális esetben kiszűrné az ismeretlen fenyegetéseket, definíció szerint nem áll rendelkezésre.
A hiányzó láncszem egy olyan réteg, amelynek kizárólagos feladata, hogy először meghatározza a szerkezeti alapadatokat: a fájl formátum-specifikációjának megfelelő elemzése, az összes beágyazott komponens kivonása, valamint ezeknek a komponenseknek az egyenkénti rendelkezésre bocsátása a további feldolgozási lépések számára. Ez az a probléma, amelynek megoldására a „File Structure Validation” funkciót fejlesztették ki.
Hogyan hidalja át a hiányosságokat a fájlszerkezet-ellenőrzés?
A fájlszerkezet-ellenőrzés még azelőtt fut le, hogy a rendszer többi része bekapcsolódna. A folyamat több mint 160 fájltípus – köztük GIS-, adatbázis- és mesterséges intelligencia-modellformátumok – esetében ellenőrzi a fájl formátumspecifikációjának megfelelőségét, felbontja a fájlt alkotóelemeire, majd mindegyikre alkalmazza a vonatkozó szabályokat.
Az objektumokat az azok értékelésére alkalmas motorhoz irányítják: Metascan™ Multiscanning, Adaptive Sandbox, a Proactive DLP™ technológiához vagy az OPSWAT Alin AI-hez. Az eredeti fájl adott esetben továbbkerül a Deep CDR™ technológiához tisztítás céljából.
Ami itt számít, az a szkennelésre gyakorolt hatás. A szignatúra-összehasonlítás továbbra is a leggyorsabb és leggazdaságosabb módszer az ismert kártevők azonosítására, és a fájlszerkezet-ellenőrzés egyáltalán nem helyettesíti ezt a munkát. Csak azt változtatja meg, hogy mit kapnak át a motorok. A hasznos teher önálló fájlként érkezik, már kicsomagolva és besorolva, így a motor magával az objektummal hasonlítja össze, nem pedig egy szülőfájlba elrejtett, tömörített töredékkel. Az észlelőmotorok pontosan azokat a bájtokat kapják meg, amelyek felismerésére adatbázisaik fel lettek építve, és ekkor azt teszik, amit mindig is jól csináltak.
Nézd meg a fájlban!
Ezt a legegyértelműbben egy olyan fájl szemlélteti, amely átmegy a vizsgálaton, mégis tartalmaz rosszindulatú kódot. Készítettünk egy koncepcióbizonyítást, amelyben egy ártalmatlan PDF-fájlba rejtettünk egy rosszindulatú kódot. A mintát ezután számos kártevőellenes motoron futtattuk, és mindegyik tiszta eredményt adott.
A következő lépésben ezt a fájlt beolvassuk az „ MetaDefender Core™” programba, az „Fájlszerkezet-ellenőrzés” funkció bekapcsolt állapotában. Miután kivonta a szülőfájl beágyazott elemeit, az „Fájlszerkezet-ellenőrzés” funkció a kimeneti objektumokat továbbítja a következő fázisban működő motoroknak további elemzés céljából.
A Metascan™ Multiscanning kártevőellenes motorjai „fertőzött” eredményt jeleztek. Ugyanazok a szignatúra-adatbázisok, amelyek korábban nem jeleztek fenyegetést, fertőzést jeleztek, miután a hasznos terhelést önálló fájlként mutatták be.
Hol kezdjük?
A „tiszta” vizsgálati eredmény azt mutatja, hogy a motor mit tudott feldolgozni. Az, hogy a fájl tartalmaz-e valami veszélyeset, egy külön kérdés, és ennek a megválaszolása egy szerkezeti probléma, amelyet még az első észlelőmotor futtatása előtt meg kell oldani.
Hogy ez önmagában a fájlszerkezet-ellenőrzést jelenti-e, vagy az adat-tisztítással és a dinamikus elemzéssel együtt, az a fájltípusaitól, a munkafolyamataitól és az integritási követelményeitől függ. Forduljon hozzánk, hogy megbeszéljük, melyik kombináció illeszkedik leginkább az Ön környezetéhez.
