Stealing Facebook HTTPS cookies with captive portal
If you visit HTTPS sites and get redirected without any warnings then the problem is that your browser doesn't correctly validate certificates - a good browser would display a warning as the captive portal's certificate does not contain the domain you wanted to visit in its common name field.
A possible vulnerability would be if you visit the site over HTTP, but there are solutions to mitigate this such as the Secure Flag on cookies that tell the browser not to send this cookie over HTTP - and HSTS which makes the browser automatically convert your HTTP requests to the site into HTTPS requests, in addition to preventing you from bypassing the certificate error if an HTTPS connection can't be made.
The behavior is browser dependent. If the browser will actually send the HTTPS request intended for Facebook to the captive portal, then it is clearly a browser vulnerability. But there are other ways to handle the situation.
I have recently had to use a network with a captive portal a few times. And in those cases I started Chromium which happened to have had a couple of Facebook tabs open from a previous session.
What happened was that a proper error message was displayed. But at the same time Chromium opened a new tab which accessed a specific HTTP URL with the actual intention to get hijacked by the captive portal. As soon as I was past the captive portal, the Facebook tabs would automatically reload and this time not get an error.
So it appears Chromium detects the presence of a captive portal, opens it safely, and finally detects once you are past the captive portal.
Similar captive portal detection exists in Android and iOS, though it is not tied to the browser but rather happens as part of associating with the access point.
I see a few misconceptions in your understanding of how captive portals are working. The captive portals I have come across certainly worked in a different way.
No interception was done for DNS traffic. As long as you used the DNS server provided through DHCP, your computer is allowed to do DNS lookups without restrictions without having accessed the captive portal.
No ICMP tricks are pulled either. Rather one of the routers on the legitimate path between your computer and the server will hijack the TCP connections to port 80. Once the TCP connection has been hijacked a redirect to the captive portal will be sent to the browser. In proper implementations this redirects to a HTTPS URL and somehow include information about the original URL such that you can be sent back there later. The entire communication with the captive portal is performed using a legitimate certificate for a domain name that actually belongs to the captive portal.
This approach works for HTTP - but not for HTTPS. The router performing the hijacking will not have a valid certificate for the site you are accessing, so in any secure browser you would get a certificate warning if the same hijacking was done for HTTPS.
There are three ways to get around this not working for HTTPS:
- Rely on users ignoring security warnings and accepting that their private information will be intercepted even after being presented for a very verbose warning about the risk.
- Rely on users understanding how it all works and on their own open an HTTP URL in order to be hijacked and then know to go to the original HTTPS URL after having passed the captive portal.
- Let client software detect the presence of captive portals and deal with it appropriately. This still relies on the users being able to spot if a captive portal is attempting to perform phishing attacks, but at least doesn't leak any cookies.