Facebook Exploits

Hey guys,

Long time since I have posted on this site... I remember when I was a lot younger, I came here all the time and learned a lot. Anyways, I wrote a long paper about two vulnerable exploits I found on Facebook for a class of mine. The first exploit allows any user to log in as a user who had previously logged in, and the second exploit is that a user never logs out of Facebook. Facebook fixed one of the exploits (exploit #2), but hasn't yet fixed the first :( Anyways, I was hoping someone here would be able to take the time to read over my paper and give me suggestions. Thanks a lot!

http://www.duke.edu/~jyw2/wwwsecurity.html

btw, the Facebook stuff starts at the end of page 4, but I would like input on the rest of the paper as well!

The "vulnerability" is not specific to Facebook at all because what you are describing are network level attacks that will effect any site that doesn't operate over HTTPS entirely. You can do this with gmail, you can do this with hotmail, you can do this with antionline, you can do this just about anywhere because http is stateless and the only thing keeping a session together is a cookie. (steal cookie, steal session)

Thus, this is a network exploit, not a problem with www. If you can't trust your network, you have much bigger problems than your fb profile anyways. :)

I hope your professor didn't know that :D

First off, thank you very much for taking the time to read the paper. I really do appreciate your input. My friends and I talked a lot about what you mentioned above, and we all came to different conclusions as to what responsibility Facebook has. Personally, I don't think that all RPC-based web services are doomed for failure just because they do transmit cookie information via the HTTP header without using some level of encryption throughout their site. I believe that if web services just give up immediately and say, "oh, its not our fault, thats the way everyone does it!", then they are not focusing on securing their app. In my paper, I mentioned a technique to add additional layers of security to prevent such an attack. The first idea is to store some type of unique identifier when the session is first spawned, so the server has a better clue as to who the user is. By doing this, the server will be more "intelligent", and base access on more variables than just a session key.

Any idea as to why sessions were not being destroyed? I noticed this when I was using a friend’s cookie credentials to take on his identity (of course he was in the room with me and we were both okay with what I was doing). I told him to log out, and noticed that even after he was logged out, I still had full access to the site! Is this just poor practice or is it justifiable? I tried the attack again before my final presentation, and noticed that Facebook had fixed the problem so I assume they want sessions destroyed when a user logs out…

I personally dont think that an antionline account has as much to loose as a regular Facebook account does. Most Facebook users spend a TON of time on the site, and have private messages that they really want to keep private. I have not investigated the way gmail and other sites handle cookies and sessions (or if they take a RESTful approach to login), so I do not have the authority to make any claims. Has anyone been able to gain access to a gmail or yahoo account by performing some type of simple session stealing attack?

Thanks again for reading! I know its long... :(

Quote:

---

I believe that if web services just give up immediately and say, "oh, its not our fault, thats the way everyone does it!", then they are not focusing on securing their app. In my paper, I mentioned a technique to add additional layers of security to prevent such an attack.

---

I can claim that X website is vulnerable to the "there's a virus on my computer" attack, when in fact all websites I visit become vulnerable. If someone can run away with my laptop, did they exploit the websites I saved my authentication in Firefox with? Again, If they put a keylogger on my machine, did they find a Facebook exploit? Of course not... so why would exploiting a vulnerability in the network have anything to do with the web application? (****, you could MITM their bank accounts and email if they were available, who cares about FB drama)

You would have an argument if you had found attacks related to XSS, but both of your 'exploits' are in regard to malicious sniffing, and is a much more fundamental problem than anything regarding the web application. Your claims are correct in that they are real world attacks against a user of a website, but they are not web application exploits. :D

So, yes, there are ways to improve upon this sort of situation. With access to the network, however, it will always be a game of catch up over HTTP.

Knowing that the first problem was with the network, it made your "facebook exploits" title somewhat misleading. I was hoping you had found something juicy. :(

sorry to let you down in that case d34dl0k1 :(

You are a tough customer not to find this stuff juicy! Most of the time, it is the simple stuff that gets overlooked. I appreciate this isn’t an intricate hack, but it doesn’t have to be as long as it works. Take into account that there are tons of RPC based web services ARE secure even though they rely on sessions for authentication and do not transmit data via HTTPS. This is not an exploit that it allows individuals to gain root access to a Facebook server. Instead, this is an issue with Facebook’s architecture and the data they choose to transmit. By taking advantage of their system, users can easily gain full access to each other’s accounts. I completely see your point that this is a network exploit, but it is only exploitable because Facebook allows it to be. Because they put all of the information in a single area, it is easy to take advantage of. If they were to spread the load out, meaning store some information on their servers, and other information in a client’s cookie, they could create a much more secure service. You can have the attitude that because it is a network exploit, Facebook is not responsible. I however believe that developers should attempt to secure their service as much as possible. Facebook can implement several techniques to prevent users from attacking each other.

This exploit is not solely related to sniffing attacks at all. In fact, in my paper i describe how a user can obtain the same kind of data using an XMLHttpRequest in a signed script. Also, the Mozilla browser suffered from a bug that allows scripts to violate the same site origin policy not long ago. I just pointed out that all a malicious hacker has to do is steal cookies to gain access to a users account. There are tons of ways to do this. Facebook expects a secure network connection, and a secure browser. If web developers rely on browser developers and IT engineers, and if browser developers and IT engineers rely on web developers, then the service will never be secure. I believe that Facebook needs to step up to the plate and do everything in their means to create a safer application.

Facebook would use your argument in its defense. The fact that it is a network issue is not good enough however, since they do have the ability to protect against it. Vulnerable exploits are vulnerable exploits. It doesn’t matter how the attacker gets in, what matters is that the attacker got in. I appreciate your funny examples of physical attacks, but most companies take this sort of stuff very seriously. There is a reason why lots of collocations are locked down and have cameras all over.

We have had a similar discussion here recently. It was regarding e-mail services (Hotmail etc).

Whilst the authentication may take place over a secure connection, the rest does not, so can be intercepted.

A large part of the problem seems to be where the service does not recognise the user logging out, so the session remains open until some magic housekeeping process takes place :rolleyes:

In my opinion it is a fundamental session management issue, and is not restricted to FaceBook by any means.

I would note that it seems to be prevalent amongst "free" services?

:(

Quote:

---

Originally Posted by nihil

A large part of the problem seems to be where the service does not recognise the user logging out, so the session remains open until some magic housekeeping process takes place :rolleyes:

In my opinion it is a fundamental session management issue, and is not restricted to FaceBook by any means.

---

Facebook now properly destroys sessions, so that has been taken care of. I went to work and noticed that flickr also suffers from sessions stealing. Their hashing algorithm computes the same session key each time. The result is that if you gain access to a single packet containing a logged in user's session key, you can always log in as that user. My paper was about how Web 2.0 companies do not place emphasis on security and privacy, and choose to focus on incorporating new features. A malicious user can completely wipe out an innocent user's flickr account, or destroy a user's facebook profile or picture database. I really think companies need to do something about this. Sessions need to be made much more secure by storing unique information on the client side as well as the server side.

Quote:

---

The result is that if you gain access to a single packet containing a logged in user's session key, you can always log in as that user.

---

That is a user security problem I would have thought. Why should the provider of a FREE SERVICE be expected to worry?

Please remember that the majority of users of the internet are connecting in a way that is secure anyway. Unsecured wireless is not mandatory and networks are still largely corporate. Corporate networks are supposed to be secure and should not be used for these services anyway?

The first question has to be, how did someone access the packets in the first place?

Quote:

---

Originally Posted by nihil

That is a user security problem I would have thought. Why should the provider of a FREE SERVICE be expected to worry?

Please remember that the majority of users of the internet are connecting in a way that is secure anyway. Unsecured wireless is not mandatory and networks are still largely corporate. Corporate networks are supposed to be secure and should not be used for these services anyway?

The first question has to be, how did someone access the packets in the first place?

---

Nihil, free or not, web 2.0 is based upon user generated content. If a user does not trust a service, they will not submit private content. If a user knows that anyone can easily obtain his/her credentials, then what is the point of a login?

Accessing packets for malicious purposes is illegal as we all know. However, just because something is illegal doesnt mean that it is not done on a frequent basis. I agree that we should stop people from accessing packets as they travel along to their end destination, however I also believe that it is up to the service to protect themselves as best as possible. Imagine a jewlery shop with giant glass windows without an alarm system or bars anywheres. Smashing a window open to steal the goods inside is illegal, but it is very easy to do, and will probably happen sooner or later. We can only then hope that the bad guy is caught. I believe however that the jewlery store also has a responsibility to rely on additional protective measures to ensure that the bad guy cannot break in (alarms, bars, etc...). Facebook (and many other Web 2.0 sites) provide the bare minimum amount of security. Instead, they rely on the network and the browser to be secure. The UNIX philosophy is do one thing, and do it right. By relying on others to protect their service, you can bet that there will be several exploits.

Web 2.0 sites will not change their security policy until users start making a fuss about the data they upload. Yes, Facebook and Flickr are free, but adding additional layers of security is not difficult and helps to build user trust.

Quote:

---

Nihil, free or not, web 2.0 is based upon user generated content. If a user does not trust a service, they will not submit private content.

---

I would imagine that the vast majority are not aware that there might be an issue.

Quote:

---

If a user knows that anyone can easily obtain his/her credentials, then what is the point of a login?

---

But anyone cannot do that. For example this is a wired ADSL connection that will only work down my telephone line ........... how can you easily intercept my traffic and obtain my credentials?

If the majority of people used wireless and/or a communal network such as in a school or college then there might be an issue, but this does not describe the majority of users. In that situation it is really a case of the environment being fundamentally insecure in the first instance.

Quote:

---

If a user does not trust a service, they will not submit private content.

---

I would not have thought it was a good idea to submit private content anyway?

You do have a point about assumptions being made. Many sites assume that you have a secure connection, because in the case of most private individuals that is probably true?

They also assume that it is your responsibility to make sure that your system is secure.

I would certainly accept criticism of sites for poor session management as that is just bad housekeeping. Most of the rest is really down to the user not understanding the insecurity of what they are doing.

EDIT: I suppose you need to consider what these sites are about. They are supposed to be communities? I guess that when they were conceived nobody really thought about security because they didn't see them as potential targets for malicious people?

The fact that they are personal in nature possibly led them to that conclusion.

I don't know the details of how FP and Flickr work, but I would be curious to know if the cookie is still required after the session has been established? If it isn't, then deleting it would seem to be a solution.

Otherwise only use these services in a discrete session and clear your cookies afterwards?

http://antionline.com/showthread.php?t=274878

That is the other thread about this sort of thing but relating to e-mail services :)

Quote:

---

Originally Posted by nihil

I would imagine that the vast majority are not aware that there might be an issue.

---

Thats where education and awareness programs comes into play :)

Quote:

---

Originally Posted by nihil

But anyone cannot do that. For example this is a wired ADSL connection that will only work down my telephone line ........... how can you easily intercept my traffic and obtain my credentials?

---

I don't know how you define easy, but there are generally many ways to take advantage of a security exploit. MITM attacks are the simplest, so I used them for reference. There have been many browser "hacks" that allow scripts to violate the same site origin policy. Signed scripts allow for this as well. It would be easy to send a random user on a subnet far far away a link that would perform some type of XSS attack. Maybe not a 10 minute hack, but still very possible.

Quote:

---

Originally Posted by nihil

If the majority of people used wireless and/or a communal network such as in a school or college then there might be an issue, but this does not describe the majority of users. In that situation it is really a case of the environment being fundamentally insecure in the first instance.

---

Here in the US, most of the people on Facebook are college kids. In fact, emarkerter released a survey stating that Facebook is the most visited site for females ages 17 - 25. (http://www.emarketer.com/Article.aspx?1004636) My campus’s wireless network is open and insecure. If I were to stick up a wireless repeater behind a hub, and sniff the link waiting for people to join, I could easily sniff their traffic. Obviously, this is illegal and would most likely get me kicked out, but it IS possible to do, and I wouldn’t be surprised if some have gotten away with it. The fact of the matter is that just because something is illegal, people/corporations shouldnt assume that it wont be done. There best bet is to implement additional security features.

Quote:

---

Originally Posted by nihil

You do have a point about assumptions being made. Many sites assume that you have a secure connection, because in the case of most private individuals that is probably true?

---

I dont mean to sound paranoid, but I never assume an online connection is secure. I think that web services should implement additional layers of security in order to render my experience more secure. Obviously, there is a limit as to what a company should do, but just because I use their free service doesnt entitle my account to be randomly hacked. In fact, if my account ever was hacked while using a free service, I would probably never upgrade to the full version!

Quote:

---

Originally Posted by nihil

They also assume that it is your responsibility to make sure that your system is secure.

---

You are right and they are unfortunately wrong. No one should assume anything about my system. Building a web service that is only capable of running in a certain browser, with JavaScript enabled, for a Windows machine is a very bad approach. Again, obviously most web services wont be able to support every single browser and set up out there, but still, I would expect a larger service like Flickr or Facebook to take the time to ensure that their services work properly (and securely) on most systems. They can't do much about a keylogger as d34dl0k1 pointed out, but they definitely should be doing all they can do!

Quote:

---

Originally Posted by nihil

I would certainly accept criticism of sites for poor session management as that is just bad housekeeping. Most of the rest is really down to the user not understanding the insecurity of what they are doing.

---

Unfortunately we live in a world where very few users actually are aware of the dangers they face on the Web. I believe that the few individuals out there with knowledge must stand up to protect the rights of others. Users upload tons of pictures on Flickr and Facebook. If my friends had the entire “first year of college” picture album erased by some punk hacker, I am sure they would be pissed. Just because users aren’t aware of a vulnerability doesn’t mean that the vulnerability shouldn’t be fixed.

Quote:

---

Originally Posted by nihil

EDIT: I suppose you need to consider what these sites are about. They are supposed to be communities? I guess that when they were conceived nobody really thought about security because they didn't see them as potential targets for malicious people?

The fact that they are personal in nature possibly led them to that conclusion.

I don't know the details of how FP and Flickr work, but I would be curious to know if the cookie is still required after the session has been established? If it isn't, then deleting it would seem to be a solution.

Otherwise only use these services in a discrete session and clear your cookies afterwards?

---

yup, cookies are still required after login for both sites. I really do think that the best solution is to store the user's IP address inside of the spawned session. If someone tries to access the site with the same cookie credentials but the wrong IP address, they will be denied access. If they attempt to spoof the IP address, then the server will respond to the spoofed IP address and NOT the malicious hacker. The innocent user's machine will deny the packet automatically because there was never a request made. Information should be stored both on the client and server side. If all of the necessary information is stored in one area, it is very prone to failure and attack.

After researching this stuff and developing a lot of crap myself, I have come to the conclusion that Web 2.0 still has a huge amount of room for improvement. My paper talks about web services incorporating technologies that renders their site more vulnerable to being exploited. Sure there is more eye candy and fancy features, but if someone can destroy my entire account, then what is the point? As sites rely on more technology, they must also be willing to dedicate the time and assets to create a secure user experience. Web services should not bet on the fact that their users are too dumb to understand security vulnerabilities, and they should not just assume that the browser and network are secure.


Sorry nihil for writing you a textbook ☺ Thank you very much for your comments! I really do think that we need more people thinking about this sort of stuff and realizing how much change is needed.

Well I think that I know the answer to this one:

Quote:

---

Sure there is more eye candy and fancy features, but if someone can destroy my entire account, then what is the point?

---

Literally hundreds of millions of dollars when they sell these outfits on........just look at YouTube for example.

Quote:

---

In October 2006, Google Inc. announced that it had reached a deal to acquire the company for US$1.65 billion in Google's stock.

---

As for e-mail, just look at the difference between paid for services and free ones.......... that IS deliberate you know?

Quote:

---

Originally Posted by White_Eskimo

I really do think that the best solution is to store the user's IP address inside of the spawned session. If someone tries to access the site with the same cookie credentials but the wrong IP address, they will be denied access. If they attempt to spoof the IP address, then the server will respond to the spoofed IP address and NOT the malicious hacker. The innocent user's machine will deny the packet automatically because there was never a request made. Information should be stored both on the client and server side. If all of the necessary information is stored in one area, it is very prone to failure and attack.

---

Hey Nihil, I was hoping we could change the direction of the conversation so that I can get your input about my suggested fix.


What do you think of storing unique information on both the server and client side. In order to protect NATed users, I recommend storing both the user's IP address and his/her MAC address. Because each IP address must be mapped to a single MAC address according to RFC 826 (ARP), a malicious hacker on the NATed subnet cannot spoof a user's account. If she/he were to make a request and spoof the correct user's MAC address, the NAT router would attempt to route the packet back to the computer with the original user's MAC address where it would be dropped. I think that this is the best solution. The only downside is that the server needs to store more information in RAM. Do you see any failures or problems with this approach that I may have overlooked? Thanks!

Webservers can't grab MAC addresses, and IP addresses can fluctuate. IP based authentication is only feasible when your audience never changes.

Regardless of that, MAC spoofing is trivial, IP spoofing is more complicated. MAC addresses are only used at the data link layer... :)

Quote:

---

Originally Posted by d34dl0k1

Webservers can't grab MAC addresses, and IP addresses can fluctuate. IP based authentication is only feasible when your audience never changes.

Regardless of that, MAC spoofing is trivial, IP spoofing is more complicated. MAC addresses are only used at the data link layer... :)

---

What if web servers COULD get the MAC address (it was passed in with the HTTP header)? Right now the only unique information about the client is that stored in the User-Agent portion of the header. That could be used instead of a MAC, but using a MAC would be much safer. I appriciate that IP addresses fluctuate, but not at a significant rate. Chances are high that a session will expire prior to your machine releasing its DHCP address. Even if your machine does release the DHCP address, DHCP is based on caching, so you will most likely get the same address again. If you have multiple IP addresses on the same computer, things will probably get a little bit more complicated... Any suggestion as to how to handle that case?

In the end of the day, the goal is to create additional security layers. Right now, gainning access to an account is as simple as copying and pasting information. Like d34dl0k1 mentioned, there are lots of web services out there that fall victim to poor session management. They can claim that it isnt their fault, but in fact they should still attempt to preventing such an attack.

Quote:

---

What if web servers COULD get the MAC address (it was passed in with the HTTP header)?

---

The EFF would hang you, and this kind of authentication is what public key cryptography is for anyway. There are things like MD5 CHAPS, but SSL is sexier anyways.

Quote:

---

Right now the only unique information about the client is that stored in the User-Agent portion of the header.

---

Sorry, this is very wrong. No header data is unique except data stored in cookies or sent via get or post (and intended to be)

Quote:

---

I appriciate that IP addresses fluctuate, but not at a significant rate.

---

Load balancing / proxies will cause IP's to fluctuate on every request (significant). Again, only feasible with a controlled audience...

Quote:

---

Chances are high that a session will expire prior to your machine releasing its DHCP address. Even if your machine does release the DHCP address, DHCP is based on caching, so you will most likely get the same address again. If you have multiple IP addresses on the same computer, things will probably get a little bit more complicated... Any suggestion as to how to handle that case?

---

see previous, unfortunately. It's good that you're being innovative, but these types of solutions aren't developed because successful ones are already available... they are just expensive when scaled. :)

It sounds to me like you have some catching up to do... but that's what college is for, right? :D

Cheers mate
dl

MAC addresses are easy to change and therefore spoof. Its actually an option in windows device manager if you know where to look. You don't need anything other than the OS.