Google security vulnerabilties stack up
With four in the last week, is Google the next security buffoon?
Customer Success Testimonial: Recovery is Everything
Analysis Google's desktop search application is vulnerable to an exploit that allows a determined attacker to remotely run most programs installed on a victim's machine. The flaw is one of at least four security holes to visit Google this past week, demonstrating that the search king, despite the god-like aura it enjoys for its pleasing software designs, remains a mere mortal in the security cosmos.
While difficult to exploit, the zero-day vulnerability highlights the inherent risks in linking PC software such as Google Desktop with online search and other types of web services. So says Robert Hansen, a security researcher, who has written a detailed demonstration of how the weakness can be abused. Another Google vulnerability exposed this week - which resides in the way Firefox updates Google Toolbar and many other types of add-on software - also demonstrates this risk.
Hansen's demo relies on a man-in-the-middle (MITM) attack. Here's how it works: While web surfing at a cybercafe, a victim using a fully-patched machine running Google Desktop performs a Google search. The MITM agent detects the query and injects two iframes, one linked to a malicious URL and the other that secretly follows the victim's cursor as it moves about on the browser page.
Voila: As the malicious search query loads, the attacker forces Google Desktop to load as well. By dint of the iframe secretly following the mouse, the victim unknowingly clicks on the Google Desktop query, allowing the attacker to run any application that has been indexed by the Google program.
At about the same time Thursday that Hansen was giving pen to his discovery, a separate researcher used an online forum maintained by Hansen to expose a nasty cross-site scripting (XSS) error in Gmail. The problem, which Hacker Webzine describes here, could have allowed an attacker to craft a URL to access or delete a Gmail user's messages. Google fixed this vuln within hours of publication of the post.
A third vulnerability, first reported by the Earl of Grey's blog, resided in a Google feature that allows webmasters to request pages be removed from Google search results. Strange thing. It turns out anybody could traverse up the directory root structure and browse folders at will and sniff out weak database passwords. The Hacker Webzine folks used the weakness to uncover login credentials that were stored in a folder that had been left readable.
The fourth vulnerability affecting Google was part of a larger problem in the way Firefox updates add-on programs made by third parties. Rather than using a protected SSL session to update Google Toolbar and Google Browser Sync, Google opted to use a less-secure, unvalidated method and also chose to install updates without seeking a user's permission. Those decisions made it possible for bad guys to silently install malware that attached itself to Firefox when a victim used a booby-trapped network at a cyber cafe, conference or other public venue. (Google was one of many companies that made third-party extensions that suffered from this flaw. Yahoo!, Ask.com and AOL were among others.)
Google says it takes security seriously. It follows best practices for product design and incident response and melds protections into its development process. The company has already plugged the holes in its Firefox update mechanism and the tool for removing pages. (It also says secondary measures prevented the misuse of the tool, even with the exposure of a password.) The company continues to investigate the Google Desktop vulnerability and didn't immediately have a comment on the Gmail issue. It is unaware of any of the vulnerabilities actually being exploited.
COMMENTS
NoScript Anti-XSS
From http://noscript.net/features#xss :
"While Cross-Site Scripting (XSS) vulnerabilities need to be fixed by the web developers, users can finally do something to protect themselves:
NoScript is the only effective defense available to "web-consumers", waiting for "web-providers" to clean up their mess."
This GMail XSS flaw is just the tip of an iceberg, check http://xssed.org/pagerank
Blue Skies .......... Joust Thinking.
"The only way to get a truly secure product is to design security in from the ground up."
Actually, in the Next Big Thing, insecurity is designed out to get a truly secure product. IT is AI Way.
Security? We don't need no security!
Imagine you're the CEO of a Web 2.0 startup working on the Next Big Thing. Your product is ready for release, but you have the choice of paying a security team a lot of money to spend 3 months kicking the tyres to find (most of) the security holes. You're going to pay the money and hold off aren't you, since security is "Job #1"? Yeah, right!
Users can't see security - except when it gets in the way or (ultimately) when it fails. And first to market trumps other concerns.
Wrapping insecure code with endless layers of sticking-plaster patches doesn't work and only introduces more holes. The only way to get a truly secure product is to design security in from the ground up. But that's tough to do, adds costs, diminishes the user experience and (worst of all) delays development. And that's why we have insecure software and (until something changes fundamentally) always will have.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
