28

I sometimes use a free Wifi service to get access to the internet.
Like most/all providers of services like this, this service employs a captive portal. So if you try to make a HTTP request (request a web page) in your browser and you are not authorised on the the network, you will only ever see the page which says "Welcome to Free -wifi network. here are our terms etc..."
I'm not interested in abusing the service for free wifi - I want to know what information (HTTP transactions) is exposed/insecure when I use this service and what persistent changes they are making to my system, i.e. hiding cookies in my browser (by using anonymous hosts).
So I connected to their wifi access point, at which point they assign my computer an IP address and DNS service etc. 

$ nmcli device show wlp2s0
IP4.ADDRESS[1]:                         192.168.12.199/22
IP4.GATEWAY:                            192.168.12.1
IP4.ROUTE[1]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]:                             123.123.xxx.xxx
IP4.DNS[2]:                             123.123.xxx.xxx

I then attempt a HTTP request - try to "browse to a webpage" while not yet authorised. (Being HTTP this request/response will be unencrypted, no identity check on the server handling the request [via. SSL certificate authority confirmation via public / private key signatures etc]) 

$ curl 'http://placeimg.com/' -H 'Host: placeimg.com'  
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' 
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'  -v -L
*   Trying 216.243.142.217...
* Connected to placeimg.com (216.243.142.217) port 80 (#0)
> GET / HTTP/1.1
> Host: placeimg.com
>
< HTTP/1.1 302 Found
< Location: http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F357812412D8
<
* Ignoring the response-body
* Connection #0 to host placeimg.com left intact
* Issue another request to this URL:  
       'http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F35792412D8'
* Connection 0 seems to be dead!
* Closing connection 0
*   Trying 1.1.2.1...
* Connected to 1.1.2.1 (1.1.2.1) port 80 (#1)
> GET /reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F8 HTTP/1.1
> Host: 1.1.2.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
>
< HTTP/1.1 200 OK
< Date: Mon, 08 Aug 2016 02:50:16 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
< Content-type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta name="viewport" content="width=device-width"/>
        <title>Login</title>
        <h1>WiFi - Free Internet Access</h1>
This service is provided primarily for the purposes of accessing Email and light web browsing ..
....
</div>
</body>
</html>

I've truncated and redacted the output, but essentially its seems, when my browser (curl) makes a request the network is providing access to a real DNS server, I tested that further by running this -while connected to the service.

$dig +short google.com
203.118.141.95
203.118.141.123
... (basically real ip addresses for google.com)

So its seems the service is providing real, truthful information about DNS,

But even though the IP address my browser is addressing seems valid, the HTTP response coming back, is not from the intended server (its a server that has been inserted by the WiFi service). The response is

  • 302 telling my browser make a new request, to the 1.1.2.1/reg.php server and URL
  • the response from that server/URL is the "captive portal" page.

When make a HTTPS request

$ curl 'https://google.com/' -H 'Host: google.com' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -v -L
*   Trying 216.58.220.142...
* connect to 216.58.220.142 port 443 failed: Connection refused
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Failed to connect to google.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: Connection refused

The request outright fails - I'm assuming because my computer won't accept a connection from a remote host it can't authenticate?
So my question is, is this a "man in the middle" type interception at the TCP/IP level? in other words, when the network stack on my computer tries to establish a TCP connection with the placeimg.com server, by starting a 3 way handshake, is the Wifi services gateway or network node responding to my SYN with an ACK/SYN and saying yes I'm that server you wanted to talk to - lets complete our TCP connection, then once established its pre-programmed to automatically send the HTTP redirect and then, because my browser is actually generating the next request to 1.1.2.1 itself - all the "funny business" can stop and its all normal HTTP/HTML behaviour from that point forward. (ie. standard form filling and submissions as you would on any normal website)
If not, how is this gateway intercepting and re-routing my requests while I am an "unauthenticated" user?

the_velour_fog
  • 727
  • 6
  • 15
  • 5
    "I'm assuming because my computer won't accept a connection from a remote host it can't authenticate?" -- Nope, the firewall implementing the captive portal is actually rejecting your connection attempts to port 443 until you accept the ToS. An intercepted HTTPS connection would cause an *untrusted certificate* type of error, which would look very different from "Connection refused" or "Network is unreachable". – Ben Voigt Aug 08 '16 at 16:26
  • 1
    "*what persistent changes they are making to my system, i.e. hiding cookies in my browser*" - if your browser saves untrustworthy cookies on your system, the blame should be placed on the browser developers / the browser. Supposedly a "user-agent" acting on your behalf, but all to often a double-agent working inside your trust field taking orders from the other side. – TessellatingHeckler Aug 08 '16 at 18:09

2 Answers2

33

So my question is, is this a "man in the middle" type interception at the TCP/IP level?

Yes, this is a man in the middle type interception which is easy for the access point because it is actually in the middle of your connection to the internet. Such redirects to the capture portal are easily done with a packet filter.

The usual way is that once you've authorized (logged in, accepted terms, whatever...) a temporary rule will be added to the packet filter of the access point which takes preference to the redirect rule and allows direct access to the internet.

techraf
  • 9,141
  • 11
  • 44
  • 62
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 2
    when you say *packet filter*, thats a firewall - right? e.g. `iptables` (netfilter) – the_velour_fog Aug 08 '16 at 04:23
  • 4
    @the_velour_fog: yes, I mean a packet filter like iptables, ipfw, pf etc. Such packet filter can be used to built a firewall but I don't consider the pure ability to filter packets not a firewall yet. – Steffen Ullrich Aug 08 '16 at 04:28
  • I know what you mean, that makes perfect sense, so by default the packet filter will have a rule like `iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.1.2.1:8080` once you are authorised then the packet filter will add a rule like `INSERT at TOP of FORWARD chain - this IP address x.x.x.x (my computer) - should be forwarded as per normal` – the_velour_fog Aug 08 '16 at 04:38
  • @the_velour_fog: yes, see also [google: iptables captive portal](https://www.google.com/search?q=iptables+captive+portal) for lots of examples on how to build such a portal. – Steffen Ullrich Aug 08 '16 at 04:48
  • 4
    As a previous developer of enterprise routers I can verify that this is exactly how we do it, iptables hacking. – slebetman Aug 08 '16 at 11:06
9

When make a HTTPS request The request outright fails - I'm assuming because my computer won't accept a connection from a remote host it can't authenticate?

It seems they aren't even trying to intercept your HTTPs connection and instead are just blocking it.

Some captive portals will try to intercept the HTTPs connection resulting in a certificate error in your client.

I've also seen some captive portals that let HTTPs though even for unauthenticated users.

So my question is, is this a "man in the middle" type interception at the TCP/IP level? in other words, when the network stack on my computer tries to establish a TCP connection with the placeimg.com server, by starting a 3 way handshake, is the Wifi services gateway or network node responding to my SYN with an ACK/SYN and saying yes I'm that server you wanted to talk to - lets complete our TCP connection, then once established its pre-programmed to automatically send the HTTP redirect and then, because my browser is actually generating the next request to 1.1.2.1 itself - all the "funny business" can stop and its all normal HTTP/HTML behaviour from that point forward. (ie. standard form filling and submissions as you would on any normal website)

Yep, that is the normal way to do it. If the captive portal server is linux based the "REDIRECT" or "DNAT" targets can be used to divert your traffic to the captive portals webserver which can then issue the redirect. Other stateful firewalling systems likely have similar options.

These systems are generally pretty flexible, so if the portal operator wants to offer access to particular parts of the internet (for example a payment gateway so you can pay them) without authentication they can easilly do so.

When you authenticate successfully the captive portal can put in place a rule that overrides the redirection rule allowing you normal access to the internet.

Note that any (non-secure) cookies set for the website you tried to visit will be sent to the captive portal webserver. It's up to the implementer of the captive portal whether they actually do anything with them.

Peter Green
  • 4,918
  • 1
  • 21
  • 26