Facebook can and should be held liable for clear failings on the behalf of their security team.
Absolutely no backend code should be pushed out that isn't first audited by a security company. God knows they can afford it, and mistakes like this could end up being much more costly to Facebook (stock price, lawsuits, etc).
Crap like this makes it clear that not only are critical changes to the security infrastructure at Facebook not at all audited (in-house or outsourced!) for even the most ludicrously-obvious security vulnerabilities, but also that Facebook itself does not take even begin to take security seriously.
And this is completely ignoring the fact that it took them five days to acknowledge such a critical issue, which is a further symptom of Facebook's sheer apathy to the security, privacy, and data of their users, both corporations and individuals alike. To think that a company/website like Facebook, containing as private and personal information as Facebook profiles have, and with such incredible monetary and technical resources at its beck and call cannot even triage incoming vulnerability reports correctly makes absolutely zero sense.
This isn't quite fair. The difficulty of writing completely secure software is out of comparison with the difficulty of finding vulnerabilities.
First, it's a numbers game. There are order magnitude more people trying to break the product than there are people trying to make it secure (dev team vs. rest of the world?). As a developer you are ALWAYS at a disadvantage.
Second, different objectives. As a vulnerability seeker you only have to find one weakness, while as a developer you attempt to write securely everywhere. This just isn't realistic. The best developers can do is try as best they can. There is no indestructible software.
Third, the response and fix time is actually good? If anything - 5 days is incredibly good turn around. We don't know what else is going on, what other crazy vulnerability may have been reported at this time or being worked on previously, etc. While security is important it is unrealistic to imagine that the team in charge of these kind of fixes is all that large or has infinite resources.
It is hard (impossible) to secure something like Facebook fully. I agree with the other sentiments that if anything their crowdsourcing efforts have been quite successful. If you are unhappy with a 5 day turn around - start looking for another solution. I think you'll be hard pressed to find anything 1) more secure, and 2) with quicker responses to security issues.
Some bugs are incredibly complex, and you can't just pay some large sum of money to have them all fixed beforehand. They're basically crowdsourcing security and it seems to be working quite well.
The website at blog.fin1te.net contains elements from sites which have been reported as “phishing” sites. Phishing sites trick users into disclosing personal or financial information, often by pretending to represent trusted institutions, such as banks."
The home page doesn't produce this message, even though the linked article is summarized there. Clicking on the article from the home page also produces this message.
Nonetheless, very simple yet very clever exploit! I'm sure someone kicked themselves pretty hard over that one.
This is mindbogglingly bad. How did they manage to introduce a dependence on unauthenticated client-side state for such a critical operation in a relatively new feature?
If they weren't willing to hit the database to recall the profile_id for the reset operation, it makes me wonder whether the confirmation codes are in fact deterministic, rather than randomly generated.
This root of this bug (exposing profile_id or some user identifier in a hidden field and passing it to the server as a parameter) is incredibly common, and super easy to exploit via inspect element.
We have a rails test that we give dev candidates, and red flags go up when we see this happening (which is far more often than I'd like to admit). Kind of scary that there's likely a bunch of production code floating around that is so easily hackable.
I don't know how I feel about the reward amount since probably it equates to 2 months of the salary (I'm estimating around 100k/year) of a facebook dev. Depends on how much time you spend searching for an exploit, the real reward would be getting some fame about your skills rather the 20k figure.
A side note - the SMS confirmation code text should explain what is going to happen when the code is used. Along the lines: "Facebook mobile confirmation code ds3467hj. Note. Entering this code would link this phone to your Facebook account".
Otherwise, if the SMS is just "confirmation code ds3467hj" it is overly easy to create a phishing attack which results in the user (striving to get access to some resource, like a magazine article for example) in entering the code on an attacker web site.
Looks more like a 1 day window. Bug was acknowledged on the 28th of May and fixed the same day. This post is almost a month after-the-fact - 26th of June.
This bug shows us, how bad their software really is and that all the PHP crap on their frontend can access every data from every users. If they have had a "middleware" between frontend and database, such kind of bugs weren't possible.
Anyone remember the bug as everyone had access to private photos of Marc Zuckerberg?
Oh my goodness a anti PHP comment in a Facebook thread. Who would have guessed?
Facebook has some of the best engineers in the world. They also have their own modified version of PHP.
And really it doesn't what they use, they could use Lua and still have this issue. Don't think just because ebay used C++ or cgi or what ever they used doesn't mean ebay didn't ever have issues. Same goes for every other site/language out there.
Please don't get confused, there are foolish people utilizing every programming language all the time. PHP may be disproportionately more popular than other programming languages but it hardly deserves the blame.
[+] [-] ComputerGuru|12 years ago|reply
Absolutely no backend code should be pushed out that isn't first audited by a security company. God knows they can afford it, and mistakes like this could end up being much more costly to Facebook (stock price, lawsuits, etc).
Crap like this makes it clear that not only are critical changes to the security infrastructure at Facebook not at all audited (in-house or outsourced!) for even the most ludicrously-obvious security vulnerabilities, but also that Facebook itself does not take even begin to take security seriously.
And this is completely ignoring the fact that it took them five days to acknowledge such a critical issue, which is a further symptom of Facebook's sheer apathy to the security, privacy, and data of their users, both corporations and individuals alike. To think that a company/website like Facebook, containing as private and personal information as Facebook profiles have, and with such incredible monetary and technical resources at its beck and call cannot even triage incoming vulnerability reports correctly makes absolutely zero sense.
[+] [-] nkarpov|12 years ago|reply
First, it's a numbers game. There are order magnitude more people trying to break the product than there are people trying to make it secure (dev team vs. rest of the world?). As a developer you are ALWAYS at a disadvantage.
Second, different objectives. As a vulnerability seeker you only have to find one weakness, while as a developer you attempt to write securely everywhere. This just isn't realistic. The best developers can do is try as best they can. There is no indestructible software.
Third, the response and fix time is actually good? If anything - 5 days is incredibly good turn around. We don't know what else is going on, what other crazy vulnerability may have been reported at this time or being worked on previously, etc. While security is important it is unrealistic to imagine that the team in charge of these kind of fixes is all that large or has infinite resources.
It is hard (impossible) to secure something like Facebook fully. I agree with the other sentiments that if anything their crowdsourcing efforts have been quite successful. If you are unhappy with a 5 day turn around - start looking for another solution. I think you'll be hard pressed to find anything 1) more secure, and 2) with quicker responses to security issues.
[+] [-] runn1ng|12 years ago|reply
This individual saw the bug, announced it to Facebook using their bounty program, they fixed it pretty fast and gave him money. What more do you want?
[+] [-] t0|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] SpikedCola|12 years ago|reply
"Warning: Suspected phishing site!
The website at blog.fin1te.net contains elements from sites which have been reported as “phishing” sites. Phishing sites trick users into disclosing personal or financial information, often by pretending to represent trusted institutions, such as banks."
The home page doesn't produce this message, even though the linked article is summarized there. Clicking on the article from the home page also produces this message.
Nonetheless, very simple yet very clever exploit! I'm sure someone kicked themselves pretty hard over that one.
[+] [-] ihsw|12 years ago|reply
[+] [-] deadfall|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] nly|12 years ago|reply
If they weren't willing to hit the database to recall the profile_id for the reset operation, it makes me wonder whether the confirmation codes are in fact deterministic, rather than randomly generated.
[+] [-] GuiA|12 years ago|reply
[+] [-] prostoalex|12 years ago|reply
[+] [-] guynamedloren|12 years ago|reply
We have a rails test that we give dev candidates, and red flags go up when we see this happening (which is far more often than I'd like to admit). Kind of scary that there's likely a bunch of production code floating around that is so easily hackable.
[+] [-] quackerhacker|12 years ago|reply
Every time I hear the reward amounts, it entices me to divert my attention to finding bugs and loopholes in systems. :/
[+] [-] lalos|12 years ago|reply
[+] [-] vxNsr|12 years ago|reply
Also good to see that the finder was amply rewarded for his effort.
[+] [-] dchichkov|12 years ago|reply
A side note - the SMS confirmation code text should explain what is going to happen when the code is used. Along the lines: "Facebook mobile confirmation code ds3467hj. Note. Entering this code would link this phone to your Facebook account".
Otherwise, if the SMS is just "confirmation code ds3467hj" it is overly easy to create a phishing attack which results in the user (striving to get access to some resource, like a magazine article for example) in entering the code on an attacker web site.
[+] [-] benguild|12 years ago|reply
[+] [-] fatbat|12 years ago|reply
[+] [-] mayank|12 years ago|reply
[+] [-] mknappen|12 years ago|reply
5 Days to Acknowledge: Yipes!
[+] [-] r2qgFKq2XxnxCBr|12 years ago|reply
[+] [-] BESebastian|12 years ago|reply
[+] [-] 3327|12 years ago|reply
[+] [-] nilsjuenemann|12 years ago|reply
Anyone remember the bug as everyone had access to private photos of Marc Zuckerberg?
http://www.telegraph.co.uk/technology/facebook/8938725/Faceb...
Same auth-bypass shit.
[+] [-] dubcanada|12 years ago|reply
Facebook has some of the best engineers in the world. They also have their own modified version of PHP.
And really it doesn't what they use, they could use Lua and still have this issue. Don't think just because ebay used C++ or cgi or what ever they used doesn't mean ebay didn't ever have issues. Same goes for every other site/language out there.
The PHP hate is getting a little old.
[+] [-] ihsw|12 years ago|reply
[+] [-] bliker|12 years ago|reply
[+] [-] thejosh|12 years ago|reply