Microsoft Security Bulletin MS00-080

Technical description:

IIS supports the use of a Session ID cookie to track the current session identifier for a web session. However, .ASP in IIS does not support the creation of secure Session ID cookies as defined in RFC 2109. As a result, secure and non-secure pages on the same web site use the same Session ID. If a user initiated a session with a secure web page, a Session ID cookie would be generated and sent to the user, protected by SSL. But if the user subsequently visited a non-secure page on the same site, the same Session ID cookie would be exchanged, this time in plaintext. If a malicious user had complete control over the communications channel, he could read the plaintext Session ID cookie and use it to connect to the user's session with the secure page. At that point, he could take any action on the secure page that the user could take.

The conditions under which this vulnerability could be exploited are rather daunting. The malicious user would need to have complete control over the other user's communications with the web site. Even then, the malicious user could not make the initial connection to the secure page - only the legitimate user could do that. The patch eliminates the vulnerability by adding support for secure Session ID cookies in .ASP pages. (Secure cookies already are supported for all other types of cookies, under all other technologies in IIS).

The original version of patches for IIS 4.0 Alpha and the IIS 5.0 systems did not install correctly. The IIS 4.0 x86 version of the patch does install correctly.

What's this bulletin about?
Microsoft Security Bulletin MS00-080 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

Why has this bulletin been re-released?
We've re-released the bulletin to let customers know about a problem in the original versions of the patches for IIS 4.0 on Alpha platforms and IIS 5.0 on x86 platforms. The problem would prevent the patch from operating correctly. The IIS 4.0 patch for x86 platforms is not affected by the problem.

Is there any change in the scope of the vulnerability?
No. We are re-releasing the bulletin because there was a problem with certain versions of the patches, not because there has been any change in our assessment of the vulnerability.

What's the problem with the patches?
The Alpha version of the IIS 4.0 patch and the x86 version of the IIS 5.0 patch did not install correctly. The IIS 4.0 patch for x86 systems did install correctly, and customers who have applied this version of the patch do not need to take any action.

What's the scope of the vulnerability?
This vulnerability could, under very restricted conditions, enable a malicious use to "hijack" another user's secure web session. That is, it could allow the malicious user to connect to another user's existing session with a secure web page, and would allow him to take action on the other user's behalf, such as placing orders or viewing personal information.
The conditions under which this vulnerability could be exploited are quite restricted. The malicious user would need to have complete control over the communications between the user and the web site, and be able to read data and insert his own data into the communications. Further, it would not enable the malicious user to start a session as another user - he could only hijack a session once the legitimate user started it. The vulnerability only affects web pages created using one particular technology.

What causes this vulnerability?
SSL-protected .ASP pages cannot mark their Session ID cookies as "secure cookies". As a result, it could be possible, under some very daunting circumstances, for a malicious user to obtain another user's Session ID and connect to their SSL-protected session.

What's a cookie?
A cookie is a small data file that contains information about a particular user and a particular web site. There are two primary types of cookies:

• Persistent cookies. These are retained from visit to visit, and typically provide historical information about the user's preferences on the web site that allows it to customize its offerings. For instance, if Jane visits Web Site A frequently, and always checks out sporting goods there, that information could be recorded in a cookie on her computer. When she visits the site again in the future, it could read the cookie and show her the latest sporting goods, rather than, say, the new selection of incense and herbs.
• Session cookies. These only contain information about the current visit to the web site, and typically provide state information - data that lets the web site know what the visitor is currently doing on the site. To understand why the site needs state information, recall that a given web site might have hundreds or thousands of people accessing its pages asynchronously, that is, in any order and with any timing they want. When Jane moves from the shopping pages to the checkout page, there needs to be some way for the checkout page to know that she's Jane, and to look up her current order.

The vulnerability involves how one particular type of web page in IIS - .ASP pages - handles one particular type of session cookie -- containing information known as a Session ID.

What are .ASP pages?
ASP, or Active Server Pages, is a technology supported by IIS that enables very powerful, dynamic web sites to be built. Rather than coding a static HTML page, under .ASP a web developer writes a program that runs on the web server and dynamically generates the HTML page that will be sent to the user. This allows the web page to be customized for the particular user and particular conditions at hand.

What's a Session ID cookie?
Among the state information that a web site needs is some way to identify Jane as she moves from page to page on the site. The way this is done is to assign a Session ID when she initially visits a page on the site, and use that value to identify her throughout her session. Each time she starts a new session with the web site, she would be issued a new session ID.

What's wrong with how .ASP pages handle Session ID cookies?
.ASP pages don't provide the ability to mark a Session ID cookie as secure. The industry standard specification that discusses the handling of cookies, RFC 2109, specifies that it should be possible for a secure web page to mark cookies as "secure", in which case the browser should only send them to secure pages on the site.

Is this a problem with how all cookies are handled in IIS?
No. It's a special case affecting only how .ASP pages mark Session ID cookies. All other technologies in IIS support secure cookies globally, and .ASP supports secure cookies in every case except the particular case of Session ID cookies.

