Re: Universal PDF XSS Remediation (Fix)

[Amit Klein <aksecurity () gmail com>]

Hi Cyril

See my comments below,
-Amit



On 2/14/07, *Cyrill Brunschwiler* <cyrill.brunschwiler () csnc ch 
<mailto:cyrill.brunschwiler () csnc ch>> wrote:

   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.



This is a weird argument. So by having other alternatives to achieving 
an attack goal, it renders the attack meaningless? by the same argument 
then, we don't need to fix the PDF UXSS in the first place, because 
maybe there are already XSS issues in the affected web sites to begin 
with. Hmmmmmm...

   Please read on and verify whether the proposed solution is still
   flawy if
   you assume that the targeted PDFs require authentication. 



Again, I simply can't assume that. XSS may mean tons of things beyond 
session hijacking. But for the sake of the exercise, I'll bear with you 
(pardon my "pun from the future") on this.


    > amit wrote:
    >
    > 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).

   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).



As we'll see below, your solution doesn't protect against XSS in 
authenticated sessions. In fact, it doesn't even protect the session 
identifier 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).



If that's your main worry, then I'll have you know that modern entry 
servers usually have a secure way of transmitting the client IP address 
to the web server, e.g. in a proprietary header which they make sure to 
erase (if such header exists) prior to providing it to the server.


    > 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
   <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



Apparently you're missing the point.  The *real* session ID was 
delivered to the client (victim) inside a cookie. Yet due to J2EE 
"standard", the session ID can be sent in the URL. Which is what this 
attack exploits. So the document.cookie will still contain the original 
session ID.

   but you might agree, beeing able to get the jsession from
   anywhere else (E.g. from the current URL, browser history or proxy log).



Again, the jsessionid of interest IS IN THE COOKIE. The one in the URL 
is crafted by the attacker. At any rate, I don't understand your argument.


   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?



See above - the jsessionid of interest is in the cookie.


   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. 



Not so fast ;-)


    >
    > 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. 



Not so. Indeed, if the session ID is maintained in the URL, then our 
XSSed page belongs to a different session, yet it's on the same domain 
with other windows that may be in the original session context, thus 
getting a handle to those windows, and extracting the 
document.location.href may provide the real session ID.


   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
       }
   }



That's right.


    >
    > 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
   <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 



Huh? I don't follow. What redirect? if you refer to *your* algorithm, 
then may I remind you that no redirection is to occur, since the request 
contains a cookie and a matching "t" value.

Over to you,
-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
--------------------------------------------------------------------------