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?

Do you have a valid usecase in mind, with a specific risk profile (if so please add it), or are you trying to find out how to bypass a 3rd party's captive portal? — AviD, Jun 09 '11 at 23:33
This seems to be too much on the black hat side, and as such is out of scope for this site. Feel free to bring the question inline with the faq and we can re-open. We are looking at ways to make questions like this more appropriate - this is not a 'black hat hackers site' - as per the faq it is for security professionals in an enterprise environment (with some leeway around that, I guess) — Rory Alsop, Jun 11 '11 at 00:04
There is absolutely nothing blackhat about this question, more than any other attack scenario being explained on this site. The answer to this question outlines interesting attacks just the same as any presentation given at a security conference. Would it make any different to edit to ask how to secure a captive portal against potential exploits? Also, the faq does nothing to restrict the community to enterprise environments. — Sonny Ordell, Jun 11 '11 at 01:40
@Rory, please explain again why this question violates the FAQ, or suggest a meaningless semantic change that you will be fine with. — Sonny Ordell, Jun 11 '11 at 12:22
From the faq: Black Hat vs White Hat -This site is not intended to be a resource for Black Hats, or malicious hackers. While we understand discussion of exploits may require examples, if the question looks too much like a request for attack tools or mechanisms to spread a virus, it may be moderated. Show us where the value is to a security professional, ie white hat rather than black hat. Yes, it would be different to provide info on securing a captive portal- much more value. — Rory Alsop, Jun 11 '11 at 14:51
@Sonny, now I like the question after your edit, I even +1'd it. :) — AviD, Jun 14 '11 at 15:53

score 11 · Answer 1 · answered Jun 09 '11 at 16:37

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

score 7 · Accepted Answer · answered Jun 10 '11 at 11:03

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

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.
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.

Would like to add that on my school's network you can just bypass our NAC manager by using Linux... wooo, security! — cutrightjm, Jan 31 '14 at 04:54

score 5 · Answer 3 · answered Jun 09 '11 at 17:36

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.

score 3 · Answer 4 · answered Jun 14 '11 at 17:20

3

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.

answered Jun 14 '11 at 17:20

Jeff Ferland

38,090
9
93
171

@Jeff why is this? Surely unauthenticated users could first be in a vlan with no external access? – Sonny Ordell Jun 14 '11 at 22:44
Moving them to another VLAN is usually done by MAC address. MAC addresses can be cloned. Without a persistent encrypted or signed connection that the data is over, the session can be hijacked by cloning. – Jeff Ferland Jun 15 '11 at 01:01
@Jeff, so if you spoofed a MAC address in vlan2 from vlan1, you would automatically transition to vlan 2? – Sonny Ordell Jun 15 '11 at 01:38
In an open WiFi network, definitely. In most other instances, that is also likely. – Jeff Ferland Jun 15 '11 at 02:32
@Jeff, is there any way to prevent that? – Sonny Ordell Jun 15 '11 at 03:08
The channel that all packets are on needs to be individually secured. VPNs and WPA2 are options. – Jeff Ferland Jun 15 '11 at 22:50
I mean is there a way to stop automatic vlan transition. That would surely stop mac spoofing from working. – Sonny Ordell Jun 16 '11 at 06:26
On a wired network, yes. On a wireless, no. – Jeff Ferland Jun 16 '11 at 14:22
1

@Jeff, why does wired vs wireless make a difference in this context? – Sonny Ordell Jun 17 '11 at 14:36
2

In the case of a wired connection, you can physically assign a port on the switch to be on a certain VLAN. With wireless, you are precluded from physical assignment and are fully dependent on the MAC address. – Jeff Ferland Jun 17 '11 at 15:12

Threat assesment for a captive portal

4 Answers4

Linked