Javascript-aanval kan toetsaanslagen monitoren via cpu-cache

Onderzoekers van Cornell University hebben een aanvalsmethode ontwikkeld waarmee de L3-cache van Intel-processors uitgelezen kan worden met behulp van javascript. Daardoor zijn toetsenbordaanslagen en muiskliks uit te lezen.

Om de aanval, getiteld 'The Spy in the Sandbox', uit te kunnen voeren, is het niet nodig andere software te installeren op de machine van een doelwit. Het slachtoffer hoeft slechts een webpagina te bezoeken waar speciaal vervaardigde content van de aanvaller op staat. De methode werkt ook binnen virtual machines, blijkt uit de onderzoekspaper. De exploitcode zal niet worden vrijgegeven voordat browsers gepatched zijn.

Het gaat om een zogeheten side channel attack. Een zijkanaalaanval is een aanval waarbij de implementatie van cryptografische systemen wordt misbruikt, in plaats van de cryptografische algoritmes zelf. Het onderzoek zelf is zeer academisch, schrijft The Register, maar de site geeft wel als voorbeeld dat het op een Mac met een Intel Core i7 en OS X 10.10.2 bij gebruik van Firefox 35.0.1 mogelijk was binnen een minuut de helft van de L3 cache in kaart te brengen.

Op het moment dat een gebruiker op een site komt met inhoud die de hacker beheert, bijvoorbeeld met behulp van een malafide advertentie, kan javascript-code worden uitgevoerd die de toetsenbord- en muisinvoer kan bekijken en opslaan. Beide handelingen gebeuren binnen de cache van een Intel-cpu. De L3-cache, ook wel last-level cache, wordt gedeeld door alle cores. De methode werkt niet bij AMD-processors omdat daar het cache-geheugen anders benaderd wordt.

Als schadelijke javascript draait, laadt de code de cache en kent hij daarmee de staat van de cache. Vervolgens wacht de code op een gebruiker om iets te doen, zoals een toets aanslaan. De code gebruikt dan de timers van de browser om op te slaan hoeveel tijd het kost om door een geheugenblok te gaan. Als de toegang sneller gaat dan bij andere acties, dan staat het nog in de cache. Met die informatie is het patroon in kaart te brengen waarmee het geheugen aangesproken wordt op bijvoorbeeld toetsaanslagen of muisbewegingen. Dat patroon kan opnieuw worden afgespeeld.

De onderzoekers geven tegen TechWorm wel aan dat de exploit niet rechtstreeks wachtwoorden of data kan stelen, maar de data-invoer van muis en toetsenbord op kan slaan. Een potentiële hacker kan de toetsaanslagen klonen en vervolgens via de surfgeschiedenis bezochte sites relateren aan die aanslagen. Volgens de onderzoekers gaat het om de eerste side channel-attack die vanuit de browser is uit te voeren.

Reacties (81)

Een zijkanaalaanval is een aanval waarbij de implementatie van cryptografische systemen wordt misbruikt

Dat is volgens mij alleen in de crypto-wereld zo gedefinieerd.
In dit geval gaat het echter niet om een side channel van een cryptosysteem.

Je moet side-channel aanvallen meer zien als het aanvallen van een systeem buiten de door het systeem gestelde informatiepaden. Zo gaat een IC er in zn werking niet van uit dat iemand de bovenkant eraf vijlt en er probes in stopt. Dat heeft verder dus niet zoveel met cryptografie te maken.
En in het in het artiekel beschreven verhaal blijk de cache middels gedrag van de implementatie informatie vrij te geven waar in het ontwerp geen rekening mee gehouden is. Dat is dus een side channel waar je onbedoelt informatie van kan tappen.

Ik heb het idee dat de issues op osx relatief vaak met javascript te maken hebben (nu is dat ook weer zo). Kan iemand mij uitleggen waarom Javascript zon bedreiging vormt?

Javascript is uitgegroeid tot een superkrachtige programmeertaal binnen de steeds complexer en krachtiger wordende browsers. Het gevaar van Javascript op internet is dat krachtige code zonder enige verificatie klakkeloos van externe servers wordt geplukt door de browser (het laden van een website), en lokaal wordt uitgevoerd, en waar een 2-weg communicatie met de server altijd mogelijk is zonder dat de gebruiker daar veel controle over heeft.

