All that is wrong with the world…

September 19, 2011

Another minor Facebook security issue

Filed under: Tech — Tags: , , — allthatiswrong @ 11:38 pm

I noticed a recent flaw in Facebooks security resolution process recently. After being asked to confirm my identity simply because I was using a different computer, I apparently took too long to identify my friends in their photos. However, I was able to try two more times before being locked out. In which case Facebook provided the exact same photos with the same selection of people to name in order to confirm my identity. What this means is that I could conceivably attempt to logon to a victims Facebook account from an unauthorized device to get such a prompt, and then take my time to research the answers.

Twenty minutes was the approximate time before my session expired, which gives roughly one hour to come up with the answers. This may not seem terribly difficult given the proclivity with which people tag their friends or publish photos on blogs. It would be even easier if the victim and attacker had a mutual friend in common on Facebook, as they would likely be able to see a lot more photos. In fact, perhaps even searching each name in Facebook could show the face, which would allow for the questions to be answered correctly.

This isn’t a minor flaw in any sense of the word, however it does seem quite possibly that the process as it is now implemented could be abused in conjunction with other vulnerabilities to gain access to someone’s account. I hope that at the least this will foster some interesting discussion on why what I have described is a non issue, or result in a fix.

November 5, 2010

Thoughts on Firesheep

Filed under: Security — Tags: , , , , , , — allthatiswrong @ 3:25 am

The last week there has been a lot of discussion over the release of the Firesheep addon for Firefox. Firesheep made the news because it allows anyone to impersonate someone on the same network on the vast majority of websites on the net. This is known as session hijacking or “sidejacking”. The problem occurs because most websites only encrypt the login process which prevents people from sniffing your username and password, but they then redirect to a non-ssl site which allows people to steal your session cookie – the unique identifier that tells a site who you are after you have logged in. If someone has hijacked your session they don’t have your username and password, but will still be logged in as you.

There has been a bit of controversy over Firesheep because some people are convinced that the person who wrote the extension should be held accountable or at the least did something wrong. Nay. Those people are simply misguided. Releasing a tool like Firesheep is the essence of responsible disclosure. The generally agreed process for dealing with exploits is to contact the developer privately to work on a fix, and reveal the exploit with the fix so both the company and researcher get credit. If the developer refuses to fix the flaw, then a proof of concept exploit is released to push the developer into doing the right thing. Firesheep is simply another proof of concept exploit for a problem that has been around for many many years. It isn’t like people were not made aware at least once before.

Facebook seems to have been getting the most press, although most sites are vulnerable. Most web email services, Amazon, other social networking sites, forums….pretty much anything you can think of. The strange thing is that most people don’t seem to care. This is generally because people don’t understand the risk or think that they won’t be a target. This is why the release of something like Firesheep is a good thing, a fantastic attempt at actually illustrating the threat. No doubt its use will become more widespread and as more people start to get taken advantage of, there will be a greater push for security that will benefit everyone.

I found it interesting that somebody went to the trouble of writing FireShepherd. FireShepherd is a tool that exploits a bug in FireSheep to prevent it from working. It doesn’t accomplish anything, and will likely be rendered obsolete in the next version. If something like FireShepherd was to be useful it should pollute the waves with fake sessions, although even this would not work terribly well.

I wanted to clear up some misconceptions that have sprung up in the wake of Firesheeps release, as a lot of bad advice seems to be being given out. First of all, logging out does not automatically make you safe. Many websites do not necessarily invalidate the session upon logout, which means even if you have logged out whoever is hijacking your session can continue to do so.

You are not automatically protected by using an encrypted wireless network. WEP does not encrypt client traffic for authorized clients and besides can be cracked in seconds. WPA/2 PSK means it uses a Pre-Shared Key. This means anyone with that key can decrypt traffic for the other clients. Firesheep may not work, but it would not be difficult to adapt it to do this. Even on a wired network you may not be safe due to ARP poising or MAC address overflow attacks.

Some people have recommended using a VPN or SSH tunneling which are one of the best solutions. They are not immune however it is a whole lot less likely that someone is sniffing anything from your ISP’s connection upwards than it is that there will be some douchebag at Starbucks looking for someone to take advantage of. Either of these solutions are the best at present as they allow you to encrypt all traffic to a point where only employees or authorized personnel would have access to take advantage of your unencrypted sessions.

What most people have been suggesting is to use an extension that forces sites to use SSL all the times. The two most suggested addons are HTTPS Everywhere by the EFF and Force-TLS. NoScript also has this capability. There is a similar addon for Chrome called KB SSL Enforcer however it is quite insecure at present. Due to the subpar Chrome extensions framework every site request will be http first, so session cookies will still be leaked and can be abused.