How could this vulnerability be exploited, and what would it allow someone to do?
It could potentially allow a malicious user to "hijack" a secure web session, but only if he already had a significant degree of control over another user's web session. Suppose that Bob were able to monitor all of Jane's web activities. That is, assume that he had physical access to Jane's network connection, and was "sniffing" her web sessions. Now suppose that Jane visited a secure page (that is, an SSL-protected page) on her favorite web site. Bob could see all of the data moving between Jane and the site but, because it would be encrypted using a key he doesn't have, he wouldn't be able to read it. Among the data that the site would send to Jane would be a Session ID cookie.
Now suppose Jane moved to a non-secure page on the same site. As before, Bob would be able to see all of the data that Jane and the web page exchanged. However, this time he would be able to read it, because it would be in plaintext. Because the Session ID cookie can't be marked as secure, it would be sent over the network in plaintext. Bob could then read the Session ID cookie and connect to the secure web page as Jane. At this point, he could take any action on the page that Jane could take.

What good would it do for Bob to connect to the secure web page? After all, he still wouldn't have a key that allows him to read the data.
If Bob's browser connected to the secure page using Jane's Session ID, the page would negotiate a new SSL key with Bob's browser and use it to protect the session. Please note that this would not give Bob a way to read the pages that had previously been sent to Jane - they were encrypted with a different key, and Bob still doesn't have it. But the ability to negotiate a new key would give him the opportunity to conduct future transactions with the secure page. That is, once he gains a way to communicate with the page as Jane, he could review her credit card information, change her orders, etc.

How likely is it that someone could have the necessary degree of control over a web session to allow them exploit this vulnerability?
It would be extremely difficult, but not impossible. The malicious user would need to either have physical access to the user's network connection, or extremely favorable network topology. That is, he would either need to be able to tap the other user's line, or be in a location through which all of the user's data passes.

What if Jane never visited a secure page on the site? Could the malicious user exploit the vulnerability then?
This vulnerability doesn't provide a way for the malicious user to initiate a session with a secure page, only to hijack an existing one. Bob would have no way to begin a secure session as Jane, because he wouldn't be able to provide the authentication the secure page requires - a digital certificate, a password, a PIN, etc. (Or, to look at the problem a different way, if he did have this information, he wouldn't need to exploit the vulnerability. He could simply log onto the site as Jane).
The vulnerability provides no way for Bob to force Jane into visiting a secure site and authenticating to it. Bob would either need to use social engineering to persuade Jane to visit the secure page, or he would need to monitor her communications until she happened to visit a particular site.

Suppose Jane visited a secure page, but didn't ever visit a non-secure page on the same site. Could the malicious user exploit the vulnerability in this case?
If Jane visited only secure pages during her session, Bob could not force her to go to a non-secure page in order to expose her Session ID. However, if she visited a non-secure page at any point during her session - even one on a different site - it would be possible for Bob to modify her request, since, in the scenario here, he would have complete control of her network communications. Under these conditions, he could change her request, or send another one in her stead, in order to redirect her to a non-secure page on the desired site. This would trigger the exchange of the Session ID, which would allow Bob to read it and use it.

Does this vulnerability mean that my cookies are at risk?
No. Keep in mind that this vulnerability only affects one particular type of cookie, and only when created by an. ASP page. All other cookies can be marked as secure, and are handled appropriately.

Does this mean that all secure web sites that use .ASP are at risk?
No. Best practices recommend that web sites use different Session IDs for secure and non-secure pages. Sites that follow this guidance would not be at risk from the vulnerability, because there would be two different Session ID cookies - one used by the secure web pages, and one used by the non-secure ones. The Session ID cookie for non-secure pages would travel in plaintext and could be intercepted, but could only be used to "hijack" a non-secure web page, which is always possible.
Even if a site did use common Session IDs for secure and non-secure pages, the vulnerability couldn't be exploited if the secure pages always required the user to authenticate before negotiating new keys. If this were done, Bob wouldn't be able to set up a session using Jane's Session ID, because he wouldn't have her password.

Who should use the patch?
The patch should be installed on any web server that requires the need to mark Session ID cookies from .ASP pages as secure.

I installed the original version of the patch. Should I install the new version?
It depends on what version of IIS you're using, and what platform your system runs on. If you are running IIS 4.0 on an Alpha platform, or IIS 5.0 on an x86 platform, you should install the new version of the patch. If you are running IIS 4.0 on an x86 platform, you do not need to install the new version.

What does the patch do?
When installed and enabled, the patch provides support for secure cookies. Knowledge Base article Q274149 has specific details about how this changes cookie handling and Session ID use.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
Knowledge Base article Q274149 provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article

What is Microsoft doing about this issue?

• Microsoft has delivered a patch that eliminates the vulnerability.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• IIS 4.0:
  • x86 platforms:

    http://support.microsoft.com/kb/274149

  • Alpha platforms:

    Available from Microsoft Product Support Services

Note:

• The IIS 4.0 version of this patch can be installed on Windows NT 4.0 systems running Service Pack 6a, and will be included in Service Pack 7.