Millions of people trust Google with their personal data every day. While we'd all like to assume that our information is safe, the fact of the matter is that even Google is not hack-proof. All technology is prone to mechanical and human errors that can leave security holes open for exploit, and Google is no exception.
Fortunately, nothing catastrophic has happened yet, but that's not to say that Google hasn't experienced any bumps along the way. Here are 6 of the most famous Google crack jobs, both real and imagined.
In October 2006, a mysterious post about Google's Click-to-Call project appeared on the official Google blog. This post reported that Google made a decision to cancel a joint project with eBay because it would be "a monopolistic approach that would damage small companies in the CRM area."
Shortly after being published, the fake post was taken down. Karen Wickre, of the Google Blog team, wrote a response to address the issue in "About that fake post". Wickre notes that a Blogger "bug," also known as a security problem, was to blame for enabling the unauthorized post. She reported that the bug was fixed, but did not offer any other details about the breach.
Ironically, the fake click-to-call post comes after a real one discussing Google security. In the post, titled "Our security stance," Google Security Team representative Heather Adkins describes Google's commitment to security, noting that they "keep the bad guys out of our systems." Adkins surreptitiously tips her hat to hackers, noting that Google security depends on the community, from users to "external security enthusiasts who keep us on our toes." Search engine experts believe the attack was made to "thumb Google's nose" and show that they are not as secure as they'd like to believe.
A user-side breach of security occurred on AdWords accounts in April 2007. Somehow, a malicious file was installed on users' systems. This file was used to steal the users' AdWords passwords and gain access to their accounts. The program then set up ads that changed the users' AdWords campaigns. Most notably, the changes included setting up links that would install a post logger, a type of malware, on the computer of anyone who clicked the link. The malicious program also modified credit card information and prevented the users' computers from accessing AdWords to see all of the changes on their accounts.
Roger Thompson of Exploit Prevention Labs points out that the hackers took advantage of the lack of a URL preview on Google's sponsored results. Meaning, if users hover over a sponsored result link, a preview of the address is not shown in the user's browser. See Thompson's screen shot for an visual explanation. A lack of this feature means that users have no idea where the links will actually take them, leaving them vulnerable to visiting Web sites with malicious code.
Google responded to the attack by reporting that they had canceled the accounts that were compromised and assured users that they were taking the steps necessary to keep something like this from happening again. Google also encouraged users to keep their computer's security up to date as the vulnerability was only successful because victims had not incorporated recent patches into their Internet Explorer browsers.
In March 2006, a Digg user claimed that his friend hacked the official Google blog. The "hacker" left a post on a blog at Google's address. The post explains how he was able to gain access: the Google blog would not come up, so the poster attempted to register the name and it worked. Of course, on Digg, he claims to have figured out the password. These two stories do not correlate, but to determine how they match up would be irrelevant, considering that the post did not constitute a real hack. Jason Goldman, Google's Blogger Product Manager, posted "And we're back," explaining that Google had accidentally deleted their own blog. D'oh! This left it open to be claimed by the poster. He clarifies that the unauthorized post "was not a hack, and nobody guessed [Google's] password."
Unfortunately, Google did not learn anything from this experience. In April 2007, a post on the Google Mac blog suggests that it, too, was taken over in the same way. Poster "Vishal" writes, "Yo! This is crazy…I tried to register this and I could!" The post was deleted and things are again back to normal for the Google Mac blog. So far, Google has not acknowledged or offered an explanation for this post, but it seems safe to assume that the Google Mac blog was accidentally deleted, and thus left open to registration by the general public. Again.
Imagine this: a hacker sets up a Web site with script designed to steal your google.com cookies. Then, they submit this Web site to Digg or Slashdot under the premise that it's a hot story. Any person who visits that site with active google.com cookies could end up with compromised cookie information, allowing the hacker access to their Gmail, search history, documents and more. It's a frightening story, and one that could have happened had a white hat hacker not discovered the security hole first.
Tony Ruscoe of Google Blogoscoped discovered a vulnerability in Blogger's custom domain service. This vulnerability, he noticed, left users open to cookie security problems. He realized that if someone were to enter a Google subdomain as their Blogger custom domain, it would work as long as Google hadn't already set up a blog at that particular address. Here's the kicker: using the Google subdomain would allow the owner of the Web site to read and write google.com cookies. Yes, the cookies that hold personal information, including passwords.
Google Security quickly wiped out Tony's proof of concept page and redirected erroneous subdomains to a "blog not found" page. As a result, presumably, Blogger no longer allows any Google domains to be entered in Blogger's custom domain function. Hopefully Google has thanked this white hat hacker for exposing this vulnerability before it got into the wrong hands and enabled a serious breach of user privacy. The results of this hole could have been catastrophic.
Because this vulnerability was exposed with Gmail in beta, Google did not have to report it. However, numerous blogs picked up the story, as well as Digg and Slashdot. Google fixed the problem about 30 hours after being notified. Perhaps security issues like this are the reason why Gmail is still in beta.
In May 2005, users who visited Google Search came upon an unexpected surprise: it wasn't there. To top this disheartening experience off, there were quite a few reports of a website, SoGoSearch, showing up instead. Not surprisingly, the blogosphere reacted, initially reporting that Google's domain was hijacked. As the story unfolded, it became apparent that Google was not hacked. Rather, they were experiencing problems with their DNS. As for the SoGoSearch Web site, experts explain that browsers redirected to it when they were unable to find google.com. SoGoSearch has the domain name google.com.net.
Another faux-hack involves Google SEO guru Matt Cutts. Google likes to have its April Fool's Day fun, and Matt Cutts is no exception. For April Fool's Day, Matt hacked his own blog. Quite a few blogs picked up the story (or played along), reporting that Matt's personal blog was hacked, displaying screen shots of a page blacked out, full of hacker shout-outs and a Dark SEO image that proclaimed, "nous sommes le proprietaire de toi" (We're the owners of you). Matt later responded to the backlash, detailing the fake hack and how he came up with the idea to do it. It turns out that his wife cooked up the page by studying screen shots of hacked sites. He even laid the groundwork for the prank by writing a post in which he said his site was having problems and that he'd be away from the computer for a while. And then he fooled quite a few people into believing his site was really hacked.
In the 1980s and 1990s, business applications and data were largely confined within and protected by a Local Area Network (LAN). The 2000s introduced a significant change. Download this white paper now to learn why the shift to the cloud is changing how companies think about and manage their IT infrastructure. more
Microsoft moved to the cloud in 2014, and, as a result, Office 365 is taking off. Now, Okta customers are connecting to Office 365 in increasing numbers. This eGuide explains why IT departments should plan and deploy solutions around identity and mobility management in concert with their Office 365 roll out to get maximum user adoption. more
For most companies, Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) play a central role in coordinating identity and access management policies. When on-premise applications are integrated to Active Directory or LDAP, users get the best possible experience. That's why Okta's cloud-based identity and access management service provides a highly useful single integration point. more
With more and more businesses adopting Software-as-a-Service (SaaS) applications, enterprise IT is fundamentally changing. This whitepaper presents the eight biggest Identity and Access Management (IAM) challenges associated with adopting and deploying cloud and SaaS applications, and discusses best practices for addressing each of them. more