dcsimg
Results 1 to 10 of 17

Thread: Facebook Exploits

Hybrid View

  1. #1
    Senior Member
    Join Date
    May 2002
    Posts
    344

    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!
    Support your right to arm bears.


    ^^This was the first video game which i played on an old win3.1 box

  2. #2
    Member d34dl0k1's Avatar
    Join Date
    Mar 2007
    Posts
    58
    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

  3. #3
    Senior Member
    Join Date
    May 2002
    Posts
    344
    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...
    Support your right to arm bears.


    ^^This was the first video game which i played on an old win3.1 box

  4. #4
    Member d34dl0k1's Avatar
    Join Date
    Mar 2007
    Posts
    58
    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.

    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.

  5. #5
    Senior Member
    Join Date
    May 2002
    Posts
    344
    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.
    Last edited by White_Eskimo; May 7th, 2007 at 09:58 PM.
    Support your right to arm bears.


    ^^This was the first video game which i played on an old win3.1 box

  6. #6
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    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

    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?


  7. #7
    Member d34dl0k1's Avatar
    Join Date
    Mar 2007
    Posts
    58
    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...

  8. #8
    Senior Member
    Join Date
    May 2002
    Posts
    344
    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.
    Support your right to arm bears.


    ^^This was the first video game which i played on an old win3.1 box

  9. #9
    Member d34dl0k1's Avatar
    Join Date
    Mar 2007
    Posts
    58
    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

  10. #10
    Senior Member Aardpsymon's Avatar
    Join Date
    Feb 2007
    Location
    St Annes (aaaa!)
    Posts
    434
    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.
    If the world doesn't stop annoying me I will name my kids ";DROP DATABASE;" and get revenge.

Similar Threads

  1. Interior Aspects of exploits...
    By n01100110 in forum Newbie Security Questions
    Replies: 4
    Last Post: October 6th, 2005, 04:26 PM
  2. how to compile exploits
    By santoshp in forum Newbie Security Questions
    Replies: 17
    Last Post: April 30th, 2003, 09:13 PM
  3. MS Exploits
    By noODle in forum The Security Tutorials Forum
    Replies: 1
    Last Post: April 19th, 2003, 05:01 AM
  4. Defeating Exploits
    By tampabay420 in forum Miscellaneous Security Discussions
    Replies: 4
    Last Post: February 4th, 2003, 09:27 PM
  5. Exploits a little confusing
    By new b in forum Newbie Security Questions
    Replies: 7
    Last Post: February 5th, 2002, 07:00 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •