WebApp Sec mailing list archives
RE: Universal PDF XSS Remediation (Fix)
From: "Cyrill Brunschwiler" <cyrill.brunschwiler () csnc ch>
Date: Wed, 14 Feb 2007 12:14:40 +0100
Amit, It looks like I failed to state that the propsed filter is thought for applications which really need to protect authenticated session. The filter is not designed to protect any website from Universal PDF XSS. I mean what can you steal on a website which does not require authentication? One could probably steal the color out of the web servers ink tank making the web pages fade away. That's it ;) To be serious, you could abuse a domains trust and spoof login forms, hijack user to foreign web sites or spoof news content which might influence a company's share value. You might achieve that goal by abusing e-mail, newspapers or tv channels as well. Please read on and verify whether the proposed solution is still flawy if you assume that the targeted PDFs require authentication.
amit wrote: Cyrill Brunschwiler wrote:Compass worked out an advanced technical paper which explains the recently identified Adobe Acrobat Plug-in vulnerability.The documenthighlights 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).
As Ivan Ristic correctly recognised, I was especially talking about the following topology: -------- -------------- -------------------- |Client|---(Internet)---|Entry Server|---|Application Server| -------- -------------- -------------------- Please see http://www.owasp.org/index.php/Talk:PDF_Attack_Filter_for_Java_EE, where OWASP states: "Absolutely - fixed", which is simply wrong. (I know I'm guilty as well, because I stated "the definitve solution" and missed to tell I'm talking about protection for authenticated sessions). I suggest pointing out the remaining risk. I agree with Ivan Ristic's suggestions that the X-Forwarded-For header might be used to improve the OWASP suggested solution and forwarding the Client IP (Remote Proxy) to the backend system. But be aware of tied X-Forwarded-For headers and pick the correct IP (not the client1 IP because this one might be forged). E.g. X-Forwarded-For: client1, proxy1, proxy2 However, there are multi-homed environements where the source IP (proxy1) address changes for every request and the internal IP is hidden (client1). Unfortunately, some of our customers cannot afford to block these customers. Thus, IP binding is not a feasible solution. SSL session binding could be an alternative but you know the drawbacks yourself (clients which do not properly support session resume)
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=javascri pt: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).
Thoughts on your sequence: 4,5) It makes no sense to request for cookies when the session was delivered in the URL but you might agree, beeing able to get the jsession from anywhere else (E.g. from the current URL, browser history or proxy log). 1-5) Does it make sense to forge a URL including a stolen session where the attack goal is to steal the already stolen session again? As I allready stated above, the filter is thought to protect sessions which need to be or are already authenticated. I further assumed that the login application hopfully changes the session id to protect from session fixation and does not copy the random token from the old to the new session. I didn't point that out properly. For the explained scenario the filter really should remediated the problem, what the OWASP solution fails.
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?
This is not an issue if the session needs to be authenticated. But I agree, if you want to improve protection for sites which doe not require authentication, then the filter should not accept sessions from the URL. public void do(HttpServletRequest request) { if (request.isRequestedSessionIdFromCookie()) { //session delivered in cookie } }
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/ms g00064.html), and shown to be vulnerable to a similar attack (http://www.webappsec.org/lists/websecurity/archive/2007-01/ms g00065.html).
I missed that somehow but the idea is very similar.
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.
If your's or Rapid7's approach proves to work then this might prove to be a remaining risk. I'm really interested on how to parse for the redirect link in the first server response (could you provide some code). The desription somehow targets towards CSRF.
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.
Oh, it's not that sad, it keeps business interesting :) Thank you for revising the paper. Nonetheless, your described attacks were challenging. Thanks, Cyrill ------------------------------------------------------------------------- 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 --------------------------------------------------------------------------
Current thread:
- Universal PDF XSS Remediation (Fix) Cyrill Brunschwiler (Feb 12)
- Re: Universal PDF XSS Remediation (Fix) Amit Klein (Feb 13)
- RE: Universal PDF XSS Remediation (Fix) Cyrill Brunschwiler (Feb 14)
- Re: Universal PDF XSS Remediation (Fix) Amit Klein (Feb 14)
- Re: Universal PDF XSS Remediation (Fix) Amit Klein (Feb 15)
- Re: Universal PDF XSS Remediation (Fix) Tim Brown (Feb 20)
- RE: Universal PDF XSS Remediation (Fix) Cyrill Brunschwiler (Feb 14)
- Re: Universal PDF XSS Remediation (Fix) Amit Klein (Feb 13)
- Re: Universal PDF XSS Remediation (Fix) Ivan Ristic (Feb 13)
- Message not available
- RE: Universal PDF XSS Remediation (Fix) Cyrill Brunschwiler (Feb 14)