Vergelijk dat met 'normale' applicaties waar de bron veel vaker duidelijk is (en je jezelf tegen kwaadaardige code kan beschermen door bv alleen apps uit de Apple Store te gebruiken), en waar je direct kan zien als ze met een externe server lopen te communiceren, en je ziet direct waarom Javascript exploits zo populair zijn bij hackers.

[Reactie gewijzigd door Dreamvoid op 21 april 2015 12:16]

Je kan je browser toch beveiligen tegen cross-site scripting (XSS)? Ik gebruik dan IE, maar in de opties -> security -> custom level staat bij de scripting opties de XSS filter aan. Geen idee hoe deze precies werkt, maar deze optie schijnt tegen cross-site scripting te gaan.
http://www.sevenforums.co...-xss-filter-turn-off.html

Eén van de gevolgen van het steeds veelzijdiger toepassen van Javascript is dat het tegenwoordig heel gebruikelijk is dat een website requests doet naar verschillende api's van verschillende partijen. Waarschijnlijk weet je er zo wel een paar op te noemen waar je kunt inloggen met je facebook-account of plattegronden uit google maps te zien krijgt. Het is dus haast onmogelijk simpelweg alle cross-origin requests te blokkeren zonder héél veel functionaliteit te breken.

Dit is ook één van de redenen waarom het gebruik van HTTPS steeds belangrijker wordt. Alleen als een website volledig via een versleutelde verbinding geladen wordt, kun je er vanuit gaan dat de scripts die daarbij meegekomen zijn, niet onderweg door een aanvaller aangepast zijn. Het is geen 100% garantie want ook de webserver zelf zou gecompromitteerd kunnen zijn, maar die kans is in ieder geval een stuk kleiner.

Off Topic:
HTTPS helpt je niet bij deze aanval zoals hij is omschreven in het artikel want er staat nergens iets over cross-origin. Het tegendeel zelfs, het gaat over een same origin aanval. En HTTPS gaat je dus 100% gegarandeerd daar nooit tegen beschermen.

Eigenlijk beschermd HTTPS je helemaal nergens tegen.
Het berust op vertrouwen in registrars. En er is al meerdere malen gebleken in de afgelopen jaren dat meerdere registrars volstrekt onbetrouwbaar waren (en mogelijk nog zijn), ondanks het feit dat ze aangemerkt zijn als vertrouwde root CA.

Je moet ook helemaal niet raar staan te kijken als in de komende tijd blijkt dat bij meerdere registrars, mensen werkzaam zijn/waren die uiteindelijk voor criminelen blijken te werken en officiële certificates aanmaken die misbruikt gaan worden voor criminele activiteiten.

On Topic:
We hebben het hier over een probleem in de implementatie van de JavaScript engine.

Met een script taal zou het sowiso niet mogelijk moeten zijn om hardware rechtstreeks te kunnen benaderen.
En de CPU cache uitlezen zou al helemaal niet moeten kunnen.

Ik vraag me af of dit specifiek in de javascript engine van Mozilla op OSX zit of dat het echt een fundamenteel ontwerp probleem is dat zit ingebakken in de Ecmascript 5 specificatie en dat het theoretisch dus met alle implementaties van Javascript kan, op alle operating systemen.

Tevens, gezien HTML 5 expliciet genoemd wordt (en daarmee dus indirect specifiek EcmaScript 5) is het goed mogelijk dat het alleen moderne webbrowsers zullen zijn die her last van gaan hebben.

HTTPS zorgt ervoor dat je in ieder geval controle hebt over de bron van de scripts die je draait. Als je die bron vertrouwt scheelt dat al een hele boel. Als de bron zelf niet te vertrouwen is (ofwel omdat de serverbeheerder zelf niet te vertrouwen is, ofwel omdat de server gecompromitteerd is) heb je inderdaad nog steeds potentieel een probleem.

Dat niet alle CA's te vertrouwen zijn is weer een heel ander probleem.

Natuurlijk is het belangrijkste dat de exploit zelf zo snel mogelijk gepatcht wordt, maar het aanbieden van encryptie is een extra vangnet in het gatenkaasmodel dat de impact van deze en vele andere exploits aanzienlijk kan verkleinen.

