Posted by theharmonyguy in Google | 2 comments

Cross-Gadget Security in Google Wave

While examining the behavior of gadgets in Google Wave, I noticed another potential security problem in addition to the ones I’d already listed. Each gadget is loaded in a container iframe with a domain separate from the main page, preventing access to the DOM of the Wave interface itself.

However, I also noticed that the container iframes for all of the gadgets I tested used the same domain. That allows one gadget to access the DOM of another gadget. Pictured below is a test gadget that generates an alert displaying the HTML source of the first gadget in the wave, in this case a Yes/No/Maybe gadget from Google.

A test gadget accessing the DOM of another gadget in Google Wave.

What’s the danger in this sort of cross-gadget access? Consider that people have already created gadgets for accessing your Facebook and Twitter via gadgets. Granted, most of those gadgets have used iframes which load other sites, and thus cross-domain rules would prevent any data breaches. Also, one Twitter gadget I tried actually loaded using its own container URI instead of the standard Google server. But as developers continue to publish more powerful gadgets, cross-gadget access poses some serious risks for CSRF and data theft.

Posted by theharmonyguy in Google | 5 comments

Google Wave as a Tool for Hacking

Many security researchers are familiar with BeEF, a browser exploitation framework by Wade Alcorn. In short, BeEF is a program that brings together various types of code for taking advantage of known vulnerabilities in web browsers. If a target computer loads a certain bit of code within a web page, that code connects to a server control panel which can then execute certain attacks against the “zombie” machine.

After noting potential security issues with the gadgets in Google Wave, I set about to finally setup a BeEF testbed and see if Google Wave was as capable a platform for malware delivery as I suspected.

Example of a BeEF zombie spawned via Google Wave

The picture above shows the results. I successfully created a Google Wave gadget that creates a new BeEF zombie whenever someone views the wave. This does not allow for the keylogger function of BeEF, but I did send an alert dialog (as shown) and used the Chrome DoS function to crash the browser tab. (I could also detect that the zombie machine had Flash installed – imagine the possibilities of using Flash or PDF exploits in an auto-loaded gadget.)

What’s even more disconcerting is that BeEF can integrate with Metasploit to potentially take over a victim’s machine. I do not currently have Metasploit setup to test using Autopwn, but based on my experiences so far, I’m fairly confident such an attack would succeed.

All of these demonstrations about security and Google Wave point to four general weaknesses in Wave’s current structure:

1. Allowing scripts and iframes in gadgets with no limits apart from sandboxing
2. Lack of control over what content or users can be added to a wave
3. No simple mechanism for verifying gadget sources or features
4. Automatically loading gadgets when a wave is viewed

Any one of these issues would be cause for concern, but taken together they present such alarming possibilities as a user getting their computer hacked simply by viewing a wave. Whatever may be said about Google Wave’s usefulness, I have to conclude that the product is not ready for prime time until these types of problems are addressed.

Posted by theharmonyguy in Google | 2 comments

Have You Seen the New Facebook Gadget for Google Wave?

The above screenshot shows an actual gadget inside a Wave that I created to demonstrate it. Imagine the possibilities of connecting Facebook with Google Wave. You could post information to your Facebook profile right from within Wave, or connect wave participants to Facebook profiles. If you came across this gadget in a wave you were viewing, wouldn’t you love to at least try it out?

There’s just one problem. The above gadget is fake. Not the screenshot, mind you – if you’re a Google Wave user, you can see the gadget in action by inserting the gadget https://theharmonyguy.com/facebook.xml into a wave. But nothing will happen when you try to connect.

And in this case, truly nothing will happen, since I’ve designed the gadget to be harmless – your login information is not sent anywhere. But I imagine many users would fall prey to such a trick, which could be easily adapted for phishing attacks. Ask yourself honestly, would you have tried to login? More importantly, if you came across such a gadget in a wave, how would you know whether it came from theharmonyguy.com, facebook.com, or a malicious host?

I post all this to raise a broader point than simply “beware of phishing attacks.” I realize that the balance between security and usability is a constant struggle for developers, or at least should be. Yet I’m somewhat concerned by the patterns we are training users to be accustomed to.

Case in point: chromeless gadgets within a wave that provide no indication of source. In some ways I almost feel that Google Wave is recreating the web browser. Browsers are applications that can load any sort of web page. Google Wave is an application that can load all sorts of web pages within waves. Yet many of the features developed for browsers to warn a user of insecure sites or phishing attacks (even as basic as the address bar, which shows the current domain) are not replicated when a user loads a gadget in Wave. Many have described Wave as a reinvention of e-mail. Reinventing a technology can be very beneficial, but let’s not forget lessons learned in the old technology – there’s a reason most e-mail clients don’t allow iframes and JavaScript, for instance.

