Return-Path: owner-ntbugtraq@LISTSERV.NTBUGTRAQ.COM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Message-ID: <000301bfcf4f$53e38950$6400000a@gee> Date: Tue, 6 Jun 2000 02:37:00 +0200 Reply-To: Mitja Kolsek Sender: Windows NTBugtraq Mailing List From: Mitja Kolsek Subject: ALERT: Bypassing Warnings For Invalid SSL Certificates In Internet Explorer Comments: To: BUGTRAQ@SECURITYFOCUS.COM, win2ksecadvice@LISTSERV.NTSECURITY.NET, cert@cert.org, si-cert@arnes.si To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM =====[BEGIN-ACROS-REPORT]===== ========================================================================= ACROS Security Problem Report #1999-12-15-1-PUB ------------------------------------------------------------------------- Bypassing Warnings For Invalid SSL Certificates In Internet Explorer ========================================================================= FULL REPORT PUBLIC ====== Affected System(s): Microsoft Internet Explorer Problem: Bypassing Warnings For Invalid SSL Certificates Severity: High Solution: Installing the patch Discovered: December 14, 1999 Vendor notified: December 16, 1999 Last update: June 5, 2000 Published: June 6, 2000 SUMMARY ======= Our team has discovered two flaws in Internet Explorer that allow bypassing of warning about an invalid SSL certificate. SSL protection is used in most major Internet-based financial services (e-banking, e-commerce). The flaws we have found effectively disable one of the two basic SSL functionalities: to assure users that they are really communicating with the intended web server - and not with a fake one. INTRODUCTION (skip this section if you already understand how SSL works) ============ When a web browser tries to connect to a SSL-protected server, a so-called SSL session is established. At the beginning of this session the server presents his SSL certificate containing his public key. At this point, browser checks the certificate for the following conditions (*): 1) Certificate must be issued by a certificate authority trusted by browser (some are default: Verisign, Thawte etc.) 2) Certificate must not be expired (its expiry date:time must be later than the current system date:time on the computer browser is running on) 3) Certificate must be for the server that browser is connecting to (if browser is connecting to www.e-bank.com, the certificate must be for www.e-bank.com) All three conditions must be met for browser to accept the certificate. For every condition not met, browser displays a warning to the user and then user can decide whether connection should be established or not. These three conditions combined provide user with assurance that his browser is really connecting to the correct server and not to some fake server placed on the Internet by malicious individual(s) trying to trick users to give them credit card information, passwords and other secret information. For example, let's take a look at a sample web e-banking system that doesn't use SSL certificates and requires one-time password tokens for user authentication. User connects to http://www.e-bank.com. Browser asks DNS server for IP address of www.e-bank.com and gets 100.100.100.100. Browser then connects to 100.100.100.100 and user is presented with login form asking for his username and one-time password. He enters this data and starts using e-banking services. A simple attack (called web-spoofing) on this system is to attack the DNS server and "poison" its entry for www.e-bank.com with attacker's IP address 99.99.99.99. Attacker sets up a web server at 99.99.99.99 that web-wise looks exactly like the original www.e-bank.com server. User trying to connect to www.e-bank.com will now instead connect to the attacker's server and provide it with his one-time password. Attacker's server will use this password to connect to the real server at 100.100.100.100 and transfer all of the user's money to his secret swiss bank account. This attack is successfully disabled by using SSL certificates. In that case, when browser falsely connects to www.e-bank.com at 99.99.99.99 rather than at 100.100.100.100, attacker's server must provide a valid certificate for www.e-bank.com, which it can't unless the attacker has stolen the secret key and the certificate from the real server. Let's look at three possibilities: 1) Attacker could issue a certificate for www.e-bank.com himself (on his own CA). That wouldn't work since his CA is not trusted by user's browser. 2) Attacker could use a stolen expired key and certificate (those are often not protected as strongly as valid ones since one could think they can't be used any more). That wouldn't work since browser will notice that certificate is expired. 3) Attacker could use a valid key and certificate for some other site (e.g. www.something.org). That wouldn't work since browser will accept only valid certificates for www.e-bank.com. It would seem that this problem of web-spoofing is successfully solved with SSL certificates. PROBLEM ======= There are two flaws in implementation of SSL certificate checks in Internet Explorer: Flaw #1 ------- Internet Explorer only checks the certificate conditions (*) at the *FIRST* SSL connection it establishes with a certain server (first in the "life" of the particular instance of IE - until it's closed). If the conditions are met, every subsequent SSL connection with the same server is established WITHOUT REGARD TO CERTIFICATE CONDITIONS. Obviously IE assumes that if certificate was OK the first time, it will be OK later, too. This assumption is critically flawed as will be demonstrated in Example #1. Flaw #2 ------- Even at the first SSL connection to a certain server Internet Explorer doesn't check all three certificate conditions (*) in case the first SSL connection is made through an image ( tag) or a frame ( tag). In this case, IE only checks for certificate issuer, while it DOESN'T CHECK FOR EXPIRATION OR SERVER NAME. The potential security consequences of this will be shown in Example #2. EXAMPLES ======== Both examples will demonstrate how a user connecting to https://www.e-bank.com can be tricked to actually connect to attacker's server without the browser ever issuing a warning about invalid certificate. The IP address of www.e-bank.com is 100.100.100.100. In both examples, attacker sets up his fake web server. This web server looks to its visitors exactly like server www.e-bank.com - same text, same design, same functionality - it only has different IP and different SSL certificate. And, of course, a different owner with very unpleasant plans. Example #1 ---------- Attacker has ability to monitor network traffic and change IP routing somewhere between user's browser and server www.e-bank.com. He installs ANY key+certificate on his server and gives the server IP address 100.100.100.100 (the certificate can even be issued by his own CA, it can be expired and it can be for any server name, although in case of self-issuance it can well be for www.e-bank.com). By monitoring network traffic attacker can determine when user is trying to connect to https://www.e-bank.com. After first SSL handshake with the real server at 100.100.100.100 he knows that user's Internet Explorer has checked the server's certificate and that it won't do it again until IE is closed. Attacker then changes IP routing between user and server www.e-bank.com so that all IP packets to 100.100.100.100 are routed to his server rather than to the original one. This way, without user ever noticing it, all subsequent communication with www.e-bank.com will actually be established with the attacker's server. A variant of this attack could be that instead of changing IP routing, attacker disables (DoS) the real server www.e-bank.com and then sets up his own with the same IP address 100.100.100.100 somewhere where current IP routing will make it accessible. The reader can try this lab example: set up two web servers (A and B) and install on server A a valid certificate for www.test.com (or whatever you might have access to) issued by a trusted CA, say Verisign. Install on server B an expired certificate for www.blah.com (or whatever), also issued by a trusted CA. Give both servers the same IP address but connect only server A to your network. Make sure www.test.com resolves to this IP within your network. Now, open Internet Explorer on any other machine and connect to https://www.test.com. As expected, see the default web page from server A appear. Then unplug server A from the network and connect server B to the network. Refresh the page in Internet Explorer and see the server B's default page appear. You (the attacker) have just successfully switched the real server with a fake one and the user didn't get any warnings! Example #2 ---------- Attacker has ability to change DNS records on user's DNS server. He could have legitimate administrative privileges there or he could do it using any one of numerous known DNS attacks. Attacker sets up a fake e-bank server at IP address 99.99.99.99 and installs on it any key+certificate from a trusted CA (it can be for any server name and can also be expired). He also sets up a web page on some free web service, for example http://www.geocities.com/attacker/trap.html containing this HTML code: (note that whatever.gif doesn't need to exist on www.e-bank.com) He then changes DNS record for www.e-bank.com from 100.100.100.100 to 99.99.99.99 and using social engineering or one of numerous technical methods makes the user open the above web-page in his Internet Explorer. When that happens, IE tries to get the image whatever.gif from www.e-bank.com over SSL secured connection. www.e-bank.com resolves to 99.99.99.99 which is the attacker's server. When SSL session is established, IE only checks the certificate issuer and if it is one of the trusted ones, session is established without checking for expiration date or server name. After that, IE won't check the certificate on any subsequent connections to https://www.e-bank.com - until it is closed. After this "prelude", user can try to connect to https://www.e-bank.com but will actually connect to the attacker's server - with no way of knowing it - except for two things: - inspecting the certificate (double click on the lock icon) will reveal invalid data; - monitoring network traffic will show that the server is not at 100.100.100.100 where it should be but rather at 99.99.99.99. It is a very rare practice to check any of these when nothing suspect is happening. SOLUTION ======== Microsoft has provided a patch that disables this vulnerability. It is freely downloadable from: http://www.microsoft.com/windows/ie/download/critical/patch7.htm [Patch for IE 4.x not yet available at the time of this writing] Installation of this patch, as far as we have tested it, corrects the identified flaw. Microsoft has also issued a Security Bulletin and FAQ about this issue, available at: http://www.microsoft.com/technet/security/bulletin/ms00-039.asp http://www.microsoft.com/technet/security/bulletin/fq00-039.asp [FAQ not yet available at the time of this writing] WORKAROUND ========== Internet Explorer users who can't or don't want to install the patch can use a "manual" method to make sure they are not under attack: When visiting an SSL-protected site, double click on the lock icon (in status line) and see whether the certificate used for the connection is really issued for the correct hostname. E.g. If you visit https://www.verisign.com, make sure the certificate used is issued for www.verisign.com and not for some other hostname. ADVISORY ======== It is important to emphasize that the flaw presented completely compromises SSL's ability to provide strong server authentication and therefore poses a serious threat to Explorer users relying on its SSL protection. Users of web services --------------------- Internet Explorer users who are also users of any critical web services employing Secure Sockets Layer (SSL) protection to provide secrecy and integrity of browser-server communication are strongly advised to install official Microsoft's patch and thus disable this vulnerability. Main examples of such critical web services are: - web banking systems (especially the ones using passwords for authentication - even one-time passwords), - web stores (especially the ones accepting credit card data) and - other web-based e-commerce systems. Providers of web services ------------------------- Providers of critical web services employing Secure Sockets Layer (SSL) protection to provide secrecy and integrity of browser-server communication should advise their users to install official Microsoft's patch and thus disable this vulnerability. Since this vulnerability allows for the type of attack that can completely bypass the real/original web server, there are no technical countermeasures which providers of web services could deploy at their sites. However, to make the attacker's job harder, it is a good idea to make users enter the secure site directly (writing https://www.securesite.com or clicking a browser's bookmark), NOT clicking on a hyperlink in an unsecured (or untrusted) site, commonly http://www.securesite.com for users' convenience. You can accomplish this by removing all links from your unsecured [parts of] sites to the secured ones. Please note that this won't completely neutralize the vulnerability, it will only improve your odds a bit. Web services using client SSL certificates for user authentication ------------------------------------------------------------------ This vulnerability does NOT allow the attacker to steal client's SSL key and thus execute the man-in-the-middle attack on web services using client SSL certificates for user authentication. It still does, however, allow the attacker to place a fake server (an exact copy) and collect other information users provide (including the data in their client SSL certificates). TESTING RESULTS =============== Tests were performed on: IE 4.0 - affected IE 4.01 - affected IE 5.0 - affected IE 5.01 - affected Tests were not performed on older versions, but they are very likely to be affected too. ACKNOWLEDGMENTS =============== We would like to acknowledge Microsoft (specifically Mr. Scott Culp and IE team) for professional response to our notification of the identified vulnerability and their help in understanding the flaw. SUPPORT ======= For further details about this issue please contact: Mr. Mitja Kolsek ACROS, d.o.o. Stantetova 4 SI - 2000 Maribor, Slovenia phone: +386 41 720 908 e-mail: mitja.kolsek@acros.si DISTRIBUTION ============ This report was sent to: - BugTraq mailing list - NTBugTraq mailing list - Win2KSecAdvice mailing list - CERT/CC - SI-CERT - ACROS client mailing list DISCLAIMER ========== The information in this report is purely informational and meant only for the purpose of education and protection. ACROS, d.o.o. shall in no event be liable for any damage whatsoever, direct or implied, arising from use or spread of this information. All identifiers (hostnames, IP addresses, company names, individual names etc.) used in examples and exploits are used only for explanatory purposes and have no connection with any real host, company or individual. In no event should it be assumed that use of these names means specific hosts, companies or individuals are vulnerable to any attacks nor does it mean that they consent to being used in any vulnerability tests. The use of information in this report is entirely at user's risk. COPYRIGHT ========= (c) 2000 ACROS, d.o.o., Slovenia. Forwarding and publishing of this document is permitted providing all information between marks "[BEGIN-ACROS-REPORT]" and "[END-ACROS-REPORT]" remains unchanged. =====[END-ACROS-REPORT]=====