

Hijacking a Facebook Account with SMS - phwd
http://blog.fin1te.net/post/53949849983

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

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

~~~
DanBC
> Third, the response and fix time is actually good? If anything - 5 days is
> incredibly good turn around.

Yes. Especially since the code wasn't actively being exploited in the wild.

------
SpikedCola
Chrome 27.0.1453.116 (for me) says:

"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
Chrome 23.0.1271.97 (AdBlock, Ghostery, 3rd-party cookies off) and I'm not
getting any phishing warning.

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

~~~
GuiA
Probably some old code that was written in haste back in the day, and that
never got touched because it got the job done.

~~~
zeckalpha
Sounds like Facebook.

~~~
wikwocket
Are you kidding? Sounds like every company everywhere.

~~~
hobs
Yuuuuup. People think FB is free of these problems because they have written
some highly performant code and have a shit ton of money. Nope, money doesnt
cure laziness and definitely doesnt cure "it works so why fix it".

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

------
quackerhacker
Great ingenuity in finding authentication flaws. It's exactly what I told a
friend who is learning programming...it's all trial and error.

Every time I hear the reward amounts, it entices me to divert my attention to
finding bugs and loopholes in systems. :/

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

~~~
quackerhacker
Oh I'd keep the check stub and photocopy it onto my resume (just kidding).

Considering exploits are _supposed_ to be hard to find (why they're large
bounties), it's just the incentive/hush money to pay the hacker, because you
have to consider a few things...

1) why and how did you find the exploit (were you trying to hack someones
account, stumble upon it [that's lucky], are you a security firm [meaning you
have success in this before], were you black hat contracted, ect).

2) a hacker would prefer the recognition [possible employment], the reward
[sandwiches aren't free], and release of liability [a company may still file
charges for probing their systems 'weev,' is an example]

I can think of very few vulnerability testers that have gained employment at
the companies where they find the exploits. Comex is one I can think of off
the top of my head (created the jailbreak for iphones, landed an internship at
Apple, then career Google).

~~~
nucleardog
The biggest reason I see for the payouts is simple:

That exploit has a value on the 'black market'. If it comes down to "no money"
or "$20k", people are going to be looking at the "something" instead of
"nothing", no matter what the laws say.

The bug bounties don't always have to be a lot - most people will want to do
the right/safe thing anyway. They just have to offer _some_ incentive (we've
all seen some success with even $800 bug bounties) to keep the honest people
honest.

~~~
ihsw
If someone needs a monetary incentive to be honest then they're not honest, in
fact they're quite the opposite.

~~~
quackerhacker
I don't agree that the motivation would be _to keep the honest people honest_.

There's nothing wrong with having a talent and wanting to make a living from
it.

~~~
ihsw
On the contrary, we're in the position to do an incomparable disservice to the
world. Companies buy exploits simply to buy the hacker's silence, and
governments buy exploits to bolster their offensive military capabilities --
when we sell to them we're complicit with the damage they do.

Personally I'm of the opinion that the only responsible disclosure is full and
anonymous disclosure.

------
vxNsr
This is an incredibly simple (and dangerous) hack, I'm happy to see it was
neutralized so soon after being discovered.

Also good to see that the finder was amply rewarded for his effort.

------
dchichkov
Nice.

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
Looks like an easy $20,000. :)

------
fatbat
Looks like there was a 2-day window between when the reveal post was made vs
when Facebook fixed it.

~~~
mayank
Facebook isn't a startup; I'm surprised it took 2 days to be honest. This
should have been an all-out panic mode, level-1 alarm and push.

~~~
xmodem
Given that at any big company, every change (even a critical security fix!)
has to go through review and QA, most startups are probably better equipped to
fix this sort of thing than most big companies.

------
BESebastian
I'm surprised this ever made it into production. Never, ever trust user input.

------
3327
So how much does a facebook 0-day go for these days anyway?

------
nilsjuenemann
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?

[http://www.telegraph.co.uk/technology/facebook/8938725/Faceb...](http://www.telegraph.co.uk/technology/facebook/8938725/Facebook-
privacy-flaw-exposes-Mark-Zuckerberg-photos.html)

Same auth-bypass shit.

~~~
bliker
Blaming technology is the worst. From the nature of the bug I think it was
just some if missing somewhere.

~~~
tene
I'm sorry, but did you even read the article? The exploit is explicitly
stated, it's trusting unauthenticated client state. That's a fundamental
design flaw in the intended behaviour, not an accidental coding error. They
gave the profile ID to reset to the client when serving the page, and then
blindly used whatever profile ID the client sent when submitting the form. The
fix was to fetch the profile ID for the authenticated user instead of sending
a profile ID on a round-trip through the client.

I certainly agree that the problem wasn't the technology here, but I disagree
with your conclusion. "some if missing somewhere" is far easier to avoid
technologically than a high-level design flaw like this. It's fairly easy for
a type system to notice that not all cases in a conditional are accounted for,
but it's much harder for a type system to understand that it's inappropriate
to use client-submitted data as a profile ID for a password reset request (as
opposed to operations like submitting a friend request, where it's perfectly
valid).

