Social Media Security Website and Podcast Reloaded!

Since 2009, I’ve been maintaining the popular Facebook Privacy & Security Guide that has been used by several universities and government agencies as well as regular users of Facebook.  If you’re not familiar with my guide, it’s a simple two page handout that walks you through recommended privacy and security settings for your Facebook profile.

The guide has been a labor of love but also required frequent updates since Facebook has drastically changed the privacy controls as well as the layout within the Facebook platform over the years.  Needless to say it’s been tough to keep the guide updated and also tough to keep it to a single page so that it can be easily distributed.  Today, I’m happy to announce that my company SecureState is now officially sponsoring the guide so that it can be maintained with frequent updates!  Having said that, I’m announcing today the release of the fourth version of the Facebook Privacy & Security Guide, updated with the latest information on Facebook’s privacy and security settings.  Please download and distribute to friends and family.

Also around the same time I started the guide, I started the Social Media Security website and podcast.  The podcast is still being recorded monthly and co-hosted by myself and Scott Wright.  Today we also released our 30th episode along with a website redesign for  I’d like to thank the podcast’s new sponsor SecureState for the new design and support of the podcast.  Special thanks go to DigiP over at Tick Tock Computers for putting together a great site redesign and logo.  I look forward to recording more podcasts and getting the word out on how to safely use social media!

The Slow Web

The Slow Web

Jack Cheng maps out a positive vision for a “slow” type of web app:

Timely not real-time. Rhythm not random. Moderation not excess. Knowledge not information. These are a few of the many characteristics of the Slow Web. It’s not so much a checklist as a feeling, one of being at greater ease for the web-enabled products and services in our lives.

Inside Google’s Plan to Build a Catalog of Every Single Thing, Ever

Inside Google’s Plan to Build a Catalog of Every Single Thing, Ever

Alexis Madrigal at The Atlantic on Google’s Knowledge Graph:

This is one of those human knowledge projects that is ridiculous in scope and possibly in impact. And yet when it gets turned into a consumer product, all we see is a useful module for figuring out Tom Cruise’s height more quickly. In principle, this is both good and bad. It’s good because technology should serve human needs and we shouldn’t worship the technology itself. It’s bad because it’s easy to miss out on the importance of the infrastructure and ideology that are going to increasingly inform the way Google responds to search requests. And given that Google is many people’s default portal to the world of information, even a subtle change in the company’s toolset is worth considering.

And that’s how I found myself on the phone with John Giannandrea discussing mojitos and semantic graphs.

Sounds like another stab at the Semantic Web. It’ll be interesting to see how Facebook’s Open Graph actions play out in this space as well.

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

The race for the most personal Twitter followers

I have had a great reply on this topic while going around the USA talking about social media security.  During my talk I give an example of why it is NOT okay to allow just anyone the right to follow you or vise versa.

I choose a volunteer out of the crowd.  Usually a nice looking woman because…why not.  I give a hypothetical situation.  We were dating and things are starting to get serious.  So serious that I take her to meet my mom for the first time. While we are at my ma’s house, I introduce her to my new brother-in-law.  My brother-in-law was in charge of bringing the dinner rolls and once again forgot.  He asks her to go to the Italian (not french) bakery down the road with him to get these rolls.  She says yes.  While they are picking up the rolls he notices that he forgot his wallet and asked her for $4.98 to cover the rolls.  She just happens to have $5.00 in her left pocket.

Would she give him the $5.00 and why?

The answer has always been “yes” and because he is associated or was introduced to her by me.  There is an applied level of trust set prior to them going to the bakery.  Well this level of trust in my opinion can be accomplished within twitter.  If I follow you and we start having a friendly conversation(your favorite sports team) I will then go after your friends and family for a small amount to help me with my “cure/run/walk”.  All I have to do is introduce myself as your friend as they can see our past conversations in twitter.  I  have had a over 90% success rate of getting their followers to click my cause link.  This success is based on the applied trust between two strangers.  So although it is really #kwel to have 70,000 twitter followers it can also cost your friends and family $4.98

For more information feel free…

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 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.

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=”’<script>window.onload=function(){document.forms[0].message.value=’Just visited 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 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 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 25