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 25 – Facebook Security Updates, FaceNiff, Social Media Background Checks

This is the 25th episode of the Social Media Security Podcast recorded July 1, 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!

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:

Social Media Security Podcast 24 – Personal Social Media Accounts, Cree.py, ProfileSpy, App Privacy

This is the 24th episode of the Social Media Security Podcast recorded April 6, 2011.  This episode was hosted by Tom Eston and Scott Wright with special guest James Ruffer. 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!

Social Media Security Podcast 22 – Skype Email, Taxonomy of Socnet Data, Facebook Graph API

This is the 22nd episode of the Social Media Security Podcast recorded January 21, 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:

  • Skype credit email as an apology – a new trend we can expect in 2011 from good guys and bad guys.  Screen shot mentioned in the podcast.
    Scott’s note: I searched for posts about this email before clicking on it, and it was actually legitimate. However, this would be a very compelling phishing attack for any organization that recently suffered a PR setback. Any time you get an unexpected email, even if it looks like the circumstances make sense, you need to check on its authenticity. And any organization issuing such an Email should also post an announcement of the campaign on their home page, and issue a press release to make it easy for people to verify the legitimacy of the email.
  • Bruce Schneier’s taxonomy of social network personal data
  • Facebook now tells you about people you know who have found friends using their Friend Finder
    Scott’s note: I always tell people never to enter their email address and password on sites that aren’t their email service. You don’t know what they will do with your password, or if it might be captured. It also exposes your friends to potentially unwanted email messages – e.g. spam.
  • Facebook Lets Developers Ask a User for Their Address, Phone Number in the Graph API
  • Twitter Worm Pushing Rogue Antivirus Scam

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!

Social Media Security Podcast 21 – Facebook Trolls, Cookie Monster, Gawker Breach

This is the 20th episode of the Social Media Security Podcast recorded December 17th 2010.  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!

Looking at Facebook’s Strategy and Possible New Directions

Over the last few months, Facebook has rolled out several significant new features, such as Places and the updated Groups. On Monday, Facebook is holding another event to announce what many expect to be an improved messaging feature. As I’ve watched these changes, I’ve been thinking about where Facebook might be headed.

At first, I started to think Facebook was simply looking to extend its reach by acting as an invisible layer of sorts. Anil Dash once talked about Facebook melting into the larger Web, but perhaps Facebook would end up becoming part of the underlying fabric of the Internet. In past public appearances, Facebook CEO Mark Zuckerberg seemed to be the kind of person who was content to remain in the background, and the company’s strategy seemed to reflect a similar style. I’ve mentioned before the idea of Facebook becoming and identity layer on the Internet, and innovations such as their Graph API have made it easier than ever for sites to integrate with Facebook.

But Facebook’s updated Groups feature changed my perspective, since it added functionality that would drive users back to facebook.com. Of course, the upgrade did enable e-mail as a way of interacting with groups. In some ways, Facebook’s overall strategy could be compared to Google’s. Years ago, many sites focused on “stickiness,” trying to keep users hooked. By contrast, Google drove users away by providing relevant links to other sites. But to see Google as non-sticky would be an oversimplification. In fact, the company built a successful ad network that extended its reach across the web. Also, Google has created a number of other products that many people stay logged into, such as Gmail.

And now, people are expecting Facebook to announce a web-based e-mail client that will compete with Gmail. I’m predicting that Facebook will roll out a new messaging system, but it won’t be a Gmail clone or simply another client for managing traditional POP/IMAP e-mail. That’s not to say there won’t be any e-mail gateway, but I think Facebook’s plans will go much further. I’m guessing that at least part of the new system will involve somehow extending private messaging features across Facebook-integrated websites.

In any event, I think Facebook’s announcement will include at least a few surprises for those who have been discussing the possibilities. Facebook has a history of introducing features that aren’t quite what people expected – and often end up leading to practical implementations of ideas that were previously niche experiments. Personally, I think it’s a bit short-sighted to think that Facebook would simply join the market for web-based e-mail without trying to reinvent it, especially given the service’s cautiousness about past features that allowed or potentially allowed spam-like behaviors.

Facebook has also been accused many times of somehow standing in opposition to “openness.” Personally, I think the term has become a buzzword that’s often used without much specificity. And even though I’ve often been a critic of Facebook, I do think many of the accusations aren’t entirely fair. From RSS feeds to developer APIs, Facebook has opened up data in ways that many other sites can’t claim. Today’s Facebook is certainly far more “open” that years ago – in fact, I would argue that the site has at times been too open lately, such as when some user data became reclassified as “publicly available” last fall. But regardless of Facebook’s degree of openness, the company has always been careful to maintain a high degree of control over information and features on the site. This can be positive, such as quickly removing malware links, or negative, such as controversial decisions to bar users or certain content.

Either way, that control has helped the site build a powerful database of profiles that generally reflects real people and real relationships. That’s part of what fascinated me about the site’s recent spat with Google over contact information. In the past, a list of e-mail addresses was about the only semi-reliable way to identify a group of people across the Internet. Now, many sites rely on Facebook’s social graph for that function. In terms of identity, the value of e-mail addresses has declined, and I don’t think exporting them from Facebook would provide as much value as Google might think. On the other hand, Google may realize this and be so concerned about the shift that they’re trying to curb Facebook’s influence. This would especially make sense if Google intends to introduce a more comprehensive social networking product that would need e-mail addresses as a starting point. Regardless, I’m sure Google feels threatened by the prospect of Facebook providing a better alternative to traditional e-mail – a change that would only bolster the value of a Facebook profile as the primary way to identify a typical Internet user.

1 2 3 4 28