Hacker News new | past | comments | ask | show | jobs | submit login
The Inside Story of How Facebook Responded to Tunisian Hacks (theatlantic.com)
105 points by ssclafani on Jan 24, 2011 | hide | past | favorite | 43 comments



I have a bit of a problem with the description of the hack as "The software was basically a country-level keystroke logger"

I think this is unnecessary dumbing down.

For most readers who already knows what a keylogger is, it should be fairly obvious to them that this is not what they were doing.

For any reader who does not know what a keylogger is, describing the hack as being like a keylogger is not going to help them understand.

Furthermore, if you are in the demographic that know what a keylogger is, but can't see how that it is obvious that is not what was going on here, it just obscures what was really at play here: authenticating over (unencrypted) HTTP.

The writer probably did not want to make this a story about authenticating over HTTP, but misdescribing a central feature of the story is misleading.


I thought this too, but if you go look at what was actually done, 'keylogger' is a fairly accurate description.

They were injecting a Javascript keylogger, not doing packet sniffing or the like. Not the same as a keylogger actually running on your OS, but I would say still the correct term.

Facebook sends login credentials over HTTPS, they aren't so dumb as to authenticate over HTTP. But they serve their login page over HTTP which is what allowed the Javascript keylogger to be 'installed'.

(edit)

PS Here's a link to the purported exploit: http://www.hackerzvoice.net/node/105


I've spent time arguing with some fairly large and supposedly security-minded entities, about just this practice -- delivering login forms over HTTP. It doesn't matter that the specified destination is HTTPS. A MITM can do whatever they want to the form and its enclosing page while it's on its way to the client browser.

There's a quite successful startup, much beloved by HN, that has exactly this problem with one version of their sign on page. I won't say which one, because I don't want to make targeting too easy. I've been having a back and forth on a support ticket with them, after noticing the problem. They did say they followed up and looked into my concern. But they compared their design to Facebook et al. and said they were following "best practices".

An aside: Once you start using the term "best practices", you need to take a serious look at your design and engineering perspective. Especially in security, your thinking should always be challenging the established model. You may not find a better way, and you should be very skeptical of yourself when you think you have. But you need to be a bit... paranoid, always challenging the "established truths".

EDIT: To that company, if you happen to read this. I posted this after emailing you. And before the coffee fully kicked in. It wasn't my intention to create so blatant a cross reference for you to follow between me here and me in email. (I.e. not some twisted version of karma; just trying to make the point.)


The RFC curmudgeon in me says we shouldn't be using login forms anyway; we should be using HTTP Digest authentication. No passwords are sent over the wire, in the clear or not.


Whoa, this is by far the most interesting news here. It occurred to me that an evil government could hijack all HTTP requests, slip a script into the <head> and literally monitor every keystroke and click and mousemove for their web users, using their browser as the key logger and with little knowledge by the end user (unless they scan the source of every script). That's freakishly powerful spying capability, beyond just tracking and logging requests/IPs/contents.


Agreed, which is why describing it as a 'key logger' seems to miss the point.

Although admittedly I guess The Atlantic are not targeting the HN crowd.

However, the problem would have been (mostly) avoided by serving the login form over HTTPS. As most people who have used a browser have some notion of HTTPS vs HTTP, couldn't the Atlantic have credited their users with some intelligence, and mentioned the significance of that in the exploit?


I didn't see a shift from http to https in the protests day. However, pages that report anti-government news, asked their audience to use https://login. so they can open censored pages.

Back to Facebook, it had played a very important role and was key to the protests success. In the past, information is spread through word of mouth. There isn't trust, when it's spread that way and also no images or videos. The information that arrives isn't quite adequate.

Emails and forums are good, but due to Video websites censoring, they can't play an important role, since only a few fraction of the Web users in Tunisia can run a proxy.

Facebook changed everything, anti-gov. pages have from 200K to 600K fans. That's more than the half of the connected Tunisian population. In the last days, activity on Facebook was terrible, I would estimate that I post 50 to 100 videos, status and images; same for my friends.

Information spread essentially from these few pages with huge popularity. In a discussion, Admins seems to be using proxies and VPN to make secure connections and they have an anonymous Facebook account to communicate with the protesters (receive videos, photos, and information).

The urgent news would take only 30 minutes at most to spread through the network. Most of my friends, spend all the night (and dawn?) until late 4 and 5 A.M.