I’m certainly not the first to raise these concerns; others have previously mentioned the danger of login forms on iGoogle gadgets. Nor am I saying that I don’t want Google Wave to succeed. But if we’re going to reinvent a technology, let’s address some of these basic issues of user expectations and security precautions from the start.

Posted by theharmonyguy in Google | 6 comments

First Impressions on Security in Google Wave

Nearly two years ago, many technology sites brimmed with hype over a new Google technology called OpenSocial. Bloggers questioned if OpenSocial would spell the end of Facebook. Amid all the discussion, I felt that many people were ignoring several serious issues regarding how OpenSocial would handle user data, privacy, and security. A few people brought up questions on this topic, but until an actual implementation hit the market, no one seemed completely sure how OpenSocial would work in practice.

When I heard that Plaxo had brought an OpenSocial framework online, I decided to check out its security for myself. That led to the first hack of an OpenSocial application, and my white-hat hacking hobby began. Admittedly, the “hack” came from poor coding practices on RockYou’s part, but highlighted the need for better authentication in OpenSocial, a problem corrected in later revisions. Still, the event was an inspiration, and led me to continue investigating my previous hacks of Facebook applications, which led to the more serious issues in this year’s FAXX hacks.

Memories of two years ago came back to mind yesterday when I received a Google Wave invite from a friend. Wave has received its share of hype, despite not being publicly available, though lately it’s drawn increasing criticism. Yet I’ve not seen many people explore the security or privacy implications of using the new platform. I decided to take advantage of the invite and start hacking Wave.

What I find was rather surprising, though not entirely unexpected. I’ve noticed several issues with the current version that could be exploited or create more serious problems in the future. Some will argue that bugs should be expected in early versions of a new product, and that future upgrades will improve the situation.  However, I would contend that some of the points raised here deal with basic aspects that should have been addressed from the very beginning. I would also add that I think Google overlooked an opportunity to add more social networking components to their system that could allow them to offer a stronger alternative to Facebook.

Anyway, here are a few of the problems with Google Wave I’ve noticed so far that I’ve not seen on several other lists of Wave criticisms:

• Allowing iframes in waves. Creating a gadget that loads an iframe is a fairly trivial task. The iframe loads within a container iframe that separates it from the DOM for Wave itself. Still, one can load just about any page using such an iframe. This means that any attack requiring a user to load an infected page, such as my original demonstration of a FAXX hack, can be automated, since viewing the wave loads the iframe page. This can also be easily adapted to make POST requests for CSRF attacks.
• Allowing invisible iframes in waves. Not only can a gadget include an iframe, it can style that iframe to be invisible, either hiding the attack from wave participants or to create a clickjacking attack within the gadget. Basically, while gadgets load in container iframes, they otherwise have free reign to include any HTML a coder desires. Note that allowing iframes could potentially let an attacker include code for finding browser exploits, which can then allow for malware delivery or even taking over a user’s system.
• Allowing scripts in waves. Once again, the scripts execute in a container iframe, so one cannot simply wreak havoc with the main application DOM. But scripts do open up several possibilities. In fact, I’ve already created a wave that forwards users to a particular page as soon as they view the wave, since the script is loaded automatically when someone views the wave.
• Allowing dynamic changes to gadgets. Google may argue that this problem is actually a feature. Essentially, a gadget is loaded dynamically from its source every time a wave is loaded. That means someone could insert an innocent-looking gadget into a wave, then the gadget owner could switch the gadget for a malicious one later on. In fact, since gadgets can be hosted anywhere, an included gadget could even be taken offline, taking away from one of Wave’s selling points (better preserving a record of communications).
• Allowing gadget access to participant information. Currently, a gadget can only access basic identifying information about who participates in a wave and who is viewing the wave when the gadget loads. However, one can already note several indications that Google will likely expand this functionality to resemble a more complete OpenSocial implementation. As with Facebook applications, allowing such unfettered access for any gadget on initialization raises a number of concerns.
• Not allowing users to be removed from a wave. I realize that since waves are shared among participants, removing users raises questions of who in the wave is authorized to make such decisions. Still, I find it a glaring oversight that the product includes no mechanism for removing a user whatsoever, especially considering that anyone can join a public wave.
• Allowing users to add anyone to a wave without approval. If I know the Google account you use for Wave, I can add you as a contact and add you to a wave, which will then appear in your inbox. This all happens without any action on your part. And if I include a malicious gadget, you will load that gadget as soon as you click on the new wave to find out what it’s about.

