Hacker News Reader

Comment by sktrdie | Hacker News Reader

How was the hacker able to get Facebook credentials? Facebook uses HTTPS and so does Live.com. Even if I'm connected to a malicious router, only me and Facebook know about the data we're sending each other.

Am I missing something or should the author of this article provide more evidence on the type of attack?

View on HN

I suspect it's not plain old sniffing. He might give fake DNS records to point to his own phishing site (facebook clone). It's trivial to re-post the credentials to the real facebook check the password and then actually log them in. curl can be used to do this, as I am sure many others.

Edit: SSL does not have to be used on the clone. Most people will not notice/care.

You can't spoof a certificate with DNS. Even if you spoofed a DNS response and made facebook.com point to 192.168.1.2 then the server at 192.168.1.2 (which could be yours) would still need a valid certificate for facebook.com.

The only way to have done this is by having the user click "continue" or "ignore" or something on an ssl error page. I know from experience that a company full of programmers will happily do that. Only a few percent would go "wait a minute, this is Facebook. That certificate should be valid." Some people here might reply "no way", but HN generally contains the one percent.

Edit: This is almost correct. You can actually prevent being redirected from http to https when typing in "facebook.com" without https:// in front. My bad.

Still though, the attentive user would notice the missing padlock. I check it 3/4 times, and 4/4 times when using a public network. I also refrain from using http sites where I log in (some forums I visit do that). But again, probably less than one percent of the tech people do that.

If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.

Yes! I just thought of this and was going to edit it in, but you are quicker. Many websites still don't use HSTS, and in any case this article is from a few months ago (I remember reading it) and HSTS is pretty new.

https://hstspreload.appspot.com/ says they don't use HSTS as a preload. They should...

Facebook seems to be doing some client sniffing to decide whether to set the headers..

In my browser (FF nightly), I see the HSTS header, with the value: "max-age=15552000; preload"

If I do a request with curl, no header... (which is probably what this app sees).

I don't have a clue why they are doing that, though. Not that curl would do something with the HSTS header anyway, but still...

Facebook has HSTS preload on www.facebook.com, but not on the redirect from facebook.com->www.facebook.com. I suppose they have their reasons

Google.com also doesn't seem to have it.

Google only uses a certificate pin and doesn't force SSL. Sadly.

> If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.

This is not entirely correct. HSTS[0] was designed to protect against such attacks.

It's true, however, that not every browser out there supports it yet, and you must visit the website at least once without MITM for the server to successfully communicate HSTS header. (In Chrome certain domains are included in built-in list[1], though.)

[0] https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_s...

[1] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...

Perhaps you haven't seen the certificate errors for quite a while, but they are now quite forceful about you not clicking OK. The Ok is hidden.

SSL Strip does works here

also, most people are not savvy enough to check the ssl credentials or to even see that they are not on a ssl enabled site. even if the phishing attack was slow, people have lower expectations for speed in a coffee shop.

If an attacker controls the access point he could do the following:

* Redirect all HTTPS traffic to an HTTP spoof site. Many users probably wouldn't notice.

* If the attacker has access to a short, 2-3 character domain, they could redirect to a wildcard HTTPS connection like, https://facebook.aa.com/ - again, many users wouldn't notice. They'd see "facebook" and the lock icon and assume they're ok.

* In either case the attacker could simply proxy all HTTP requests from victim to Facebook (or any other site). So the user's browsing experience remains the same but all passwords, cookies and personal info are logged. Scary stuff!

Probably don't even need a short domain. Facebook.login.secureauthredirectsystem.moregibberish.com probably would seem sorta legit. After all, Microsoft's auth systems do crazy stuff like that. So does the moronic Verified by Visa system - it's something like "ww2.secpayment.com" and looks totally sketchy but it's legit.

So does MasterCard (for "3D Secure" 2 factor auth) - I had to do a whois/traceroute on the domain before I trusted it the first time.

Can you clarify the first point more? I would assume that if the user is able to connect to "facebook.com", then the connection would immediately go to HTTPS and the router could not "forcefully redirect" or do anything to the connection.

Alternatively, I could imagine a situation where the router hijacks the _DNS_ request for Facebook to a malicious site. Is that what you were referring to?

Don't know if this works still today... but I've definitely used it before: http://www.thoughtcrime.org/software/sslstrip/

I think that attack is exactly what HSTS (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is meant to solve.

HSTS and bookmarks... along with settings increasingly built in to a lot of browsers should make it all but impossible to MITM facebook.com.

There is a bit of a weak link with DNSSec, but in truth there are WAY easier ways to get someone's Facebook ID once you can spoof traffic to them.

You can't redirect https traffic to http, without having valid certificate. But of course with all these CA problems, it could be possible to arrange one. It's then another story, if users use http -> https recirection in first place. Due to leaving the https prefix out from the url when connecting the site very first time. That's immediate security fail, but it's up to users to get this straight. HSTS won't help because due to privacy mode, all data between browser sessions will be purged, including HSTS data. Any failure to purge any data between sessions, could break privacy, because then it's known that you have already visited that site. But these questions are quite complex. Which is best configuration for each situation needs to be very carefully considered. I personally like DANE, if I would be running any serious service, I would configure it. Some of my friends have already done that.

In the original Dutch article (https://decorrespondent.nl/845/Dit-geef-je-allemaal-prijs-al...) the author explained in the comments that they used SSLstrip for facebook and live.com So, the connection was over HTTP and not HTTPS. They added a padlock favicon.ico image to give the impression the site was secure

Ah. I wonder how hard would it be to extend protocol to let Facebook, for example, state that they will never go https again, so that browser would scream.

If you meant to say "never go http again", then the protocol for that already exists.

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

https://plus.google.com/+JoshuaBerg/posts/YrdsMzYzotr

https://hstspreload.appspot.com/

That is cool, thank you!

Isn't this exactly what HSTS is for?

sslstrip might explain that, but don't most major sites use HSTS these days?

Probably sslstrip: http://www.thoughtcrime.org/software/sslstrip/

Reply on news.ycombinator.com