'Websites kunnen surfgeschiedenis browsers achterhalen door laadtijd te meten'

Chrome, Firefox en Internet Explorer zijn nog kwetsbaar voor een oude aanval, waarbij de surfgeschiedenis kan worden achterhaald. Dat blijkt uit recent onderzoek van een Belgische student van de Universiteit Hasselt. Ook andere browsers lopen vermoedelijk risico.

De Belgische student, Aäron Thijs, onderzocht of browsers het websites toelaten de surfgeschiedenis te achterhalen. Daarvoor schreef hij code die hij baseerde op het werk van Paul Stone, de onderzoeker die de kwetsbaarheid vorig jaar wereldkundig maakte.

In zijn onderzoek gebruikte Thijs een programmeerinterface om te bepalen of een website eerder door de browser is bezocht. De interface heet requestAnimationFrame en is voornamelijk bedoeld om animaties op websites soepeler af te spelen. Door de interface aan te roepen op een pagina met veel links, is het mogelijk om de surfgeschiedenis te achterhalen. Dit kan door het verschil te meten in de huidige tijd en de tijd dat een linkje van kleur verandert als een site eerder is bezocht.

Volgens Thijs zijn in ieder geval Chrome, Firefox en Internet Explorer nog kwetsbaar voor de kwetsbaarheid, die vorig jaar aan het licht kwam. Hij denkt dat ook Safari en Opera risico lopen. Hoewel Thijs dit nog niet heeft getest, lijkt het aannemelijk dat de gebruikers van die browsers ook risico lopen. Beide hebben namelijk oorspronkelijk dezelfde browserengine als Chrome, namelijk WebKit.

Thijs waarschuwt dat de aanval in iedere website kan worden geïmplementeerd en dat het, zonder medeweten van de bezoeker, gegevens kan vergaren en die vervolgens kan doorspelen. Het is niet ondenkbaar dat dit gebeurt; in 2010 bleken websites als YouPorn en PornHub met javascriptcode eveneens de surfgeschiedenis van gebruikers te achterhalen, wat voor die partijen vermoedelijk strategische inzichten bood. "In mijn voorbeeld controleerde ik alleen Facebook, maar de aanval zou kunnen worden aangepast om een grotere set met websites te controleren", laat de student aan ArsTechnica weten.

De browsermakers hebben ondanks dat de kwetsbaarheid al een tijd bekend is, nog geen oplossing uitgebracht voor de recente kwetsbaarheid. Firefoxmaker Mozilla zou al werken aan een softwarepleister. Daarnaast zouden Chrome-ontwikkelaars aan het nadenken zijn over een fix en is het privacyprobleem ook aangekaart bij Microsoft. Gebruikers die in de tussentijd minder risico willen lopen, kunnen de browsergeschiedenis uitschakelen.

Update, 19.40 uur - In het artikel stond aanvankelijk dat Thijs de kwetsbaarheid ontdekte, maar dit is onjuist. Hij gebruikte een aanval die was gebaseerd op bekend werk van Paul Stone. Daarnaast was de uitleg over de werking van de aanval niet correct. Het artikel is op beide punten aangepast.

Reacties (37)

Dit komt een keer in de zoveel tijd weer terug in een of andere vorm. Voorheen door de kleur op te vragen van link elementen of te timen hoe lang het duurde voordat een iframe is geladen. Af en toe blokkeren browsers een methode die te efficient en met te grote zekerheid kan checken of een website is bezocht, maar helemaal voorkomen kunnen browsermakers het niet.

Zo kan je nog steeds een plaatje laden van een andere website en timen hoe lang dat duurt. Duurt het kort dan is de website bezocht, duurt het lang, dan waarschijnlijk niet. Zie bijvoorbeeld deze bug uit 2007 die nog steeds niet is opgelost: https://bugzilla.mozilla.org/show_bug.cgi?id=377117

[Reactie gewijzigd door Blaise op 6 juni 2014 18:47]

"Gebruikers die in de tussentijd minder risico willen lopen, kunnen het onthouden van de zoekgeschiedenis in hun browser uitschakelen." Ik denk dat hier de browsercache wordt bedoeld. Ik ben dan wel benieuwd of dit nog werkt als je de library's bij google vandaan plukt

ben benieuwd of dit ook van toepassing is wanneer je 'incognito' surft

A PoC that uses method 1 is attached. It repeatedly cycles through a number of URLs. For each URL it draws a number of <a> elements then uses requestAnimationFrame to time the next 5 frames. Usually the first two frames are involved in rendering the links, then a redraw will occur around the 3rd or 4th frame if the link is visited. The PoC tries to detect if more than 2 frames are 'slow' and regards this as a visited link.