HTTPS zorgt voor encryptie van web verkeer tussen punt A en punt B. En dat is *alles* wat het doet.

Het zegt niets over de inhoud van de bron.
Het zegt niets over de betrouwbaarheid van die bron.
Het garandeert ook niet of de inhoud uberhaupt afkomstig is van diezelfde bron of dat je wordt geredirect naar een andere HTTPS website met een ander geldig certificate die gebruik maakt van scripting truckjes waardoor het lijkt alsof het URL in je browser er goed uitziet, en/of zelfs dezelfde is als die waar je verwachtte op uit te komen.

En omdat HTTPS fundamenteel defect is kun je zelfs niet eens met zekerheid weten of de informatie niet is aangepast ergens tussen punt a en b door een man in the middle die tussentijds decryptie en re-encryptie doet.
Zo lang er een certificate aan hangt die ergens in de chain een CA heeft die in de browser als vertrouwd staat aangemerkt krijg je niets te zien of te horen over wat er onderweg al dan niet is gebeurt.

Encryptie biedt nul veiligheid of garanties met betrekking tot exploits of malware. Het is fundamenteel onbruikbaar als beveiligings mechanisme daarvoor.

Dit filter is verre van perfect, veel XSS-aanvallen omzeilen het met gemak. Dit is ook de reden dat het filter niet meer bestaat in nieuwere versies van IE.

Ik had al zo'n vermoeden dat het filter niet perfect zou zijn. Overigens zeg je dat het filter niet meer bestaat in nieuwere versies van IE, maar ik heb IE11 en zie de optie nog steeds.

Excuses, ik meende te hebben gelezen dat het al niet meer bestond. Wellicht dat Microsoft in de toekomst dit dan wel gaat doorvoeren, aangezien zelfs de meest simpele XSS-vectoren vaak niet herkend worden

Wel weten dat simpele XSS vectoren niet herkend worden in IE, niet weten dat IE11 (en dusver ook Spartan) gewoon XSS filter heeft.

When the IE team talks about Cross-Site-Scripting (XSS) attacks, we’ve usually grouped them into three categories

Type 0: DOM-based XSS
Type 1: “Reflected” XSS
Type 2: Persistent/Stored XSS

DOM-APIs like toStaticHTML enable pages to protect themselves against Type 0 attacks. The Internet Explorer XSS Filter can block Type 1 attacks by detecting reflected script and neutering it. Servers can protect themselves against Type 2 attacks using the Anti-XSS library to sanitize stored data.

http://blogs.msdn.com/b/i...e-address-bar-in-ie9.aspx

Overigens,
http://blogs.msdn.com/b/i...nd-internet-explorer.aspx

[Reactie gewijzigd door batjes op 21 april 2015 17:13]

Achja, kan niet alles weten, toch :-)

true, was ook geen aanval verder

Probleem is niet eens XSS, maar meer: het is redelijk makkelijk om mensen geen native apps van dubieuze afkomst te laten installeren, maar iedereen kan met 1 klik op een vage website terecht komen waar malafide Javascript code staat - sterker nog met automatische redirects hoef je niet eens te klikken.

[Reactie gewijzigd door Dreamvoid op 21 april 2015 19:37]

Er zit nog wel enige nuance in, deze aanval is op OSX, Windows Android mogelijk, iOS bied deze mogelijkheid niet.

Er zit ook nog een verschil in de browser soort, zowel Safari als Chrome als IE kennen dit probleem, wel is het zo dat het makkelijker is op Chrome, dan IE dan Safari. Dit heeft te maken met een timing (High Resolution Time API).

Beetje een lang stuk maar legt het wel uit (staat op pagina 11 van het onderzoeks rapport):

The effectiveness of our attack depends on being able to perform precise measurements using the Javascript High Resolution Time API. While the W3C recommendation of this API [16] specifies that the a high-resolution timestamp should be “a number of milliseconds accurate to a thousandth of a millisecond”, the maximum resolution of this value is not specified, and indeed varies between browser versions and operating systems.

