Facebook Privacy & Security Guide Updated to v3.0

I’ve finally updated the Facebook Privacy & Security Guide to version 3.0.  This is a major revision which includes directions on how to set the latest privacy and security controls in Facebook.  Maintaining this guide has been challenging over the last year as Facebook has made major changes multiple times in regards to the way privacy settings are enabled.  Having said that, this is a great time to use my guide and review what your privacy settings are.  Things like enabling secure browsing, login approvals and limiting the audience to what you post are more important then ever.

As always, feel free to distribute this guide to friends and family!  Happy Thanksgiving!

Download v3.0 of the Facebook Privacy & Security Guide here

Social Media Security Podcast 27 – Facebook Friend Unlock, The Anti-Facebook, Facebook Games

This is the 27th episode of the Social Media Security Podcast recorded November 11, 2011.  This episode was hosted by Tom Eston and Scott Wright.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Taking over the Facebook Page “buy now” button (Part 2 of 2)

As I have been testing the security settings of companies social media strategies, I have consistently noticed two things, marketing is desperately trying to find its ROI and IT/Security doesn’t even know they have a FB page.  I do agree that after a number of months, it is time to show the CFO that spending that insame amount of time on their social media sites is worth the payroll checks. Unfortunately, analytics alone have been a blurry way of making that compelling argument and can be defeated by saying, if, I had put those payroll checks into google…I could see our ROI in a nice neat report. This is one of the reasons that marketing is jumping head first into technologies like Shoutlet, payvment or others (FB E-commerce). Why not sell your items on your FB Page?  Your team has worked extremely hard to get thousands of new users to click follow/like. Ultimately, this is going to be the future of pages but because IT/Security is not involved in the social media process it also opens a HUGE GAPPING HOLE in your security policy and procedures. And of course here is your example:

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.”

Part 2

After this meeting we agreed to stop and allow IT/ Security to be a part of the implementation of this new e-com solution and lock down this new site.  After a couple of months we were given the green light that all social media was secure and our attacks would now #fail.  Well they were wrong!  Here is what happened;  Technology constantly changes and therefor we should also be constantly training/testing these changes.  Yes, all https was checked.  Yes, they read www.socialmediasecurity.com on a regular basis.  But they forgot to monitor their social media accounts like they would an email server.  There is still a core failure in my opinion of Facebook pages.  Who?!? owns the data and when is it okay to monitor the admins personal accounts? Because these users of the pages still enjoy using Facebook for personal use. They do not apply the corporate rules to their personal accounts nor should they if that is how they live.  So, we are either forced to create fake accounts or all share one admin account.  Well with our testing we are still targeting the admins of these pages.  There are many many ways to gain access to their accounts and once in, we only have to create our own evil twin account to keep access.  Example: if Bob Alice is the admin of the page just create another Bob Alice and copy the information including the  profile imagine and allow this new user admin rights to the page.  Most common users will just think this is a Facebook glitch and it is showing their profile twice. But in reality it is a way for us to keep a constant admin account to this system.  If you maintain a Facebook page you know that admins just lose their rights to the page all the time out of the blue.  So constantly adding the same person is a regular process.  If the company was monitoring its data it would see these changes or see that there were in fact 2 different accounts attached to this page.  But we are not monitoring these accounts, yet. Social media security can be a full time job depending on the risk and frequency of the sites.   For more information feel free as always to email me.  info@unixbox.ws

Social Media Security Podcast 26 – Google +, New Facebook Privacy Controls, FBPwn Tool

This is the 26th episode of the Social Media Security Podcast recorded September 8, 2011.  This episode was hosted by Tom Eston and Scott Wright.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Taking over the Facebook Page “buy now” button (Part 1 of 2)

As I have been testing the security settings of companies social media strategies, I have consistently noticed two things, marketing is desperately trying to find its ROI and IT/Security doesn’t even know they have a FB page.  I do agree that after a number of months, it is time to show the CFO that spending that insame amount of time on their social media sites is worth the payroll checks. Unfortunately, analytics alone have been a blurry way of making that compelling argument and can be defeated by saying, if, I had put those payroll checks into google…I could see our ROI in a nice neat report. This is one of the reasons that marketing is jumping head first into technologies like Shoutlet, payvment or others (FB E-commerce). Why not sell your items on your FB Page?  Your team has worked extremely hard to get thousands of new users to click follow/like. Ultimately, this is going to be the future of pages but because IT/Security is not involved in the social media process it also opens a HUGE GAPPING HOLE in your security policy and procedures. And of course here is your example:

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.” Part two is coming…but I leave you with this..

