Tegenwoordig verschijnen steeds meer ‘hotspots’ – gebieden met draadloze toegang tot internet. Bij de meeste hotspots moet worden betaald en totdat betaalde, geautoriseerde toegang is verkregen, zou internetverkeer daar niet mogelijk moeten zijn. De werkelijkheid is vaak anders.
Wanneer een computer uitgerust met een wifi-kaart wordt opgestart, zal de wifi-kaart een verbinding aangaan met de hotspot. Via een protocol genaamd dhcp krijgt de computer een ip-adres. Wanneer de gebruiker nu een browser start en naar een willekeurige url gaat, zorgt speciale software ervoor dat in plaats van de opgevraagde url een loginscherm van de hotspot wordt getoond. Daar kan dan worden ingelogd, of worden betaald met een creditkaart.
Computers op internet communiceren door pakketten te sturen naar adressen van andere computers. Een voorbeeld van zo’n adres is 192.168.1.1. Dit soort adressen is niet bepaald gebruiksvriendelijk; daarom is er het ‘domain name system’ of kortweg dns.
Met behulp van dns kunnen gebruiksonvriendelijke ip-adressen gekoppeld worden aan een veel makkelijker te gebruiken naam, ook wel ‘hostnaam’. Bij het gebruik van dns worden steeds vragen gesteld, zoals bijvoorbeeld naar het ip-adres van een hostnaam.
De antwoorden op die vragen worden gegeven in de vorm van zogenaamde ‘resource records’ (rr’s). Bij de vraag kan al worden aangegeven in wat voor rr’s de vrager geïnteresseerd is. Voorbeelden van rr-types zijn: A-records (adres), MX-records (‘mail exchange’), Cname-records (‘canonical name’; de gevraagde naam hierin is een alias van een andere naam) en txt-records (tekst).
Wanneer de gebruiker contact heeft met een hotspot, wordt meteen het ip-adres meegegeven van een dns-server. En nu komt het interessante: deze dns-server kan al worden gebruikt vóórdat men heeft betaald. De reden daarvoor is dat dns-functionaliteit noodzakelijk is om de gebruikelijke manier van inloggen op de hotspot te ondersteunen.
Tunnels
Bij legitieme dns-vragen kunnen we willekeurige informatie meesturen. Door de gedistribueerde werking van het dns-systeem kunnen we ervoor zorgen dat deze informatie aankomt op een door ons gecontroleerde dns-server op internet. Bovendien kan deze dns-server weer willekeurige informatie met de antwoorden terugsturen. De heen-en-weer gestuurde informatie kan naar believen worden ingevuld: er kunnen dus zelfs complete ip-pakketten in de vragen en antwoorden worden meegestuurd. We noemen dit soort constructies een ’tunnel’.
Een niet-geautoriseerde gebruiker van een hotspot kan dus een tunnel opzetten via het dns-protocol. Hierdoor kan hij gratis gebruikmaken van de hotspot. Uiteraard is hiervoor wel speciale software nodig. Wij gebruiken een gemodificeerde variant van Nstx (http://freshmeat.net/projects/nstx/). Een waarschuwing is hier overigens wel op zijn plaats: Nstx heeft standaard geen enkele vorm van authenticatie. Het gebruik van Nstx is dan ook een veiligheidsrisico: immers, in principe kan iedereen een tunnel creëren naar de Nstx-server op internet. Op die manier heeft iemand rechtstreeks toegang tot deze server, zonder dat tussenliggende firewalls daar iets aan kunnen doen.
Nstx gebruikt vreemde domeinnamen om ‘heengaand’ verkeer te tunnelen. Terugkomend verkeer wordt ‘verstopt’ in txt-records. Txt-vragen zijn daarvoor uitermate geschikt omdat het antwoord vrije tekst kan bevatten. Het principe werkt als volgt. De dns-client stelt als vraag: “is er txt-informatie voor ‘wat_is_de_kleur_van_gras.example.com’.” De dns-server van de hotspot speelt dit antwoord uiteindelijk door naar de Nstx-server op internet. Deze geeft als antwoord: “het antwoord is ‘groen’.” In het geval van Nstx worden dus ip-pakketten verpakt in txt-vragen en de antwoorden daarop.
Wanneer een protocol, zoals het hier gebruikte dns, de mogelijkheid biedt om stiekem informatie mee te sturen, dan spreekt men van een ‘covert channel’, ofwel een ‘verscholen kanaal’. Deze soort kanalen zijn over het algemeen ongewenst omdat ze ongecontroleerd zijn. Daardoor is immers gratis gebruik te maken van hotspots. Ook Icmp-‘echo’-verkeer (gebruikt door het ping-commando) heeft de mogelijkheid om een ‘covert channel’ op te zetten. Dus ook het toestaan van pings naar internet geeft de mogelijkheid tunnels te creëren. Wanneer betaalde toegang tot internet wordt geboden, is het raadzaam om ‘verscholen kanalen’ te herkennen en waar mogelijk uit te sluiten.
Niet betalen
Niet alle internetaanbieders weten hun installatie afdoende te beschermen tegen ongewenst gebruik, bleek uit een praktijkonderzoek in Eindhoven. Vier hotspots werden daarbij gecontroleerd: Mobilander (wlan via KPN), aangeboden in de binnenstad, net als WinQ Kenniswijk. Daarnaast bezochten we twee hotels die wifi beschikbaar stellen: het Mandarin Hotel, dat voor deze service samenwerkt met Swisscom/Eurospot, en Motel Eindhoven, dat samenwerkt met HupHop (KPN). In alle gevallen was het mogelijk om, zonder te betalen, connecties naar buiten te maken via dns.
Het valt dus blijkbaar niet mee hotspots afdoende af te schermen. Toch zijn er mogelijkheden. Zo zou men het aantal dns-vragen voor ongeautoriseerde gebruikers kunnen beperken. Een andere mogelijkheid is de dns-server zó in te stellen dat deze altijd hetzelfde antwoord geeft op vragen van de gebruiker, totdat de gebruiker geauthenticeerd is. Elke vraag om een ip-nummer bij een naam te zoeken zal dan worden beantwoord met het ip-nummer van de authenticatieserver. Hierdoor zullen automatisch alle bezoeken aan webservers uitkomen op de authenticatieserver. Een probleem is echter dat, in het geval er al een geauthenticeerde gebruiker is, zijn ip-adres wellicht kan worden misbruikt om de tunnel te creëren (dit noemt men ‘spoofing’). En tunnels zijn eigenlijk niet te voorkomen, omdat er een dns-connectie met internet bestaat.
Er blijven, om zorg te dragen voor een goede beveiliging, eigenlijk maar twee opties over. Ten eerste het detecteren van ongewenste tunnels. De manier om zo’n tunnel op te sporen is door te kijken naar het verkeerspatroon van het dns-verkeer. Normaliter zal een host niet zo vaak dns-vragen stellen, maar wanneer een tunnel actief wordt gebruikt, dan zal het aantal dns-pakketten ineens serieus toenemen. Bovendien zal het merendeel van de vragen over een en hetzelfde (sub-)domein gaan.
De tweede oplossing is het frustreren van de functionaliteit van de ongewenste tunnel. Dit kan worden bereikt door de hoeveelheid dns-vragen per tijdseenheid te beperken.< BR>
Guido van Rooij, Cto en senior security consultant van Madison Gurkha bv
