Archive for the Google Category

On his blog, Wladimir Palant complains about Google providing browser users with a not effective enough way to opt-out from Google Analytics.

Specifically, he doesn't like how the Google Analytics Opt-out Browser Add-on actually allows Google Analytics scripts to load and run, just setting a global variable (

_gaUserPrefs

) in the hosting page which tells the code not to send back data.

This approach is inherently flawed, because the hosting page can easily force Google Analytics to run by simply overwriting the aforementioned

_gaUserPrefs

variable.

Worse, the

_gaUserPrefs

variable is automatically added to every single page you load. Hence, the fact itself you're using this "opt-out" add-on can be easily detected if you keep JavaScript enabled, adding some extra points to your unanonymity score. Something like

if (!!_gaUserPrefs) alert("You hate Google Analytics, don't you?")

can make a nice test to update the Panopticlick suite with, singling out privacy concerned persons.

However, the original sin is that the Google Analytics' script still being downloaded and executed, and if you find this questionable from a security/privacy perspective, then the Google's Analytics Opt-Out Browser Add-on serves no purpose.

Wladimir's post initially advertised his own extension as a better solution, but later he had to retract:

Still, until Google can come up with something better I recommend people to use Adblock Plus with EasyPrivacy filter subscription, that’s the easy and reliable solution (check the update below).

Update: Sorry, that last part wasn’t entirely correct — EasyPrivacy doesn’t block Google Analytics script either, due to many websites being broken without it as mentioned above.

True, if you block Google Analytics' script by using a proxy, a firewall, a host file or Adblock Plus with an ad-hoc filter, many sites are going to break because they depend on JavaScript objects provided by Google Analytics. They integrate GA calls within essential functionality, such as link and button event handlers or even initialization routines, and they fail more or less dramatically when the script is missing. Sad, silly but true.

This is no news (and no problem) at all for NoScript users, though: in fact, almost one year and half ago, this very issue prompted the development of NoScript's Script Surrogates feature, which prevents the breakage by "emulating" the blocked script with dummy replacements. This means that NoScript users have Google Analytics blocked by default, with no site-breaking side effects.

So, until Google can come up with something better I recommend people to use the reliable and easy solution ;)

On April the 1st (!) 2009 I had a phone call with Mickey Kim of Google. The Chromium development team was starting to design a browser extension API, and they wanted to know what kind of hooks were needed for FlashGot and NoScript to be ported on Chrome. I gave them detailed answers with references to related Mozilla technologies, and they promised to keep me updated with progresses.

Eight months later, Chrome extensions are here but NoScript is not among them yet, and people are asking why. The reason is very simple: Chrome is still lacking the required infrastructure for selective script disablement and object blocking.

Maybe Google plans to implement the missing stuff later, maybe they're still trying to figure out whether it can be done without enabling effective ad blocking, but in the meanwhile the pale AdBlock and FlashBlock imitations which have been hacked together by overwhelming popular demand, are forced to use a very fragile CSS-based hiding approach, ridiculously easy to circumvent.

Just install the most popular FlashBlock clone for Chrome and visit this page I put together in 3 minutes to see what I mean...

Update

Sam Hasler came to the rescue:

The top rated FlashBlock clone for Chrome does block your example page.

Of course, it took another 3 minutes to fix "the top rated" as well ;-)

If you can see my Google Talk Badge on the right, either you're browsing with anything else than IE8/Chrome/Safari/Firefox+NoScript, or the issue we're talking about has already been fixed by Google. Edit 7 Dec 2009: the issue has been fixed, so I've removed my badge to prevent a spam flood.

Otherwise, you're getting an error page (hard to read, since it's embedded in a tiny frame) -- or a blank one if you're on Chrome -- because Google is sending down a X-Frame-Options HTTP header with value

SAMEORIGIN

, allowing only pages served from www.google.com to embed this badge.

Now, Google playing the early adopter of bleeding edge security technologies like

X-Frame-Options

or STS, both in its browser and in its web properties, is really great because it speeds up their acceptance hugely, making the whole web safer. But if the service you're offering is based on cross-site frames, you'd better keep them enabled ;-)

On a side note, users can easily disable NoScript's implementation of

X-Frame-Options

, if needed, via about:config preferences: either globally (noscript.frameOptions.enabled) or per-embedding-site (noscript.frameOptions.parentWhitelist). Don't worry, ClearClick will still be watching your back...

Thanks to IE8's touted Clickjacking protection which will work on those pages whose authors decide to adopt the new proprietary X-FRAME-OPTIONS header (now cross-browser), the buzz about this topic has been raising again. Unluckily, Clickjacking (or more precisely, talking about IE8's mitigations, "frame-based UI Redressing") is not well understood enough yet for the "technical" press to spare us some frankly embarrassing articles:

