Hacking NoScript

Well, some people have recently asked why I am on some NoScript release notes.. and that's a good question..

I haven't released any details on the hacks against NoScript, since most of them where reported privately to Giorgio..

This is not the exception, I wont release any 0days here, I'll just give the details of the issues that I've reported in the past, and current NoScript users are immune to.

Is important to say, that Giorgio fixes stuff in "hours", (or minutes in some cases), and he has done some crazy stuff, just so NoScript users can be safe, so if you dont use it, go get it.

So, I'll go on chronological order:

v 1.1.6.25
=====================================================================
+ Fix for Sirdarckcat's JS redirection trick

That was.. if a website has an open redirection (like, for example, Google's default open redirection feature), and you have that website as trusted (such as most people I guess they have.. Google).. a embed script on a website, pointing to Google's redirection, will be reported to be "from Google", and it will be loaded and executed.

This was useful for example, to attackers that were not able to make a self contained XSS payload, and they needed to load the script from their website, but since their website was surely not on their victims whitelist, then the attack would be unsuccesfull.

Anyway, by means of this, an attacker could be able to do something like the following PoC: http://www.sirdarckcat.net/hades

There I use another redirection on pages.google.com.

If you use NoScript>=1.1.6.25, this attack will be unsuccesful.

v 1.1.7.6
=====================================================================
+ srv.br "special" TLD (thanks Rodrigo Ristow Branco)
+ Better protection against "setter" based XSS vectors and encoded
"name" payloads (thanks RSnake, Sirdarckcat and Kuza55, see
http://ha.ckers.org/blog/20071104/owning-hackersorg-or-not/ )
+ Improved hidden links management, preserves original body CSS
attributes when possible (thanks mdots)

That was an issue on NoScript XSS payload detection, that I discussed some time ago.

The issue was that NoScript didn't detected setter/getter assignations, and so http://ha.ckers.org/xss.swf?a=1:setter/**/a=eval,setter/**/b=atob,a=b=name

Was able to bypass NoScript filters.

The xss.swf page was removed by RSnake, and (if you have ha.ckers.org as trusted) you will see NoScript XSS detection alert, if you are using NoScript >=1.1.7.6

v 1.1.7.8
=====================================================================
+ JAR uris are forbidden from loading as documents by default, see
http://noscript.net/faq#jar for details
+ Block untrusted XBL (thanks Sirdarckcat for inspiration)
x Various IFrame blocking refinements

Well, I didnt reported that, I just inspired ma1 (and I dont know the details), but.. I guess that means that now -moz-binding XBL are not loaded if they are hosted on an untrusted website.

This is probably related to rsnake's hacking attempt.

v 1.2.2
=====================================================================
x Changed noscript.filterXGetRx default to make single quote removal
happen only after positive injection checks (thanks sirdarckcat for
suggestion)

About that one, it was a bug (not a vulnerability), that removed single quotes from websites, and iframes on some situations.

Actually I discovered this while visiting kuza55's blog, since the little iframe in the top of blogspot blogs include the blog's title, and his blog title has a single quote.. that created some errors.

v 1.6.9.2
=====================================================================
x Fixed Injection Checker checking ASCII 43 as a "plus" sign but not
as a www-form-encoded space (thanks Sirdarckcat for report)
x Google search anti-XSS exception now checks for real TLDs, rather
than short 2nd level domains (thanks Sirdarckcat for report)
+ Refactored unescaping flow, allowing for easier extension
+ Ebay-style unescaping

That's detailed on sla.ckers, here:
http://sla.ckers.org/forum/read.php?12,17238,page=2#msg-22925

I'll quote my message:

Re: Hacking noscript

Posted by: sirdarckcat (IP Logged)

Date: June 16, 2008 04:02AM

Ah! hacking noscript?

thats easy..
[trustedsite.com]

for example.. (eBay has a XSS issue very similar to the one I'm describing (well, actually, a lot of sites, but eBay rocks))

But duuuude!! what's happening?

Well, NoScript thinks, that.. "+" is a plus.. but in reality.. "+" is a space, and so..

var x=''+alert(document.cookie) //a:';

is valid js code! (damn, I'm good, 10 minutes to hack NoScript :D)

Greetz!!

PS. It's a joke, noscript is great :P, and even do I did spent 10 minutes to find the issue, it was because I had this idea for attacking noscript since a couple of months ago, but I didnt tested it till today.


but WAIT!!
thats all?

The hell it isn't!! (anyway, this last attack is not so dangerous, since it requires user interaction [enabling javascript on an untrusted domain])

Let's take a look at NoScript's default anti-xss rules:
^[url]http://[/url]([a-z]+)\.google\.(?:[a-z]{1,3}\.)?[a-z]+/(?:search|custom|\1)\?

That means, well.. that:
[images.google.com]

Will bypass NoScript (because we all trust google =D), but.. wait.. that's for google domains exclusively right?

Well, wrong!! because, well.. 20 bux, we can get a 3 letter domain [www.3character.com]

And so do:

[www.google.xss.com]

Pointing google.xss.com to your router or something.

There's an issue with this last attack.. NoScript does his job, and automatically denies google.xss.com.. anyway, enabling javascript in such domain (social engineering) would allow the attacker to send evil XSS attacks to your router/intranet what-ever.

Anyway, hacking noscript is fun :D

And in any case someone wondered..

[search.ebay.com]

And yeah, that's not triggering noscript alarms :D

Greetz!!

And after all, this is ma1 response (where he uncovered that eBay uses a weird Q encoding, I didn't saw):

Re: Hacking noscript

Posted by: ma1 (IP Logged)

Date: June 16, 2008 09:36AM

FIXED

Now that it's fixed, I'll explain my innuendo to Ebay's "scary and brainless" issue, which reminds me closely last month's Base64 Yahoo one.

Your PoC was

hxxp://search.ebay.com/search/search.dll?_trksid=&satitle=ME+XSS+U&category0=&from=%27%2Balert(document.cookie)%2B%27

and it did not bypass NoScript. I guess you meant to write it in the "mixed plus" form, but this is not.

But here's the truly scary one:

http://search.ebay.com/ME-XSS-U_W0QQfromZQ27Q2balertQ28documentQ2ecookieQ29Q2bQ27

As you can see, ebay uses its own custom "Q-encoding", allowing XSS payloads virtually undetectable to any filter, except NoScript >= 1.6.9.2 ;)

IMPORTANT REQUEST (rules change)
Since as far as I can see NoScript now is actively used by more than 1.5 million users, it would be kind of you if new issues were responsibly disclosed to me before posting them there.
I guarantee to handle them the very same day I read your report and to publish a development build with proper credits, but since one week is probably the minimum user-bearable window for automatic updates on stable releases, a 7 days grace period would be nice as a compromise to avoid an excessively tight update schedule for stable version users.

And PHPIDS now supports Qencoding decripting btw :P

v 1.6.9.8
=====================================================================
x Restored the noscript.forbidData preference to its orginal "true"
default value (thanks Sirdarckcat for reporting an issue in the
about:blank context prevented by this change)

And this one, the latest, is about a way of executing javascript even on untrsuted domains, if you can get your users to click while holding Ctrl.

This are the e-mails:

/(?:Ctrl|Shift)[::click::]/.test(NoScript);
9 messages

---

Eduardo Vela <>	Sat, Jun 21, 2008 at 7:07 AM
To: Giorgio Maone <>
Hi Giorgio! I've found out that NoScript allows javascript code execution on untrusted sites if you make your visitor click Control or Shift, and click on a page. I've mounted a PoC: http://www.sirdarckcat.net/aw.html Hold Control and then click somewhere. The script runs on about:blank context.. so it's not so, so, dangerous, but anyway.. Greetings!! -- Arnold Schwarzenegger - "I have a love interest in every one of my films - a gun."

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:32 AM
To: Eduardo Vela <>
Hi Edoardo! Thanks for the info, it's very interesting. I'm investigating it. Cheers -- Giorgio [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:35 AM
To: Eduardo Vela <>
BTW, shift does not work for me (must still test on a clean profile, though) but ctrl does. [Quoted text hidden]

---

Eduardo Vela <>	Sat, Jun 21, 2008 at 9:36 AM
To: Giorgio Maone <>
Control should open the script on a new tab, and shift on a new window.. maybe popup blocker stuff, or something? [Quoted text hidden] -- Frank Lloyd Wright - "TV is chewing gum for the eyes."

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:38 AM
To: Eduardo Vela <>
Maybe, or Tab Mix Plus. Shift does open a window for me, but it's empty and no script gets executed. [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:56 AM
To: Eduardo Vela <>
Forgot to tell, this is a bug for me (likely a regression), because I've got code in place to prevent exactly this sort of javascript:/data: url openings. Hence expect a fix build in a very short time. Thanks! [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 10:12 AM
To: Eduardo Vela <>
OK, I found the culprit. At a certain point in time I turned the default for the "noscript.forbidData" about:config preference to "false", in order to work-around a Firebug bug. It seemed a relatively innocuous change, considered also that about:blank is not in the default whitelist. Anyway, since the Firebug issue is obsolete and I'm much more worried of this kind of bypass, next build will restore the original "true" default. Thanks again -- Giorgio [Quoted text hidden]

---

Giorgio Maone	Sat, Jun 21, 2008 at 10:34 AM
To: Eduardo Vela
Done :) Please wait for public release of 1.7 (in a week or even earlier) to disclose the details. [Quoted text hidden]

So, that's all, we are on 1.7.1 and this last bug was fixed on 1.6.9.8, so we are all safe =)

Anyway, as it wil be soon explained, just blocking javascript, flash, and other plugins is not enough.. we have a sexy assassin uncaptured ;)

Greetings!!