Dus om jullie vragen te beantwoorden: nee, het is echt de browsergeschiedenis die je uit moet hebben staan en in chrome incognito werkt het niet op z'n minst.

Om het even in basis taal uit te leggen:

• Stap 1 is het aanmaken van een linkje
• Stap 2 is het wegschrijven van de huidige tijd
• Nu, Stap 3, als een link bezocht is krijgt hij een ander uiterlijk, maar dat kan je in code niet achterhalen, wat je wel kunt doen is kijken wanneer de browser je min of meer zegt: "ik heb weer tijd".
• Als het verschil tussen stap 2 en stap 3 "klein" is dan weet je dat het uiterlijk van de link niet hoefde te worden aangepast, is het verschil relatief groot (vergeleken met een control link die zeker niet bezocht kon zijn) dan is de site wel bezocht

Al met al heeft het dus niks te maken met

hoe lang een browser doet over het tonen van een bepaalde website

. Klinkklare onzin. Sorry tweakers. En nog respect aan het adres Paul Stone (ik kan niks vinden wat Aaron Thijs hieraan zou hebben bijgedragen, de gehele aanval kan worden uitgevoerd op basis van de bug reports van Paul Stone en er is dus ook niks nieuws aan), je komt vaak genoeg hacks en bugs tegen die nergens op slaan, maar dit vind ik toch wel geniaal bedacht.

[Reactie gewijzigd door David Mulder op 6 juni 2014 18:49]

Je quote daar van de link in de laatste paragraaf van het artikel. Ik twijfel of die over hetzelfde item gaat, aangezien de timestamps een jaar oud zijn. De auteur meldt daar ook dat ie "komende maand" (dus nu: "afgelopen jaar") een presentatie zou houden op Black Hat over dat onderwerp. Ik kan me niet voorstellen dat een issue dat al een jaar geleden op een grote conferentie behandeld is nog te beschouwen is als een "nieuwe ontdekking".

Edit:
Heb even die Black Hat presentatie gegoogled, dit zou hem moeten zijn: http://www.youtube.com/watch?v=KcOQfYlyIqw
Op 12:20 wordt verwezen naar requestAnimationFrame, wat (voor zover ik kan zien) de kern van de methode is. Dus inderdaad, lijkt erop dat er niks nieuws is ontdekt.

Edit2:
Zie dat het artikel inmiddels ook is aangepast.

[Reactie gewijzigd door robvanwijk op 6 juni 2014 21:14]

Dat is de grap, dat is het ook niet, de aanval is exact dezelfde als Paul Stone reeds had omschreven in zijn veel uitgebreidere artikel waar hij een hele serie van potentiele en concrete aanvallen omschrijft: http://www.contextis.com/...rowser_Timing_Attacks.pdf Ik heb het artikel op ArsTechnica doorgelezen en ik kan niks, maar dan ook niks vinden wat Aaron Thijs hieraan zou hebben bijgedragen.

(Nu voor de duidelijkheid, ik stel niet dat hij credit probeert te stelen of wat dan ook, zover ik weet kan het goed zijn dat zijn motivatie simpelweg was om een browser exploit onder de aandacht te brengen want bij ArsTechnica word hij ook niet op de manier gepresenteerd als hier op tweakers, maar goed, zonder meer info weet ik het niet)

[Reactie gewijzigd door David Mulder op 6 juni 2014 19:00]

Ik wou even verduidelijken dat ik nooit beweerd heb dat ik de kwetsbaarheid zelf ontdekt heb. Bij mijn IE bug report heb ik het originele onderzoek gerefereerd en bij mijn feedback op het Ars Technica artikel heb ik duidelijk aangegeven dat de credit voor de ontdekking naar Paul Stone moest gaan.

Ook heb ik Paul Stone onmiddellijk gecontacteerd nadat de Dan Goodin van Ars Technica mij gevraagd had om meer informatie over de aanval te geven.

De implementatie van de techniek was deel van een groter onderzoek over HTML5 security in web browsers. Waarbij het belangrijk is dat gerapporteerde bugs ook daadwerkelijk opgelost worden.

Ik heb het rendergedrag van de laatste browser veries uitgebreid geanalyseerd en daarna eigen implementaties van de aanval gemaakt voor de drie browsers die accuraat kunnen aangeven of een URL bezocht is. (Accuraat op de systemen waarop ik het getest heb; ik beweer niet dat het onder alle omstandigheden 100% nauwkeurig is.)

