Web session tracking security prob. Vulnerable: IIS and ColdFusion (maybe others)

["Jeff Jancula" <Jeff () Jancula com>]

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.Jancula () FirstUnion com
Chris Howser, Technical Advisor, e-mail: Chris.Howser () ISS FirstUnion com
Chris Hudel, Technical Advisor, e-mail: Chris.Hudel () FirstUnion com