First let me thank the first two SecurityVibes members who posted comments at the bottom of this article which has given me the opportunity to update this article. Their comments really show the power of networking in a community such as ours.

The attacks that have been rediscovered by the First Base Technologies’ web application testing team can result in criminals hijacking legitimate users’ sessions whilst they are shopping online or using critical services, such as web mail or remote network access. Even real world web sites today have been shown to be vulnerable, including sites using Microsoft SharePoint and those using two-factor authentication tokens.

“This is an inherent problem in the configuration of many e-commerce sites and remote access services which can be exploited both directly and indirectly” said Peter Wood, Chief of Operations at First Base Technologies.

The vulnerability was listed in the OWASP.org 2007 Top Ten Guide for web developers and discussed how insecure HTTP can be used to subvert secure HTTPS. Peter Wood then put this into an understandable step by step guide.

Essentially, when a user logs in to a web application, the web server generates a session token. The session token is a unique identifier that is generated and sent from the server to the user’s browser in a cookie to identify the current interaction session. The use of session tokens means that the client only has to handle the identifier (a small piece of data which is otherwise meaningless and thus appears to present no security risk) and all session data is stored on the server linked to that identifier.

The problem arises if the session token associated with an SSL secure session (HTTPS) is also transmitted over a clear text connection (HTTP). For example, a catalogue of products on an e-commerce site will be offered over an HTTP connection since it is faster and doesn’t require authentication. However when a user logs in to the site to make a purchase, they will be switched to HTTPS to encrypt their sensitive information. At this stage a session token will be generated for the HTTPS session and transmitted in a cookie. If the user then continues to browse the site, they will be switched back to HTTP but in some cases the cookie will continue to be transmitted, this time in clear text.

Sites that do not mark the SSL cookie as ‘secure’ will behave in this fashion. Suppose an attacker can intercept this clear text cookie, for example on an insecure wireless network or WiFi hotspot. If the server permits concurrent sessions for a single user instance (a common configuration mistake), the attacker will then be able to present the session token back to the server and impersonate the logged in user. If the server permits concurrent sessions, it will accept the token, since it cannot differentiate between the attacker and the legitimate user even if they are on different machines.

Web Application Configuration Mistake
A second problem occurs if the web application does not invalidate the session token when the user logs off, which is quite a common configuration mistake. In this case the attacker can continue to impersonate the legitimate user even after they have logged off.

An attacker may also entice a user to click on a link to invoke this problem. If the legitimate user is logged on to a secure connection, such as Outlook Web Access, and then responds to a targeted phishing e-mail to browse to an HTTP connection on the same server, the session token along with everything else is transmitted in clear text. The session token for the secure OWA session is automatically sent because the user is already authenticated at the time of clicking on the link in the e-mail. This transmission enables the attacker to capture the session token by sniffing the network traffic and then to compromise the victim’s e-mail account by replaying the session token to the target site while the session is still active.

This type of attack can be prevented by using the 'secure' attribute while setting a new SSL cookie. If the cookie is marked ‘secure’, it will only be transmitted if the communications channel with the host is secure and will not reveal sensitive information to an attacker via network interception.

After Publishing Note
SecurityVibes members pointed out a more dangerous way to subvert SSL using a weaponised form (sslstrip) of the above attack produced by Moxie Marlinspike from the February Blackhat conference - see references below.

References
Blackhat PDF: Pictures of Sites Compromised and SSL Subversion Techniques Used
Blackhat Interview: Moxie Marlinspike on SSLStrip and Potential Defences
For more on Firstbase Penetration Testing
SecurityVibes Article: Remote Working and Pandemics Open Organisations to Further Breaches
SecurityVibes Article: Laptop Protection under Epidemic Situations notes for a CISO