CERT ontdekt nieuw veiligheidslek Internet Explorer

Denk je, "ik betaal veilig, ik betaal via een SSL verbinding", dan heb je het toch mooi mis als je Internet Explorer 4, 4.01, 5 of 5.01 gebruikt. Deze versies van IE gaan niet helemaal netjes om, met de controle van SSL-certificaten, ze laten wat steekjes vallen wat ervoor kan zorgen dat de informatie die je verstuurt in verkeerde handen kan terecht komen :

Wie een creditcardbetaling op het net verricht of persoonlijke gegevens invult, heeft vaak te maken met SSL. De gegevens worden dan versleuteld over internet verzonden, onderin de browser is dan een sleuteltje te zien. De browser van Microsoft gaat hier echter slordig mee om, zo ontdekte het Computer Emergency Response Team (CERT) van de Carnegie Mellon Universiteit.

Het gaat om IE 4.0, 4.01, 5 en 5.01. Microsoft komt met patches voor deze versies. Volgens de softwarefabrikant komt het lek in slechts zeer bijzondere gevallen aan het licht. Kwaadwillenden moeten namelijk via een aanpassing in de DNS-entry een domeinnaam naar een eigen server zien te leiden.

Internet Explorer controleert weliswaar of een SSL-certificaat is afgegeven door een te vertrouwen partij, maar checkt de verloopdatum van dit certificaat en de naam van de server niet. Bovendien wordt het certificaat niet opnieuw gecontroleerd als er een nieuwe SSL-sessie wordt gestart. De beveiliging van IE is voltrekt onvoldoende, zegt CERT: "Er zijn veel manieren om misleidende DNS-informatie te verstrekken. Het is dus fundamenteel onveilig te vertrouwen op DNS-informatie."

Voor het hele verhaal moet je hier zijn op WebWereld.

Reacties (17)

[Verwijderd]

</div><div class=b4>Kwaadwillenden moeten namelijk via een aanpassing in de DNS-entry een domeinnaam naar een eigen server zien te leiden.</div><div class=b1>

Ditzelfde geintje hebben ze toen ook met de Rabobank-site uitgehaald, nu werken ze dan met certificaten en dan krijg je dit weer.

Dit lijkt mij een zeer ernstig probleem want bij certificaten draait alles om 'trust' die je krijgt van meerdere partijen. Met dit soort fouten kan er heel wat wantrouwen ontstaan jegens het gebruik van certificaten.

Ik ben benieuwd of de CRL wel door IE geraadpleegd wordt.

* 786562 bitprobe
CRL = Lijstje met Certificates die geRevoked zijn.

[Verwijderd]

Dit is dus de manier om MS in het algemeen te foppen

Men neme 1 linux doos werpt die op als DNS server

schop (meestal 2) dns servers in je netwerk onderuit met spray..... ms doet namelijk een broadcast naar een dns niet naar ip nummer (dat is D-dns)
hebbie ook nog eens nis draaiendan zit je bijna altijd binnen...


Daarom is jackal gek op windows machines
hoe ouder hoe beter

[Cmdr.Keen]

Je kan onder Windows heel makkelijk www.tweakers.net naar een ander IP sturen door het hosts bestand in de windows directory aan te passen.

Dit zou iemand natuurlijk kunnen doen met een trojan, maar dan lijkt het mij handiger om gelijk een keylogger in te bouwen, dat zou een stuk makkelijker zijn dan die bug uit te buiten..

[Verwijderd]

Nou ze zijn weer snel hoor bij webwereld. Het Microsoft Security Bulletin over deze bug kreeg ik eergisteren al.
De patch is er ook al lang en wel hier:
www.microsoft.com/windows/ie/download/critical/patch7.htm

