Date: Mon, 28 Jun 2010 22:28:21 +0530
From: Lavakumar Kuppan <lava@...labs.org>
To: Chris Evans <scarybeasts@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Chrome and Safari users open to stealth HTML5
	Application Cache attack

Hi Chris,

Excellent points. Please find my answers inline.

>It's an interesting twist but it does not seem to offer network
>attackers any additional advantage beyond what they can already
>achieve.

The real advantage is in the lifetime of the cache.
If the root resource of www.andlabs.org is cached, the moment the user hits
the refresh button this cache would be cleared.
Because the browser would make a request to the server and for the root page
the response would be a 200.
However a cache created with the Application Cache can survive this and can
till the user explicitly clears the cache.

Having said that, the claim that HTTPS sites can only be compromised using
Application Cache is inaccurate, thanks for pointing it out. I will update
the post to highlight this.

>In terms of your documented attack, the fake login page (step 6) is
>shown over plain HTTP, i.e. the SSL lock icon will be missing. This
>would be the same user experience as if the user were under attack via
>SSLstrip.

That is correct and I had mentioned SSLstrip in the post as well.
The big advantage is that for SSLstrip to work they have to access that site
when on the unsecured network.
Where as with cache poisoning, they only have to open their browsers as even
the request sent for the default home page can be used to create these
malicious caches.
The actual attacks happens when the users are on trusted network and they
are more likely to ignore this as they would feel safe then.

>(FWIW, Chromium resolves this for me. When I type mail<enter> into
the omnibar, it auto-completes to https://mail.google.com/

This happens because you might have typed in 'https://mail.google.com/'
earlier in your browser.
If you only access gmail by typing in gmail.com then Chrome does not
auto-complete to the https equivalent.
At least that has been my experience.

Cheers,
Lava


> On Sun, Jun 27, 2010 at 3:28 PM, Lavakumar Kuppan <lava@...labs.org>
> wrote:
> > Google Chrome and Safari support HTML5 Application Cache.
> > But unlike Firefox and Opera they do not ask for user permission before
> > allowing a site to create an Application Cache.
> > On unsecured networks, attackers could stealthily
> > create malicious Application Caches in the browser of victims for even
> HTTPS
> > sites.
> > It has always been possible to poison the browser cache and compromise
> the
> > victim's account for HTTP based sites.
> > With HTML5 Application Cache, it is possible to poison the cache of even
> > HTTPS sites.
> > Details
> > -
> http://blog.andlabs.org/2010/06/chrome-and-safari-users-open-to-stealth.html
> > I have also released a POC using which both Facebook and Gmail can be
> > compromised.
> > POC - http://www.andlabs.org/tools/imposter/imposter_poc.zip
> > Video - http://www.youtube.com/watch?v=00sKMMyXJsI
> >
> > Cheers,
> > Lava
> > http://www.andlabs.org
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists