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 andthe desiderated session cookies. The Apache bug can be abused in a series of attack scenarios such as the following:It should also be noted that the Apache Web Server is often used as aconfiguration. As a result, any session object on any server-side technology, could be attacked with the described vectors.

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.

In the previous post, a new cross-domain extraction method - affecting the latest version of the Mozilla Firefox browser - has been presented. Thewas 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.

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.

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=

Figure 5 - Cookie defined with attacker-controlled input.

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(Figure 3 and Figure 4).As detailed in Figure 5, the navigation of the above URL involves the setting of the cookie namedand thena bit ofdefines two new cookie fields namedand(Figure 6) that complete the desiderated malformed HTTP request.