19

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?

Improve this question
8
  • You meant WiFi right?
    – this.josh
    Commented Jun 9, 2011 at 19:58
  • 3
    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 ♦
    Commented Jun 9, 2011 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 ♦
    Commented Jun 11, 2011 at 0:04
  • 1
    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
    Commented Jun 11, 2011 at 1:40
  • 2
    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 ♦
    Commented Jun 11, 2011 at 14:51

4 Answers 4

Reset to default
7

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.

Improve this answer
1
  • Would like to add that on my school's network you can just bypass our NAC manager by using Linux... wooo, security!
    – cutrightjm
    Commented Jan 31, 2014 at 4:54
11

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

Improve this answer
5

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.

Improve this answer
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.

Improve this answer
10
  • @Jeff why is this? Surely unauthenticated users could first be in a vlan with no external access?
    – Sonny Ordell
    Commented Jun 14, 2011 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 ♦
    Commented Jun 15, 2011 at 1:01
  • @Jeff, so if you spoofed a MAC address in vlan2 from vlan1, you would automatically transition to vlan 2?
    – Sonny Ordell
    Commented Jun 15, 2011 at 1:38
  • 1
    @Jeff, why does wired vs wireless make a difference in this context?
    – Sonny Ordell
    Commented Jun 17, 2011 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 ♦
    Commented Jun 17, 2011 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .