Remote Retrieval of Authentication Data from Internet Explorer ------------------------------------------------------------------------ SUMMARY So, you have launched your new web-based e-purchasing system and protected it with 128-bit SSL. Your users logon to it through their browsers, providing their usernames and passwords. Entire communication is protected with SSL so there is no way anyone could intercept his or her authentication data. Alternatively, maybe your web admin is remotely administering your web server through some remote admin app (like IISAdmin) and you are relying on SSL to encrypt the HTTP "Basic" authentication when it is going through the Internet. You feel safe; you trust SSL to do its job protecting your users and your system. Their passwords are secure. Or are they? The following article will show that it could be possible to retrieve the cached authentication data from your user's web browser with little or no user's cooperation, even when due care was taken to protect the communication between browser and server with SSL. Note: The article will put all bugs in various SSL implementations aside and assume SSL is working as specified. DETAILS Vulnerable systems: Internet Explorer 4.01 SP2 - affected Internet Explorer 5.01 - affected Immune systems: Communicator 4.72 - not affected Communicator 4.73 - not affected Internet Explorer 5.5 - not affected (according to Microsoft) For the purpose of this report, the article will define "cached authentication data" as static username:password pairs that the client application (web browser) needs to provide to the server in order to get his requests processed. The article will also only deal with username:password pairs for HTTP BASIC authentication, which is one of the authentication mechanisms that Internet Explorer provides. Arguably, BASIC authentication is the only browser-integrated authentication that is supported by both Internet Explorer and Netscape Navigator so chances are that every public web-based system that pops up a dialog window requesting a username and password at login is using this type of authentication. Our definition of cached authentication data is not to be mistaken for "Password Caching", a feature of Internet Explorer that allows users to store their passwords in Explorer's storage so that they are never again asked for them (even after IE is closed and rerun). However, using the feature users are clearly making the attack this article describes below even easier to work. Analysis: Throughout the analysis, it is assumed that the attacker is capable of the following: 1) Listening to network traffic between client and server 2) Generating fake (spoofed) network traffic between client and server Note: These assumptions are only a part of the assumptions stated in the SSL Specification. SSL was developed for protecting against this (and much stronger) type of attacks. For this analysis, we have set up a web server (www.example.com), installed a valid SSL key+certificate and enabled Basic HTTP authentication. We have also written a script (variables.cgi), which displays the contents of HTTP authentication data (username:password) received by the browser. Then, we opened Internet Explorer, typed "https://www.example.com/variables.cgi" and we were presented with an authentication dialog asking us for username and password. When these were entered correctly, the script variables.cgi was executed which displayed our username and password. The username and password were sent between client and server over an encrypted SSL connection, preventing anyone listening from intercepting them. Then, by opening the page "http://www.example.com/variables.cgi" (no SSL here!) we could observe the authentication data being transmitted to the server over an unencrypted link, thus making them interceptable for a network listening attacker. The conclusion is that even though username and password were sent to the server over an encrypted connection, they are also sent to the server over a subsequent, unencrypted connection if the browser establishes one. While normally, the browser would not establish such a connection (except in a badly designed web application), this opens an opportunity for the attacker to force the browser to do so. Exploitation: For the purpose of exploitation, there are at least two ways of making the user's browser connect to an arbitrary URL: Social Engineering Technique The first one is (very popular in examples) sending the user a "malicious" e-mail message including a hyperlink to the attacker's web page, which contains a hidden <img> tag opening an unencrypted connection to the affected web-based system. When the user clicks on the link in the attacker's e-mail message, the attacker's web page is opened in the browser and the <img> tag causes the browser to send its authentication data to the critical web-based system, over an unencrypted channel. Surely, a serious attacker cannot go relying on the user clicking a link in his e-mail message. He needs a more effective technique. Active Network Technique This technique assumes the attacker has the ability to both listen to and generate fake (spoofed) network traffic between browser and server. We will assume a web-based system at "https://www.sensitive.com" using HTTP BASIC authentication. Phase 1: The HTTPS waiting phase First, the attacker listens to the communication between the user (his browser) and server to determine when the user connects to www.sensitive.com on port 443 (HTTPS port). This is an indication that the user has started a session on the sensitive server. After some amount of data is exchanged between the two (due to encryption the attacker can't observe much more than just the amount of exchanged data), attacker can assume that the user has successfully authenticated to the server and his browser has cached the authentication data. Note: Actually, network traffic analysis can give reliable hints whether the HTTP authentication was successful or not, especially when the attacker had the ability to observe a controlled session beforehand and learn the sizes of various server's responses. Phase 2: The HTTP waiting phase After the "HTTPS waiting phase" is over, the user's browser has the username and password in its memory. Now, what the attacker would like to see is the user's browser connecting to www.sensitive.com over (unencrypted) HTTP protocol on port 80. To force that, he waits for the browser to send a HTTP request to ANY server, for example "http://www.yahoo.com/index.html". Phase 3: Cached authentication data retrieval When this happens, the attacker sends a fake response from "www.yahoo.com" to the browser, containing the following document: <html> <head> <meta http-equiv="refresh" content="1; URL=index.html"> </head> <body background="http://www.sensitive.com/image.gif"> </body> </html> What this document does is (1) try to load "image.gif" from server "www.sensitive.com" over unencrypted HTTP protocol (thus transmitting authentication data for this server in clear text) and (2) reload the page after one second. This (second) time, the attacker lets the real "www.yahoo.com" server answer the request so that the user gets what he requested. Meanwhile, by sniffing the network traffic, the attacker has retrieved the user's authentication data for the sensitive server. Note: The file "image.gif" doesn't need to exist on "www.sensitive.com". Note: If the "www.sensitive.com" server does not have port 80 (HTTP) open, the attacker can make a fake response on its behalf, convincing the browser that the port is open. However, in the case of Internet Explorer, there is easier ways for making it send the authentication data over HTTP: by "planting" a request for "http://www.sensitive.com:443/image.gif". This way, the connection will be established to the (naturally open) port 443 and when the server responds that it is there, the browser sends its request (including username and password). Then, of course, the connection hangs since a HTTP client is trying to talk to a HTTPS server, but that is no problem since the sensitive data was already retrieved and the page will reload in one second, that's long before a timeout would occur and possibly alert the user. Identity theft By knowing the user's username and password, the attacker can login to the sensitive system, assuming the user's identity. Solution: Microsoft has issued a patch for IE. See more information in our previous article: < http://www.securiteam.com/windowsntfocus/Internet_Explorer_Cached_Web_Credentials_vulnerability__Patch_available_.html > Internet Explorer Cached Web Credentials vulnerability (Patch available) This patch changes the behavior of Internet Explorer so that it never sends the cached authentication data over an unencrypted connection if it was initially sent over an encrypted connection. Users of Internet Explorer are advised to install the patch. Managers of sensitive web-based systems using BASIC authentication are urged to advise their users to install the patch. It is important to note that our limited testing only covered two web browsers: Internet Explorer and Netscape Navigator (which isn't vulnerable). Many other web browsers could be potentially affected by the identified vulnerability. Workaround: Users of web browsers can destroy cached authentication data by closing all instances of their browsers immediately after logging out of critical web-based systems - that is before accessing any other web site. In addition, between logging in and logging out of such system, they should not visit any other web site - not even web sites they trust. For connecting to critical web-based systems, every user should: 1) Close all instances of the browser (if there are any) to prevent possible JavaScript attacks 2) Launch the browser 3) Log in to the system 4) Use the system 5) Log out of the system 6) Close all instances of the browser (to delete cached authentication data) The above procedure could also protect users from various other vulnerabilities inherent to web-based systems and should in our opinion be used as a "best practice". -- Eko Sulistiono MIKRODATA & AntiVirus Media Web: http://www.mikrodata.co.id/ WAP: http://www.mikrodata.co.id/wap/index.wml This message contains no viruses. Guaranteed by AVP. ------------------------------------------------------------------------ Forum Komunikasi Penulis-Pembaca MIKRODATA (FKPPM) Informasi : http:[EMAIL PROTECTED] Arsip : http://www.mail-archive.com/forum%40mikrodata.co.id/ WAP : http://mikrodata.co.id/wap/index.wml Milis ini menjadi kontribusi beberapa rubrik yang diasuh tim MIKRODATA. Termasuk rubrik-rubrik yang ada di media lain. Memakai, Menyebarluaskan, dan Memperbanyak software bajakan adalah tindakan kriminal. Please check with the latest AVP update before you ask about virus: ftp://mikrodata.co.id/avirus_&_security/AntiViral_Toolkit_Pro/avp30.zip