Each of these addons make use of HSTS which rely on the server to have support. If the server does have support then the entire session can be encrypted. Unfortunately not many sites support this at present, and forcing an SSL session by rewriting http requests is not ideal. Some websites will break if you try this, such as chat no longer working in FaceBook. Some sites may not load at all as they will depend on http content for various reasons, such as hardcoded links or content from another domain. Even if a website supports wholly SSL sessions there may still be information leaks, such as AJAX requests or a fallback to HTTP happened to Google a few years ago.

The only decent solution is for websites to implement sitewide SSL . Secure cookies, and SSL for everything from the login and after. No fallback to just HTTP, at all. Of course, this approach has gotten some criticisms. People claim that SSL is too expensive, however this simply isn’t true. Google showed earlier this year that having SSL as the default option for Gmail increased server load only %1. If Google can manage this, Facebook and Amazon sure as hell can. People are saying the performance will be diminished because you can’t cache with ssl however this is false, you just have to set Cache-control: public. Then there are people who complain about needing a dedicated IP, which is also false. Basically, in this day and age, there is very little reason not to have an entire encrypted session for anything remotely valuable. It is appalling that so many companies and sites have ignored this problem for so long and I think it is great that Firesheep has brought attention to the problem, again.

Of course, I don’t expect anything to change although in another few years there will probably be a similar tool released and the discussion will start up again, at which point there truly won’t be any excuse for default non-encrypted sessions to be so prevalent.

Update – November 11th 2010

A few days after I wrote the above, a tool called BlackSheep was released which aims to help people detect someone using Firesheep on a network. The tool does as I said above, sending fake sessions and reporting when one is accessed. I haven’t looked at it in detail but I would think it could easily be mitigated either by learning to identify the type of sessions BlackSheep sends out or finding some other way to detect or disable it. This just gets into a never ending cat and mouse game all the while ignore the real problem.

I was made aware of an addon for Firefox, SSLPasswdWarning. This addon will alert you if your password or sensitive information will be transmitted over an insecure connection, so is useful in helping to determine if there is a risk or not.

March 25, 2010

Facebook’s security check is anything but.

Filed under: Security, Tech — Tags: , , , , , — allthatiswrong @ 10:31 pm

When logging into Facebook from either a different location, a security check will come up with an alert asking you to identify yourself. I tend to travel around a lot, and so this is very annoying. I use Facebook quite infrequently, I can only imagine how annoying it would be for those that travel and use the site daily. What’s worse here is that a different location is not necessarily a different city or even country, but can just be a different computer. For example, if you login at an internet café 10 minutes from your house for whatever reason, the warning will come up. This also adds to Facebook’s poor history of privacy, as for this check to work they must be maintaining a record of all the locations you use Facebook from. Logfiles are one thing, but actively maintaining a record of your location history for commercial gain is something else.

The fact that an account is signing on from a different location is in no way an indication of malicious activity. I don’t really understand the moronic reasoning that could have thought this was a good idea. Perhaps if the account was active in two different locales within a reasonable time difference, but simply from a different location? As stupid as the security check may be in the first place, it is made worse in that it is not effective in any way. The only information it asks you to enter to authenticate yourself is your birthday. Information that most people on Facebook make publically available without a second thought. Even if they don’t, it’s not exactly the hardest info to find out. Why not ask for the user to reenter their password, which would help protect against many type of session stealing attacks, or to confirm the location they last logged in from. At least something that wasn’t entirely security theater because at present it accomplishes nothing and is just a frustration.

What about if the attacker doesn’t know your birthday, or you used a fake birthday to signup and don’t remember what it was? In this case Facebook will send out a security code to one of your registered email addresses. This also allows for a breach of privacy, in that all email addresses will be exposed here, regardless of if they are marked as private or not. If the attacker does not have access to one of these email accounts then this might work OK. However even this security check is flawed, as it never changes. I.E. Every time that you fail to correctly enter your birthday, the exact same security code will be emailed out! This only means you need one million attempts to successfully brute force this code. This would take several days, but for someone who doesn’t use their Facebook account that often it would allow for it to be cracked. I have not investigated too deeply, but Facebook does not seem to have any preventative measures against bruteforcing this security check.

I find it hard to believe the Facebook developers could be this stupid. It seems much more likely that this “Security Check” is actually a measure to make sure their location information for users is accurate, disguised as security theater. Then again, Never attribute to malice that which can be adequately explained by stupidity.