ASPSession ID's, SSL and a potential major security hole.

From: Stephen Thair (stephen_thair@YAHOO.CO.UK)
Date: 12/14/01 

Date:         Fri, 14 Dec 2001 16:27:28 +0000
From: Stephen Thair <stephen_thair@YAHOO.CO.UK>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Hello all,

A potential security risk has come to light for internet applications that make use of ASP SessionID's to maintain user state information, even if most of the site is over a secure SSL session.

Because of two flaws in the IIS architecture it is possible that:

(a) an ASP SessionID is allocated even if the .ASP pages sets the session state to "false" by <%@ EnableSessionState=False %>. See KnowledgeBase Article http://support.microsoft.com/default.aspx?scid=kb;EN-US;q273974 for more details.

and

(b) The SAME ASP SessionID is shared between a HTTP and HTTPS (SSL) session. See KnowledgeBase Article http://www.microsoft.com/technet/support/kb.asp?ID=274149 for more details. This is also discussed in MS Security Bulletin MS00-080 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS00-080.asp

< The Problem >

So what does this mean? It means that you might be sending out ASPSessionID's when you think you aren't, AND that the same ASP SessionID cookie is being sent in clear text HTTP as is used in the encrypted HTTPS (SSL) session.

So, *if* I can get that ASPSessionID cookie I can impersonate another user EVEN OVER AN SSL SESSION. If a new user connects the server will just seemlessly renogiate the SSL session, and when they then present the valid ASP SessionID the application will then serve them up another users session (eg, for an online bank read: their account details...).

The normal assumption here would probably be that a user would have to have malicious intent to "sniff the wire" (intercept network traffic) to get the ASP SessionID cookie and then present it back to the host web server.

Unfortunately, this isn't true. :-(

A poorly configured web cache or proxy server might just do the hacking for you by CACHING either the initial Set-Cookie header or the cookie itself. Thus the second user who requests the same URL might get the cookie inadvertantly sent to them out of the cache, and on subesquent requests might retrieve information from another users session. (see URL's in appendix below for further reading on cookie caching).

How can I tell if this is happening? Look at your IIS logs and scan for duplicate Source IP/ASP SessionID pairs. If the source IP's are significantly different, ie enough to discount that they are just going through load-balanced cache/proxies then it might be happening to your site/application.

< Resolution(s) >

So what can be done to avoid this happening?

(a) explicitly turn OFF ASP session handling in the IIS metabase for any virtual directories that don't need it, and don't rely on the <%@ EnableSessionState=False %> directive. This should be mandatory for any part of the site that is HTTP not HTTPS. Ideally the site/application should be structured that the HTTP portion of the site is distinct from the HTTPS secure area, and the insecure part can be load-balanced across servers without any need for session persistence.

(b) Implement the patch and fix in Q274149/MS00-080 described above. Note that this requires MORE that just installing the patch - it requires that some changes be made to the metabase ie: "adsutil set w3svc/1/AspKeepSessionIDSecure 1". This change can be set on the site level, or scoped down to any IIS application namespace for finer grained control.

(c) Try to stop any of the pages being cached by setting the following in either the .ASP page or in the virtual directory custom headers property

Response.CacheControl = "no-cache"

Response.AddHeader "Pragma", "no-cache"

Response.expires = -1

(d) Add a random value to the URL for each client when they establish a session - this unique URL would then also help to prevent caching. Obviously this unique value SHOULD NOT be used for any session handling, as it may also be available 'en clear' for any HTTP part of the site.

(e) Don't use ASP SessionID's at all. Implement another, more robust, load balancer friendly user state mechanism. Note that this may change with .Net/IIS6 distributed state mechanisms.

(f) related to (e) use a more robust security system like Netegrity SiteMinder which is able to resist session cookie spoofing.

(g) Make the entire site HTTPS: - but this obviously incurs a performance hit, which can be partly overcome by the use of SSL acceleration.

Cheers,

Steve

< Appendix/Further Reading >

< ASP SessionID structure - nb MS confidential/under NDA >

A typical ASP cookie from an IIS Log looks like this:

ASPSESSIONIDGQGGQYNO=LJALNFJCGLOICFEPIAPBFDEJ

There is a structure to it like this

ASPSESSIONID GQGGQYNO = LJALNFJCGLOICFEPIAPBFDEJ

The blocks have the following meanings:

ASPSESSIONID this is a constant

GQGGQYNO this is an 8 character "munge" of the process ID for the process running the application

                    = (this is an equals sign ;o)

LJALNFJCGLOICFEPIAPBFDEJ is a 32 character "munge" of the 32 bit session ID (see later for how session ID is created)

Session ID is created from a random seed number that is generated when the system starts up). The random seed is incremented every time a new session starts. Note that the "munge" doesn't increment in the same way that the Session ID does.

