Showing posts with label facebook. Show all posts
Showing posts with label facebook. Show all posts

Tuesday, January 31, 2012

Intercepting Requests in Web Games

[Disclaimer: I am writing this post as an educational look into intercepting and editing GET and POST requests. How you use it is up to you. However, it is not a "security" issue and more of a poor design.]

Most people have probably played some form of online game, especially a "social" game within Facebook. I first got to thinking about these games when a member of the security group I'm in (SPARSA) gave a presentation on editing Android APKs. One demo he gave involved editing the list of approved words in Words with Friends, a Scrabble-like game on Facebook. That demo was done by decompiling the Android APK, editing the source files, and recompiling it. However, since the game had an online counter-part, I wanted to see how Facebook games were sending and receiving their data.

As I mentioned, this application involves playing what is essentially Scrabble with your Facebook friends. To play, a player must use an actual word. On the mobile version, the word is checked against a list of approved words stored within the APK. On the desktop version, the word is sent off to the Zynga's servers to be validated and a response, either valid or invalid, is returned.

As it turns out, intercepting this "word check" is surprisingly simple. In the presentation below, I walk through the steps of intercepting and modifying the GET requests to allow any word to be validated properly, essentially permitting the playing of any word.

Video:


Presentation:

Sunday, January 15, 2012

Spreading Malicious Links by Redirecting Facebook's Previewer

When you post a link on Facebook, Facebook has a link fetcher / preview function that visits the website, grabs information about it, along with a thumbnail if available. If you post a bit.ly link, Facebook's fetcher  is still able to follow through the redirect and grab the end-result information.

Let's start with an example. We have this lovely image of a dog and cat on Imgur (found on /r/aww): http://i.imgur.com/vwMRV.jpg. Out bit.ly link is: http://bit.ly/zrhnPz.

Facebook displays the link like so:


Note that once the link converts to a preview, the original text can be replaced.


Notice that the end link (imgur) is displayed and not the original link of bit.ly. But suppose we skip bit.ly and make our own redirect service. To demo this, I've created a site with a spare domain I have. It is located at: http://blasze.com/iplog/. This site is just a redirection service that logs visitor IPs. But if I was to have more malicious intentions, I could have a browser exploit on the page in between Facebook and the redirect. Then, Facebook's preview utility would successfully fetch the end link, but the user clicking it could be exploited. Let's take a look.

My site generates a URL to post.


Now, like in the previous example, I can edit the link and title and unsuspecting users will think it is a cute dog. However, they're actually being redirected through my malicious site (note: it's not actually malicious. It simply logs IP addresses to prove a point, but an attacker could compromise the browser).

I post and wait...


As you can see in this image, I have a click! The redirection was entirely seamless to the user, just like using bit.ly. But without them ever knowing, I have logged their IP, host name, and user agent string. This isn't terrible, but I could have used a browser exploit to compromise their system instead of just redirecting.

But then wouldn't I be attacking Facebook's previewer too, since it visited the site? Well technically yes, unless I wrote a quick PHP script that simply redirects Facebook's IPs but attacks others.

This is just a demo of something I realized. Please don't use it maliciously, but also be aware that any link you click on Facebook could actually go somewhere else that is not what the preview indicates. To help mitigate this problem, Facebook could include an additional warning on links that redirect.

Friday, October 28, 2011

Facebook (Appears to Have) Fixed the EXE Vulnerability

Just yesterday, security researchers at Security Pentest pointed out a vulnerability in Facebook's Message center, allowing users (with some POST-data editing) to attach EXE files to a message and send them to anyone capable of receiving messages on Facebook (almost everyone, even non-friends). EXEs have been sent via email for ages, but Facebook users are notorious for clicking links and attachments on the site, so having the extra layer of security to block EXEs is important. The full vulnerability post can be read here: http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html