Good for Facebook. From the article, it sounds like they did two major things: 1) shift all Tunisian IP addresses to https instead of http. 2) anyone who logged out/in while the keylogger code was running was shown a social CAPTCHA. The CAPTCHA asks you to identify friends in photos.


I've had to answer the social CAPTCHA myself, when logging in from a different country while on vacation. Details:

You are shown two pictures of the same friend, with the tag of him/her showing (i.e. a square around them, like what you get when you hover over their name in a tagged photo). You are then asked to say which friend of yours it is, choosing from a list of around 7 names.

You can skip as many of these questions as you like, in case you've got pictures where the tag isn't very good (e.g. someone tagged a comic or something instead of an actual photo). But every question you answer has to be correct.


How can this possibly work for blind people? Facebook is already pretty inaccessible but this seems utterly impassable.


Blind people have to click on Stevie Wonder.


You are only allowed to skip twice.


I wonder if Facebook uses only photos where the tag area doesn't overlap. Many of my friends will tag the same person as themselves and their spouse so that person will see the picture. They use the tag system as pure notification.

I could see myself getting the answer wrong in this instance even though I know who the person is.


What happens when you answer wrong?


A couple of things:

1)how sure can we be that switching to SSL really got rid of the sniffing going on? I'm asking because I assume that it's totally within the capabilities of the government to sneak-install a CA certificate on clients.

Or they don't bother and trust people to just click through the security warning.

2) is that "identify your friends" check maybe a bit pointless as the needed answers can probably be determined using data from already hacked accounts.

3) playing devil's advocate here: if the laws of Tunesia allow for the government to do such things, is it Facebooks place to violate those laws? And: could they be pressed into giving away that data anyways due to political pressure from wherever?

I wouldn't use Facebook to post anything that I would not want a third party to see - unless I encrypted it beforehand.


These matters aren't binary and solutions don't have to work for all time; raising the sophistication and effort required to bulk-compromise accounts for now is a worthwhile goal.

Of course requiring SSL won't save people from widely-trusted rogue CAs, ignoring all security warnings, or even very active man-in-the-middle attacks which hide from users that SSL was ever being required. But each of those attacks requires a larger investment than tampering with a plain HTTP page.

Same with the social verifier: if the agents had already studied a specific person's network of friends, and need to break that one account, with effort they can. But their previous automatic dragnet was broken.

Facebook may have been in a stickier position if the Tunisian government had attempted a superficially 'legal' demand for user information. But the government didn't. And even if it had, unless Facebook has Tunisian offices/hosting, the government's pull over what Facebook does on its US-based servers would be very limited. To even try ordering Facebook around would have worsened the domestic discontent. (The article reports that it was rumored at one point Facebook would be blocked nationwide.)


About 2), I'm not sure how that's possible. I've written details of the method that I think they used in another comment, but basically, they're showing you tagged pictures of friends and asking you who it is. A computer will be unable to translate the picture of a friend to a name.


Why not? Facial recognition algorithms are becoming common features. I'm not saying the Tunisian government would have had the ability to drum up a hack like that, but the concept has been proven possible by several independent entities.


At this point of complexity, it might be easier for them to get a valid cert and mitm everything.


This is in french but the code used by the Tunisian dictatorship is here: http://www.hackerzvoice.net/node/105


Crazy, so if this is legit, this really is more akin to a keylogger than them sniffing the network traffic, which is what I thought was meant by it.

Tunisian IPS's were injecting some javascript code on Facebook's login page that was watching the keystrokes in the login/password fields. When someone clicked LOGIN, the script would send those credentials to a URL, but also Facebook's HTTPS login page, so everything proceeded as normal.

Interesting vector for an attack, seems like the solution, of serving the login page itself in HTTPS as well is simple (and cheap) enough that everybody should adopt it.


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

Right, for all those pre-21st century sites that still don't enforce SSL for authorization. It should be a standard, not a counter-measure.


But login requests on Facebook do use SSL- if you use firebug on the Facebook homepage, the login form points to " https://login.facebook.com/login.php?login_attempt=1 ". The issue seems to be that code is injected in pages that merely contained a login form: http://blog.rootshell.be/2011/01/13/tunisia-tracks-users-wit...


But if the page containing the form isn't served through SSL, it's subject to alteration by a man in the middle --- which is what actually happened in this case. And users who don't "view source" every single time have no way to notice the difference before logging in (and precious little after, if the logger quickly resubmits to the real McCoy).