Once again, many will argue that Google will eventually address these problems, and I certainly hope they do. But I find such oversights of basic security issues rather disconcerting. And while sites such as iGoogle have included “gadgets” with scripts for some time, Wave adds a new dimension in that such gadgets can be loaded with hardly any user interaction or approval.

One possible solution that people will raise is that Google can shut down accounts of known attackers or spammers, ensuring that each Wave user corresponds to a real person who will abide by certain rules, as Facebook has sought to do. But doesn’t this turn Google Wave into exactly the same kind of closed garden which Facebook’s critics have lambasted so often? Yet if Google is not the gatekeeper and opens up the system to users with Google accounts, what has Wave done to address spam and malicious attacks? In fact, as expounded above, if Wave is open to anyone, it provides a powerful new means for delivering malware and exploiting vulnerable users.

Again, I realize that Wave will probably include more privacy controls, such as who can add you to a wave without your permission. But if Google is not building such controls into the product to start with, how effective will they be when they do finally appear?

Posted by theharmonyguy in Facebook | 8 comments

The Dangers of Clickjacking with Facebook

Clickjacking is an admittedly difficult problem to solve entirely, though I question why invisible iframes are necessary. Still, a few techniques to combat the attack exist, such as frame-busting scripts. Twitter implemented this approach after a proof-of-concept attack circulated earlier this year, at the time, several researchers speculated on the ramifications for other sites, such as Facebook.

I’ve noted previously that authorizing a Facebook application requires only a single click, even if you’ve exempted your profile from the Facebook Platform. After noticing another possible clickjacking attack vector, I began compiling a list of single-click actions that should give any Facebook user pause. All of the following actions can be mistakenly performed by a user simply clicking a link or button on an innocent-looking page via clickjacking:

• Authorize a malicious application. This can happen regardless of any privacy settings. On authorization, an application can immediately access your profile information, your photos, your posted links, your notes, your status updates, etc. It can also send notifications to your profile, send notifications to other people (anonymously or from you), and post feed stories to your wall, all with links included. Note that under default privacy settings, an application can access most of your data if a friend of yours falls prey to this type of attack.
• Authorize a legitimate application with a cross-site scripting exploit. Most applications vulnerable to such an attack allow for clickjacking installs, where a single click authorizes the application and then forwards a user to an infected application page. That landing page can then execute any of the actions listed above for a malicious application. Note that if a friend falls for this attack and you have authorized the application, all of your data is vulnerable as well.
• Post a link to your profile. This is possible by applying clickjacking to several Facebook pages used for sharing content. A custom title and description can be set for the link. Other content, such as a Flash video, can also be posted this way.
• Publish a feed story from a malicious application. Note that this can work regardless of whether you have authorized the application. Applications may publish feed stories prior without authorization by a single click, though this does not grant them access to a user’s data. The feed story may include images, descriptive text, and links. The application can also pre-populate the user’s comments on the story, which would then be submitted upon execution of the clickjacking attack.
• Send a message to another user. The recipient, subject, and message content, including links, can all be pre-populated. This no longer gives the recipient more access to data than usual, but could still be easily used to spread malware.
• Send a friend request to another user. This means that a victim could unknowingly send a friend request to a malicious attacker’s profile, and the attacker would simply need to approve the request to gain access to everything on a user’s profile that their friends can access by default.
• Harvest a user’s post_form_id. Those familiar with Facebook’s code will realize how serious this issue is. However, exploiting a post_form_id also requires knowing a user’s Facebook ID, and so far this attack does not provide the latter.

This list is not simply theoretical – I did some simple testing to make sure that each of these attacks worked. I also would not pretend that my list is exhaustive, and I would welcome any additions from other researchers.

Most of these are already known or fairly trivial to figure out. I am not aware of anyone reporting my method for the last attack, however, and I will be reporting the details of it to Facebook, as I believe it involves a code issue that can be patched apart from any clickjacking protection. Update: Facebook pushed a fix last night which I’ve confirmed. The hole came from a dialog page that one could load via a POST request. Outside its normal context, clicking the submit button on the page would forward a user back to the referring page but with the post_form_id appended.

I hope this list will help raise awareness of the potential dangers of clickjacking. Creating a Facebook version of Twitter’s “don’t click” worm would be fairly simple, and as this list indicates, one could do far more than simply post a link in the process.