In our testing we discovered, for instance, that the actual resolution of this timestamp for Safari for MacOS was on the order of nanoseconds, while Internet Explorer for Windows had a 0.8µs resolution. Chrome, on the other hand, offered a uniform resolution of 1µ on all operating systems we tested. Since, as shown in Figure 3, the timing difference between a single cache hit and a single cache miss is on the order of 50ns, the profiling and measurement algorithms need to be slightly modified to support systems with coarser-grained timing resolution. In the profiling stage, instead of measuring a single cache miss we repeat the memory access cycle multiple times to amplify the
time difference. For the measurement stage, we cannot amplify a single cache miss, but we can take advantage of the fact that code access typically invalidates multiple consecutive cache sets from the same page frame. As long as at least 20 out of the 64 cache sets in a single page frame register a cache miss, our attack is successful even with microsecond time resolution.

The attack we propose is also easily applied to mobile devices such as smartphones and tablets. It should be noted that the Android Browser supports High Resolution Time and Typed Arrays starting from version 4.4, but at the time of writing the most recent version of iOS Safari (8.1) did not support the High Resolution Time API.

Javascript staat niet aan, klik hier voor de versie zonder Javascript *muisklik*
Javascript staat niet aan, klik hier...

Behalve voor specifieke online software zoals mijn email en CRM programma, een tiental bank, foto en multimedia websites heb ik genoeg aan web 1.0 voor informatieve doeleinden.

Zelfs professionele sites van banken kunen niet laten Google scripts toe te laten, een schreeuw om installatie van NoScript.
Wilde Javascripts zijn meer regelmatig dan niet een pain in the ass die je moet gedogen als je aan informatie wilt raken.

Een browser waar je per tab javascript kunt inschakelen indien gewenst lijkt me een minimumvereiste om de argeloze surfer te confronteren met zijn verantwoordelijkheid mbt scripts op een vreemde website.
De laatste keer dat ik het gezien heb was een browser waarvan de naam me onglipt, op Symbian OS

Zonder JS zit je niet direct op web 1.0, met server-side scripting kan je vrijwel alles doen - maar ten koste van wat snelheid, en enorm veel meer serverload, en daar zitten websites niet op te wachten.

Niets staat je in de weg om een Javascript-loze bank website te maken met enkel HTML5/CSS3, allemaal netjes over HTTPS.

Dat blijft de ellende met JavaScript, het hele concept waar de client ongeverifieerde code van onbekende servers uitvoert is fundamenteel lek. Beter zou zijn om scripts enkel serverside te draaien en enkel HTML te renderen op de client, maar dat kost weer zoveel cpu tijd aan de server kant...

In het geval van advertenties klopt dit wel. Waarom moeten publishers JavaScript code in hun advertenties kunnen serveren? Een advertentie mag voor mij enkel plain HTML zijn met wat tekst en/of een afbeelding.

Met HTML5 en daarop gebaseerde banners wordt het alleen nog maar erger. Reclame makers willen je aandacht, die zijn ze allang kwijt met enkel een plaatje en tekst, dus moeten ze een stap verder, tot we daar ook niet meer op reageren en weer een stap verder moeten gaan om onze aandacht op te eisen.

Met css aninaties, links en zelfs video kan je zonder scripts toch wel een hoop doen. Het hoeft lang geen statische banner te zijn.

Javascript wordt al jaren steeds populairder, omdat je er zoveel interactie mee kunt creëren. Minder data versturen, meer functionaliteit en snelheid. Daar heb je de browser bij nodig.

Kost niet alleen maar CPU tijd. Alle acties gaan dan opeens een roundtrip vereisen, dus alles wordt enorm traag.

Op het moment dat een gebruiker op een site komt met inhoud die de hacker beheert, bijvoorbeeld met behulp van een malafide advertentie, kan javascript-code worden uitgevoerd die de toestenbord- en muisinvoer kan bekijken en opslaan.

Is het in dit speciale geval dan al niet meer nodig om op zo een advertentie te klikken om geïnfecteerd te worden? Dat maak ik een beetje uit het dik gedrukte deel op. Dat zou dan moeilijk te ontwijken zijn.
Of moet je toch eerst specifiek op zo een advertentie klikken?

Hoe gevaarlijk deze aanval is ligt aan de technology van de advertentie. Sommige advertenties include je als script, dat betekend dat de code dezelfde 'rechten' heeft als code van de site zelf. Daardoor kun je naar alle events op de pagina luisteren.

