Nyt NetSpectre-angreb kræver ikke ofre for at downloade eller køre skadelig kode

Sikkerhed / Nyt NetSpectre-angreb kræver ikke ofre for at downloade eller køre skadelig kode

NetSpectre bombarderer maskinhavne for at få adgang

4 minutter læst

Et nyt CPU-angreb fra Spectre-klassen har fået opmærksomhed fra akademiske forskere, da de for nylig udgav et forskningsoplæg med titlen 'NetSpectre: Læs arbitrær hukommelse over netværk', der går i dybdegående detaljer om, hvordan denne klasse af CPU-angreb fungerer.



Hvad der gør det nye Spectre CPU-angreb lidt skræmmende er, at det kræver ikke angriberen for at narre deres offer til at downloade og køre ondsindede scripts på deres maskine eller endda få adgang til et websted, der kører ondsindet JavaScript i brugerens browser.

NetSpectre vil simpelthen bombardere en maskins netværksporte, indtil den finder en måde at nå sine mål på.



”Specterangreb får et offer til spekulativt at udføre operationer, der ikke ville forekomme under strengt seriebestemt behandling af programmets instruktioner i rækkefølge, og som lækker et offer fortrolige oplysninger via en skjult kanal til en angriber”



NetSpectre kommer dog ikke uden sine egne fejl. Det har en utrolig langsom eksfiltreringshastighed, omkring 15 bit i timen, for angreb, der skal udføres via en netværksforbindelse, og målretning mod data, der er gemt i CPU-cachen.



I forskningsopgaven var akademikerne i stand til at opnå op til 60 bits / time med en speciel variation af NetSpectre, der målrettede mod data, der blev behandlet via CPU's AVX2-modul, som er specifikt for Intel-CPU'er.

I begge tilfælde betragtes NetSpectre i øjeblikket for langsom til at være værdifuldt for angribere, hvilket betyder, at NetSpectre kun er en teoretisk trussel, ikke noget, som virksomhederne skal dykke til dækning fra lige endnu . Efterhånden som teknologien skrider frem, vil eksfiltreringshastighederne utvivlsomt stige, og så har vi en helt ny klasse af levedygtige og utroligt nemme at udføre CPU-angreb at bekymre os om.

Det nye NetSpectre-angreb er relateret til Spectre V1-sårbarheden (CVE-2017-5753), som Google-forskere afslørede tidligere på året (2018). Dette betyder, at alle CPU'er, der kan blive påvirket af Spectre V1, også antages at være NetSpectre, hvis den er implementeret med korrekt OS- og CPU-firmware.



Der er i øjeblikket to angrebsvarianter til NetSpectre: Uddrag af data fra målsystemet og fjernbrydning af ASLR (Adresse Space Layout Randomisation) på målsystemet.

Begivenhedskæden for den første slags angreb går sådan her:

  1. Mistræn filialprediktoren.
  2. Nulstil tilstanden for det mikroarkitektoniske element.
  3. Læk lidt ud til det mikroarkitektoniske element.
  4. Eksponer tilstanden for det mikroarkitektoniske element til netværket.
  • I trin 1 fejler angriberen grenprediktoren for offeret for at køre et Spectre-angreb. For at fejle grenprediktoren udnytter angriberen lækagadget med gyldige indekser. De gyldige indekser sikrer, at grenprediktoren altid lærer at tage filialen, dvs. grenprediktoren spekulerer i, at betingelsen er sand. Bemærk, at dette trin kun er afhængig af lækagadget. Der er ingen feedback til angriberen, og derfor behøver den mikroarkitektoniske tilstand ikke at blive nulstillet eller transmitteret.
  • I trin 2 skal angriberen nulstille den mikroarkitektoniske tilstand for at muliggøre kodning af lækkede bits ved hjælp af et mikroarkitektonisk element. Dette trin afhænger i høj grad af det anvendte mikroarkitektoniske element, f.eks. Når man udnytter cachen, downloader angriberen en stor fil fra offeret; hvis AVX2 bruges, venter angriberen simpelthen i mere end 1 millisekund. Efter dette trin er alle krav opfyldt for at lække lidt fra offeret.
  • I trin 3 udnytter angriberen Spectre-sårbarheden til at lække en enkelt bit fra offeret. Da grenprediktoren mistrainses i trin 1, vil tilvejebringelse af et indeks uden for grænserne til lækagadget'en køre in-bounds-stien og ændre det mikroarkitektoniske element, dvs. biten er kodet i det mikroarkitektoniske element.
  • I trin 4 skal angriberen transmittere den kodede information via netværket. Dette trin svarer til anden fase af det oprindelige Spectre-angreb. Angriberen sender en netværkspakke, der håndteres af transmitteringsgadgeten og måler tiden fra afsendelsen af ​​pakken, indtil svaret ankommer.

Angrebsmetode nr. 2: Fjernbrydning af ASLR

  1. Mistræn filialprediktoren.
  2. Få adgang til et indeks uden for grænserne for at cache en (kendt) hukommelsesplacering.
  3. Mål udførelsestiden for en funktion via netværket for at udlede, om adgangen uden for grænsen cachede en del af den.

Specter modforanstaltninger

Intel og AMD anbefaler at bruge lfence-instruktionen som en spekulationsbarriere. Denne instruktion skal indsættes efter sikkerhedskritiske grænsekontroller for at stoppe den spekulative udførelse. At tilføje dette til alle grænsekontrol har imidlertid en betydelig præstationsomkostning.

Da NetSpectre er et netværksbaseret angreb, kan det ikke kun forhindres ved at afbøde Spectre, men også gennem modforanstaltninger på netværkslaget. Et trivielt NetSpectre-angreb kan let detekteres af en DDoS-beskyttelse, da flere tusinde identiske pakker sendes fra den samme kilde.

En angriber kan dog vælge enhver kompromis mellem pakker pr. Sekund og lækkede bits pr. Sekund. Således kan den hastighed, hvormed bit lækker, simpelthen reduceres under den tærskel, som DDoS-overvågningen kan registrere. Dette gælder for enhver overvågning, der forsøger at opdage igangværende angreb, fx indbrudsdetekteringssystemer.

Selvom angrebet teoretisk ikke forhindres, bliver angrebet på et eller andet tidspunkt umuligt, da den tid, det tager at lække lidt, stiger drastisk. En anden metode til at afbøde NetSpectre er at tilføje kunstig støj til netværksforsinkelsen. Da antallet af målinger afhænger af variansen i netværkslatens, kræver yderligere støj, at en angriber udfører flere målinger. Således, hvis variansen i netværkslatens er høj nok, bliver NetSpectre-angreb umulige på grund af det store antal nødvendige målinger.