Re: URL Spoofing vulnerability in different browsers

[James Voss <james.voss () northwestdedicated com>]

Lol, okay

-- 
Regards,

James Voss <james.voss () northwestdedicated com>
LinkedIn: http://www.linkedin.com/in/jameswvoss
312-000-0000 - Direct
847-000-0000 - Fax

PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary, confidential
and/or privileged information. If you are not the intended recipient, any
use, copying, disclosure, dissemination or distribution is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all
copies.

On Fri, Jul 22, 2011 at 4:15 PM, Chris Truncer <
CTruncer () christophertruncer com> wrote:

> Just ignore Mustlive. The rest of the list does.
>
>
>
> On Jul 22, 2011, at 4:08 PM, Chris Evans <scarybeasts () gmail com> wrote:
>
> > On Fri, Jul 22, 2011 at 8:36 AM, MustLive <mustlive () websecurity 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.
> >
> > FWIW -- no, Chrome Security Team does not operate that way, and you
> > should be well aware of that!
> >
> > In case you weren't, please check out the Hall of Fame:
> > http://dev.chromium.org/Home/chromium-security/hall-of-fame
> > As can be seen, we have a long record of working with a variety of
> > excellent researchers, including paying rewards and issuing credit in
> > multiple places.
> >
> > I don't even know what bug you're talking about because you mention a
> > Chrome 13 security features blog post and then (directly above) you're
> > saying we fixed something in Chrome 12.
> >
> > If you provide the Chromium bug URL that you reported this to, I'd be
> > happy to investigate what happened and whether you should be added to
> > any credit page.
> >
> >
> > Cheers
> > Chris
> >
> > > 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/
> >
> > _______________________________________________
> > 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/