En de volledige omschrijving van het probleem:
Issue
Two vulnerabilities have been identified in the way IE handles digital certificates:
When a connection to a secure server is made via either an image or a frame, IE only verifies that the server’s SSL certificate was issued by a trusted root – it does not verify the server name or the expiration date. When a connection is made via any other means, all expected validation is performed.
Even if the initial validation is made correctly, IE does not re-validate the certificate if a new SSL session is established with the same server during the same IE session.
The circumstances under which these vulnerabilities could be exploited are fairly restricted. In both cases, it is likely that the attacker would need to either carry out DNS cache poisoning or physically replace the server in order to successfully carry out an attack via this vulnerability. The timing would be especially crucial in the second case, as the malicious user would need to poison the cache or replace the machine during the interregnum between the two SSL sessions

Wim
--

www.win2kwereld.nl

[Ortep]

Servaas, zo krijg je je kaartjes altijd opgestuurd. Ik had laatst ook voor iets van 1200 gulden aan kaartjes besteld. Gewoon via de telefoon. Ik kreeg een accept en betaalde. Een week later lagen ze gewoon in de bus. Als jij ze gevonden had, had je ze kunnen gebruiken.

Paniek over de credit cards is ook overdreven. Als jij mijn nummer zou hebben dan kan je spullen gaan bestellen....maar waar wilde je ze laten afleveren? Zodra er een adres bekend is staat de politie op de stoep. Bovendien weet iedere kelner in een restaurant waar je er mee betaald het nummer. Dat risico is VEEL groter dan de kans dat iemand mijn nummer van het net vist tussen al die miljarden andere IP pakketjes.

De credit card maatschappij stuurt trouwens je kaart ook niet aangetekend op. Laatst had ik hem zelfs bijna weggegooid omdat ik dacht dat het een reclame folder was. Op het laatste moment zag ik dat het de nieuwe kaart was.

Kortom: SSL is veiliger dan het echte leven.

[servies]

Het kan wel zijn dat altijd zo is, maar ik betaal graag die 10 gulden extra als dat betekent dat ik m'n kaartjes aangetekend krijg opgestuurd. Dan kun je tenminste nog aantonen dat je ze niet gekregen hebt.
Wat verder dat gebruik van dat credit-card nummer en opsturen van goederen betreft: doodsimpel: een postbusnummer aanvragen. Met de legitimatie is er dan
meestal wel een mouw aan te passen... Je wilt niet weten hoeveel vertrouwen mensen meestal hebben in niet-officiele legitimatiebewijzen...
Het verschil met die ene frauderende kelner en die mensen die creditcard-nummers van het internet afplukken is dat de 2e categorie vaak een heel stuk moeilijker te achterhalen zijn omdat ze vaak internationaal werken en dus moeilijker aan te pakken zijn. En bedenk: die mensen zitten gericht te vissen...
Dus ga het ze niet gemakkelijk maken door geen SSL te gebruiken bij creditcard betalingen. Zo'n moeite is dat toch niet?
Ik zeg ook niet dat SSL onveilig is, ik zeg alleen dat het niet bij alleen SSL moet blijven, het natraject kan ook onveilig zijn opgezet etc.
M'n creditcard heb ik destijds bij de bank (met legitimatie) moeten ophalen.
Maar we beginnen een beetje van onderwerp af te raken...

[xavalon]

Het maakt weinig uit of je creditkaart nummer met SSL of zonder SSL verstuurd. De kans dat een hacker je creditkaartnummer onderschept tijdens het transport tussen jouw computer en de server van de winkelier is erg gering. Wat een veel groter risico met zich meebrengt is het feit dat na aankomst - met of zonder SSL - je creditcardnummer wordt opgeslagen in de database van de winkelier. Letterlijk honderden - zo niet vele duizenden winkeliers zijn vergeten hier een adequate beveiliging op toe te passen. Ofwel een hacker kraakt de database en voila duizenden creditkaartnummers en verval datums liggen open en bloot. Als je je nu afvraagt hoe dit komt.. denk maar dat de gemiddelde HTML-boer c.q. reclamebureau die een dergelijke winkel ontwikkeld geen benul heeft van beveiliging.

