Your Facebook Profile is Already Public

As Facebook’s privacy settings continue to evolve, many have discussed the increased openness as users gain more options to share content publicly.  All the while, though, ongoing problems with the Facebook Platform detract from the perceived level of control over privacy.

In essence, you should already think of your profile information as public.  First, any application you authorize has carte blanche access to your data.  You have no way to limit this access apart from avoiding authorization to start with.  Second, if a friend authorizes an application, that application likely has the same amount of access to your profile via your friends’ sessions.  You can limit the available data if you have not also authorized the application.

Finally, the current architecture of the Platform leaves users vulnerable to attacks that allow others to harvest profile information.  I have demonstrated such attacks before, and the more I investigate them, the more ridiculous the situation becomes.

This morning I found yet another XSS hole in a top 10 Facebook application (by monthly active users).  However, this was another FBML application, and as with several other cases, I could not immediately replicate my old XSS+CSRF attack for stealing profile data.  With a bit of experimenting, though, I realized another trick.  Rather than trying to insert script directly, I took a slightly different approach for executing this script.  This new technique ensured script execution, at the price of easy access to the session secret.  Using referrers, though, I gained access to the session secret as well.  This does require a user to have referrers enabled for JavaScript, but I’m fairly certain that’s the default on most browsers.

Not only did this new trick enable the attack on that particular application, it allowed me to launch the attack using another top 10 application that I already knew had an XSS hole.  Both of these applications also allow for clickjacking installs, meaning I could once again relaunch the full attack if I so desired.

Keep in mind that you need not visit an attack page for this to affect you.  If you’ve not limited unauthorized applications or the attack uses an application you’ve already installed, your data is vulnerable if a friend visits an attack page.

In short, an attacker could launch pages right now (this is zero-day stuff, people) that silently harvest profile information and photos from nearly any Facebook user.  Between these hacks and the threat of rogue applications, you should regard anything you post on Facebook as public information.

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

View proposed changes to the Facebook SRR/ToS

fb_governanceYou can view and comment on changes to the Facebook SRR (Statement of Rights and Responsibilities or better known as “Terms of Service”) located on the Facebook Governance Page.  You can download and review the redlined proposed changes here.  The deadline for comment is 12pm PST August 18th.  It is important for Facebook users to review these new terms as there are significant changes to the SRR and the wording that is used.  Most of the SRR will affect your privacy as a Facebook user.

For example, make sure you note the following:

1. For content that is covered by intellectual property rights, like photos and videos (“IP content”), you specifically give us the following permission, subject to your privacy and application settings: you grant us a non‐exclusive, transferable, sub‐licensable, royalty free, worldwide license to use any IP content that you post on or in connection with Facebook (“IP License”).  This IP License ends when you delete your IP content or your account (unless your content has been shared with others, and they have not deleted it).

3. When you add an application and use Platform, your content and information is shared with the application.  We require applications to respect your privacy settings, but your agreement with that application will control how the application can use the content and information you share.

4. When you publish content or information using the “everyone” setting, it means that everyone, including people off of Facebook, will have access to that information and we may not have control over what they do with it.

You should already know these things though, right?  🙂 Remember: Anything you post to Facebook private or not…consider it public information.  You can leave your comments on the Facebook Governance Page or feel free to comment here.  We would love to hear your opinion of these upcoming changes.

Staying Safe & Secure on Twitter

We recently added a presentation that Tom Eston did at the Cool Twitter Conference in Cleveland last week to the presentations section.  You can also find it on SlideShare.  This presentation should give you some good tips on how to use Twitter safely.  Stay tuned for a printable guide and video similar to the Facebook Privacy & Security Guide.

Tom was also interviewed by Dan Hanson from the Great Lakes Geek Show about his presentation as well as other social media security issues.

MonkeyFist Fu: The Intro

MonkeyFist Image

MonkeyFist is a dynamic request attack tool. It allows you to do some interesting things with various forms of cross-site requests and play them back to the user’s browser. These requests may contain session information bypassing Cross-Site Request Forgery protection mechanisms. It’s really a lot more simple than it seems.

