SECURITY PROBLEMS WITH WEB SERVERS' SESSION TRACKING MECHANISMS. On February 20, 2001 we reported the following problem (with specifics to IIS and SITESERVER) to the Microsoft Security Response Center. On March 22, 2001 we also reported a similar problem to Allaire (now Macromedia) for ColdFusion. Approximately 2-3 weeks after reporting to appropriate vendors, we also reported these vulnerabilities to CERT.ORG. PROBLEM DESCRIPTIONS: Microsoft Internet Information Server (IIS) and Site Server do not verify that session cookie values were actually issued by the server. An Internet user can generate their own session cookie, which will be accepted as valid by these servers. An attacker could use cross-site scripting vulnerabilities to generate a modified session cookie, with a predictable session value, then use the predetermined session value to later take over (impersonate) other users. Similarly, Allaire's ColdFusion Server does not verify that session tracking values CFID and CFTOKEN were actually issued by the server. An Internet user can generate their own CFID/CFTOKEN session values, which will be accepted as valid by the server. An attacker could set CFID/CFTOKEN values on a URL line contained in an e-mail message, or use cross-site scripting vulnerabilities to generate CFID/CFTOKEN session cookies, with predictable values, then use the predetermined session values to later take over (impersonate) other users. These vulnerabilities, especially when combined with well-known cross-site scripting vulnerabilities, could cause loss of confidentiality, failure of non-repudiation and fraud. SUMMARY OF VENDOR RESPONSES: Microsoft agreed that we had uncovered a bug in IIS, which would be fixed in a future release. However, they did not consider the bug to be a security vulnerability because it requires another security vulnerability (cross-site scripting) to work. Allaire agreed that we had unconvered a security problem with ColdFusion and recommended that applications requiring high security implement their own session tracking mechanisms - in other words, don't rely on ColdFusion's session tracking (CFID/CFTOKEN). Allaire also indicated that they are considering a redesign of their session cookie mechanism to improve security. Like Microsoft, CERT isn't convinced that a real security problem exists. Personally, I'd like to know if the security community thinks this is a real problem or not. BACKGROUND: When a Internet browser user visits IIS or ColdFusion hosted web sites, the web server issues browser commands similar to: (for IIS) Set-Cookie: ASPSESSIONID=BBBBBBBBABCDEFGHIJKLMNOP (for CF) Set-Cookie: CFID=123 (for CF) Set-Cookie: CFTOKEN=4567890 The browser stores and returns the "ASPSESSIONID" or "CFID/CFTOKEN" values with each subsequent request to the web server. IIS and ColdFusion use these values to identify and track each user. IIS and ColdFusion do a pretty good job of generating random session values, so that users can't guess each other's session values. However, an attacker could force a predictable cookie value, by using JavaScript or an <META HTTP-EQUIV> tag to override the relevant cookies: document.cookie = "ASPSESSIONID=BBBBBBBBAAAAAAAAAAAAAAAA"; or, <META HTTP-EQUIV="Set-Cookie" Content="CFID=123; path=/"> <META HTTP-EQUIV="Set-Cookie" Content="CFTOKEN=1111111; path=/"> Of course, the hard part is getting the JavaScript or META tag to the victim's browser (that's were cross-site scripting comes in - a subject covered elsewhere). ColdFusion makes this attack even easier, because it allows its session tracking variables to be specified on the URL line. So, an attacker could force a predictable cookie value by passing a user a link, via e-mail, another web site, or as a bookmark. For example: http://www.MyColdFusion.net?CFID=123&CFTOKEN=1111111 Regardless of the method used, the browser will send the modified ASPSESSIONID or CFID/CFTOKEN values for all future requests to the web server. The problem is, the web server honors the modified session values - as if the server actually issued them! Note that the cross-site scripting hack (using META tags or other JavaScript commands) could change a user's cookies mid-stream, causing the web server to detect a new session start and possibly cause the user to re-authenticate (logon). The user would only notice that they were seemingly "kicked out" of their session, and probably not report the incident to support personnel. The user's previous session would eventually be abandoned by the server; and the attacker could now intercept the new session. HOW FIRST UNION DETECTED THIS PROBLEM: This problem was detected by First Union's application security testing team, while testing servers for potential use with First Union internal applications. The team used various hacking tools to perform a man-in-the-middle attack to modify ASPSESSIONID and CFID/CFTOKEN cookies. These attacks were NOT tested on live financial/production systems. Confidential customer or employee data was not exposed during these tests. RELEVANT VERSIONS: The tested Microsoft servers were running IIS 4, SiteServer (version?) on Windows NT 4.0, service pack 6a. Although only slightly confirmed, we believe IIS 5 on Windows 2000 is also vulnerable. The tested Allaire servers were running ColdFusion 4.6 on Solaris. REFERENCES: "Security Best Practice: URL Session Variables and HTTP_REFERER" article on Allaire's web site (www.allaire.com). TECHNICAL CONTACTS: Jeff Jancula, Technical Advisor, e-mail: Jeff.Janculaat_private Chris Howser, Technical Advisor, e-mail: Chris.Howserat_private Chris Hudel, Technical Advisor, e-mail: Chris.Hudelat_private
This archive was generated by hypermail 2b30 : Wed Aug 29 2001 - 22:08:30 PDT