|
Brought to you by:
Suppliers of:
|
|
|
| |
IIS uses a mechanism called session ID cookies, in order to maintain a logical 'session' related to a certain user as they move from page to page on a web site.
IIS does not support the secure session ID cookies (defined in RFC 2109), and therefore in a scenario where a user initiates a connection to an SSL protected web site, and later moves to a non-secure page, the session ID cookie used by the asp pages to identify the user is passed in plaintext, and can be 'hijacked' by an attacker who can sniff the communication between the user and the server. This information enables the attacker to take over the user's session - for example, if a user entered credit card information on the secure pages, the attacker can use this session cookie to take actions on behalf of the user, and the server will not require further authentication since it is tricked to think the user is continuing his session. |
| |
Credit:
This security problem has been discovered by ACROS Security.
|
| |
Vulnerable systems:
IIS 4.0 and 5.0
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 (http://www.ietf.org/rfc/rfc2109.txt). 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.
However, 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 an attacker 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.
Mitigating Factors:
- The attacker would need to have complete control over the target's communications with the web site. That is, he would need the ability to monitor the target's communications and add his own to the session.
- The attacker could not make the initial connection to the secure page - only the legitimate user could do that.
- The vulnerability is limited only to how Session ID cookies are handled in .ASP pages. Secure cookies already are supported for all other types of cookies, under all other technologies in IIS.
Patch Availability:
A patch is available to fix this vulnerability.
IIS 4.0
http://www.microsoft.com/ntserver/nts/downloads/critical/q274149/default.asp
IIS 5.0
http://www.microsoft.com/Windows2000/downloads/critical/q274149/default.asp
|
|
|
|
|