Als je een advertentie in een iframe draait (op een ander domein) dan mag code in het iframe niet bij de parent window. Je kunt dan alleen events capturen die op het iframe worden uitgevoerd.

Klikken maakt niet uit. Klikken is alleen nodig als je iemand een popup wilt geven omdat browsers standaard popups (`window.open()`) blokkeren als deze niet uit een klik event voort komt.

Ik heb het even opgezocht ter controle en een iframe kan weldegelijk aan de code van zijn parent raken. Je moet er gewoon van uit gaan dat een veilige pagina niet echt bestaat.

[Reactie gewijzigd door FlaffTweakr op 21 april 2015 19:13]

Iframes maakt niks uit voor deze attack. Het gaat erom dat de code uitgevoerd wordt. Parents of niet belemert de code daar niet in

Dus deze aanval is via advertentie scripts wel degelijk effectief.

[Reactie gewijzigd door Engineer op 21 april 2015 22:29]

Een iframe kan alleen de parent uitlezen als ze op hetzelfde (sub)domein draaien. Ervan uitgaande dat jouw advertentie leverancier de advertenties serveert op hun eigen domein kan de code dus niet bij de parent.

Bedenk immers wat mogelijk zou zijn als deze domein ristrictie er niet was. Facebook opent een iframe naar ing.nl en kan jouw bankgegevens inzien (als je toevallig bent ingelogt), en vice versa! Dat kan natuurlijk niet.

Het sandbox attribuut bied nog meer mogelijkheden om de rechten van een iframe in te perken.

JS wordt automatisch al ingeladen, dus hoef je idd niet meer te klikken

De paper staat op arXiv.

Nou ben ik geen programeur maar mijn inziens is de foto in dit artikel wl een tikkeltje misleidend. In hun paper The Spy in the Sandbox – Practical Cache Attacks in Javascript staat het volgende hierover:

To evaluate the bandwidth of this covert channel, we wrote a simple program that iterates over memory in a predetermined pattern (in our case, a bitmap containing the word “Usenix”). Next, we attempted to search for this memory access pattern using a Javascript cache attack, then measured the maximum sampling frequency at which the Javascript code could be run.

Dit betreft dus een bitmap, en niet een 6 letter woord an sich. Daaruit besluit ik dat het niet zo is dat men met deze side channel attack zomaar een dump krijgt van alles wat je typt op je keyboard.

Moet ik zeggen dat de toepassingswaarde van deze "hack" voor malifide doeleinden toch wel erg beperkt is - je moet erg veel tijd en energie investeren om te leren waar de gebruiker naartoe heeft genavigeerd - en dan moet je die gegevens nog in een zinnig beeld gaan gieten waar je wellicht een klein beetje economisch wijzer van kan worden. Ik vermoed dat men toch liever op zoek gaat naar eenvoudigere exploits met meer knallen voor de pegel.

Het is eerder dat het erg knap gevonden is en bij bepaalde mensen de geest zou moeten verruimen betreffende software security en sandboxing.

Weer een reden om altijd NoScript en Adblock gebruiken.

Dat is toch wel heel kort door de bocht...

Dus omdat er nu een bug bekend is binnen javascript dat misschien door advertenties gebruikt word knal je er alles vanaf.

Paar jaar geleden was Nu.nl ook besmet met een of ander nasty iets, ga je daarom nu maar alle nieuwssites vermijden?

edit: typo

[Reactie gewijzigd door Yariva op 21 april 2015 12:07]

NU.nl wordt sowieso gemeden.

Maar (wekelijkse?) nieuwsberichten zoals deze laat weer duidelijk zien dat men er goed aan doet een 'internetcondoom' te gebruiken in de vorm van ad- en scriptblockers. Net als dat je je autodeur op slot doet, ondanks dat het 99 van de 100 keer geen probleem is dat niet te doen. Het gaat juist om die ene keer dat het fout gaat en gevolgen heeft voor jouw systeem.

[Reactie gewijzigd door geekeep op 21 april 2015 12:34]

Paar jaar geleden? Vorig jaar nog... en een paar jaar ervoor ook.

