Re: Universal PDF XSS Remediation (Fix)

[Amit Klein <aksecurity () gmail com>]

Cyrill Brunschwiler wrote:
> Compass worked out an advanced technical paper which explains the
> recently identified Adobe Acrobat Plug-in vulnerability. The document
> highlights the numerous useless remediation trials. Furthermore, you
> will experience why even the Open Web Application Security Project
> (OWASP) proposed solution seldom meets the requested security
> requirements.
>
> The full featured report is prepared for download at... 
> http://www.csnc.ch/ (Anti-PDF-XSS Actions 9. Februar 2007)
>   

Interesting paper. Let's see:

Regarding the "OWASP solution", it states:
"Unfortunately, the client IP address in entry server and proxy 
environments is always the same and therefore an attack during the ten 
seconds timeout is still possible.".
This is only correct for users behind NAT/proxy. And the attacker should 
be behind the same proxy/NAT with the victims. I wouldn't say that this 
"seldom meets the requested security requirements", especially when no 
better solution is around (hold on, I'm getting to that).

Now comes the interesting part:
"Currently it looks like that the only safe way to protect from the 
Universal PDF XSS attack, is to create a secure random token which is 
bound to the client’s session ID and attached to every requested PDF 
document link. [...] The Definitive Solution Explained"

I must disagree here. The proposed solution is flawed. Moreover, the 
approach is flawed. Let's take a quick stab at the proposed solution. 
Here is an attack against it:
1. Attacker (from its own machine, at his/her leisure) goes to 
http://any.whe.re/file.pdf
2. Attacker is redirected to (say) http://any.whe.re/file.pdf?t=12345#X, 
and receives a Set-Cookie: jsessionid=67890
3. Attacker sends a malicious link to the victim: 
http://any.whe.re/file.pdf;jsessionid=67890?t=12345#a=javascript:alert(document.cookie)
4. The victim's browser requests 
http://any.whe.re/file.pdf;jsessionid=67890?t=12345 from the server 
(filter).
5. The filter considers this a legitimate request, because it ties the 
"t" to a session (67890) in which this t was produced. The filter has no 
idea that the session identifier was found in the URL and not in a 
cookie, and the filter has no idea that the session was actually created 
for a different client.

Note that the attack makes use of a J2EE application engine feature - 
its willingness to accept URL session ID (even if the session ID was 
originally provided via a cookie).

OK, that was a trivial attack, and circumventing it within the current 
code is pretty simple - only allow session IDs inside cookies. But in 
the meanwhile we saw an important observation: a secure solution must 
take into account the ability of an attacker to communicate with the 
server and pass to the victim session-specific data. In this respect, I 
find the following statement from the paper questionable:
"In the sample filter code, session handling is based on Cookies but the 
code could easily be rewritten to allow URL rewriting which would 
support clients that reject Cookies as well."
In light of the above attack, it would make life much easier for an 
attacker, and quite hard for the filter - as now the filter can't demand 
that the session ID be presented to it via a cookie. How is the filter 
going to protect itself from that attack?

Moving on to a pure cookie solution. To begin with, such solution was 
already suggested in the past 
(http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00064.html), 
and shown to be vulnerable to a similar attack 
(http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html).
The attacker now needs to work harder. In step 1, he/she got a cookie 
(jsessionid), but in step 2 the session ID cannot be used in the URL. It 
has to be presented to the site inside a Cookie HTTP request header. 
That's where some flash techniques kick in. Flash allows pretty liberal 
manipulation of the HTTP request to an arbitrary site. So an attacker 
can send the victim a Flash link (in the attacker's site), or a simple 
link (to the attacker's site, showing HTML with Flash object). This 
Flash will send out the request to the PDF-hosting server with the 
Cookie header. Using trivial methods such as 
http://www.securityfocus.com/archive/1/441014 doesn't seem to work with 
the Cookie header, but more advanced techniques such as Rapid7's 
http://www.rapid7.com/advisories/R7-0026.jsp and my own 
http://www.securityfocus.com/archive/1/443391 enable crafting a complete 
HTTP request. There's a bit of a complication here, since the forged 
request is the second one - the browser has to be forced to send another 
HTTP request so that the response will match it. But at the end of the 
day, the result is that it's possible to forge requests with Cookie header.
Note: unlike anti-DNS pinning techniques, the Flash tricks don't provide 
access to the response, yet do operate within the target's domain. So 
the XSS vectors are relevant.

We need to understand the sad fact that browser requests can be 
completely forged. Hence, solutions should be demonstrated to resist 
attacks that forge complete requests.

Thanks,
-Amit


-------------------------------------------------------------------------
Sponsored by: Watchfire

As web applications become increasingly complex, tremendous amounts of 
sensitive data - personal, medical and financial - are exchanged, and 
stored. Consumers expect and demand security for this information. This 
whitepaper examines a few vulnerability detection methods - specifically 
comparing and contrasting manual penetration testing with automated 
scanning tools. Download "Automated Scanning or Manual Penetration 
Testing?" today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fH6
--------------------------------------------------------------------------