Slashdot Mirror
How Facebook Responded To Tunisian Hacks
jamie writes "Facebook's security team opens up, shedding light on a revolution that could become a parable for Internet activism. Quoting: 'After more than ten days of intensive investigation and study, Facebook's security team realized something very, very bad was going on. The country's Internet service providers were running a malicious piece of code that was recording users' login information when they went to sites like Facebook. By January 5, it was clear that an entire country's worth of passwords were in the process of being stolen right in the midst of the greatest political upheaval in two decades. Sullivan and his team decided they needed a country-level solution — and fast. Though Sullivan said Facebook has encountered a wide variety of security problems and been involved in various political situations, they'd never seen anything like what was happening in Tunisia.'"
Really is annoying that Facebook defaults to http
When Facebook does something right, they should be commended. They easily could have shrugged their shoulders and said, "Not our problem!"
Gamingmuseum.com: Give your 3D accelerator a rest.
makes you wonder why a country is able to steal it's Facebook user's passwords.
Article Summary: They switched facebook to use https in Tunisia.
I wish facebook would consider just switching all traffic to https.
So Facebook's sales guy called the President of Tunisia and said "Dude, you have to pay for all that user data just like everyone else does. What makes you think you're special?"
I believe the ISP changed the facebook login page to execute additional javascript to grab the entered password before it was sent off, encrypted, to the fb server. But then again I didn't RTFA...
The article is a little light on details, but am I right in thinking that people's session cookies were being sidejacked? AFAIK, despite FB not sending everything over https, the password is sent over https. So I don't see how a keylogger like approach would work to intercept the pw, unless the Tunisian government was smart enough to run something like Moxie Marlinspike's sslstrip where they did a MITM attack and sent unencrypted http traffic to the user and then stole their password. I doubt this was the case because a) they don't seem smart enough and b) no security measure would circumvent this unless people knew not to log in over http.
So now we just wait until the government uses sslstrip...
P.S. - It's unbelievable that in this day and age FB doesn't encrypt the whole session given how trivial session-jacking is.
Facebook doesn't want anyone accessing their customers' personal information unless Facebook is being compensated.
#DeleteChrome
As bad as every other site that doesn't require https:// for login.
- Dan
Add the character "2" at the end of all current passwords?
The attack may have been a little more sophisticated. Most pages are loaded over a non-encrypted connection. Just the pasword may be sent over an https connection. However, the use of unencrypted pages for everything else allows man in the middle attacks that insert a javascript keylogger into the reply that logs keystrokes directly from the source PC, not from packets as they cross the wire.
That's why FB's response was to respond to all requests from Tunisia using https. That's why GMAIL now defaults to 100% https.
The real "Libtards" are the Libertarians!
A valid point -- end-to-end encryption in both directions is required. Meaning the calls to always use https actually make sense.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Anyone who logged in during the period of time where passwords were being captured was presented with photos and asked to pick the ones featuring their friends. Then they were asked to choose a new password.
Sullivan's team rapidly coded a two-step response to the problem. First, all Tunisian requests for Facebook were routed to an https server. The Https protocol encrypts the information you send across it, so it's not susceptible to the keylogging strategy employed by the Tunisian ISPs.
Https would still be suceptible to keylogging. I won't detail how the attack would be laid out (wouldn't want to inspire potential attackers ;) ), but https won't protect from a keylogging javascript being attached to the login page by an ISP. Do your research on MIM attacks if anyone wants to find out.
So, either the solution won't work, or the attack wasn't as cleverly implemented.
And let me say which one it is: both.
I've just inspected facebook's login page, and it transmits passwords in the clear (in a POST request), protected only by a MIM-vulnerable https implementation. Yet, the article says facebook reports that their workaround "seems to work". It would only work if the attack was poorly implemented.
The ISP can run a proxy which pretends to be the user from the point of view of facebook and pretends to be facebook from the point of view of the user. It can run an https connection to facebook and forward it to the user as a plain http connection. That way it can record or change anything in the facebook session and the user probably won't be aware that the proxy is there.
The proxy could also run an https connection between the proxy and the user but that is more difficult because encryption software in the browser would alert the user that the proxy is not facebook. However if the browser has been fiddled with its game over for the user on many levels. Lots of people in the third world access the internet from internet cafes. One place I used in Malaysia has a single windows image which is booted across the LAN when a workstation is started. If the Government got their own software on to the server with that image, or changed the template for all the internet cafes then it would be impossible to guarantee security.
http://michaelsmith.id.au
Agreed, but this part of the article had me intrigued:
I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?
Not like I've RTFA or anything, or even an expert, but my guess is simply the issue of- facebook _allows_ http logins, so all a nefarious government/network need do is break https for the site. I.e. the solution is to not have an unencrypted option, such that if a gov/net breaks https, instead of falling back to an insecure login, people get pissed that they can't use the site at all, and thus it becomes a high profile news story, etc.
Once again, our friends at the EFF are ahead of the curve. Their HTTPS Everywhere extension, released a few months ago, probably would have beaten this attack by Tunisian security services, or at least made their jobs much harder.
Here's the extension: https://www.eff.org/https-everywhere
Work that donate button a little while you're there.
SSL3/TLS will only protect against MITM attacks if BOTH the client AND the server mutually authenticate. This would require the issuance of a signed certificate to the client, not something that any garden variety retail grade web service does. On the other hand it is quite possible that just using HTTPS would have thwarted the attack simply because it puts a rather higher technical barrier in place and makes it necessary to use more intrusive measures. In any case the point is a good one, HTTPS should be universal for any kind of authentication for a whole raft of reasons.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Yes, https increases CPU and bandwidth, but if you also include the benefits: reduction in staff, support, bandwidth, cpu, etc currently wasted trying to fix the resulting stolen/hijacked accounts, it would come out ahead, probably way ahead.
Tm
Support TBI Research: http://www.raisinhope.org
Meaning the calls to always use https actually make sense.
Indeed. Most (all?) those online services, whether it be yahoo, facebook or myspace have their login box accessible from their main (non https) page. Even though login itself may be encrypted, the user is not supposed to enter the https himself, but he is instead redirected to a https page once he clicks login.
It's scary how easy this is (I once did it for a friend who wanted to spy on his estranged wife), and you don't even need any funny javascript. Just have a proxy that substitutes https://login.service.com/ with http://login.service.com/ and you're set.
This also makes those obnoxiously scary "bad certificate" warnings so pointless: the smart man-in-the-middle will avoid the certificate issue entirely, and just redirect everything to non-encrypted http.
The only solution to this is to make the user aware of the process. Make it explicit that in order to login, you need to go to https://www.facebook.com/ or https://yahoo.com/ . That way, the user is forced to "do the right thing" if he wants to log in, and an interloper will have much more trouble intercepting. Instead of just hacking up a quick proxy perl script, he'll actually have to ask TunisCert to issue a fake certificate...
It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.
WTF? There's nothing wrong with disclosing the public key (hint: it's right there in the name. You can encrypt with the public key, publish the key on websites, in newspapers, hell broadcast it on national radio - it doesn't matter. That's the point. Just don't publish the private key.
'Nuff said.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
Agreed, but this part of the article had me intrigued:
I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?
It's called SSL Stripping... It's an old issue, but a recent tool has made it a bit more mainstream. There's a presentation here: http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf. And a tool here: http://www.thoughtcrime.org/software/sslstrip/
The slides are worth looking through. At the root it's a very simple concept: people do not type https into the browser, they usually get to https through a redirect from http. A MiTM can tamper with that and continue talking http with the client... or he can talk https with both client and server (two different connections), but then he needs to play some tricks to get a signed certificate for a domain that looks to the user like facebook.com.
but Sullivan said that Facebook had not seen that happen.
How would they know? the MiTM could easily talk https with facebook.
Or just find a CA that is either sympathetic to your cause or subject to your coercion.
read and weep. A list this long and spread through so many different countries is not the way to run a tight ship security wise.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register