Remote Retrieval of IIS Session Cookies from web browsers ------------------------------------------------------------------------ SUMMARY The ACROS team has analyzed how popular web browsers could be tricked to reveal IIS's session ID cookies and discovered a way in which a remote attacker can retrieve this information even when SSL is used to protect the data. Because of this analysis, ACROS has identified a weakness in Microsoft's Internet Information Server. It should not be assumed, however, that only this product is affected - all vendors of web servers and HTTP session management solutions are urged to review their products for the identified vulnerabilities. DETAILS Vulnerable systems: Internet Information Server 4.0 Internet Information Server 5.0 Internet Information Server 3.0 was not tested, but its session ID generation is so weak that it is definitely not usable for critical systems even if it's not affected. Introduction: So you have launched your new web-based e-banking system and protected it with 128-bit SSL. Your users logon to it through their browsers, providing their usernames and one-time passwords, and then cryptographically strong random session cookies are computed and sent to their browsers for session authentication. Entire communication is protected with SSL so there's no way anyone could intercept the sensitive cookies. You feel safe; you trust SSL to do its job protecting your users and your system. Their session ID cookies are secure. Or are they? It could be possible to retrieve the session cookies 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. Lets put all client-scripting issues aside for the time (including cross-site scripting, which is very suitable for stealing cookies). We'll also ignore all bugs in various SSL implementations aside and assume SSL is working as specified. Session ID Cookies: Most "stateful" web-based systems are using session ID cookies for maintaining sessions. A session ID cookie is generated on the server in such a manner that a potential attacker could not guess (or calculate) its value. Usually strong cryptographic algorithms are used for this purpose. The server only provides the user with a session ID cookie after the user has proved his identity (by providing username and password, for example). Cookies are generally transmitted between browser and server in plaintext in HTTP headers. For protection against network sniffing and traffic redirection, SSL is often deployed to encrypt and authenticate the communication. Note: While it is generally clear that username:password pairs are indeed authentication data and therefore sensitive, it is many times not clear that session ID cookies are also frequently used for authentication. Numerous web-based financial systems use a strong form of authentication for the initial login (like one-time passwords or SSL client certificates), while throughout the session they rely entirely on users' presentation of correct session ID cookies. Obviously, for the attacker, stealing such a cookie would mean a successful takeover of user's identity. Hence the notion that in critical systems, session ID cookies are just as sensitive as passwords (effectively they are equivalent to username:password pairs). 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 These assumptions are only a part of the assumptions stated in the SSL Specification. SSL was developed for protecting against this type of attacker. For this analysis, we have set up IIS 5 web server (www.example.com), installed a valid SSL key+certificate and written a script (login.asp) that sets a (native IIS) "session ID cookie" when accessed by browser. We have also written another script (cookies.asp), which displays the contents of all cookies sent by the browser. Then we opened a browser, typed "https://www.example.com/login.asp" which executed the script login.asp and our browser was "marked" with the session ID cookie. The cookie was 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.asp" (no SSL here!) we could observe session ID cookie being transmitted to the server over an unencrypted link, thus making it interceptable for a network listening attacker. The conclusion is that even though a session cookie was sent to the browser over an encrypted connection (and would be normally - in a real-life system - sent back to the server over an encrypted connection too), it is also sent to the same server over an unencrypted connection if the browser establishes one. While normally, the browser wouldn't establish such a connection (except in a badly designed web application), this opens an opportunity for the attacker to make any user's browser 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: Malicious E-mail Technique The first one (very popular in examples) is 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 session ID cookie to the critical web-based system, over an unencrypted channel. Surely, a serious attacker can't go relying on the user clicking a link in his e-mail message while his browser still holds the session ID cookie. 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 session ID cookies for session 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 the amount of exchanged data), attacker can assume that the user has successfully authenticated to the server and his browser has received the session ID cookie. Actually, network traffic analysis can give pretty 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 session ID cookie 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) tries to load "image.gif" from server "www.sensitive.com" over unencrypted HTTP protocol (thus transmitting session ID cookie for this server in cleartext) and (2) reloads 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 session ID cookie for the current session. Note: The file "image.gif" doesn't need to exist on "www.sensitive.com". If the "www.sensitive.com" server doesn't have port 80 (HTTP) open, the attacker can make a fake response on its behalf, convincing the browser that the port is open. Identity theft By knowing the user's session ID cookie, the attacker can hijack his current session, assuming his identity. Patch Microsoft has issued a patch for IIS, available at: <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25233> http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25233 (IIS 4.0) <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25232> http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25232 (IIS 5.0) This patch pertains to a similar vulnerability, described at: <http://www.securiteam.com/windowsntfocus/Session_ID_Cookie_marking_vulnerability__Patch_available_.html> Session ID Cookie marking vulnerability (Patch available). It also solves the problem described in this advisory. This patch makes it possible for IIS to mark its session cookies as "secure" thus preventing them from being sent over unencrypted connections. Administrators of IIS-based critical systems (e.g. web-banking) are advised to install the patch and configure the appropriate registry options accordingly. It is important to note that the limited testing only covered one web server. There are many other web servers and various session management server add-ons that could be potentially affected by the identified vulnerability. Workaround: Users of web browsers can destroy session ID cookies by closing all instances of their browsers immediately after logging out of critical web-based systems - that's before accessing any other web site. In addition, between logging in and logging out of such system, they shouldn't 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 session cookies). 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". ADDITIONAL INFORMATION The information has been provided by <mailto:[EMAIL PROTECTED]> ACROS Security. -- 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