Onlangs is weer eens aangetoond dat tientallen sites in nederland onveilig zijn ingericht en dat de wachtwoorden van databases open en blood liggen. Oke, het waren allemaal websites op basis van de Microsoft Internet Information Server. Maar voordat je nu denkt dat er weer eens een beveiligingslek is gevonden in een Microsoft product think twice this time. Wat gebeurd is dat bij installatie van de webserver je de optie hebt om voorbeeld scripts (sample pages) te installeren. En 1 van die scripts is gevaarlijk in die zin dat het een voorbeeld is om elke willekeurig bestand op de webserver te openen. Nu open je natuurlijk het bestand waarin de wachtwoorden staan om de webserver met de database te laten communiceren (global.asa). Wat de systeembeheerder echter is vergeten, is deze voorbeeld scripts te verwijderen voordat hij in productie gaat. Maar ja, zoals ik al zei, geen enkel benul van beveiliging.. als de website er maar mooi uit ziet is toch veel belangrijker.

Daarbij zou een database waarin creditkaartnummers staan gewoon standaard encrypt moeten zijn - een modern database systeem (de software) biedt een dergelijke mogelijkheid - maar wederom te ingewikkeld voor de gemiddelde systeembeheerder/HTML-boer.

[Verwijderd]

</div><div class=b4>Kwaadwillenden moeten namelijk via een aanpassing in de DNS-entry een domeinnaam naar een eigen server zien te leiden.

Internet Explorer controleert weliswaar of een SSL-certificaat is afgegeven door een te vertrouwen partij, maar checkt de verloopdatum van dit certificaat en de naam van de server niet. Bovendien wordt het certificaat niet opnieuw gecontroleerd als er een nieuwe SSL-sessie wordt gestart</div><div class=b1>

Werkelijk, hoe bedenk je het, knap van die gasten bij CERT dat je dat soort dingen eruit haalt.

Ik zou er niet opkomen om ff met mijn DNS info te gaan knutselen.

Maar ja, aan de andere kant, hoe reeël is dat "gevaar" nu werkelijk, het komt slecht in zeldzame gevallen voor. Is toch lastig om een mening te vormen als eindgebruiker: is dit nu een typisch voorbeeld van een storm in een glas water, of moeten we ons zorgen maken?

Soms ben ik bang dat dit door de media weer eens opgeblazen wordt, omdat de naam MS erin voorkomt (let maar op alle reacties op Tweakers die nog gaan volgen...).

Petje af voor CERT!!!

* 786562 TgF

[irrelevant]

* 786562 irrelevant
Ik heb voor mijn stage bij een modemfabrikant gewerkt aan hardwarematige 512 bits versleuteling. Als ze dat nou eens een wereldwijde standaard zouden maken zouden we van heel veel problemen af zijn. Dan kun je onderscheppen wat je wilt, je kunt het toch niet lezen. Je zou dan een heel DPC project op moeten zetten voor een enkel berichtje.

Het soort bugs dat in dit artikeltje genoemd wordt zal volgens mij nl. altijd blijven bestaan.

[servies]

En dan nog... vorige week bij ticketservice 3 kaarten voor Roskilde besteld met een creditcard... Omdat ik er vanuit ga dat bedrijven die dit soort diensten aanbieden wel gebruik maken van SSL heb ik 'ns niet gekeken of het een beveiligde verbinding was... Enfin, ik had de betaling verricht (meer dan 800 piek in totaal) en valt mij ineens op dat dat hangslotje (ik gebruikte Netscape) niet geel en dicht was... En dan nog... Hoe krijg ik m'n kaarten opgestuurd: Niet eens aangetekend... gewoon in een standaard envelopje met een postzegel van 80 cent. Wat nu als de postbode het per ongeluk in de verkeerde brievenbus had gedaan... Hoe had ik ooit moeten bewijzen dat het nooit was aangekomen? M'n geld wordt er wel afgehaald maar kaarten in dat geval: ho maar...
Er is in dit geval niets fout gegaan maar toch...
Les die ik eruit heb geleerd, altijd even kijken naar die icoontjes die de status van de verbinding aangeven. En de veiligheid van het kopen via internet houdt niet op bij de internet-verbinding...