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 12:22:35 -0800
From: "Andrew A" <gluttony@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google / GMail bug, all accounts vulnerable

PS-- Have you managed to get hired in an actual security position yet or are
you running around San Francisco begging for scraps from our tables?

PPS-- Namedropping the head of a project you plagiarized from in your cover
letter is not good policy. Especially in this industry. Its a smaller world
than most, and now you're fucking blackballed buddy. You'll work as desktop
support at FOX forever.

On Dec 12, 2007 12:01 PM, Andrew A <gluttony@...il.com> wrote:

> Actually, the suggested prevention tactic is to create a post variable in
> your form of type "hidden" with a securely generated one-time ticket that an
> attacker would not be able to scrape without performing an xmlhttp call,
> therefore signalling a (real) security problem with the app in question.
> Requiring the user to re-input their login credentials for every database
> write would be absolutely ridiculous from both a design and security
> perspective.
>
> But then again, you must know all this with your extensive experience in
> web app security and development.
>
>
> On Dec 12, 2007 9:31 AM, Kristian Erik Hermansen <kristian.hermansen@...il.com>
> wrote:
>
> > 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 'kiddie 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/
> >
>
>

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