Who is in charge of these buttons?  Have these tools been tested and approved by IT/Sec before you took the 6 mins to install on your facebook page? What permissions are you giving this solution? HEY! IT/Sec does your company have a FB page?  Have you seen it lately? Is it part of your compliance testing?

Firesheep’s Revenge

No, this is not an article on the new version or even newly added super hero features for firesheep? #titlefail? Maybe but please read on then decide.

I know firesheep has lost its shiny coin syndrome with most but the attack is still working quite well in the field.  While the readers/listeners have been doing a good job of enabling secure browsing options in Twitter and Facebook, we still have a long way to go. Please keep spreading the word and keep pleading to social networking sites to enable secure browsing by default.  So, Why the “Firesheep’s Revenge” title?  Well these last month’s, a couple of us have been testing common social media monitoring (SMM) tools.  These tools are generally used by small businesses, internal marketing, or external marketing companies to help update social media accounts without the hassle of logging into every social networking site individually.  We have been testing these SSM’s and found that:

http://hootsuite.com/dashboard#
http://sproutsocial.com/dashboard
http://standard.cotweet.com/channels#

Are not using secure browsing by default, allowing us to hijack sessions.  What does this mean? Well by adding your social media accounts into these SMM tools, you are granting the tool permission or full control over that account(s). By gaining control over the tool we are bypassing all the hard work you did by enabling secure browsing in each of your twitter and facebook accounts.  Try explaining to the VP of Marketing that even though you checked the “defeat firesheep” box it still works. And not only will it work on Facebook/Twitter but now LinkedIn, Foursquare, ping.fm and Ning accounts all in one interface. Most of the time we were looking at full access to the corporations social media strategy. So, we are right back to where we started, teaching the user that security is usually the last thing on the mind of these rapid development firms. If you do not see the option of “secure browsing”, then please be careful of where you update your social media accounts. Ask your tool makers where this option is located.  If they do not have this option then maybe you should look for another tool.

James F. Ruffer III
Unixbox
@jruffer

Recent Facebook XSS Attacks Show Increasing Sophistication

A few weeks ago, three separate cross-site scripting (XSS) vulnerabilities on Facebook sites were uncovered within a period of about 10 days. At least two of these holes were used to launch viral links or attacks on users – and it’s clear that attacks against Facebook users are becoming increasingly sophisticated.

The first issue came from a page on the mobile version of Facebook’s site. The interface was a prompt for posting stories to a user’s wall, and the parameter for the text of the prompt did not properly escape output. On March 28, a blogger identifying themselves as “Joy CrazyDaVinci” posted code that demonstrated how the vulnerability could be used to spread viral links:

