Hi, A related question would be: How non-interactive ssl clients in EAI and web services software handle these cases and MIM attacks of this sort? Examples are: WebMethods, MS BTS, etc. ssl clients (there is no user intervention involved). TIA, ----- Original Message ----- From: <security@e-matters.de> To: <bugtraqat_private> Sent: Saturday, December 22, 2001 6:37 AM Subject: IE https certificate attack > e-matters GmbH > www.e-matters.de > > -= Security Advisory =- > > > > Advisory: Interner Explorer HTTPS certificate attack > Release Date: 2001/12/22 > Author: Stefan Esser [s.esser@e-matters.de] > > Application: Microsoft Internet Explorer 5.0/5.5/6.0 > Severity: Vulnerability in IE's SSL Certificate handling allows > undetected SSL Man-In-The-Middle attacks > Risk: Very High > Vendor Status: Notified > Reference: http://security.e-matters.de/advisories/012001.html > > > > Overview: > > A flaw in Microsoft Internet Explorer allows an attacker to perform > a SSL Man-In-The-Middle attack without the majority of users recognising > it. In fact the only way to detect the attack is to manually compare the > server name with the name stored in the certificate. > > For a basic introduction into SSL MIM attacks I recommend reading: > > Phrack #57 - Hang on, Snoopy (by stealth) > http://www.phrack.org/show.php?p=57&a=13 > > > Details: > > There is a flaw in the way IE checks HTTPS objects that are embedded into > normal HTTP pages. According to my tests IE does only check if the certi- > ficate of the HTTPS server is properly signed by a trusted CA but totally > ignores if the cert was issued onto the correct name or has already ex- > pired. This is in fact not dangerous because the user considers HTTPS > objects embedded in a HTTP page not secure. The problem is that IE flags > the certificate as trusted and caches this certification trust until your > browser session ends. That means once you visited a normal http page that > included an image from the MIMed SSL Server, IE will not warn you about > an illegal site certificate as long the certificate was signed by f.e. > Verisign. > > A possible scenario would be: > > Hacker runs a MIM attacking tool for HTTP/HTTPS in the subnet of your > site. The HTTP part of the tool auto appends > > <img src="https://www.yoursite.com/nonexistent.gif" width=1 height=1> > > to any html page that is returned to your customer's browser and the > HTTPS part presents his browser a valid but stolen certificate for > www.shop.com. IE will only check if the cert was signed by a trusted CA > when trying to display the image and won't compare the name inside the > cert or check the expiration date. If your customer now tries to login > to your site via HTTPS IE will consider the cert trustworthy without > checking it again. Your customer will only be able to determine that he > was just tricked by manually checking the servername in the cert. But > you can be sure that only paranoid people would check. The majority of > people don't even know how they can do so. Imagine the hacker stole the > cert from "yoursite.de"... How many users of "yoursite.com" would not > trust a cert that was issued on "yoursite.de". The average user does > not know anything about SSL than it's making his payment "secure". > > > Proof of Concept: > > A proof of concept webpage was put up at http://suspekt.org. Clicking > onto the "To the secure page..." link will send your browser to > https://suspekt.org without IE warning you that the certificate was not > issued onto that server. > > This is not a MIM but it has the same effect: IE will tell you a page is > secure although the certificate is illegal and its possible for a third > party (anyone who owns the given certificate) to decrypt your traffic in > realtime. > > > Vendor Response: > > 26 November 2001 - Microsoft was informed about this vulnerability > 27 November 2001 - Proof of concept page got visited by lots of MS IPs > 01 December 2001 - Microsoft informed us with a standard reply that > they have received the advisory > 12 December 2001 - Microsoft was informed that were going to release > the advisory within the next 3 days > 13 December 2001 - Microsoft asked us to wait because the issue is > complex due to the fact a lot of cryptography > is involved > 21 December 2001 - Microsoft sent an update: no patches yet, > still a complex issue > > > Conclusion: > > Until today Microsoft did not release a patch, they had nearly a month > time to fix the bug. Instead they call it a very complex issue. Because > I don't know the source code of the Internet Explorer I cannot check the > validity of these claims, but from my point of view fixing this missing > check is just a matter of copy and pasting a few lines. Unfortunately it > is christmas time and especially during the last month millions of cus- > tomers where buying christmas presents on the internet all around the > world. That means millions of customers were shopping with insuffient > protection of their private data. Because there are no patches out yet, > I strongly recommend that you use Mozilla, Opera or another non MS brow- > ser to do your internet banking or shopping these days. If you think > (for whatever strange reason) that you need the Internet Explorer, > ensure that the certificate is the correct by comparing the servername > in the certificate with the one in your browser... > > > GPG-Key: > > http://security.e-matters.de/gpg_key.asc > > pub 1024D/D19C5835 2001-11-26 e-matters GmbH - Securityteam > Key fingerprint = DD27 8C4B CEDE 41A9 5766 39BA AF65 B19C D19C 5835 > > > Copyright 2001 Stefan Esser. All rights reserved. > > > >
This archive was generated by hypermail 2b30 : Sun Dec 23 2001 - 20:53:24 PST