Goed dat je zelf ook nog even reageerde ja, had het eigenlijk al eerder verwacht Het lijkt vaak alsof iedere ICT'er binnen het nederlandse taal gebied tweakers leest, maar soms merk je op dat het toch wel meevalt. En klopt inderdaad ja, zeker een exploit die meer aandacht mocht krijgen, al moet ik eerlijk toegeven dat ik zelf niet weet hoe ik hem zou oplossen. Zelfs als je geen redraw hebt blijft het probleem dat black on white sneller gaat dan een text met 30 box en text shadows en weet ik veel wat.

Hoe dan ook, klinkt als een leuk project/onderzoek

[Reactie gewijzigd door David Mulder op 11 juni 2014 16:03]

History sniffing door middel van timing attacks zou opgelost kunnen worden door het gedrag in beide situaties uniform te maken. Het timing verschil treedt alleen op wanneer de stijl opnieuw berekend wordt.

:visited en :unvisited stijlen kunnen alleen van kleur verschillen, dus black on white vs text shadows is geen probleem meer; dit werd al eerder opgelost.

In 2010 werd er in een Mozilla bug report al voorgesteld om altijd een restyle te doen wanneer een history lookup finishes; dit zou het probleem moeten oplossen (en de bug is “Assigned”). Dezelfde fix zou voor IE moeten werken. IE11 past de stijl van zijn links alleen de eerste keer aan, maar omdat het een asynchronous lookup is zijn ze nog kwetsbaar. Voor Chrome zou er altijd een restyle moeten gebeuren als de href van een link veranderd wordt.

Buiten deze aanval is er trouwens nog minstens één andere history sniffing timing attack (in Firefox) mogelijk, voor zover ik weet. Die heb ik ook niet zelf getest, maar wel even gekeken naar test code die ook tijdsverschillen aangaf.

Fijn dat het onderzoek interessant klinkt.

Wow, feeling stupid, ik dacht me te herinneren dat :visited alles mocht doen behalve de grote van de box veranderen. Geen flauw idee waar ik dat idee vandaan had, mogelijk was dat alleen een proposed solution die het nooit heeft gered. Indien dat niet het geval is heb je helemaal gelijk en is het een non issue om dit op te lossen en moet ik toegeven dat het me verbaasd dat het inderdaad niet veel sneller is verholpen over de gehele linie.

Vroeger mocht :visited inderdaad op meer vlakken verschillen dan alleen kleur. Zie https://developer.mozilla...and_the_:visited_selector

Dit artikel heeft het in 2010 ook al over timing attacks: http://blog.mozilla.org/s...ing-the-css-history-leak/

nee, het is echt de browsergeschiedenis die je uit moet hebben staan en in chrome incognito werkt het niet op z'n minst

Nu ken ik de details van Chrome Incognito niet, maar de Inprivate van IE schermt onderlinge sessies wel degelijk af. Voor de zekerheid nog even getest een link naar Tweakers blijft 'blauw' terwijl ik in een andere sessie deze post type. Enkel dus de links die aangeklikt zijn in diezelfde sessie zijn dan herkenbaar.

Ik kan me bijna niet voorstellen dat Chrome Incognito niet ook zo werkt?

Overigens vind ik de term 'kwetsbaarheid' wel een beetje zwaar in deze context. Men kan op deze wijze namelijk 1 link per keer, en enkel tijdens de actieve sessie meten. En dan nog is het statistisch, en dus niet gegarandeerd. Er zijn namelijk externe factoren die dit protentieel verstoren omdat de Javascript niet gegarandeerd atomic uitgevoerd wordt. Vaak wel geef ik toe, maar hoe complexer de pagina, hoe groter de kans op verstoring.

Verder kan het verschil afhankelijk van de opmaak tussen een bezochte en niet-bezochte, erg klein of zelfs afwezig zijn zodat dat het wegvalt in de statistische ruis. Echter je kunt dan tegenwerpen dat de maker van die 'malafide' website dat uiteraard niet zal doen.

Dus privacy kwestie ja, maar 'kwestbaarheid' nee want dat suggereerd meestal ernstige lekken waarin data gestolen of zo kan worden.

Ik begin zo langzamerhand schijtziek te worden van alle crap die er mogelijk is. Wat we willen is gewoon 100% veilig browsen zonder dat allerlei informatie verzameld wordt. Geen cookies meer, geen scripting, geen lokale opslag meer op computers zoals flash doet. Als ze willen weten wanneer je voor het laatst bent langsgekomen dan bewaren ze dat maar op de server. We moeten af van alle informatie vergaring. Browsers horen standaard 100% dicht te zitten.

Ik weet niet zeker of je serieus bent of dat je aan het trollen bent... maar als je serieus bent: Wees blij dat je uberhaupt veilig kunt browsen, er was een tijd dat je allemaal excecutabels moest draaien voordat je iets kon lezen.

Geen cookies meer