En hoe weet die NoScript wanneer het gewoon gaat om site functionaliteiten?

Dat noemen we nou whitelisting. Ik heb standaard alle third-party javascripts gedisabled. Alleen de javascripts welke voldoende aan same-origin worden by default geladen. Voor alle andere scripts moet ik toestemming geven om het script te draaien..

Deze werkwijze heeft ook een nadeel. Steeds meer scripts worden van CDN's gelezen en die werken dus ook niet met mijn policy. Althans niet standaard out of the box. Je zult dan bepaalde CDN's moeten gaan whitelisten.

Los van wel of niet draaien van javascript. Hoe is het in godsnaam mogelijk dat javascript RECHTSTREEKS toegang krijgt tot de hardware op *ALLE* browsers want de drie grote browser fabrikanten hebben elk hun eigen javascript engine..

Ik krijg ineens flashbacks naar eind jaren 90 waar VBScript standaard ook allerlei ActiveX controls kon benaderen..

het concept sandbox en rechtstreekse toegang tot het l3 cache vind ik ook nogal tegenstrijdig
of stelt zo'n sandbox eigenlijk niets voor?

Tsja, dat is nou eenmaal wat de markt wilde - HTML5/JS met super krachtige API's zodat je met een remote hosted webapp vergelijkbare dingen kan als met een native app. We weten al 20 jaar wat de security implicaties zijn, maar de drive naar al-maar-diepere toegang van browsers in het OS is onstopbaar.

In principe ben ik voorstander van het blokkeren van *alle* client-side scripting - met de komst van HTML5 heb je in principe al veel minder Javascript nodig. Maar zolang nog zoveel websites anno 2015 steunen op client-side JS zal dat nog wel even duren voordat dat praktisch wordt.

[Reactie gewijzigd door Dreamvoid op 21 april 2015 19:42]

Zoals in het artikel als voorbeeld word gegeven : "Op het moment dat een gebruiker op een site komt met inhoud die de hacker beheert, bijvoorbeeld met behulp van een malafide advertentie, kan javascript-code worden uitgevoerd die de toestenbord- en muisinvoer kan bekijken en opslaan. "
Voor functionaliteit heb je geen externe partijen nodig dus die kan je dan blokken.

Voor functionaliteit heb je geen externe partijen nodig dus die kan je dan blokken.

Als je een scriptje gebruikt om je pagina horizontaal te scrollen en dat script staat uit dan zijn er genoeg sites die dat nu momenteel toe passen en het na het blocken niet meer doen... Beetje utopistische stelling...

Als je een scriptje gebruikt om je pagina horizontaal te scrollen en dat script staat uit dan zijn er genoeg sites die dat nu momenteel toe passen en het na het blocken niet meer doen... Beetje utopistische stelling...

Maar dat soort scripts moet je (imho) ook gewoon zelf hosten.

Nog steeds ben ik geen fan van het blocken van alle javascripts, dat gaat me een stapje tever. Maar dat je voor de functionaliteit van je site geen externe partijen nodig hebt, daar kan ik me wel in vinden.

Ik ben benieuwd naar de paper over deze aanval.
Ik ben c++ / JavaScript georiënteerd .

En ik zou deze attack graag helemaal willen snappen, en het liefst willen herproduceren voor leer doeleinden.

In de paper http://arxiv.org/pdf/1502.07373v2.pdf staat de uitschrijving, niet geheel in code maar als je het goed doorleest zou je het zelf kunnen schrijven. Daarvoor zijn onderzoek papers bedoeld.

Ik vrees dat je voor deze hack van goede huize zal moeten komen. Gaat een stuk meer skills in zitten dan puur het Javascript gedeelte iig.

Je zal 100% moeten snappen, tot op de bit, hoe je cpu werkt, hoe L3 cache gebruikt wordt, hoe je met Javascript timers daar metingen aan kan verrichten, hoe je die metingen icm gedane toetsaanslagen kan herleiden naar andere informatie.

Ik zou me maar 3x bedenken eer hieraan te beginnen Tenzij je helemaal hardcore-into dit soort puzzels bent.

[Reactie gewijzigd door Engineer op 21 april 2015 22:24]

ja anders zou ik mijn intresse niet tonen.