MonkeyFist is basically a small web server that performs some attacks on the data it receives based on information you provide in the payloads.xml file. To do a deeper dive in to the issues that MonkeyFist exploits you can refer to the white paper we wrote prior to Black Hat on Dynamic CSRF located on the docs page of Hexsec

The best way to get familiar with MonkeyFist is just to dive right in. If you haven’t done so, you can go here to download it from the Hexsec Labs page

MonkeyFist requires you be intimately familiar with the request you want to forge. This should be painfully obvious because you need to tell the tool how to construct the request in order for it to be successful.

The Files

There isn’t much to MonkeyFist, all of the files are pretty small. There are a few items in the zip file, but you really only need to worry about and payloads.xml. All of the configuration for payloads in MonkeyFist is done through payloads.xml. We will get in to syntax in another post. In case you didn’t notice the .py extension, MonkeyFist is written in Python. So if your operating system doesn’t have Python installed (Probably just Windows systems) you are going to need it. I suggest version 2.5 or greater. The version that comes with most Linux distributions and OSX is fine. As a final note about the files, ensure that you run MonkeyFist from the same directory as the other files that come with it. Otherwise, it won’t know where they are located ;)


In the beginning there were no further dependencies but I a saw it was necessary to potentially need to do some more complex parsing for the fixation payload. For that reason I decided to add lxml. I could have gotten away with a more simple parser, but was trying to think ahead a bit. To use the Fixation payload you are going to need to install a 2.x version of lxml. This would be different depending on your operating system. If you are using Ubuntu / Debian don’t just to to apt install lxml, it will give you an old version. Python setuptools helps a lot, it’s just a good idea to use that anyway.

For OSX Leopard (Make sure you have the development tools installed) I just ran:

sudo easy_install lxml

For Ubuntu you have to take a few other steps because you need a few dependencies and the development headers for Python.

If you don’t have setuptools installed:

sudo apt-get install python-setuptools

Then you need to apt-get install the following if you do not have them installed:

After that you can go ahead and:

sudo easy_install lxml

If you have build problems you probably don’t have the build tools installed:

sudo apt-get install build-essential

Then run easy_install again.

If you decide not to run lxml or do not have the ability to install it, the tool will still run you just won’t be able to use the Fixation handler without a nice failure and error message :)

Payload Types

There are several types of payloads you can construct with MonkeyFist. Each of these would depend on what the goal of the attack would be or the type of content on a site you would have control over. The basic payload types are dynamic redirect, POST construct, dynamic page, and fixation.

Dynamic Redirect

The dynamic redirect payload simply parses any cross-domain information looking for session data to dynamically construct in to a GET based payload to send back to the user’s browser. Basically, the user would request something and the tool would respond with a 302 redirect to a location. The location value would be the constructed payload. The user’s browser would just request content like normal and follow the redirect and execute the payload.

This payload type is best used in instances where you have the ability to add images tags or other HTML to a site. This way it could be relatively hidden from a user’s browser.

Dynamic Page

This payload constructs a page that performs several functions depending on what type of attack you are performing. You can either have the page perform a GET or a POST for an attack. Both the GET and POST types will be submitted by the user’s browser. So what does the page do? The attack that you construct gets embedded in the page and after the attack happens the user is immediately redirected to a location of your choice. So you could perform an attack and immediately send someone to the Benny Lava video ;) This could be combined with an URL shortener for further obfuscation.

This payload is best used in instances where you have the ability to embed hyperlinks to pages. Another thing to note about the dynamic page payload is that it makes POST based CSRF a whole lot easier to pull off. If you thought submitted data as a POST was a protection mechanism for CSRF you might want to rethink you point of view ;)

POST Construct

This payload is a bit different because the POST request is made by the tool and not the user’s browser. This needs to be kept in mind when using it. You will not have the advantage of the browser being helpful and submitting header information. If the cross-domain leakage is enough that you can perform an entire POST request without the user’s browser then this payload can be used. Otherwise, it will be pretty useless to you :)