Zet ze maar uit en merk eens op hoeveel sites er niet meer werken... het is niet zonder reden dat ze zo veel worden gebruikt. Wij besloten bij ons op werk ook niet browsers te supporten waar cookies uit stonden.

geen scripting

Je beseft dat je dan niet eens je comment had kunnen schrijven?

geen lokale opslag

Bye bye google! En facebook! En tweakers en iedere moderne site...

Als ze willen weten wanneer je voor het laatst bent langsgekomen dan bewaren ze dat maar op de server.

En hoe weten ze dat jij dat was? Op basis van je ip ofzo (kan mss in ipv6 als routers transparant worden)? of browser fingerprinting?

Stop maar met internetten dan. Of gebruik alleen nog maar TOR. Ben je nog het dichtst bij onreeele eisen.

Zonder cookies, lokale opslag of scripts weet een andere partij nooit wie jij bent. Zin om weer met overschrijvingskaarten geld over te maken die je per post opstuurt? Je weet dat daar ook fraude mee gepleegd wordt toch?

Serieus: je reactie klinkt alsof je niet weet hoe een gemiddelde website werkt. Software bevat bugs en browsers dus ook.

Je eisen zijn niet reeel. Maar wat wel eens mag stoppen is om alles in een browser te stoppen. Vooral Google lijkt te denken dat een browser alles moet kunnen. Doordat een browser 'alles' moet kunnen is het straks geen sandbox meer.

Zeer interessant, maar ik kan me best inbeelden dat er nog zat andere manieren zijn om de browsergeschiedenis te achterhalen, niet? Het is niet dat browsers dit achter slot en grendel bewaren... Ik ben benieuwd wanneer hier een fix voor uitkomt.

De vraag is hoe nieuw dit is. Ik heb een aantal jaar geleden als onderdeel van een workshop die ik gaf bij mijn werkgever een simpele website neergezet (als aanmeldformulier voor de workshop), en daarin een niet-zichtbare div aangebracht met een aantal links naar diverse websites. Vervolgens kon ik met een simpel stukje javascript de kleur van de links uitlezen en op die manier achterhalen of ze bezocht waren of niet. Die resultaten stopte ik vervolgens als onzichtbaar veld in het formulier.

Destijds werkte deze aanpak louter met Firefox, maar deze aanpak met requestAnimationFrame zou wel eens op alle browsers kunnen werken en ook lastig te repareren kunnen zijn.

Voor wie zich afvraagt waar de workshop over ging: security, privacy en (unethical) hacking.

Stel www.noem-eens-een-grote-site.nl zit vol met reclame, dat redelijk wat tijd nodig heeft op zijn (oude) computertje en na een gegeven tijd bezoekt de persoon de pagina weer om er achter te komen dat er allerlei andere reclame op staat.. Maakt dat het verhaal niet wat ingewikkelder omdat deze andere (nieuwe) reclame opnieuw geladen moet worden, wat als resultaat een langere laadtijd heeft?

Dan krijgt tweakers.net zeker voordeel, want dat is een van de snelst ladende sites die ik ken (bedankt devs!)

Blink, niet WebKit.

Edit: ondertussen aangepast in de post zie ik. :-)

Context is belangrijk ja, maar Blink is een fork, en heeft dus niet noodzakelijk hetzelfde gedrag of dezelfde bugs.

[Reactie gewijzigd door R0BK3 op 6 juni 2014 21:28]

Blinkt is gebaseerd op Webkit. Context is belangrijk.

Veel succes! Voor het laden van mijn youporn historie is sowieso al wel een half uur nodig... dan hebben we het nog maar over 1 site.

Niet teveel reacties op mijn post a.u.b., ik ben over 5 minuten terug...

Ja dan maar weer terug naar de rooksignalen.
100 procent waterdicht op het web zal het nooit worden,.
Welkom in het digitale tijdperk, er is altijd wel wat.
Is dat goed of slecht, tsa wat is privé en wat mogen ze weten.
Zit ik heel de dag op datingssites, of marktplaats of online shoppen.
Zolang ze me niet dood gooien met spam od vind ik het prima.
en reclames en zooi, kan je ook weren.
10 keer op de site van opel geweest, liever geen aanbieding voor een cabrio.
so be it, kijk maar wat ik opzoek en hoe vaak.
zolang ze niet aan privé gegevens en loginns kunnen komen vind ik het prima

ze mogen veel van me weten maar als ik een mail stuur met prive file of info dan wil je dat alleen de persoon het krijgt aan wie je hem stuurd denk aan zaken naakt foto van je vriendin of info 06 nummers wachtwoorden je kan je aanstellen maar er kan ook sprake zijn van prive stel ik zet op mijn facebook op niemand denk je dan dat dat niemand zal lezen ik denk het wel