3 ms·

HSTS is a great mechanism to help protect against this. Although it assumes the user has visited the site previously within the HSTS expiration period. There’s

HSTS is a great mechanism to help protect against this. Although it assumes the user has visited the site previously within the HSTS expiration period. There’s also the HSTS preload list: https://hstspreload.org/ https://hstspreload.org/

beachy 2y ago
How does this help if the evil portal is an entirely new destination for the victim?
goldpizza44 2y ago
Interesting site on hsts. I don't think HSTS will help if he is running his own WWW site on his laptop with a proper CA signed cert. If I understand correctly his laptop was presenting a proper WWW login page presumably over HTTPS after victims connected to his WIFI. What he was probably faking was the redirect to the Identity Provider (IDP) by staying on his own properly credentialed HTTPS site which would pass all HSTS checks. He may have also been faking DNS responses to keep users where he wants them.
- omegabravo 2y ago
  How would they have got a proper CA signed cert for a domain they don't own? HSTS will only make a HTTPS connection. Without the valid certificate, they should get a warning. The only way this "works" is if a captive portal pops up a browser to a site that looks the same like amaz0n.com. Password manager wouldn't popup, but many people don't use them. Faking DNS also won't help with the TLS warning, they won't have the certificate. Basically, this shouldn't be possible with HSTS.
  - rahimnathwani 2y ago
    > How would they have got a proper CA signed cert for a domain they don't own? No need. People probably don't look closely at the domain name.
- willhackett 2y ago
  Exactly this. Apple devices in fact use a domain https://captive.apple.com/ https://captive.apple.com/ to detect when to redirect to a captive portal which will grant the user access to the internet. HTTPS isn't used here because the captive experience is to re-write all DNS lookups to a local IP to serve the captive experience. This experience would just redirect the user to a site they've never been to before, say: wa-man-likes-your-data.com. This could have a legitimate signed cert from anywhere and look legitimate to the device with a lock icon. Put the airline's logo and a form for PII, wait a couple of hours and you've collected a plane load of data. I used to think about doing something similar but as an education campaign. Similar to Phishing Simulators at large corporates, I had the idea to display a captive page that explained what the user did and how they can learn to avoid it in future. Apple & Google should really make it clearer on phones that users are joining untrusted networks, especially any network not implementing Wi-Fi Certified Passpoint (Hotspot 2.0).
  - 2024disan 2y ago
    [flagged]
  - 2024disan 2y ago
    [flagged]
  - omegabravo 2y ago
    as I understand it, it would be http://captive.apple.com http://captive.apple.com so that the captive portal can intercept and write their own login.
    - willhackett 2y ago
      Yes, my brain auto-corrected me to HTTPS.
ajsnigrutin 2y ago
Meh, easily avoided. Just do a captive portal redirect to "google.johnsmith.example.com" with a properly signed certificate, add google logo and login fields, and after a user enters his credentials, just redirect them to actual google.com. Most people don't look at domains in the url. You can actually probably register a domain like "freegooglewifi.com" or something.
rty32 2y ago
Criminals are smart enough to skip any of that -- they'll trick you into opening a site that has the "same" domain and looks the same, except that the domain uses a Unicode character that is just a tiny bit different from the real one. (Thank you ICANN!) I get junk email from them every day. Even if just 1 out of 50 people fall for this, they get a good payout. And that's just one of the many possible scenarios. When you control someone else's Internet, there is a lot of things you can do. Google's certificate transparency is going to help a lot here, but only as much as what happens in a browser.
VoodooJuJu 2y ago
HSTS does absolutely nothing to protect against evil portals. These portals aren't spoofing DNS for google.com, they're typically displaying their own TLS-enabled site with a familiar-looking login flow, i.e. "Log in with Facebook/Google/Amazon to access Wi-Fi."

beachy 2y ago

How does this help if the evil portal is an entirely new destination for the victim?

goldpizza44 2y ago

Interesting site on hsts. I don't think HSTS will help if he is running his own WWW site on his laptop with a proper CA signed cert. If I understand correctly his laptop was presenting a proper WWW login page presumably over HTTPS after victims connected to his WIFI. What he was probably faking was the redirect to the Identity Provider (IDP) by staying on his own properly credentialed HTTPS site which would pass all HSTS checks. He may have also been faking DNS responses to keep users where he wants them.

omegabravo 2y ago
How would they have got a proper CA signed cert for a domain they don't own? HSTS will only make a HTTPS connection. Without the valid certificate, they should get a warning. The only way this "works" is if a captive portal pops up a browser to a site that looks the same like amaz0n.com. Password manager wouldn't popup, but many people don't use them. Faking DNS also won't help with the TLS warning, they won't have the certificate. Basically, this shouldn't be possible with HSTS.
- rahimnathwani 2y ago
  > How would they have got a proper CA signed cert for a domain they don't own? No need. People probably don't look closely at the domain name.
willhackett 2y ago
Exactly this. Apple devices in fact use a domain https://captive.apple.com/ https://captive.apple.com/ to detect when to redirect to a captive portal which will grant the user access to the internet. HTTPS isn't used here because the captive experience is to re-write all DNS lookups to a local IP to serve the captive experience. This experience would just redirect the user to a site they've never been to before, say: wa-man-likes-your-data.com. This could have a legitimate signed cert from anywhere and look legitimate to the device with a lock icon. Put the airline's logo and a form for PII, wait a couple of hours and you've collected a plane load of data. I used to think about doing something similar but as an education campaign. Similar to Phishing Simulators at large corporates, I had the idea to display a captive page that explained what the user did and how they can learn to avoid it in future. Apple & Google should really make it clearer on phones that users are joining untrusted networks, especially any network not implementing Wi-Fi Certified Passpoint (Hotspot 2.0).
- 2024disan 2y ago
  [flagged]
- 2024disan 2y ago
  [flagged]
- omegabravo 2y ago
  as I understand it, it would be http://captive.apple.com http://captive.apple.com so that the captive portal can intercept and write their own login.
  - willhackett 2y ago
    Yes, my brain auto-corrected me to HTTPS.

ajsnigrutin 2y ago

Meh, easily avoided. Just do a captive portal redirect to "google.johnsmith.example.com" with a properly signed certificate, add google logo and login fields, and after a user enters his credentials, just redirect them to actual google.com. Most people don't look at domains in the url. You can actually probably register a domain like "freegooglewifi.com" or something.

rty32 2y ago

Criminals are smart enough to skip any of that -- they'll trick you into opening a site that has the "same" domain and looks the same, except that the domain uses a Unicode character that is just a tiny bit different from the real one. (Thank you ICANN!) I get junk email from them every day. Even if just 1 out of 50 people fall for this, they get a good payout. And that's just one of the many possible scenarios. When you control someone else's Internet, there is a lot of things you can do. Google's certificate transparency is going to help a lot here, but only as much as what happens in a browser.

VoodooJuJu 2y ago

HSTS does absolutely nothing to protect against evil portals. These portals aren't spoofing DNS for google.com, they're typically displaying their own TLS-enabled site with a familiar-looking login flow, i.e. "Log in with Facebook/Google/Amazon to access Wi-Fi."