The fixation payload allows you to make a request for data that you fixate on to the attack you send to the user. This is still experimental and only works in some narrow situations. This will be expanded later. This works as a modified page payload that performs and extra request and parses the response and gains the necessary information to perform the attack. This would be commonly used to make a request for tokens that you can fixate on to a request forged by the user’s browser.

Default Payload

The default payload gets matched when there is no cross-domain information for the tool to match with your entries in the payloads.xml file. It’s best to not perform an attack with this ;) The best thing to do is to make this a link to some real content like an image. This can make the tool a bit more stealthy.

You need to specify a default payload. Not doing so would be like crossing the streams. Well maybe not that bad, but it wouldn’t be good.

MonkeyFist Running Options

There are only a couple of running options with MF and well, all of them do not work as of yet. So, the main one you need to be familiar with is -s. This is the standard attack mode. The -p option specifies the port you would like MF to run on. You won’t need privileged access unless you are trying to run on a low order port. The following would run MonkeyFist on port 8080 using standard attack mode:

./MonkeyFist -p 8080 -s

You can get the about information by running -a, just in case you were curious about what version you are running.

./MonkeyFist -a

Of course, if you need some reference there is always the ole’ help with -h

./MonkeyFist -h

There are a couple of other options that are planned for the future. A testing mode and a random mode will be added as well, but currently, they are not implemented.


The payloads.xml file is where you define your attacks. This is where all of your work will be done. The exact options that are specified in this file are still being worked out. This is because as content goes, there needs to be flexibility when identifying these issues. There is a basic set of options that allow you to pull of some attacks even as MonkeyFist sits at version 0.4. Expect some changes in these options. The payloads.xml file will be covered in more detail in a future post.

The Others

You will notice a few other files in the MonkeyFist zip file. You might not want to delete them or you may have some unintended consequences. The page2.html file is blank, but it won’t be if you pull off any Page attacks. Contents are put in to this file dynamically and change per attack. is something I didn’t write, it just allowed me to quickly generate some HTML. This was before I made the decision to use lxml. For now I am going to leave it in there, even though it is not the best option. is the most important. This is the workhorse that takes care of all the work.

In Closing

I think that’s it for a small intro on MonkeyFist. In future posts I will explain more about the payloads and how they are constructed. If you notice any problems while running MF please let me know. You can send an email to monkeyfist {at} hexsec {dot} com. This is still a work in progress so please don’t beat me up too bad. I do welcome your feedback though. Thanks.

Dynamic Cross-Site Request Forgery (CSRF)

Bypassing CSRF Protections With Dynamic CSRF

At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk called Weaponizing the Web: More Attacks on User Generated Content. During the talk we discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic CSRF methods can be used to create new attack vectors and compromise CSRF protection mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post about it and link our Dynamic CSRF White Paper.

Static CSRF Attacks

The current way people are exploiting CSRF issues is pretty static. A link may be crafted and people are tricked in to clicking on it or viewing a page with this link embedded. They may even do something such as create an auto-submitting POST that the user executes when visiting certain content. The moral is that someone crafts this attack for a specific location and chooses a vector for delivering it to users. On it’s own, this static CSRF attack method can be pretty devastating or perhaps totally innocuous. That’s just the nature of CSRF. There aren’t too many vulnerabilities that fall in to this category, which may be why it can sometimes be hard to understand.

Let’s just think about some things that would make CSRF even more dangerous. What if we had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user was on the site that we wanted to attack? What if we could use a central point to dynamically attack multiple sites? What if we could create a custom payload on the fly to include tokens and session data? What if we could request data in another process and fixate it on to a request that the user executes? CSRF would become much more dangerous. Well, it just did….

Dynamic CSRF Attacks

With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where requests are originating from. Sensitive information sent in a cross-domain fashion can be packaged in to a customized payload and sent to a location. Disjoined or bolted on components can be queried and fixated on to a user’s request. This opens up new opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks for multiple sites and applications with the ability to remove and repackage any leaked session information.

Dynamic CSRF

Using dynamic methods may allow for the bypass of CSRF protections. Whether these protections are leaked in the referer or if they can be requested by other means and fixated on to the request, bypassing may be possible. This makes requests that were previously not vulnerable to CSRF vulnerable again.

