accesing internet hotspot (no WEP/WPA protection)

Data that travels over the air and how to protect (or decipher) it

Re: accesing internet hotspot (no WEP/WPA protection)

Post by thetan on Mon Mar 01, 2010 1:21 pm
([msg=35942]see Re: accesing internet hotspot (no WEP/WPA protection)[/msg])

Goatboy wrote:The first thing you should read up on is what SQL actually is. I see you already use Google, which is a big plus around here, so I'll give you this link as a freebie: http://www.w3schools.com/sql/default.asp
....
Once you understand how those technologies work together, you'll be able to understand SQL Injection.

A+ for effort. However, i happen to know a thing or two about captive portal systems on a first hand basis. I've set up a couple of them for my non profit startup free and open wireless mesh network. The likely hood of them using SQL at all for an authentication scheme is less likely then any other standard web based authentication. This is due to the nature of most captive portal systems.

Typically a captive portal based gateway is actually a stack of technologies.
  • The captive portal daemon (my fav is CoovaChilli)
  • The authentication, authorization and accounting (AAA) daemon (my fav is FreeRadius but i guess any radius or even kerberos could work)
  • The authentication engine (you can configure Radius to use MySQL, standard *nix users, flat files, etc etc)
  • The HTTP server to host the captive portal page (lighttpd ftw!!)
  • and finally a backbone CGI auth script that will authenticate via FreeRadius and upon authentication grant the user a pass through the captive portal daemon.

Now known and hard to defeat weaknesses in common captive portals include:
  • The captive portal daemon is really only capable of authenticating access via IP and MAC.
  • Most captive portals allow unregulated DNS traffic through.

The first weakness can easily be exploited via a standard MiTM attack plus a quick mac spoof (easy to change your mac addy in *nix using ifconfig)

The second weakness can be exploited by tunneling TCP over DNS packets. This will account for ridiculous network overhead as you are carrying OSI layer 3 traffic over layer 7 and that layer 3 traffic is most likely going to encapsulate layer 7 data. So it's essentially tunneling layer 7 through layer 7 resulting in far far from optimal network performance. However, it will get you through. In order for something like this to work though you're going to have to set up something like a dns2tcp server on a remote host you have access to and connect to it over the captive portal network and tunnel your traffic through that. the shitty thing is dns is a wide open and genereally "insecure protocol" so you should really only enable the server portion to access ssh and then you can establish a secure channel through SSH over DNS (ouch layer 7 through layer 7 of layer 7) but it will work and it will be secure and private on your part.
"If art interprets our dreams, the computer executes them in the guise of programs!" - SICP

Image

“If at first, the idea is not absurd, then there is no hope for it” - Albert Einstein
User avatar
thetan
Contributor
Contributor
 
Posts: 657
Joined: Thu Dec 17, 2009 6:58 pm
Location: Various Bay Area Cities, California
Blog: View Blog (0)


Previous

Return to Networking

Who is online

Users browsing this forum: No registered users and 0 guests