Fix voor hole 196?
Home › Nieuws & Pers › Wireless › Fix voor hole 196?
Fix voor hole 196?
Waarom iedereen behalve Meru er om moet vragen
Wat is Hole 196?
Security experts van AirTight Networks hebben een beveiligingsgat in het Wi-Fi WPA2 beveiligingsprotocol gevonden. Dit beveiligingsprobleem is 'Hole 196' genoemd naar de betreffende bladzijde in het IEEE 802.11 (2007) standaard document. Aan het eind van pagina 196 worden de sleutels die in WPA2 gebruikt worden, geïntroduceerd: de PTK (Pairwise Transient Key), dewelke uniek is voor iedere WiFi client en die gebruikt wordt voor unicast trafiek, en de GTK (Group Temporal Key) dewelke voor broadcast en multicast gebruikt wordt. Hoewel datavervalsing en gespoofde MAC-adressen via de PTK gedetecteerd kunnen worden, biedt de GTK diezelfde mogelijkheden niet.
De Airtight experten halen dit aan als de oorzaak van het probleem aangezien dit een client in staat stelt willekeurig broadcast pakketten uit te sturen waarop andere clients antwoorden met informatie. Airtight heeft aangegeven slechts 10 extra lijnen code toegevoegd te hebben aan de populaire, vrij beschikbare open source MadWifi driver om van een PC met een standaard wireless client het MAC adres van het Access Point te spoofen en zich als gateway voor te doen bij het uitzenden van deze trafiek. Aanvallers kunnen dit uitbuiten om het netwerk schade toe te brengen, bijvoorbeeld via denial-of-service (DoS) attacks. De enige factor die de attack moeilijk maakt, is het feit dat de aanvaller een interne, geauthenticeerde WiFi gebruiker moet zijn. Bij Airtight gaan ze er van uit dat er geen patch voor 'Hole 196' zal komen aangezien het probleem eigenlijk in de standaard vervat zit.
Wat betekent dit?
Een client op een access point gebruikt twee sleutels om zijn data beveiligd te versturen: één voor unicast trafiek (genaamd PTK) en één voor multicast en broadcast trafiek (GTK). De unicast key is uniek voor elke client terwijl de broadcast key uniek is per AP en dus per BSSID. Dit wil zeggen dat de GTK dezelfde is voor alle clients op dat AP.
Indien nu één van de eigen geassocieerde en geauthenticeerde clients deze attack uitvoert, zal hij zich voordoen als het access point waar hij en de andere clients op geassocieerd zijn. Hij zal dan broadcast berichten naar deze clients uitsturen om antwoorden van hen te krijgen met info over de PTK sleutel.
De man-in -the-middle attack bestaat erin een broadcast ARP bericht te sturen waarbij de aanvaller zijn eigen MAC adres koppelt aan het IP adres van de gateway. De clients die dit pakket ontvangen, updaten hun ARP tabel waarbij ze de aanvaller zijn MAC adres mappen naar het gateway adres. Wanneer 'vergiftigde' clients dan hun pakketten uitsturen, doen ze dit naar het access point maar met de aanvaller als destination! Dit antwoord is een unicast pakket geëncrypteerd met hun PTK. Aangezien die PTK van client tot client verschilt, wordt dit unicast bericht naar het access point gestuurd voor vertaling. Het antwoord wordt dus naar de aanvaller gestuurd, geëncrypteerd met zijn eigen PTK! De aanvaller krijgt zo de trafiek van de clients binnen en kan deze zelfs nog doorsturen naar de echte gateway zodat niemand wat merkt.
Let wel, hierbij is er geen sprake van het kraken van encryptie, noch van het breken van het authenticatiemechanisme.
In een normaal draadloos netwerk ageren Access Points als Ethernet hubs. Iedereen die geassocieerd is met dat AP is geassocieerd met dezelfde BSSID en is bijgevolg vatbaar voor de 'Hole 196' kwetsbaarheid.
Hoe wordt het opgelost?
De vraag is - indien de kwetsbaarheid in de broadcast zit, hoe stop je dan het gebruik van dezelfde shared key voor alle gebruikers bij broadcasts in een draadloos netwerk wanneer de AP zich als een hub gedraagt? Het antwoord is virtualisatie en het AP zich meer als een switch laten gedragen.
Meru's Virtual Port virtualizeert het AP voor iedere client en zorgt er voor dat iedere client zijn eigen, unieke BSSID heeft. Elke client denkt dus dat hij zijn eigen private en persoonlijke AP heeft. Bijgevolg is de broadcast key voor WPA2 uniek per client! Dit maakt het onmogelijk voor een 'slechte' client om het MAC adres van het AP te spoofen en de broadcast key kwetsbaarheid uit te buiten aangezien niemand dezelfde sleutel deelt. Meer zelfs, aangezien de client in zijn eigen 'persoonlijke ruimte' vertoeft, worden broadcast berichten enkel door zichzelf en de Meru infrastructuur gezien. De aanvaller krijgt nooit directe access tot andere clients!