When not limited by static requests a few new attack vectors open up. I just wanted to highlight a couple here.

Getting Dynamic

In the next couple of sections I am going to point out some dynamic methods for bypassing CSRF protection mechanisms.

HTTP Redirect

A simple redirect attack can be made more devastating with the addition of session related data added to the request. So a user hits a piece of HTML on a web page that sends a GET request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session data can be taken from the referer and repackaged in to a payload that is sent to the users browser as a location for a 302 redirect.

HTTP Redirect

A scenario for this type of attack might be embedding a hidden image tag that links to a location offsite. This image tag may leak session data through referer allowing a tool to repackage that session data and get the user’s browser to execute it as a payload. This could be used to bypass CSRF protections by using the CSRF tokens from the referer.

HTML-based Redirect

For this scenario a hyperlink could point to a page that is created dynamically per-each request. This page contains a hidden GET or POST that could contain session data taken from referer as mentioned previously in the HTTP Redirect. The page would then refresh to a legitimate destination. To a user there would only appear to be a short pause prior to their landing on the legitimate destination, but in the background an attack has happened.

This attack could be made more interesting with URL shortening services. People have become accustomed to URL shorteners due to their use of Twitter and other social networks. Using a URL shortener would mask the location of the dynamic page and may not raise further suspicion.

HTML-based Redirect

A scenario for this would be posting a link that is shortened with a URL shortener on a web site that supposedly links to a video on YouTube. When the user clicks the link a hidden action (GET or POST) is executed. After the hidden action takes place, the browser does a refresh to the expected destination (the YouTube video). The victim may get little or no indication that the hidden attack has happened.

Fixation Based Attacks

Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF token and a valid session identifier, but those two values aren’t associated together from a session perspective. Say you are posting on a message board. This message board issues you a Session ID in a cookie and also issues you a token for use when posting. If these two values aren’t linked from a session perspective, it would allow for any valid token to be added to the request. Since the Session ID is in the cookie value, if a forged request had a valid token appended this would bypass CSRF protections.

Fixation Attack

What makes this fixation attack an interesting scenario is it requires no leaking of any session data in a cross domain fashion. As long as you have some visibility to the token, it can be requested and fixated to the request.

Other Scenarios

There are other scenarios as well. It really depends on how much session data gets leaked in a cross-domain fashion. For example, if the full session ID is leaked, there could be some real problems. It could allow for a tool to construct any GET or any POST to the target application.


MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on a system listening for all incoming input. When it receives a request it looks in the referer to determine where the request is coming from. It then uses this information to parse a payloads file and look for the specific attack to construct for that domain. You can have multiple entries in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST) and an Experimental Fixation handler are all included in the application. You can learn more about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be, but it works. More streamlining and modifications will come soon. I am still recovering from Black Hat and Defcon :)

I have some posts on MonkeyFist that are coming soon as well.

More Info

That’s it for a quick intro to Dynamic CSRF. If you would like more information you can read our white paper which is available here.

Twitter and Facebook DDoS was Targeted at One User

The following article was just posted over at CNET News regarding the massive DD0S (Distributed Denial of Service) that targeted Twitter, Facebook, LiveJournal and more.

Via CNET News:

A pro-Georgian blogger with accounts on Twitter, Facebook, LiveJournal and Google’s Blogger and YouTube was targeted in a denial of service attack that led to the site-wide outage at Twitter and problems at the other sites on Thursday, according to a Facebook executive.

Read the entire article here.

New Research Released on Koobface

Today Trend Micro released probably the most comprehensive research yet on the Koobface social network worm.  This research details how Koobface works, the malicious payloads it carries and how this worm has spread to all the major social networks.  The most recent victim being Twitter.   Most alarming is that Koobface will still continue to evolve and is the beginning of a new generation of malware targeting social networks.

Check out the article and download the PDF for the full report.  We will also have this link posted in the “Research” section of the site.

Call for Volunteers and Contributors!

Want to help out with  Have content and/or ideas to contribute?  Join our volunteer mailing list to join the discussion!

1 23 24 25 26 27 35