lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2007 13:05:35 -0500 (EST)
From: "Steven Adair" <steven@...urityzone.org>
To: "Kristian Erik Hermansen" <kristian.hermansen@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Google / GMail bug, all accounts vulnerable

A few question and notes:

I guess I am not understanding why this is considered to be a big CSRF
issue.  You aren't really able to take action on Google's site per the
real definition of CSRF.  What you have is a page once request, will
destroy certain Cookies - regardless of how it was requested.  This is an
issue with the page itself.  Right now that's all you can do as this is
just how the logout page behaves.  You cannot send/delete e-mail or take
any real actions can you?

As a result with pages that just automatically do this, you can accomplish
the same thing by simply doing <img
src="http://mail.google.com/mail/?logout">, by creating a meta-refresh to
it, or by doing a 301 redirect to it on anything you put in your own page
- to include the favicon.ico.  I guess I see some what of what is being
said about favicon.ico being requested so many times.  I did not verify
this but I will take your word for it.  It could be quite annoying I
suppose if you left the page open and kept trying to login.

However, when we start talking about injecting stuff..what do you mean by
injecting?  Do you consider doing a redirect injecting?  Let's keep in
mind that these redirects keep the HTTP referer field in tact.  So when
you start doing a 301 redirect from favicon.ico to something excplicit on
YouTube -- your website is going to be in their access_log as the referer.
 Not exactly stealthy unless you have some alternative method of doing
this.  If you do I will look forward to the advisory information.

Steven
http://www.securityzone.org


> On Dec 12, 2007 3:20 AM, ad@...poverflow.com <ad@...poverflow.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> ridiculous advisories are generating ridiculous replies that's well
>> known and you figured it out.
>
> The data is all there.  So, the trick is how to utilize CSRF to
> influence a large number of users to make requests which disrupt,
> taint, or modify their accounts on popular services.  In the example,
> I point the favicon.ico object as a 301 redirect to a GMail URI.
> Since the favicon.ico object, for some reason, influences the account
> even without revisiting the website again, the GMail account is again
> influenced any time you click a tab.  It is an interesting finding,
> and not one that I have heard ever publicly stated.  Correct me if I
> am wrong here, but why would the favicon.ico object be requested every
> time you merely click on a tab?  And does this only happen in FF, or
> IE as well?   What other browser's exhibit this behavior and/or is it
> supposed to be this way?
>
> However, in addition to all this, CSRF is getting to be more
> dangerous.  Major sites are not protecting against a wide range of
> attacks.  The suggested prevention tactic is to ask for a password
> upon any account modifications.  However, this does not always seem to
> be implemented.  Too, many requests can cause distress to a user which
> do not necessarily modify their accounts.  For instance, it is
> possible to taint the credibility of a remote user as well.  Say you
> could inject searches on Youtube for 'k----- porn', or make Google
> requests for 'how to murder your wife'.  All of these are possible
> attacks, frightening, and how would they be prevented?  This is
> becoming a large issue, and why I wrote up the PoC for the specific
> Google / GMail case.  It is possible that these type of attacks could
> perhaps be used to incriminate someone in court based on secondary
> evidence, if they were suspected of say, murdering their wife.  The
> user's search history on Google have been subpoenaed before, and
> injecting requests into someone's search history is frightening and
> definitely needs to be addressed, don't you think?  The worst part
> about all of this is that there doesn't seem to be a viable solution
> at the moment, which is why everyone should start thinking about the
> problems now.  There are some great papers which describe a few
> methods, but one demonstrating the implications is still missing...
> --
> Kristian Erik Hermansen
> "I have no special talent. I am only passionately curious."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