Facebook Exploits

[White_Eskimo]

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

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.

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.

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!

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!

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.

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.

[nihil]

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

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.

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?

[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!

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

[White_Eskimo]

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.

[d34dl0k1]

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.

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)

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

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?

Cheers mate
dl

[Aardpsymon]

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.