And so on...
Even Heise Security fell in this trap, sigh. The mood of most of these "reports" is, more or less,

Look ma, there's this Clickjacking PoC which works in Chrome and Firefox, but is defeated in IE8, which has Clickjacking ProtectionTM. Did you see? IE is the most secure browser of the pack, OMGROTFLMAO!!!

Now, I know the ones to really blame and bash here are this so called "security firm" looking for (and finding) free advertisement by exploiting the security buzzword of the day, and the "security researcher" Aditya K. Sood. But why did nobody of these journalists and bloggers try to verify Secniche's claims (and orthography)?

Clickjacking is a malicious software form that can seemingly take control of the links that an Internet browser displays for various Web pages. Once that takes place, and once a user tries to lick (sic!) on that link, the user is taken to a site that is unintended. In some cases, the user may be able to recognize this immediately; in other cases, the user may be totally unaware of what took place.Once an infected ad has been loaded into your browser, your clipboard (where you copy and paste text) becomes overwritten with a URL.

A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another functionThe exploit may also take over your browser and visit links without you knowing.

A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers show a set of dummy buttons, then load another page over it in a transparent layer. The user thinks he is clicking the visible buttons, while he/she is actually performing actions on the hidden page.

The hidden page may be an authentic page, and therefore the attackers can trick users into performing actions which the users never intended to do and there is no way of tracing such actions later, as the user was genuinely authenticated on the other page.

Well, by these standards (and grammar and syntax), hereby I disclose my sensational "Clickjacking PoC" which works everywhere, even against IE8 RC1:

Clickjack The Target (http://www.yahoo.com) : (http://evil.hackademix.net)

Even better, mine is just 188 characters long, i.e. 1/3 of the one by Secniche:

<a href="http://yahoo.com"
onclick="location='http://evil.hackademix.net/images/stallowned.jpg';return false"
>Clickjack The Target (http://www.yahoo.com) : (http://evil.hackademix.net)</a>

Unfortunately, like I told Heise guys (who honestly rectified their article):

that's not Clickjacking by any stretch of imagination, and hardly malicious: you just get on a "surprise" destination, but nothing more since it can't do any of the cross-site evils (e.g. bypassing CSRF protection) of the real thing.

Or, quoting Michał Zalewski's answer to Mr. Sood on BugTraq:

1) It is by now well-understood that because of the inherent and broadly depended on properties of HTML, every sufficiently featured browser is and likely will remain susceptible to the behavior known as clickjacking. A more thorough analysis, also covering Chrome, is provided here:

http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)

2) To my best knowledge, the proof of concept provided in your post, where a same-origin <div> follows a mouse pointer, is not a valid demonstration of the issue at hand.

Nor is mine, of course: LickJacking, maybe ;)

Talking about rectifications, Security Watch's apology of Microsoft's take on Clickjacking protection, while defending X-FRAME-OPTIONS against the general skepticism from security experts, emphatically warned twice that "NoScript won't protect you". Larry Seltzer's premise, "JavaScript is not required for the attack" was obviously correct, but unfortunately for him (and fortunately for Firefox users), NoScript doesn't rely on script blocking to defeat the attack. He had apparently never heard about ClearClick, the specific anti-Clickjacking protection provided by NoScript, which is extremely effective even if JavaScript is enabled (or the attack is scriptless). Ironically, ClearClick is also the only available implementation of Michał Zalewski's "favorite solution", which his article even tries to explain.

However, as soon as I managed to tell him about his mistake (after working around the unbelievable suckiness of PCMag's spam filters, which coughed on any sentence of medium complexity and even on the word "google"), Larry demonstrated solid deontology. He honestly admitted to have been misled by an ancient post by RSnake, which actually reported that older NoScript versions could be circumvented by some Clickjacking setups, while more recent (ClearClick enabled) versions are effectively protected. Larry, I did appreciate that, and I'm sorry I couldn't post not even a simple "thanks" as a comment on your Security Watch blog (danx? th3nx? 10x?)

Just googled for Vista TCP Limit on behalf of FlashGot user.
The first 500 results at least are all reported as malicious sites, including the top two, Softpedia and MSFN.
Luckily enough for P2P addicts, Firefox's Safe Browsing -- even if backed by Google's data -- doesn't seem to agree ;)

Update Sat Jan 31 2009 16:32:50 GMT+0100

Looks like it was a more general Google bug, fixed now.

Bad Behavior has blocked 735 access attempts in the last 7 days.