9 ms·

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

by sktrdie 12y ago

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?

zokier 12y ago
sslstrip might explain that, but don't most major sites use HSTS these days?
xamolxix 12y ago
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.
- lucb1e 12y ago
  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:// 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.
  - MisterNegative 12y ago
    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.
    - lucb1e 12y ago
      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.
    - iancarroll 12y ago
      https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ says they don't use HSTS as a preload. They should...
      - Wilya 12y ago
        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...
      - zokier 12y ago
        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
      - ma2rten 12y ago
        Google.com also doesn't seem to have it.
        iancarroll 12y ago
        Google only uses a certificate pin and doesn't force SSL. Sadly.
- weaksauce 12y ago
  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.
leepowers 12y ago
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/ 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!
- MichaelGG 12y ago
  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.
  - voltagex_ 12y ago
    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.
- huntaub 12y ago
  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?
  - smtddr 12y ago
    Don't know if this works still today... but I've definitely used it before: http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/
Maxnuf 12y ago
In the original Dutch article (https://decorrespondent.nl/845/Dit-geef-je-allemaal-prijs-als-je-inlogt-op-een-openbaar-wifi-netwerk/25988820-b2a600e1 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
- k_bx 12y ago
  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.
  - Quentangle 12y ago
    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 http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://plus.google.com/+JoshuaBerg/posts/YrdsMzYzotr https://plus.google.com/+JoshuaBerg/posts/YrdsMzYzotr https://hstspreload.appspot.com/ https://hstspreload.appspot.com/
    - k_bx 12y ago
      That is cool, thank you!
  - DasIch 12y ago
    Isn't this exactly what HSTS is for?
thomble 12y ago
Probably sslstrip: http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/

by sktrdie 12y ago

zokier 12y ago

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

xamolxix 12y ago

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.

lucb1e 12y ago
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:// 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.
- MisterNegative 12y ago
  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.
  - lucb1e 12y ago
    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.
  - iancarroll 12y ago
    https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ says they don't use HSTS as a preload. They should...
    - Wilya 12y ago
      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...
    - zokier 12y ago
      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
    - ma2rten 12y ago
      Google.com also doesn't seem to have it.
      - iancarroll 12y ago
        Google only uses a certificate pin and doesn't force SSL. Sadly.
weaksauce 12y ago
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.

leepowers 12y ago

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/ 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!

MichaelGG 12y ago
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.
- voltagex_ 12y ago
  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.
huntaub 12y ago
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?
- smtddr 12y ago
  Don't know if this works still today... but I've definitely used it before: http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/

Maxnuf 12y ago

In the original Dutch article (https://decorrespondent.nl/845/Dit-geef-je-allemaal-prijs-als-je-inlogt-op-een-openbaar-wifi-netwerk/25988820-b2a600e1 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

k_bx 12y ago
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.
- Quentangle 12y ago
  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 http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://plus.google.com/+JoshuaBerg/posts/YrdsMzYzotr https://plus.google.com/+JoshuaBerg/posts/YrdsMzYzotr https://hstspreload.appspot.com/ https://hstspreload.appspot.com/
  - k_bx 12y ago
    That is cool, thank you!
- DasIch 12y ago
  Isn't this exactly what HSTS is for?

thomble 12y ago

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