Archive for the Google Category

Not a great month for Google security.
In the past 3 days, 34 interesting disclosures have been published:

  1. Google Search Appliance XSS discovered by MustLive, affecting almost 200,000 paying customers of the outsourced search engine and their users: this Google dork shown 196,000 results at the time of disclosure, now dropped to 188,000. Fear effect?
  2. Billy Rios and Nate McFeters revealed the gory details of their already announced Picasa exploit, leveraging a clever combo of XSS, Cross Application Request Forgery, Flash same domain policy elusion and URI handler weakness exploitation to steal your private pictures, straight from your local hard disk, just visiting a malicious web page.
  3. Finally, the most simple yet impressive, because of the huge number of users involved: beford decided to launch his new blog disclosing a Google Polls XSS which, thanks to the (too) smart "widget reuse" allowing Google services to integrate the same functionality across multiple services, can be used to attack Search, Blogspot, Groups and, the most dramatic exploitation scenario, GMail:

    For such an attack to be successful, the victim just needs to visit a malicious website while logged in Google, e.g. by following a link from an incoming message (unless she's got anti-XSS protection).

  4. update -- a few hours after I released the first version of article, I heard of another Google-outsourced vulnerability, an Urchin Login XSS disclosed by GNUCITIZEN's Adrian Pastor, which could compromise local Google Analytics installations. Its severity may vary depending on how Urchin is installed (e.g. on a domain different than your main site), but the provided proof of concept is quite interesting because it shows an actual credential theft in action, rather than the usual, boring
    alert('XSS')

    . Not that a more spectacular example proves anything new about the dangers of XSS, but some people just don't believe until they can see with their own eyes.

These vulnerabilities are surely being fixed at top speed, since Google is one of the most reactive organizations in this fight, but they're nonetheless disturbing because they hit the very main player on the field, with the largest user base on the web: this make this kind of incidents unavoidable ipso facto.
How many vulnerabilities like those just go undisclosed and unpatched, but yet exploited by unethical hacrackers?
In Gareth Heyes' words,

This proves everything is insecure, there are just degrees of insecurity.

Talking about XSS, if you're an end user and you don't like to stay at the very bottom of the insecurity food chain, you'd better use Firefox with NoScript -- but that's your choice, of course. ;)

I've just read on RSnake's blog that MustLive, a very active the Ukrainian researcher, disclosed yet another XSS vulnerability affecting the Google Search Appliance.

The Google Search Appliance starts at $30,000, whereas the Mini starts at $1,995.

This means that about 196.000 web sites, many of them belonging to very important Universities and other public bodies, are willing to pay for putting their data and their users at risk.

Last time I checked, putting up a self-hosted search engine was not a terribly hard task, no matter if you prefer Java, PHP or just plain CGI.
When you discover your own web site is broken, do you really want to depend on someone else for a fix?

Today RSnake revealed a cross site scripting vulnerability affecting Google Gadgets in the gmodules.com domain.
This XSS hole allows anybody to store his/her own web content, including JavaScript code, anywhere and to have it rendered and executed in the context of the gmodules.com domain, with no further validation of sort.
RSnake responsibly reported his finding to Google before resorting to public disclosure, but the G guys answered that this behavior is "by design" and won't be fixed.

What does it mean?
(more...)

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