what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

ie.cert.attack.txt

ie.cert.attack.txt
Posted Dec 26, 2001
Authored by Stefan Esser | Site e-matters.de

A flaw in Microsoft Internet Explorer allows an attacker to perform a SSL Man-In-The-Middle attack without the majority of users recognizing it. In fact the only way to detect the attack is to manually compare the server name with the name stored in the certificate due to a flaw in the way IE checks HTTPS objects that are embedded into normal HTTP pages.

tags | exploit, web
SHA-256 | be656d7d8e024e7317da02518924572f3527b139ee72d711816b35515804709c

ie.cert.attack.txt

Change Mirror Download

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.


--- Packet Storm ---


UPDATE: IE https certificate attack

Date: 2001/12/25

This morning i was googling through the web and found out that
the issue is not that new for Microsoft.
If you compare
http://www.acros.si/aspr/ASPR-1999-12-15-1-PUB.txt
with my advisory at
http://security.e-matters.de/advisories/012001.html
you can see that the same bug was reported 2(!) years ago to
microsoft. At that time (or better half a year later) Microsoft
released the patches for that vulnerability that fixed the
bug within IE 4.0 and the early versions of IE 5.0.
The Microsoft Security Bulletin (MS00-039) clearly states that
IE 5.01 SP1 and IE 5.5 are not vulnerable.
That means, that one of the "security patches" that Microsoft
released since that date reimplemented the bug and made all
IEs vulnerable again.

Stefan Esser


Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close