Threat assesment for a captive portal

Question

I am interested in setting up a captive portal on a wireless network.

From what I understand I would do this by initially having all guests in a temporary vlan, moving them to the real vlan when authenticated or against some other criteria.

What threats should I look out for that people may be able to bypass the captive portal and access the network?

Should attacks against the webserver be my primary point of concern, or are there network level attacks I should look out for as well?

(Mod Edit- for the threats you list, what mitigation scenarios are effective)

Answer 1

There are two different ways captive portals / hotspots are bypassed:

1. Either using tunneling of some kind, usually using the DNS protocol because clients have the outgoing port 53 open, or through http/https, or using icmp to tunnel or other similar wats. @Ori has provided examples of this.

2. Another way is by directly bypassing the authentication mechanism: Ultimately all hotspots have to authenticate a client, and this is (usually) done through the MAC or IP address or cookies. On certain occasions these can be spoofed or sniffed to get an already authenticated session by impersonation. There may even be configured certain devices in the network, with hardcoded mac or ip address that are pre-authenticated, eg. printers, and you can take their address.

Answer 2

We were discussing a technique in another thread that would likely accomplish this. NSTX and ICMPTX both take advantage of common protocol holes that organizations have. NSTX is the most likely candidate since it's not likely the organization with the captive portal prevents access to the DNS proxy/server you're using to resolve the captive portal name.

If you can issue a DNS query to resolve your nameserver then you're pretty much set. This requires you manage your own DNS machine externally, but with EC2 costing what it does figure you're out 20 bucks a month to accomplish this task.

NSTX essentially uses the DNS query mechanism as a data channel. Pentesters have been using this technique for a while, and the idea is not new (botnets have even used DYNDNS C-Name resolution to create passive C&C structures.) It's a dirty world, but DNS administrators have done a great job of creating a shadow network to pass your traffic around.

A quick reference: http://think-security.com/ip-over-dns/

Good ol' Howto: http://thomer.com/howtos/nstx.html

Answer 3

From the captive portal implementations that i have seen, after association to the AP and agreeing to/authenticating via the captive portal, the MAC address is the denominator is an allows list of sorts.

The best scenario is if there is a white list for specific users to not have to go through the captive portal. If you notice that someone is not sand-boxed by the portal, spoof their mac address and it's very likely that you will be automagically be tossed in an active VLan or removed from whatever sand-boxed group that would otherwise be forced to.

Aside from the above, which is a remote possibility, the NSTX and ICMPTX perspective presented by @Ori is an excellent idea.

Answer 4

I have never encountered a captive portal that was successful at preventing the transmission of traffic by somebody. Aside from the technique of having a complicit external host to transmit your data through DNS and ICMP tunnels, changing your MAC address to mirror somebody else's address will treat you to a connection.

I believe the only way to control this is to require a VPN connection to be established. I presume that we don't see that in practice because it is a nuisance for the end user to configure and presents a loss limited to the fee for access. Compared to customers choosing not to pay for a connection because of the hassle of secure setup, this is usually considered an acceptable loss.