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: Fri, 22 Jul 2011 18:29:31 +0200
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: MustLive <mustlive@...security.com.ua>
Cc: full-disclosure@...ts.grok.org.uk, submissions@...ketstormsecurity.org
Subject: Re: URL Spoofing vulnerability in different
	browsers

Hey MustLive,

I'm not sure if I understood your post correctly, so please correct me
if I'm wrong.
The thing you describe sounds similar to the thing described in the
Browser Security Handbook
(http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication):

"Amusingly, its ghost still haunts modern web applications: HTTP
authentication prompts often come up in browsers when viewing trusted
pages where a minor authentication-requiring sub-resource, such as
<IMG>, is included from a rogue site - but these prompts usually do a
poor job of clearly explaining who is asking for the credentials. This
poses a phishing risk for services, such as blogs or discussion
forums, that allow users to embed external content."

There is also a cross-table there with the behaviors of different
browsers and different methods (somewhat similar to what you have
written).

Is this the same issue/attack-vector? If so, then shouldn't the
Browser Security Handbook be in your reference section, since it's
prior art?
Also, the issues you describe seem to be previously known anyway.

Best regards,
Gynvael


On Fri, Jul 22, 2011 at 5:36 PM, MustLive <mustlive@...security.com.ua> wrote:
>
> Hello list!
>
> I want to warn you about URL Spoofing vulnerability in Mozilla Firefox,
> Internet Explorer, Google Chrome, Opera and other browsers. I found it long
> time ago, at 6th of February 2008, just after finding of built-in CSRF
> vulnerability in Mozilla and Firefox (it's funky CSRF attack via prefetching
> functionality), which I described at my site in March.
>
> -------------------------
> Affected products:
> -------------------------
>
> Vulnerable are all browsers which support Basic/Digest Authentication. It's
> all modern browsers and many from old browsers. In particular affected are
> Mozilla Firefox 3.0.19, 3.5.11, 3.6.8, Firefox 4.0b2 (and Mozilla and all
> other Gecko-based browsers), Internet Explorer 6, 7, 8, Google Chrome
> 1.0.154.48 and Opera 10.62 and previous and next versions of these browsers.
> And other browsers which support Basic/Digest Authentication.
>
> In March, after my informing, Mozilla opened Bug 647010 in Bugzilla
> (https://bugzilla.mozilla.org/show_bug.cgi?id=647010).
>
> Among four browsers developers informed by me only Mozilla said, that they
> are planning to fix this vulnerability (without specifying the time). Google
> even didn't answer me, but in June they informed in their blog
> (http://blog.chromium.org/2011/06/new-chromium-security-features-june.html),
> that they fixed this vulnerability in browsers Chrome 13 (it's now beta
> version) and higher.
>
> ----------
> Details:
> ----------
>
> This is better to call attack, then vulnerability, because it's using
> built-in browsers functionality (and its intended behavior) to attack users
> of web sites. This attack allows to conduct phishing attacks on users of web
> sites - in this case phishing is doing not at other (phishing) sites, not
> with using of holes of target sites (like reflected XSS or persistent XSS),
> but with using of browsers functionality (and allowed functionality of
> target sites to place external content).
>
> I called this attack as Onsite phishing (or Inline phishing). It can be used
> (including by phishers) for stealing of logins and passwords of users of web
> sites.
>
> As I've tested, a lot of different methods (with using of tags and CSS),
> which allow to make cross-site requests, can be used to conduct this attack.
> Except prefetching (in all Gecko-based browsers which support prefetching
> functionality), which doesn't show Authentication window at receiving of 401
> response from web server. The next methods can be used:
>
> Tags img, script, iframe, frame, embed, link (css) - Mozilla, Firefox, IE,
> Google Chrome and Opera.
> Tag object - Internet Explorer, Google Chrome and Opera.
> CSS (inline, in html files, in external css files): such
> as -moz-binding:url - Mozilla and Firefox < 3.0, such as
> background-image:url - in all browsers.
>
> Here are screenshots of the attack in different browsers (in Firefox 3.0.19,
> 3.5.x, 3.6.x. 4.0b2 the dialog window looks almost equally):
>
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Mozilla.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Firefox.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE6.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE7.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20IE8.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Chrome.png
> http://websecurity.com.ua/uploads/2011/03/Attack%20on%20Opera.png
>
> The attack can be made as reflected at target site, as persistent (with
> using of allowed functionality at target site, which allows to put some
> tags, like img tag). The persistent attack is more dangerous (and such type
> of attack is showed on screenshots). And there are millions of web sites
> which allow such user generated content (like img tags) which can lead to
> such persistent attacks.
>
> ------------
> Timeline:
> ------------
>
> 2011.03.26 - announced at my site.
> 2011.03.31 - informed Mozilla, Microsoft, Google and Opera.
> 2011.04.01 - Mozilla answered and opened entry in Bugzilla
> (https://bugzilla.mozilla.org/show_bug.cgi?id=647010).
> 2011.04.01 - Microsoft answered and asked for more details.
> 2011.04.03 - gave additional details for Microsoft. But they ignored to fix,
> like Google and Opera did.
> 2011.06.14 - Google hiddenly and lamerly fixed this hole in Chrome 12 beta
> (and future versions), without answering and thanking me for informing.
> Which is lame behavior and I don't respect companies with such behavior. But
> this Google's step should force other browsers developers to fix this
> vulnerability in their products.
> 2011.07.21 - disclosed at my site.
>
> I mentioned about this vulnerability at my site
> (http://websecurity.com.ua/5038/).
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/



--
gynvael.coldwind//vx

_______________________________________________
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