<iframe id=”CrazyDaVinci” style=”display:none;”
src=”http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt=’<script>window.onload=function(){document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</script>”></iframe>

This bit of HTML would be included in a viral page. The code sets the content of the wall post to a message that includes a link to a viral page, then submits the prompt automatically. Anyone clicking the link would get the same code executed on their account. The viral page could be used for malware distribution or phishing attacks, but in most cases where I saw this trick used, the page simply loaded advertisements or “offer spam”.

By the next day, several links were spreading virally and caught the attention of security researchers. Facebook moved quickly to patch the issue, and Crazy DaVinci issued an apology for the example code, explaining that versions of it had actually been circulating for several days prior and that the demonstration was intended to push Facebook for a fix.

On April 3, another XSS problem came to light, this time with a Facebook “channel” page used for session management. Both another security researcher and I had previously looked at this interface and found it properly escaped, so it’s likely a code update mistakenly changed the page’s behavior. Facebook again patched the problem soon after news of it spread.

I didn’t observe any viral exploitation of the second vulnerability in the wild, but after the first problem came to light, I noted that it was mostly used to submit a form already on the page for posting links. The payload made use of functionality within the vulnerable page, but XSS allows an attacker to do far more. I wondered when we might see a Facebook attack that made greater use of cross-site scripting’s potential.

What a Difference a Space Makes

I didn’t have to wait long. On April 7, I got word via Twitter of a Facebook app that had live XSS, but the app had disappeared before I got to see it in action. At first, I thought this was yet another case of XSS within the context of a Facebook app. But I soon found other version of the app which were still online, and I quickly realized this was actually an XSS problem with the Facebook Platform. Also, the XSS payload being used did much more than submit a form.

The attack used FBML-based Facebook apps, which render in the context of an apps.facebook.com page. Normally, Facebook filters code to prevent any scripts from directly modifying the page’s DOM, but the XSS problem gave attackers a bypass. When a user visited the app page, they would see what appeared to be a fairly benign page with a popular video.

Unlike many Facebook page scams, the promised video actually works – if you click play, the video will load and nothing unusual seems to happen. But as the code screenshot below reveals, that click does much more than load the video.

When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.

According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.

A More Advanced Attack

Clicking the link executed an inline script that in turn added a script element to the page. This loaded more code from a remote address and included several parameters in the GET request. The parameters set variables within the remote code that specified what video to load, what URLs to use for viral posts, and so on. Multiple Facebook apps and domains were used for the viral links, but the main script always came from the same host. This helped the attack persist, since blocking one site would not stop it and the central code was loaded dynamically.

The remote code handled actually loading the video, but also included a number of functions which make use of having script access in a facebook.com context. The script would set the user as attending spam events, invite friends to those events, “like” a viral link, and even send IMs to friends using Facebook Chat.

When I came across the attack, one block of code had been commented out, but one blogger discovered a version of the attack a few days prior and saw it in action. This part loaded a fake login form which actually sent the entered username and password to a log interface on the attacker’s server. (Remember, this phishing form would appear in the context of a page with typical Facebook chrome.) Since the attack page would load even if a user was not logged in to Facebook, this could have also been a way to make sure a session was available before launching the other functions.

Fake videos and viral links are nothing new on Facebook, but most of these scams tend to be fairly simple. In fact, it’s not hard to find forums where people offer boilerplate code for launching such schemes – much like the first XSS worm above which simply submitted a form. But the April XSS attack involved multiple domains, multiple user accounts, and multiple methods for spreading and hijacking user accounts. And it still only scratched the surface of what’s possible with an XSS vulnerability. I expect we’ll see more XSS-based attacks and more powerful payloads in the future.

Postscript on Real-Time Research

I came across the April attack late one afternoon as I was preparing to leave work… so I could present on XSS at a local OWASP meeting! Those following me on Twitter saw a somewhat frantic stream of tweets as I tried to find live examples of the attack and sorted through the code while closely watching the clock and wrapping up last-minute presentation details. Earlier this week, I did some searching to review information for this post, and I came across this article from eWEEK: “Facebook Bully Video Actually an XSS Exploit“.

I was a bit surprised by it, as I hadn’t known about it before and saw that it quoted me. I then realized it was quoting my tweets! I then read that I had “confirmed to eWEEK on Twitter” one aspect of the story. At first I was confused, but then remembered that during my flood of tweeting, another user had sent an @ reply asking about the very detail the story talked about. Checking that tweet again, I found out the question had come from the article’s author.

I relate all this not because any of it bothered me, simply because (1) I found it somewhat fascinating that a few quick Twitter updates could become the primary source for a news article and (2) I was humbled to realize that a few quick Twitter updates could become the primary source for a news article! While it’s great that a story can spread so fast, it was certainly gave me a reminder to be careful when discussing topics of interest on a public forum. But I’m glad I can do my part in helping raise awareness of online dangers, particular the implications of XSS.

Social Zombies Gone Wild: Totally Exposed and Uncensored

Kevin Johnson and Tom Eston gave the third and final “Social Zombies” talk at Notacon 8 this weekend.  This talk focused on how social networks are using geolocation and the abuse of location based services.

“Social networks have jumped onto the geolocation bandwagon with location-based tweets, status updates, check-ins, mayorships, and more. This doesn’t take into account EXIF, QR codes, and advancements in HTML 5 geo implementations, which are being built into these location-based services. This is often implemented and enabled without the user even knowing it. In fact, geolocation is one of the hottest technologies being used in everything from web browsers to mobile devices. As social networks throw our location coordinates around like candy, its only natural that bad things will happen and abuse will become more popular. This presentation will cover how social networks and other websites are currently using location-based services, what they plan on doing with it, and a discussion on the current privacy and security issues. We will also discuss the latest geolocation hacking techniques and will release custom code that can abuse all of the features being discussed.”

Slides are on SlideShare below:

1 2 3 4 14