Weer een security hole in Internet Explorer

[e-mail]" rel="external">Da_Taxman meldt: dat er weer een gat is gevonden in Internet Explorer, door een klein beetje gegoochel met URL's is het mogelijk toegang te krijgen tot alle koekjes van iemand die toevallig langs een verkeerde website surft :

Security enthusiasts Bennett Haselton and Jamie McCarthy demonstrated how a simple substitution in Web addresses (URLs) can foil IE's security checks, exposing the cookie files that Web sites place on visitors' computers. Cookies authenticate people's identities when they return to Web sites and store data about visitors' activities and purchases.

Microsoft noted that the hole doesn't let an attacker "inventory" the visitor's cookies, but only targets specific ones from certain sites. The company also said that a victim would have to visit a malicious Web site.

Still, Microsoft acknowledged that the hole leaves room for plenty of trouble.

"The vulnerability could allow a malicious Web site to read, change or delete cookies that belong to another Web site," Microsoft said in a statement. "We expect to deliver the patch shortly. A security bulletin will be published...to discuss the issue and advise customers how to obtain and apply the patch."

The hole lends credence to the fears of privacy advocates, who say the technology and business of collecting Web surfers' private information--such as when and where they surf and which books and other items they purchase--is prone to abuse and mishap.

Reacties (36)

Dan heb ik ook een security hole gevonden in de Albert Heijn hier om de hoek, door een beetje te zoeken kan je ook daar toegang krijgen tot alle koekjes die ze hebben....

DvE, cookies worden regelmatig gebruikt voor het onthouden van wachtwoorden. (ook op tweakers.net)
En als anderen die zomaar kunnen lezen is dat erg ja.

Ik gebruik rabo internetbankieren waar ook wel degelijk cookies worden gebruikt. Ik heb geprobeerd te bekijken wat er allemaal in staat maar daar is geen wijs uit te worden en dat zegt mij dat het wel belangrijk is!
Is het niet zo dat wanneer je een personal firewall gebruikt (waarbij je vertelt welke sites iets met cookies mogen doen) dat deze op tilt slaat wanneer er gebruik wordt gemaakt van deze security hole?

Onno, het is toch niet te hopen dat er usernames/passwords in cookies gezet worden maar eerder een session ID client-side.

Een Session ID zou inderdaad beter zijn, maar toch wordt vaak het wachtwoord opgeslagen.

Zo ook hier:

</div><div class=b4>www.tweakers.net TRUE / FALSE 960360536 p ********
www.tweakers.net TRUE / FALSE 960360536 u Onno</div><div class=b1>

Onno: wellicht ten overvloede: Netscape had recent ook een koektrommel security flaw. (is gepatcht in 4.73, alle vorige versies zijn vulnerable) (of de Invalid SSL Certifcate Bypass vulnerability (gepatcht in 4.73)). Niet om te zeuren, maar netscape heeft net zo goed leaks. Overstappen naar netscape is lood om oud ijzer. (wel is het zaak natuurlijk om de laatste versie te downen, ivm de leaks in oudere versies)

Dit soort leaks komt voort uit het toevoegen van functies en daarbij gefocussed blijven op die ene functie. Op zich doen die functies het heel aardig, alleen door ze met anderen te combineren ontstaan ineens mogelijkheden voor kwaadwillenden. Het wordt in de toekomst alleen maar erger, wanneer we steeds meer verschillende apparaten met elkaar laten praten over publieke netwerken. Doordat er voor al die apparaten software beschikbaar komt, zijn de mogelijkheden voor combinaties steeds groter en de kans op lekken steeds groter, of bv het plaatsen van malicious code in een netwerk.

Als ik kijk naar de waslijst koektrommel bugs van de afgelopen jaren in beide browsers vind ik het echt raar waarom sites niet zijn overgegaan naar client certificates. Die kun je zelf genereren, je geeft ze uit aan iedereen die zich registreert, die persoon installeert het certificate en klaar ben je. Je hebt meteen SSL, men hoeft niet meer in te loggen en het is safe.