Since the 8 char string after ASPSESSIONID is a "munge" of the process ID it will be (a) the same for all "In-process" applications (b) a different value is shared for all "Medium isolation (pooled)" applications and (c) unique for each Out-of-process application.

Note to that for IIS5 the ASP session id COOKIE value is that same FOR THE ENTIRE WEBSITE... even though that ASP SessionID is DIFFERENT for each application name space (global.asa). So what you get back from session.sessionID will be different. For more information see<http://www.microsoft.com/technet/prodtechnol/iis/reskit/iis50rg/iischp6.asp> (follow the "The Middle Tier" link and look for "ASP Session IDs Are Not Unique")

< Cookie Caching >

See "point two" http://security.royans.net/info/articles/loadbalancingproblems.shtml

Old list thread re cookie caching http://www.roads.lut.ac.uk/lists/http-caching/1996/02/0066.html

Old AOL FAQ that also talks about their view of caching http://webmaster.info.aol.com/faq.html

The HTTP 1.1 RFC that specifically tries to add new directives to deal with this issue HTTP 1.1 <http://www.w3.org/Protocols/rfc2068/rfc2068.txt>

< Other related MS software bugs >

Site Server GUID issue http://support.microsoft.com/support/kb/articles/Q238/6/47.ASP

Another Site Server issue http://support.microsoft.com/support/kb/articles/Q263/7/30.ASP

---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

============================================================================
Delivery co-sponsored by VeriSign - The Internet Trust Company
============================================================================
Protect your servers with 128-bit SSL encryption!
Get VeriSign's FREE guide, "Securing Your Web Site for Business." You will
learn everything you need to know about using SSL to encrypt your e-commerce
transactions for serious online security. Click here!
http://www.verisign.com/cgi-bin/go.cgi?a=n016065650057000
============================================================================

Relevant Pages

  • Re: File Upload - Security Issues
    ... You want to upload a file for what reason and you do ... file and what pitfalls you see re: security might be helpful on this end?! ... files to an IIS server that doesn't have MS Office actually installed? ... 2* Upon submit this is submitted to an ASP page that then (using the XML ...
    (microsoft.public.scripting.vbscript)
  • AW: ASP Dot Net Security Guidelines
    ... Betreff: Re: ASP Dot Net Security Guidelines ... Basically you'll treat an asp.net application server as you would an asp ... > to set the permissions as it brings up access denied errors on the ...
    (Focus-Microsoft)
  • Re: VB Component debugging as anonymous access
    ... formatting the date on the LCID 1046 as dd/mm/yyyy, ... behavior both in ASP and in my component, ... security on the Web Server, ... Thats why I need the debugger ...
    (microsoft.public.inetserver.asp.components)
  • RE: Page not found with SSL/https but ok on http
    ... find server or DNS ... You dont' have port 443 definied as your SSL port. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Security Scan on IIS shows files and folders
    ... > Recently our comapny had a Professional Security Scan done one of our ... I recommend checking your IIS web logs. ... who can guess the name of the files and folders can view them. ... to .Old or .Bak is a serious problem as the attacker gets to see your .ASP ...
    (microsoft.public.inetserver.iis.security)