Timingattacker på webben

Första passet var kring aktuell forskning på Stanford (Dan Boneh) och UCSB (Giovanni Vigna).

Det var faktiskt ett tag sen jag hängde i såna här akademiska kretsar men det är härligt. Som när vi slog oss ner på lunchen. Giovanni har precis haft sin presentation och en kille från Brown University inleder lunchsamtalet med "One thing I was annoyed with in your presentation was ..." Sen var det igång. Ärliga och rättframma diskussioner.

Det matnyttga från första presentationen ...


Timing Attacks
Timing-attacker på nätet handlar om informationsläckage trots same domain policy, dvs attackeraren kan via sin webbsida få ut information från offrets andra aktiva webbsidor och webbkonton trots att det inte ska vara möjligt. Hur? Jo, attackeraren lurar offret att göra anrop till intressanta sidor och mäter sen tiden det tar att få svar. Tiden skiljer sig åt beroende på offrets state på den intressanta sidan.

Antag att attackeraren vill veta om offret är autentiserat till Google Apps. Attackeraren kör en CSRF-attack och lurar offret att ladda ett referensobjekt (logga/bild) från Google på ett felaktigt sätt och mäter tiden till error-sidan har laddats. Sen görs ett anrop till Google som kräver att offret är autentiserat. Om det tar längre tid så vet attackeraren att offret är inloggat på Google. Annars kommer en felsida vars requesttid nu är känd av attackeraren.

På det viset kan man t ex avgöra storleken på offrets kundvagn på någon e-handelssajt. Man kan också genomföra en distribuerad ordboksattack online. Man lurar offret att försöka logga in på en skyddad webbapp. Tiden för misslyckad/lyckad inloggning skiljer. Nästan alla sidor läcker på det här sättet.

Vanligtvis görs timingattacker med JavaScript men det går ockaå att göra mha CSS (ladda länk från egen sajt, ladda länk från offersajt, ladda länk från egen sajt, mät tid mellan request).

Skydd mot timingattacker
Hur skyddar man sig? Konstant tid för alla request suger eftersom det ger kass användbarhet. Att lägga till slump funkar inte eftersom timingattacken körs om och om igen och då kommer fördelningen avslöja sig ändå.

Ett lösningsförslag från publiken var att alla request returnerar en liten html-sida som sen laddar resten med CSRF-skydd (tokens) så att nästa request misslyckas i timing-attacken eftersom det saknar token.

Men i dagsläget står vi utan skydd.