mja... luiheid?

Mja %2f niet herkennen als slash. Dat is wel heel triest. Zoals ik al zei: de code werkte gewoon, alleen iemand doet er iets anders mee en hop! het kan ook de andere kant op werken.

Wat deze lame bug aantoont:
1) Sites die username/passwords ONGECRYPT opslaan in cookies zijn dom bezig. Waarom crypt je die dingen niet alvorens ze in een cookie te zetten? iedereen kan die cookie files lezen indien hij toegang heeft tot de computer... Niet zo slim. (Beter is inderdaad een ID op te slaan, bv de key van het userrecord, en dan gecrypt)
2) Waarom zijn cookies nog zo rampzalig opgeslagen en is het mechanisme zo triest? waarom is het niet 1 grote file, gecrypt zodat mensen achter een PC er niet bij kunnen en is het algorithme zo slap om de cookies op te halen? waarom kan een webserver niet een unique crypting key meegeven die alleen de webserver weet, zodat mocht iemand anders de cookies rippen (zoals nu gebeurt) die er NIETS aan heeft, want hij heeft de decrypting key niet.

Als je er 20 seconden over nadenkt kom je al op slimmere ideeen dan hoe het nu gaat. Mja... ik vrees echter wel dat 'vernieuwing' in het cookie system alleen werkt als iedereen meewerkt. Nu is het huidige system door ene M. A. bedacht... hmm... naja, wellicht doet zn ex-toko mee.

Het "algoritme" om cookies op te hale?
SetCookie BLAAT=666
Mjah.. HTTP protocol noeme ze dat toch ? =)

</div><div class=b4> . (Beter is inderdaad een ID op te slaan, bv de key van het userrecord, en dan gecrypt)
</div><div class=b1>

Jah is inderdaad wel een idee, maar er is
dan altijd een 1 woord dat alles gaat kunne
decrypten.. njah decrypten is niet het goede
woord.. PHP's crypt() is een one-way DES encryptie.. Tblijft beetje dweile met een kraantje aan vind ik =)

PS.

$string = "CaPSiej doet een \"s%2f %2f%2f\" met sed dingetje";

if (preg_match("/(%\df)+/", $string, $match))
print rawurldecode($string);

als een browser gewoon degelijk in elkaar zet ... en met de gegevens in een cookie alleen communiceert met een server als ze ook door die server in het cookie gezet zijn is er toch weinig aan de hand ?

(maar ja ik geloof dat het in m'n eerste veronderstelling van "degelijke browser" al mis gaat ;-) )

hmm, zo te zien heeft tweakers.net dus een erg vrij brakke cookie authorisatie. Session ID's bijhouden, session ID one-way encrypten en in een cookie zetten + userID erbij en klaar. Nog steeds helemaal niet fool-proof maar iemand moet dan en de userID goed gokken en de session ID - wat dus niet zo makkelijk gaat aangezien de session ID ge-encrypt als een random string eruitziet. Komt dus neer op hetzelfde als password en userID gokken, ware het niet dat de sessionID meestal iets van 32 chars lang is. Heb hier nog wel een php lib en een mod_perl mod liggen die dat doen, interesse-> mail.

Otis: meestal gaat het om logins voor fora e.d. en dan zijn certificates meestal overkill. Voor bijv. Rabo Telebankieren zou ik uberhaupt geen cookies gebruiken maar indeed zo'n constructie.

Cookies ge-encrypt op je HD neer te zetten is denk ik niet de juiste weg om te gaan, de developer die cookies gebruikt moet maar ietwat beter nadenken wat hij in die cookies stopt. Zelfde als met de I Love You worm, je kan wel de bouwers van het geheel blijven blamen maar users beter opvoeden werkt nog altijd beter.

* DF040F eGosh