UI Redressing Mayhem: HttpOnly bypass PayPwn style

In the previous post, a new cross-domain extraction method - affecting the latest version of the Mozilla Firefox browser - has been presented. The iframe-to-iframe technique was successfully used in a UI Redressing attack affecting LinkedIn. Today, I'm introducing an instance of the aforementioned method that involves a known Apache Web Server security issue, in order to steal session cookies that are protected by HttpOnly flag, thus allowing the attacker to perform Session Hijacking attacks. A new attack targeting PayPal systems will be also presented.

CVE-2012-0053: HttpOnly bypass and beyond

In January 2012 - even if the Apache defect was known and exploited for a while - Norman Hippert disclosed CVE-2012-0053 bug affecting the Apache Web Server. The software was not able to correctly restrict an header field information disclosure in case of overlong or malformed HTTP requests. The vulnerability could be effectively combined with a Cross-Site Scripting attack to bypass the protection mechanism introduced by the HttpOnly flag and steal any session token stored as cookies value. Infact, an XSS vector could manipulate the document.cookie object to set an overlong cookie field, and forward a malformed request to the affected Apache Web Server with the intention to trigger the error message and extract the desiderated session cookies. The Apache bug can be abused in a series of attack scenarios such as the following:

• Bypassing HttpOnly flag with a XSS vulnerability on the same domain that is affected by the CVE-2012-0053;
• Bypassing the limitation introduced by cookie path whereas the XSS vulnerability affects a web resources that resides outside the defined path itself;
• Bypassing HttpOnly flag if a XSS vulnerability is found on any subdomains of the host that is affected by the Apache disclosure issue, if exploited in conjunction with a UI Redressing attack - that allows the cross-domain content extraction of the information included in the triggered Apache error message.

It should also be noted that the Apache Web Server is often used as a reverse proxy configuration. As a result, any session object on any server-side technology, could be attacked with the described vectors.

Smashing PayPal for Fun but.. NO Profit

 

During my security research on UI Redressing attacks I found multiple PayPal subdomains (e.g. https://b.stats.paypal.com) affected by the Apache disclosure bug as detailed in Figure 1 and Figure 2.

Figure 1 - HTTP request with the overlong cookie.

Figure 2 - Apache error message with the disclosure of the malformed Cookie header.

Despite in the first instance the bug could appear as useless, I found that the PayPal application - www.paypal.com - delivers the session cookies defining the domain to .paypal.com (Figure 3 and Figure 4).

Figure 3 - Post-authentication cookies delivery.

Figure 4 - Cookies delivered to the personal.paypal.com subdomain.

The highlighted security issues could be abused to attack authenticated PayPal users, implementing the mentioned UI Redressing attacks combined with the cookie disclosure bug. But.. I had a problem: I had no XSS vulnerability on any PayPal web application - not that there're not! I was able to circumnavigate the limitation identifying another vulnerability on a different PayPal subdomain, that allowed me to define a monster cookie with a single HTTP request. As first, please note the following URL:

• https://history.paypal.com/helpcenter/script/pphc_rating.js.jsp?locale=&_dyncharset=UTF-8&countrycode=CA&cmd=_AAAAKKKKKKAAAAKKKKKK[..very long string here...]KKKKKKAAAAKKKKKKAAAAKKKKKK&serverInstance=9002&no_strip= 

As detailed in Figure 5, the navigation of the above URL involves the setting of the cookie named navcmd and then a bit of client-side black magic defines two new cookie fields named s_sess and s_pers (Figure 6) that complete the desiderated malformed HTTP request.

Figure 5 - Cookie defined with attacker-controlled input.

Figure 6 - Final monster cookie.

7350PayPwn

 

The exploitation is now trivial. The following are the logical steps implemented by the Proof of Concept exploit:

1. The exploit triggers the victim to open an under pop (Figure 7) web page that generates the monster cookie - with domain=.paypal.com - involving the history.paypal.com application;
2. The https://b.stats.paypal.com is then framed thus inducing the forward of a malformed HTTP request that triggers the disclosure of the Cookie header, containing the PayPal account's session cookies;
   
3. The malicious page allows the victim to play the d&d game with the extraction of the secret session cookies.

Figure 7 - Pop-under page with the navigation of the monster cookie's generation URL.

The attacker now holds the cookies that can be used to perform a Session Hijacking attack against the victim's PayPal account. A working Proof of Concept has been developed and can be download here. The following is a video that illustrates the described attack: