A webböngészők világszerte több milliárd eszközön vannak telepítve, így a kiberbűnözők elsődleges célpontjai. Mivel a főbb webböngészők hatalmas felhasználói bázissal rendelkeznek, egyetlen sebezhetőségnek is messzemenő következményei lehetnek. A böngészők naprakészen tartása kritikus fontosságú a fejlődő fenyegetésekkel szembeni védelem fenntartásához.
A webböngészőkben található sebezhetőségek súlyosságának illusztrálására munkatársaink átfogó elemzést végeztek a CVE-2024-6778-ról, a Chromium-alapú böngészőkben található sebezhetőségről, amely különösen a Chrome DevTools-t érinti. Ez a blog részletesen megvizsgálja a sebezhetőség technikai aspektusait, a lehetséges hatást és a kárenyhítési stratégiákat.
A CVE-2024-6778 háttere
A CVE-2024-6778 egy versenyfeltételekkel kapcsolatos sebezhetőség, amelyet a Chrome DevToolsban fedeztek fel. Lehetővé teszi a támadók számára, hogy rosszindulatú böngészőbővítményeken keresztül rosszindulatú HTML-t vagy JavaScriptet juttassanak be a privilegizált böngészőoldalakba. Az NVD (National Vulnerability Database) szerint ez a sebezhetőség magas súlyosságú, 8,8-as CVSS pontszámmal rendelkezik.
A sebezhetőség magas súlyossági besorolása annak köszönhető, hogy távoli kódfuttatást tesz lehetővé, ami a rendszerek veszélyeztetését, a bizalmas adatok sérülését és a rendelkezésre állás csökkenését eredményezheti.
Chromium biztonsági áttekintés
A CVE-2024-6778 következményeinek mélyebb megértéséhez fontos ismerni a Chromium biztonsági modelljének legfontosabb aspektusait. A Chromium az olyan böngészők nyílt forráskódú alapja, mint a Google Chrome, a Microsoft Edge, az Opera és a Brave. Többfolyamatos modellt alkalmaz, amelyben minden egyes lap, más néven renderelő, és a böngésző különböző összetevői elszigetelt folyamatokban futnak, hogy a stabilitás és a biztonság növelése érdekében korlátozza a potenciális veszélyeztetések körét.
A Chromium biztonságának alapvető eleme a homokdoboz-mechanizmus, amely korlátozza a renderelő folyamatok közvetlen hozzáférését a rendszer erőforrásaihoz. Ehelyett minden interakciót IPC (Inter-Process Communication) csatornákon keresztül kezelnek, hogy csak az engedélyezett műveleteket hajtsák végre.
A Chromiumon belül nem minden komponensre vonatkozik a teljes homokdobozolás. A WebUI oldalak, mint például a chrome://settings és a chrome://downloads, a renderelő folyamatokon belül kerülnek megjelenítésre, de részleges sandbox korlátozásokkal működnek. Ez a folyamat hozzáférést biztosít számukra olyan böngésző API-khoz, amelyek jellemzően nem érhetők el a weben keresztül.
A chrome://policy oldal például létfontosságú szerepet játszik a vállalati környezetekben, mivel lehetővé teszi a rendszergazdák és a felhasználók számára a böngésző biztonsági szabályzatainak konfigurálását és érvényesítését. Ezeket a házirendeket a Windows rendszereken a csoportházirendeken keresztül is kezelik.
Mivel a chrome://policy közvetlenül kapcsolatba léphet az operációs rendszerrel, értékes célpont a támadók számára. A CVE-2024-6778 sebezhetőséggel, amely egy versenyállapotot használ ki a Chrome DevToolsban, a támadók rosszindulatú kódot juttathatnak be ezekbe az oldalakba, ami komoly biztonsági kockázatot jelent.
A CVE-2024-6778 technikai elemzése
Discovery
Ezt a sebezhetőséget a Chrome Enterprise 117-es verziójában bevezetett tesztfunkcióban fedezték fel. Ez a funkció lehetővé teszi a házirend tesztelését a chrome://policy/test oldalon keresztül. Mivel a funkcióra vonatkozó hivatalos dokumentáció korlátozott, munkatársaink alaposan megvizsgálták a Chromium forráskódját, kiegészítve a CVE szerzőjének meglátásaival, hogy teljes mértékben megértsük a funkció megvalósítását és azonosítsuk a kapcsolódó biztonsági réseket.
A házirend-kezelés összetevői
OPSWAT munkatársainak forráskód-elemzése kimutatta, hogy az OPSWAT belül chrome://policy/test, a házirendek kezelése a PolicyInfo interfészen keresztül kommunikál a WebUI és a böngésző folyamatok között a PolicyTestBrowserProxy osztály. A PolicyInfo struktúrát a következőképpen határozzuk meg:
Az ezen irányelvek kezeléséért felelős osztály további vizsgálatával azonosított egy módszert, amelynek neve applyTestPolicies. Ez a módszer egy privát API használ, setLocalTestPolicies, a házirendek listájának dinamikus alkalmazásához.
Ahhoz, hogy betekintést nyerjenek abba, hogy a házirend-kérelmeket hogyan dolgozzák fel ezen az API keresztül, a munkatársak elemzik a HandleSetLocalTestPolicies módszer a PolicyUIHandler osztály:
A HandleSetLocalTestPolicies metódus a megadott argumentumokból lekérdezi a házirend adatait, és kap egy mutatót a LocalTestPolicyProvider példányt a böngésző globális házirend-csatlakozóján keresztül. Ezután ellenőrzi a szolgáltató létezését, mielőtt az aktuális felhasználói profilt utasítja annak használatára.
Ez az ellenőrzés elégtelennek bizonyult, mivel csak azt biztosítja, hogy local_test_provider a házirendek alkalmazása előtt nem null. A létrehozása és inicializálása local_test_provider a CreateIfAllowed módszer:
A CreateIfAllowed metódus esetén a visszatérési érték teljes mértékben a IsPolicyTestingEnabled funkció. Ez a függvény határozza meg, hogy egy LocalTestPolicyProvider példányt hoz létre a felhasználói beállítások és a böngésző kiadási csatornájának kombinációja alapján:
Mivel pref_service következetesen nullára van állítva minden alkalommal, amikor IsPolicyTestingEnabled() meghívása esetén az első feltétel megkerülésre kerül, így az engedélyezési döntés kizárólag a böngésző engedélyezési csatornáján múlik.
A nem márkás Chromium-építésekben a kiadási csatorna alapértelmezett értéke Csatorna::ISMERETLEN. A funkció logikája szerint, Csatorna::ISMERETLEN ugyanúgy kezelik, mint Csatorna::DEFAULT, amely alapértelmezés szerint engedélyezi a házirend-tesztelési funkciót. A kódáramlás elemzése kimutatta, hogy a privát API setLocalTestPolicies a WebUI-n keresztül lehet meghívni, hogy házirendeket alkalmazzanak mindenféle értelmes hozzáférési korlátozás nélkül.
Kihasználás
Ennek a privát API az azonosításával és kihasználásával a támadó önkényesen alkalmazhat házirendeket a WebUI-n keresztül, lehetővé téve az olyan beállítások manipulálását, mint a következők BrowserSwitcherEnabled, BrowserSwitcherUrlList, AlternativeBrowserPath, és AlternativeBrowserParameters parancsok végrehajtásához. Például a AlternativeBrowserPath a powershellhez és AlternativeBrowserParameters a címre. ["calc"], tetszőleges héjparancsok hajthatók végre, amikor egy adott URL-t meglátogatnak.
Tetszőleges rosszindulatú felhasználói házirend alkalmazása privát API keresztül
Annak bemutatása, hogy a házirendek hogyan alkalmazhatók a privát setLocalTestPolicies API az előző elemzés során azonosított, a következő JavaScript kód egy olyan szkript, amely beállítja a AllowDinosaurEasterEgg politikát, és hatékonyan alkalmazza azt a WebUI a setLocalTestPolicies:
A házirend sikeresen alkalmazható a AllowDinosaurEasterEgg beállítás.
A nagyobb hatás érdekében a támadó célba veheti a BrowserSwitcher politika:
Ez a házirend lehetővé teszi a böngésző számára, hogy egy alternatív böngészési útvonalat hívjon fel, ha az URL megfelel bizonyos feltételeknek. Ezt úgy lehet kihasználni, hogy ezt az elérési utat úgy konfiguráljuk, hogy az operációs rendszer parancsainak végrehajtásához a rendszer futtatható fájljára mutasson. A következő JavaScript-kód ezt a megközelítést mutatja be:
Ez a szkript a következő feladatokat végzi:
- Engedélyezi a
BrowserSwitcherfunkció a example.com számára - A böngésző alternatív elérési útvonalának beállítása a powerShellhez
- Végrehajtja a
calcminden alkalommal, amikor a megadott URL elérésre kerül.
Rosszindulatú Chrome-bővítmény szimulációja
A házirendek alkalmazását lehetővé tevő privát API azonosítása jelentős támadási vektort jelent a támadók számára. A sebezhetőség hatékony kihasználásához a támadónak olyan rosszindulatú Chrome-bővítményt kell kifejlesztenie, amely a Chrome DevTools API használja rosszindulatú JavaScript-kód futtatására.
A lehetséges valós hatások bemutatására munkatársaink egy olyan forgatókönyvet szimuláltak, amelyben egy rosszindulatú Chrome-bővítményt telepítenek egy sebezhető böngészőre, és azt használják a támadás végrehajtására.A Chrome-bővítmények chrome.devtools API-jai lehetővé teszik a fejlesztők számára a Chrome DevTools felületének bővítését és interakcióját.
A DevTools API kiterjesztésen keresztül történő futtatása azonban bizonyos kihívásokat jelent, amelyeket meg kell kerülni. Először is, a DevTools API csak akkor működik, ha a DevTools nyitva van, és aktívan vizsgálja a webhelyet. Másodszor, a DevTools API nem engedélyezi a kódfuttatást a webes felhasználói felületen, a WebUI-n. Ez a korlátozás segít fenntartani a WebUI biztonságát és integritását a fejlesztési és ellenőrzési folyamatok során.
Javascript végrehajtását jelző jelek az újratöltési API keresztül
A további elemzés kimutatta, hogy a chrome.devtools.inspectedWindow.reload funkcióból hiányzik az ellenőrzés annak megerősítésére, hogy egy bővítménynek engedélyezett-e a szkriptek futtatása a vizsgált oldalon. Az egyetlen védelmi szintje a devtools bővítménykiszolgáló, amely blokkolja a hozzáférést, amint a vizsgált oldal URL címe megváltozik.
About:Az üres oldalak az őket megnyitó oldal engedélyeit és eredetét öröklik. Ez azt jelenti, hogy a webes felhasználói felület jelzéseiből történő átirányításkor az about:blank oldalon kódot lehet végrehajtani, ami potenciális sebezhetőséget jelent.
Kód végrehajtása a webUI-n az újratöltési API keresztül
A versenyfeltétel a chrome.devtools.inspectedWindow.reload() lehetővé teszi a kódfuttatást a Chrome WebUI oldalain (pl. chrome://policy), amelyek általában védettek. A kihasználás kihasználja az újratöltési API azon képességét, hogy az oldalátmenetek során JavaScriptet injektáljon. A következőképpen működik:
- Cél webUI: Nyisson meg egy WebUI oldalt (pl. chrome://policy) egy lapon, és csatolja a DevTools-t.
- Injekciós forgatókönyv: A reload() API használata egy
injectedScriptparaméterrel tetszőleges JavaScript futtatására az újratöltés során. - Versenyállapot kihasználása: A versenyfeltétel akkor lép fel, amikor az újratöltés a WebUI biztonsági mechanizmusainak teljes inicializálása előtt elindul, lehetővé téve a bejuttatott szkript végrehajtását.
Az about:blank oldalról a chrome://policy:
Mivel az oldal eredete helyett csak az URL-t ellenőrzik, a navigáció után van egy rövid időszak, amikor az eredet az új oldalt tükrözi, míg az URL változatlan marad.
Ha chrome.devtools.inspectedWindow.reload meghívása ebben az ablakban történik, előfordulhat, hogy a céloldalon véletlenül JavaScriptet hajt végre.
A megbízhatóság javítása a versenyfeltételekhez
A versenyfeltétel kihasználása eleve megbízhatatlan az időzítéstől való függősége miatt. Ezenkívül a gyors újratöltés vagy a rosszul formált szkriptek oldalösszeomlást okozhatnak. A megbízhatóság javításának újszerű megközelítése az oldal összeomlásának szándékos előidézése, mivel a DevTools segítségével kiadott parancsok általában törlődnek az összeomlás során, de a Page.reload leképezve chrome.devtools.inspectedWindow.reload() fehérlistára kerül, és az oldal újratöltése után végrehajtódik.
A következő egy munkafolyamat-modell, amely egy oldal összeomlását okozza a következő parancsok nyomásával:
A hibakeresési utasítás a Tartalomkönyvben összeomlást okozhat
A hibakereső kétszeri gyors egymás utáni használata megszakítja a navigációs folyamatot egy tartalmi szkriptben. Ez összeomláshoz vezethet azáltal, hogy a navigation_commit_state_ váratlan állapotba kerül. Ez a kérdés akkor merül fel, amikor RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 végrehajtásra kerül, a _navigation_commit_state módosítása egy váratlan értékre.
Az első meghívás szünetelteti a végrehajtást, így a navigation_commit_state_ inkonzisztens állapotban, a második pedig szünetet tart a CHECK_EQ ellenőrzést, így nem sikerül az állapotellenőrzés és összeomlik a rendszer.
Helyreállítás
Ha elmulasztja a böngésző verziójának rendszeres frissítését, akkor eszköze komoly biztonsági fenyegetéseknek lehet kitéve, különösen a CVE-khez (Common Vulnerabilities and Exposures, közös sebezhetőségek és veszélyforrások) kapcsolódó veszélyeknek. E kockázat csökkentése érdekében a MetaDefender Endpoint™ megbízható védelmet nyújt a böngésző verziójának észlelésével és a sebezhetőségek ellenőrzésével, beleértve az ismert CVE-ket, mint például a CVE-2024-6778.
MetaDefender Endpoint biztosítja, hogy az alkalmazás naprakész legyen, és jelzi az elavult vagy fertőzött verziókat. Emellett CVE súlyosság szerint kategorizálva felsorolja az ismert sebezhetőségekkel rendelkező telepített alkalmazásokat, és javításokat javasol a potenciális fenyegetések hatékony csökkentése érdekében. Ha élő bemutatót szeretne látni arról, hogy MetaDefender Endpoint hogyan segíthet Önnek csökkenteni ezeket a kockázatokat, lépjen kapcsolatba szakértőnkkel még ma.
