A fájlfeltöltést megkönnyítő webes alkalmazások számos szervezet számára váltak nélkülözhetetlenné, mivel portálként szolgálnak az ügyfelek, partnerek és alkalmazottak számára a különböző típusú dokumentumok és fájlok megosztásához. Egy HR-cég például lehetővé teheti a felhasználók számára az önéletrajzok feltöltését, vagy egy vállalat megkönnyítheti a partnerek számára a fájlok megosztását egy speciális webes platformon keresztül.
A támadók még a fokozott biztonsági intézkedések és a szigorúbb érvényesítési eljárások ellenére is kifinomult módszerekkel használják ki a sebezhetőségeket. A jóindulatúnak tűnő fájlok, például képek manipulálhatók, hogy veszélyeztessék a webkiszolgáló biztonságát.
A poliglott fájlok olyan fájlok, amelyek egyszerre többféle típusként is érvényesek lehetnek, lehetővé téve a támadók számára a fájltípus-alapú biztonsági intézkedések megkerülését. Ilyen például a GIFAR, amely GIF- és RAR-fájlként is működik, a JavaScript/JPEG poliglott fájlok, amelyeket JavaScriptként és JPEG-ként is értelmeznek, valamint a Phar-JPEG fájlok, amelyeket Phar archívumként és JPEG-ként is felismernek. Ezek a poliglott fájlok észrevétlenek maradhatnak megtévesztő vagy üres kiterjesztésekkel, amelyek "becsapják" a rendszereket, hogy azt higgyék, hogy jóindulatú fájltípusról van szó (például kép vagy PDF), miközben észrevétlen rosszindulatú kódot tartalmaznak.
Fájl feltöltés érvényesítés
A felhasználók által megfelelő vagy átfogó érvényesítés nélkül feltöltött fájlok engedélyezése jelentős veszélyt jelent a webes alkalmazásokra. Ha egy támadó sikeresen feltölt egy rosszindulatú fájlt, például egy webes shell-t, akkor potenciálisan átveheti az irányítást a kiszolgáló felett, veszélyeztetve a rendszert és az érzékeny adatokat. E kockázatok mérséklése érdekében bevált gyakorlatok kerültek kidolgozásra, amelyek a fejlesztők számára útmutatást nyújtanak a hatékony validálási intézkedések alkalmazásához. Ezek a gyakorlatok segítenek biztosítani a fájlfeltöltések biztonságos feldolgozását, ezáltal minimalizálva a kihasználás kockázatát.
A fájlfeltöltések biztonságának legfontosabb területei a következők:
- Bővítmény érvényesítés: A fájlkiterjesztések blokklistájának vagy engedélyezési listájának bevezetése annak biztosítása érdekében, hogy csak az engedélyezett fájltípusokat fogadják el.
- Fájlnév-helyreállítás: Feltöltéskor véletlenszerű karakterláncokat generál a fájlnevekhez.
- Content-Type érvényesítés: Ellenőrizze a feltöltött fájl MIME-típusát, hogy az megfeleljen az elvárt formátumnak.
- Képfejléc érvényesítés: A képfeltöltésnél a PHP olyan funkciói, mint a getimagesize(), használhatók a fájl érvényességének megerősítésére a fejléc ellenőrzésével.
Fájl feltöltés szűrő megkerülése
Az említett védelmi intézkedések végrehajtása ellenére a támadók folyamatosan fejlesztik a módszereket az érvényesítési mechanizmusok megkerülésére. Az olyan technikák, mint a nullkarakterek bevitele, a kettős kiterjesztések és az üres kiterjesztések alááshatják a kiterjesztések érvényesítését: egy fájl olyan névvel jelenhet meg, mint "file.php.jpg", "file.php%00.jpg", "file.PhP" vagy "file.php/", hogy elkerülje a felismerést. A MIME-típus érvényesítés megkerülhető a fájl kezdeti mágikus bájtjainak módosításával, például a GIF89a fejlécre, azaz a GIF-fájlokhoz tartozó fejlécre cserélve, ami becsaphatja a rendszert, hogy a fájlt legitim formátumként azonosítsa. Emellett egy rosszindulatú .htaccess fájlt is fel lehet tölteni a szerverkonfigurációk manipulálására, lehetővé téve a nem engedélyezett kiterjesztésű fájlok végrehajtását.
Poliglott fájl támadások
Még a fájlfeltöltési szűrő megkerülési technikájának megakadályozására szolgáló, több biztonsági intézkedést kombináló szigorú érvényesítési folyamatok végrehajtása ellenére is jelentős biztonsági fenyegetést jelentenek a poliglott fájlokat vagy poliglott képeket célzó kifinomult támadások. Ez a módszer lehetővé teszi a támadók számára, hogy olyan fájlokat - például képeket - készítsenek, amelyek megfelelnek a képfájloktól elvárt bináris struktúrának, de egyidejűleg rosszindulatú kódot is képesek végrehajtani, ha más kontextusban értelmezik őket. Ezeknek a fájloknak a kettős jellege lehetővé teszi, hogy megkerüljék a hagyományos érvényesítési mechanizmusokat, és bizonyos forgatókönyvekben kihasználják a sebezhetőségeket.
Egyszerű poliglott fájl az ExifTool segítségével
Egy egyszerű technika a poliglott kép létrehozására az ExifTool használata. Ezt a nagy teljesítményű alkalmazást különböző metaadatformátumok, például EXIF, XMP, JFIF és Photoshop IRB olvasására, írására és módosítására tervezték. A rosszindulatú személyek azonban kihasználhatják az ExifToolt káros műveletek végrehajtására, beleértve a poliglott kép rosszindulatú szándékkal történő létrehozását is. Az ExifTool használatával a támadók rosszindulatú kódot ágyazhatnak be egy kép EXIF metaadataiba - különösen az olyan mezőkbe, mint a UserComment és a ImageDescription -, így poliglott képet hozhatnak létre, és növelhetik a sikeres kihasználás esélyét.
A következőkben a kép EXIF-metaadatait mutatjuk be, amelyek átfogó információkat tartalmaznak a képpel kapcsolatban.
Az ExifTool használatával egy fenyegető szereplő rosszindulatú kódot ágyazhat be egy kép EXIF-metaadataiba, és ezáltal olyan poliglott fájlt hozhat létre, amely megkerülheti az érvényesítési mechanizmusokat.
Bár a MIME-típus-érvényesítés korlátozhatja az alapvető webhéjfájlok feltöltését, ez a poliglott kép megkerülheti ezeket a korlátozásokat, lehetővé téve a támadó számára egy poliglott webhéj feltöltését.
A támadó ezt követően a poliglott webes héj segítségével átveheti az irányítást a webkiszolgáló felett.
Javascript/JPEG poliglott fájl
A JavaScript/JPEG poliglott fájl úgy van felépítve, hogy mind JPEG-képként, mind JavaScript-szkriptként érvényes legyen. Ennek eléréséhez a rosszindulatú szereplőnek átfogóan ismernie kell a JPEG-fájl belső szerkezetét. Ez a tudás lehetővé teszi a rosszindulatú bináris adatok pontos beágyazását a képbe, biztosítva, hogy a JavaScript-motor úgy tudja feldolgozni a képet, hogy az ne befolyásolja annak JPEG-képként való érvényességét.
Egy JPEG kép a következő felépítésű:
| Bájtok | Név |
| 0xFF, 0xD8 | A kép kezdete |
| 0xFF, 0xE0, 0x00, 0x10, ... | Alapértelmezett fejléc |
| 0XFF, 0XFE, ... | Kép megjegyzés |
| 0xFF, 0xDB, ... | Kvantálási táblázat |
| 0xFF, 0xC0, ... | A képkocka kezdete |
| 0xFF, 0xC4, ... | Huffman táblázat |
| 0xFF, 0xDA, ... | A keresés kezdete |
| 0xFF, 0xD9 | A kép vége |
JPEG formátum - forrás: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
A JPEG képszerkezetben a fejlécet a hosszinformáció követi. Amint az előző példában látható, a fejléc a 0xFF 0xE0 0x00 0x10 szekvenciával kezdődik, ahol a 0x00 0x10 a szegmens hosszát jelöli, ami 16 bájtot jelent. A 0xFF 0xD9 jelző a kép végét jelöli.
A JavaScript/JPEG poliglott fájl létrehozásához módosítani kell a kép hexadecimális értékeit, hogy a JavaScript motor felismerje és feldolgozza azokat.
Először is, JavaScriptben a 0xFF 0xD8 0xFF 0xE0 szekvencia értelmezhető nem-ASCII értékként, de a 0x00 0x10 érvénytelen, és meg kell változtatni. Ezeknek a hexa értékeknek a megfelelő helyettesítője a 0x2F 0x2A, ami a /* hexadecimális ábrázolása, ami a JavaScriptben a megjegyzések megnyitására használt szintaxis. Ez a helyettesítés lehetővé teszi, hogy a fennmaradó bináris adatokat a megjegyzés részeként figyelmen kívül hagyjuk.
Mivel azonban a 0x00 0x10 eredetileg a JPEG fejléc hosszát jelöli, a 0x2F 0x2A értékre történő módosítás, amely tizedes számban 12074-nek felel meg, a JPEG fejléc újradefiniálását igényli annak érvényességének fenntartása érdekében. Ehhez nullbájtokat kell hozzáadni, és a JavaScript hasznos terhelését a 0xFF 0xFE jelölő után kell elhelyezni, amely a JPEG-struktúrában egy képkommentárt jelez.
Például, ha a hasznos teher */=alert(document.domain);/*, amely 28 bájt hosszú, a szükséges nullbájtokat a következőképpen kell kiszámítani: 12074 (új hossz) - 16 (eredeti fejléc hossza) - 2 (a 0xFF 0xFE jelölőhöz) - 28 (hasznos teher hossza) = 12 028 nullbájt.
Következésképpen a JPEG-képen belüli JavaScript-kód a következőképpen nézne ki:
Végül a 0x2A 0x2F 0x2F 0x2F 0x2F (a *///-nek megfelelő) sorozatot közvetlenül a 0xFF 0xD9 JPEG végjelző előtt kell elhelyezni. Ez a lépés lezárja a JavaScript-kommentárt, és biztosítja a hasznos teher helyes végrehajtását a JPEG-fájl szerkezetének megzavarása nélkül.
A módosítás után a kép továbbra is érvényes képként értelmezhető, ugyanakkor futtatható JavaScript-kódot tartalmaz.
Ha egy HTML-fájl betölti ezt a képet JavaScript forráskódként, akkor az érvényes marad, és képes végrehajtani a beágyazott JavaScript-kódot:
A többnyelvű képfájlok nemcsak az ügyféloldali kihasználás, hanem bizonyos körülmények között a szerveroldali támadások szempontjából is kockázatot jelentenek. Erre példa a Phar/JPEG poliglott fájl, amely egyszerre értelmezhető PHP archívumként (Phar) és JPEG képként. A Phar fájlszerkezet lehetővé teszi a szerializált adatok metaadatokba való beágyazását, ami potenciális kockázatot jelent a deserializációs sebezhetőségek szempontjából, különösen bizonyos PHP-verziókban. Ennek eredményeképpen a Phar/JPEG poliglott fájlok kihasználhatók a fájlfeltöltés érvényesítésének megkerülésére és sebezhető szerverek kihasználására.
A Phar fájlformátum a stub/manifest/contents/signature (csonk/manifeszt/tartalom/aláírás) formátumok szerint épül fel, és a manifesztben tárolja a Phar archívumban található legfontosabb információkat:
- Stub: A csonk a PHP-kód egy darabja, amely akkor kerül végrehajtásra, amikor a fájlhoz végrehajtható környezetben hozzáférünk. A csonk tartalmára nincsenek korlátozások, kivéve azt a követelményt, hogy a csonk a __HALT_COMPILER(); kifejezéssel záruljon.
- Nyilvánvaló: Ez a szakasz metaadatokat tartalmaz az archívumról és annak tartalmáról, amelyek tartalmazhatnak serialize() formátumban tárolt, szerializált Phar metaadatokat.
- A fájl tartalma: Az archívumban szereplő eredeti fájlok.
- Aláírás (nem kötelező): Aláírási információkat tartalmaz az integritás ellenőrzéséhez.
Mivel a csonk nem ír elő semmilyen tartalmi korlátozást a __HALT_COMPILER() feltételén túl, egy fenyegető szereplő be tudja juttatni a kép hexadecimális értékeit a csonkba. Azáltal, hogy ezeket az értékeket a PHAR fájl elejére helyezi, az érvényes képként azonosítható. Következésképpen egy PHAR/JPEG poliglott könnyen létrehozható egy JPEG-kép hexadecimális bájtjainak az elejére történő beillesztésével, ahogyan azt a következő példa mutatja:
Ezzel a módszerrel a generált poliglott fájl érvényes képként és legitim PHAR-fájlként is funkcionál, és ezért felhasználható bizonyos fájlfeltöltési érvényesítési mechanizmusok megkerülésére.
Bár ez a poliglott fájl képes megkerülni a fájlfeltöltési szűrőket, jelenleg nem képes kihasználni a webkiszolgálót. A PHAR fájl vagy PHAR poliglott fájl sikeres kihasználásához és egy webkiszolgáló kompromittálásához elengedhetetlen, hogy a fájl manifesztjébe rosszindulatú, szerializált metaadatokat juttassunk be.
Amikor a PHAR fájlt a PHAR wrapper (phar://) segítségével érjük el bizonyos PHP függvényekben (PHP ≤7.x), amelyek fájlműveletekhez kapcsolódnak - mint például a file(), file_exists(), file_get_contents(), fopen(), rename() vagy unlink() - az unserialize() függvényt indítjuk el a szerializált metaadatokra. Végső soron a PHPGGC, a PHP gadget-láncok építésére széles körben használt eszköz felhasználásával a fenyegető szereplők kihasználhatják a deserializációs sebezhetőséget egy PHAR poliglott fájlon keresztül, és ezáltal veszélyeztethetik a webalkalmazás kiszolgálóját.
A PHAR/JPEG poliglott fájlok és a deserializációs sebezhetőségek kombinációja lehetővé teszi a támadók számára, hogy beszivárogjanak egy webes alkalmazáskiszolgálóra, még akkor is, ha a fájlfeltöltési szűrők be vannak építve. Figyelemre méltó, hogy ez a kompromittálódás akár egy képfájl feldolgozása során is bekövetkezhet.
A poliglott fájlok kihasználásával a fájlfeltöltési szűrők megkerülésével és a PHAR wrapper (phar://) csatolásával a fájl helyéhez a támadók manipulálhatják a webkiszolgálót, hogy a fájlt PHAR-archívumként kezelje. Ez a manipuláció ezt követően deserializációs sebezhetőséget válthat ki, ami a fájlműveleti függvényeken keresztül távoli kódfuttatáshoz vezethet.
A poliglott fájlokkal kapcsolatos kockázatok érzékeltetésére az alkalmazásban egy olyan környezetet szimuláltunk, ahol az alkalmazás szigorú fájlfeltöltési szűrőket alkalmaz, hogy megakadályozza a rosszindulatú fájlok vagy webes kagylók feltöltését. Ezen óvintézkedések ellenére egy poliglott kép megkerülheti az érvényesítési folyamatot, és bizonyos körülmények között távoli kódfuttatáshoz vezethet, ami végül veszélyezteti a sebezhető webes alkalmazáskiszolgálót.
Ez a példa egy hagyományos webes alkalmazást mutat be, amely lehetővé teszi az ügyfelek, partnerek és szervezetek közötti fájlmegosztást:
MetaDefender Core és a MetaDefender ICAP Server megvédi webes alkalmazásait ezektől a fenyegetésektől, és növeli hálózata és infrastruktúrája biztonságát.
MetaDefender ICAP Server és a MetaDefender Core együttműködve a következő módon védi webkiszolgálóját a rosszindulatú PHAR/JPEG poliglott fájlokat tartalmazó kifinomult támadások ellen:
Amikor egy PHAR/JPEG poliglott fájlt feltöltünk a webes alkalmazásba, azt először továbbítjuk a MetaDefender Core MetaDefender ICAP Server keresztül egy átfogó szanálási folyamathoz a Deep CDR ™ technológiánk segítségével. Az egyszerű fájltípus-ellenőrzőkkel ellentétben a Deep CDR alaposan elemzi a feltöltött fájl szerkezetét, eltávolítja a szkripteket, makrókat és a szabályokon kívüli tartalmakat, és a JPEG-fájlt úgy állítja helyre, hogy csak a szükséges adatokat tartalmazza.
Ez a folyamat eltávolítja a káros PHAR-tartalmat, amely a JPEG-végjelző(0xFF 0xD9) után van csatolva, biztosítva, hogy a tisztított fájl szigorúan JPEG legyen. Ennek eredményeként a webes alkalmazás védve van a PHAR/JPEG poliglott támadásoktól; még ha egy támadó meg is tudja változtatni a fájlfeldolgozási sémát, hogy PHAR csomagolást juttasson be, nem tudja kihasználni a webkiszolgálót.
A már kiépített hálózati biztonsági infrastruktúrával rendelkező szervezetek - akár WAF-okat (webes alkalmazás tűzfalakat), proxykat vagy belépési vezérlőket használnak - mostantól a MetaDefender ICAP Server segítségével fokozhatják védelmi mechanizmusaikat.Ez a megoldás interfészt hoz létre a meglévő webkiszolgálók és a MetaDefender Core között, átlátható biztonsági ellenőrzési pontot hozva létre az összes bejövő fájl számára. A ICAP interfészen keresztül továbbított minden tartalom átvizsgálásra és feldolgozásra kerül, mielőtt elérné a webkiszolgálót, így biztosítva, hogy csak biztonságos és legitim tartalom kerüljön be a hálózatba és jusson el a végfelhasználókhoz.
Ez a megközelítés azt jelenti, hogy a szervezetek kihasználhatják meglévő biztonsági beruházásaikat, miközben a védelem egy további, hatékony rétegét adják hozzá. Az NGINX ingress controller-t használó szervezetek a MetaDefender ICAP Server proxy-konfiguráción keresztül integrálhatják a meglévő infrastruktúrájukba.
OPSWATmegközelítése túlmutat a hagyományos fenyegetésérzékelésen. Ahelyett, hogy egyszerűen csak jelezné a gyanús fájlokat, a MetaDefender Core aktívan semlegesíti a potenciális fenyegetéseket, a veszélyes fájlokat biztonságos, használható tartalommá alakítja át. A MetaDefender ICAP Server a webszerverrel integrálva átfogó védelmet nyújt a nulladik napi fenyegetések és a poliglott támadások ellen.
A "Trust no file. Ne bízz semmilyen eszközben. ™" filozófia alapján a OPSWAT világszerte szabadalmaztatott technológiákkal oldja meg az ügyfelek kihívásait az infrastruktúra minden szintjén, biztosítva a hálózatokat, az adatokat és az eszközöket, valamint megelőzve az ismert és ismeretlen fenyegetéseket, a nulladik napi támadásokat és a rosszindulatú szoftvereket.