I decided to try out the vulnerability to see if it had been fixed (it's been about 24 hours since the issue was made public, but over a month since Facebook was notified). From what I've been able to tell, Facebook has now fixed the vulnerability.

Using Tamper Data (an add-on for Firefox), the POST data could be edited when submitting a file as an upload to a message. The string <filename="filename.exe"> could be changed to <filename="filename.exe "> (angle brackets added for readability). Notice the space after the file name. Apparently, Facebook was not trimming this data and the additional space was enough to allow an exe file to slip through.

However, now the vulnerability appears to have been fixed. Attempting the same exploit results in an error message: "Unfortunately, your attachment could not be uploaded at this time. Please try again later."

TamperData - Changing the file name in the POST header
Facebook Messaging Error


Tuesday, July 19, 2011

Google+ Vs Facebook: Separate But Integrated Services


Since Google+ launched several weeks ago, it has been fairly universally praised, yet it has also been doubted and questioned extensively. Can Google+ compete with Facebook and its myriad of over 700 million users (and growing)? Many have wondered if Google, an algorithmic company at its core, has the talent and engineering skills to produce a product that is used in a very different way than traditional search. Although I believe that Google+ will have a slow start, I also feel that the product will ultimately become not only a viable alternative to Facebook, but a better one. There is one major advantage that Google has over Facebook: separate, yet tightly integrated services.

For years, Google has been slowly moving our lives to the cloud. Gmail, although not the top email service, is used and loved by millions of people around the globe. Next, our calendars became available online, easily synced to any computer or device. Google Docs now stores and provides access to almost any file type imaginable without ever leaving the browser. Google Pictures (Picasa), YouTube, Reader, Tasks, Maps, the list goes on. Ultimately, these are separate, yet tightly integrated services. If you need directions, you access Google Maps; events take us to Google Calendar; email to Gmail. Yet within all of these services, although they appear to be distinct and separate, there is an element of connectivity. For example, Google Calendar integrates well with Gmail: we can send and receive invites seamlessley and access our contacts. The same goes for Google Docs.

You may be wondering what this has to do with Google+ or Facebook. My point is that the average user wants separate but integrated services. They want to be able to access their email without seeing their documents; they want to plan a trip without seeing YouTube videos. This is where Facebook falls short. Even with only a few "clones" of Google products, Facebook is starting to become crowded - a fact that many users are now complaining about. Facebook Messages, Events, Groups, Video Chat, regular chat, group chat, fan pages, and many other apps and services are slowly crowding a News Feed that was once a stream of updates from friends. There's only so many features that can fit on a single page and Facebook seems to be running out of white space. Google, although it has probably ten times more services than Facebook, does not feel crowded at all. All of Google's products are separated out into distinct web applications rather than crammed onto the same page. As I mentioned: separate but integrated services.

Now let's take into account social. For Facebook, social means having a base social platform and adding services to it. For Google, social means taking a base set of services and adding social to them. This is a key difference that I believe will ultimately benefit Google. If users can access their notification bar on every Google product (something Google is beginning to do already), social is not only more easily accessible, it is practically jumping out at users. Facebook has limited reach in these terms. Yes, they can have their own notifications as text messages or emails, but you will never see Facebook notifications as you surf the web, plan events on your calendar, or type documents in the cloud. Google already has these products, now it just needs to tightly integrate social into them just like they've integrated their existing products already.

So why do I think Google+ will have a slow start? For many users, moving to a new platform is a big change. The current dilemma facing Google+ seems to be the lack of users (although they are purposefully limiting it). It's a catch-22 of "I won't join until my friends join" and vice versa. However, Google, with its multitude of products can really begin to make not joining Google+ feel like missing out. When the notification bar is always a click away, I think it will become more and more tempting for non-users to give in and sign up. Google can have retention through integration. For Facebook, retention means keeping users on Facebook.com and no where else; for Google retention is becoming synonymous with opening a web browser.

Wednesday, June 1, 2011

Potential Facebook Security Issue

Facebook introduced its tagging feature (in wall posts) not too long ago. Since then, almost everyone I know on Facebook has learned to tag their friends in both status updates and comments. But one thing that I haven't seen much of, yet something that could be a security concern, is the ability to tag pages in wall posts using the '@' reference. This works well when the page is on Facebook, such as the company's official Facebook page or a product or service. Here is an example of tagging a company's page on Facebook:


When the user presses 'enter,' the tag is converted into a link that takes anyone clicking it to the official Grooveshark Facebook page.


The word "Grooveshark" becomes a link that directs the user clicking it to the Facebook page for Grooveshark. However, not all pages are contained within Facebook. For example, prior to recent changes (Facebook changed the "liked" links into wall post stories rather than a recent activity), a "page" could be created from any page on the web with Facebook's like button installed. Here is an example from Blogspot blog with a random post.


(Keep in mind that this only works with pages that have been "liked" previously and does not work with new posts).

Clicking "Like" under the post causes a post to be made to your Facebook profile wall saying that "user x likes page y." However, in this case, it simply says "User X likes 'did that five year old I just saw have a cell phone?'" The name of the page is a clickable link redirecting to the original blog page (as it should for viral purposes). Now here is where the potential vulnerability comes into play. Since Facebook treats these older "likes" as pages, the user can "tag" the page as well.


This creates a link, which is posted on the user's wall to the original blog post.


So essentially, this creates a problem because we have links that are masked by text (the same way they are around the web). However, this is especially problematic on Facebook because users will almost always click a link posted by their friends without investigating the underlying URL. It is important to remember that the owner of the original blog post still has complete control over that web page. He or she can redirect it, add malicious code, etc., and there is nothing Facebook can do about it.

Now imagine if the above link said "This video is hilarious!" It looks like a trustworthy post from a friend. But in reality, it's a post made by a rogue application that obtained permissions to post to the user's wall. The text "This video is hilarious!" could redirect to any page on the web.

Fortunately, this problem is not a large one. First, it is hindered by the fact that very few users are aware that they can tag pages. Secondly, Facebook has stopped treating new "likes" as pages and instead treats them as links, displaying their full URLs. However, the problem can still exist on older pages, of which there are millions.

To protect against this threat, always be aware of where the link is going. On Facebook (and any other site), hovering over the link reveals the URL at the bottom of the screen.


This isn't a major security issue with Facebook, nor will it probably be corrected. However, it is important to continually monitor Facebook before clicking any links.

Saturday, November 13, 2010

Facebook and Email - What Could Be Announced Soon

If you follow any of the technology blogs, or even happened to glance at Yahoo! during the past few days, you may have noticed that Facebook is planning an "event" for this coming Monday. As usually happens with these events, almost everyone has been speculating as to what new feature the popular social network could roll out next. This time, it seems to be an overhaul of Facebook's email system, with all of its users possibly getting an @facebook.com email address.

This announcement is interesting, yet also confusing to me. Allow me to explain. Back in the beginning days of the Internet (and technically speaking, still today), we access websites through a series of numbers called IP addresses. So to go to one website, you would type, for example, 129.23.88.1 into the web browser and be taken to that homepage. But then, along came the domain name system, which allows a word to be translated into that address. So instead of remembering a very complex set of numbers for every one of their favorite sites, users can now simply remember facebook.com or google.com. You're probably wondering what this has to do with anything.

Well, in order to send someone an email, we have to remember a series of letters and numbers followed by an @ sign, followed by more letters, followed by a period, followed by more letters. This is ridiculous. I have saved all of my contacts, so sending them an email is not difficult because Gmail or whatever email program you use stores the names and associated emails. But suppose you want to send an email to your friend "John Smith?" You know his name, just not his email address. So what do you do? You either have to look his email up on Facebook, assuming it is publicly available, or you have to wait and ask him for it at some other time. This is a problem; it is a problem that Facebook can fix.

Email needs to be more social - a form of social which is not necessarily a bad thing. So what can Facebook do? Facebook, as you are aware, is currently the biggest social network in the world. It knows all of your connections; it knows that when you want to talk to "John Smith," it's not the same "John Smith" that someone else is likely wanting to talk to. This is where the confusion comes in, which I will do my best to explain.

Essentially, I am proposing that Facebook begin to change email all-together. Redo the inbox, make it a full-featured web-application, even allow IMAP and POP support. But it can be different than email in this way: Instead of having to remember my immature friend's email address of "fancypants340@facebook.com," I can instead formulate an email by typing, from any account, john.smith@facebook.com. Then, when Facebook's servers receive the email, they can compare the sender with the recipient and know which John Smith it was intended for. Have two John Smith's in your friends list? It could reply with an email that asks for clarification.

Internally, this would work similar to email, but in another way, entirely different. Instead of having to remember or store 2,000 contacts, all I have to do is remember their name. I think, if human social interaction demonstrates anything, that it is much easier to remember a name (think google.com) than a series of numbers of letters (think 173.194.33.104).