And if the page that has the link to the login form isn't served through SSL, it's subject to alteration by a man in the middle to hijack the login page. And if the page that has the link to the page that has the link to the login form... you get the idea. Use SSL on every page, or you lose.


It is very poor security to teach your users to enter their passwords on HTTP pages. Even the small minority of technical people who check the page uses HTTPS when it posts the form do not check it every time they use the page.


Bravo, Facebook.

In short, there were indications that the government was swiping passwords on each new Facebook login. Within days, Facebook switched all Tunisian sessions to HTTPS, and required people whose passwords had likely been compromised to go through a password-reset based on identifying pictures of friends.

(Also, the article suggests that Facebook is a more important news and organizing outlet in Tunisia than Twitter.)


A tunisian citizen here. I wanted to add that this kind of attacks was not limited to Facebook. GMail, Yahoo mail and Live mail were also affected. I've checked the source code of their login pages if served over HTTP and they contained a similar JS snippet.


The broader aspect here is what is going to happen to Facebook in the longer term? Shaky Governments now must be getting very worried about this type of political activism - an entire nation can be turned around with hardly anyone marching in the streets. Or a large protest could be organised as a kind of flashmob. While it's not Facebooks problem - only one Government has jurisdiction over Facebook - I'm wondering where this will all lead to. I know I'm not the first to ponder these things, but I can't help thinking this is either a great force for good, or something that could easily be used against people. A small government like the one of Tunisia is pretty much powerless against facebook unless they turn off the entire internet in their country. And that's not likely to win friends. Just blocking the facebook IP would be bypassed easily and would spread in a viral way.

As for the anonymous activism - the power with Facebook is the real identities attached. People believe it because they know and trust the people sharing the news and images. Twitter tends to degenerate into a retweeting mess of platitudes around any major news event, and the anonymous nature of most tweets makes exaggerations and rumors spread like wildfire.


I admire the company for the steps that it took to protect the passwords of Tunisian users, but the story of how it responded surely can't help its efforts to get into China and other states that rely on information control to stifle dissent.


Perhaps the article doesn't have enough detail in it. But it sounds like ISPs were just sniffing HTTP packets for usernames and passwords.

It doesn't sound like a directed attack on facebook, though perhaps it was a session replay attack.

The real question for me, is why didn't facebook already require SSL login.


> But it sounds like ISPs were just sniffing HTTP packets for usernames and passwords

Nope, Facebook's login page, if requested over http, was manipulated on the fly to inject a javascript code that is triggered when the login button is clicked. It retrieves the login/password values from the form and sends them to another url, besides Facebook's login url.


On a related note,I hosted glype (a free proxy script) on a server in the US to help people from Vietnam access facebook. But javascript is disabled and I m having trouble enabling it. If you are interested in helping me, pm me please. My php/proxy skills are pretty limited


Governments will find it easy to target any commercial or centralized system. P2P and open source couldn't have arrived sooner.


The story's "Everybody says Twitter played a huge role, but really Facebook's role was bigger" angle suggests that Facebook PR played a big role in pushing this one.

This is not to take away from the truthfulness of the story or the awesomeness of Facebook's response. In fact, given how prominently Twitter has featured in stories about the Iranian revolution et al, this is to be expected.


Mmm, does that mean the Tunisian ISP modified the login pages from Facebook to include a key logger?


no that means that like any ISP they have full access to unencrypted traffic, including login POST requests


Actually no, they do inject code into the login pages. Here is the code injected into the FB login: http://www.hackerzvoice.net/node/105

It is not simply a case of sniffing traffic. They log what users input into the login form, via Javascript injection.


But login requests on Facebook do use SSL- if you use firebug on the Facebook homepage, the login form points to " https://login.facebook.com/login.php?login_attempt=1 ".

The issue seems to be that code is injected in pages that merely contained a login form: http://blog.rootshell.be/2011/01/13/tunisia-tracks-users-wit...


Even of the login form was submitted to a HTTPS url (which is the case), the fact that the login page was served over HTTP allows the government to inject the JS code, which will execute locally and retrieve the login and password inputs and send them via Ajax to another URL.


This is why any page that lets you login to a site must also be accessible over HTTPS-only.


Or any page that points to a page that lets you log in to a site must be accessible over HTTPS-only. Or any page that points to a page that points to a page... you get the idea. SSL everything, or you lose.


What's happening to the ISPs for collaborating with the previous government on these requests?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: