Belgische student ontdekt bug in wpa-implementatie iOS

Een Belgische student heeft een gat gevonden in de implementatie van wpa2-enterprise, waardoor een kwaadwillende in staat is een iOS-gebruiker verbinding te laten maken met een vervalst netwerk. Wpa2-personal is niet getroffen.

Normaliter moet een apparaat alarm slaan als een aanvaller een wpa2-enterprise-netwerk vervalst, maar in iOS gebeurt dat blijkbaar niet, schrijft Datanews. Daardoor kan een aanvaller toch een vervalst netwerk opzetten en verkeer van gebruikers onderscheppen. Het is niet bekend waardoor het probleem precies wordt veroorzaakt; de Belgische student die het probleem vond, Pieter Robyns, was niet bereikbaar voor commentaar.

Apple heeft het probleem bevestigd en zal het oplossen in iOS 8. Het is onduidelijk of de bètaversies van iOS 8 al voorzien zijn van een fix, of dat de patch voor de introductie van iOS 8 nog wordt toegevoegd. Toestellen die geen upgrade naar iOS 8 krijgen, zoals de iPhone 4, blijven kwetsbaar.

Wpa2-personal, dat werkt met een vooraf bepaalde privésleutel, is niet getroffen door het probleem. Wpa2-enterprise wordt, zoals de naam al doet vermoeden, vooral gebruikt in zakelijke omgevingen. Het systeem laat beheerders van een netwerk bepalen wie toegang heeft, zonder dat er privésleutels moeten worden gedeeld. Daarbij moeten gebruikers inloggen met een gebruikersnaam en wachtwoord.

Overigens hebben onbeveiligde wifi-netwerken hetzelfde probleem; er is geen goede manier om de authenticiteit van een open netwerk te controleren. Daardoor is het relatief makkelijk om een open netwerk na te bootsen door een netwerk met een naam als 'KPN' aan te maken.

Reacties (77)

[Verwijderd]

Auteur van de vulnerability hier, het gaat hier niet om een klassieke man-in-the-middle waarbij data van clients kan worden gedecrypteerd. Om het op een eenvoudige manier te zeggen gaat de aanval door middel van een vals netwerk een "halve" authenticatie uitvoeren met een iDevice. Vervolgens verbindt de aanvaller tegelijk met het legitieme netwerk en worden de authenticatiegegevens van de iDevice gebruikt om hier op in te loggen. De aanvaller krijgt in essentie toegang tot het interne bedrijfsnetwerk en het internet, zonder zelf in het bezit te zijn van een gebruikersnaam en wachtwoord. Indien er iemand graag een uitgebreidere en meer technische uitleg zou willen lezen: ik heb de paper die mijn aanval beschrijft online gezet op https://uhdspace.uhasselt...2/17013/1/p189-robyns.pdf.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:23]

[Verwijderd]

Hoe kom je hier in godsnaam achter?
Erg sterk artikel overigens, voor mij een ver van mijn bed show.

[Verwijderd]

Bedankt! Ik heb dit onderzoek gedaan in kader van mijn thesis. Een startpunt waaruit ik vertrokken ben is kijken naar de verschillen tussen Android, iOS, Windows Phone, etc. Eenmaal je begrijpt hoe alles werkt (en zou moeten werken) kan je zien of een bepaalde implementatie zodanig gebreken vertoont dat deze kunnen worden uitgebuit.

[Carrein]

Is je thesis als geheel al beschikbaar? Klinkt als interessant leesvoer!

[Verwijderd]

Ik heb mijn thesis online gezet op http://research.edm.uhass...is_pieter_robyns_2014.pdf. Veel leesplezier :)!

[Carrein]

Super, bedankt!

[NovapaX]

De aanvaller krijgt in essentie toegang tot het interne bedrijfsnetwerk en het internet, zonder zelf in het bezit te zijn van een gebruikersnaam en wachtwoord

Dit is wel een essentieel deel van jouw reactie wat niet duidelijk wordt gemaakt in het artikel. En logischerwijs (door mij ook) verkeerd werd aangenomen.

[UvAkid]

Dit is serieus.....

[soulrider]

eigenlijk heb je dus de ontdekking vanuit die defcon video van hierboven beschreven/uitgebreid?
https://www.youtube.com/watch?v=-uqTqJwTFyU
spijtig genoeg zonder ze enige erkenning te geven?
(en ga je een halfjaar/jaar na datum lopen met hun pluimen, want zij en niet jij hebben die fout in iOS ontdekt of ze in ieder geval eerder public gemaakt?)

[Reactie gewijzigd door soulrider op 22 juli 2024 15:23]

[MAX3400]

Ik vraag me af waarom dit nog niet is aangepast in recente iOS-updates; het lek zou in januari 2014 al zijn ontdekt en doorgegeven aan Apple.

Eind januari 2014 ontdekte Pieter Robyns een bug in Apple’s implementatie van WPA2-Enterprise – een IEEE-standaard in de bescherming van draadloze netwerken in bedrijven. Hierdoor is het voor hackers en misdadigers mogelijk om een vals draadloos netwerk op te zetten, waar werknemers op inloggen in plaats van op het echte bedrijfsnetwerk. Zo kan informatie over onder meer gebruikersnamen en wachtwoorden worden verzameld, die vervolgens in het echte netwerk kunnen worden misbruikt door de aanvallers.

Twee dingen die me hieraan opvallen: ten eerste zou je als beheerder van het netwerk toch een extra stukje authenticatie kunnen/moeten implementeren zoals MAC-addressen opnemen in de whitelist. Ten tweede lijken/zijn er dus bepaalde zaken die draaien op iOS-devices die dus in plaintext communiceren met het netwerk en dus onderschept/misbruikt kunnen worden.

Tja, lastig verhaal allemaal; wpa2-enterprise is/was anders vrij veilig maar ik vraag me dus af waar nu de waarheid ligt: is iOS "slecht" beveiligd en ligt daar het lek of zijn er mogelijk andere lekken in wpa2-enterprise in het algemeen waar we nog niet vanaf weten?

[Miepermans]

Misschien is het handig, om je in te lezen in "hoe WPA2-Enterprise werkt"

Alle devices hebben een per-session key(crypt) dus er word zeker niet in plaintext gecommuniceerd. Overigens is je aangedragen MAC authenticatie erg onveilig en is dit jaren geleden al als onveilig gemarkeerd.

Ik denk ook dat je dit bericht fout opgevat hebt, Mac authenticatie werkt namelijk alleen aan de accesspoint zijde, De client heeft geen mac-allow list om te bepalen met welke accesspoints hij mag connecten. Dit is overigens ook onmogelijk om bij te houden als je bijvoorbeeld op een campus loopt met 500 accesspoints, welke allemaal meerdere BSSID's hebben.

We kunnen echter alleen maar hopen dat mensen niet klakkeloos alles over internet verzenden, en waar mogelijk een vpn opzetten naar een veilige locatie.

[MAX3400]

Ik zal zeker in mijn studies Microsoft eens nakijken hoe alles ook alweer werkt.

Het gaat om de beheerskant; op een gemiddeld netwerk wil ik helemaal geen wildgroei van iedereen die maar een prive/corporate device meebrengt en dat ding wil laten werken/communiceren met het netwerk. Als beheerder zou ik dus MAC-addressen opnemen aan mijn kant van het netwerk en gebruiken als eerste blokkade voor ongeauthoriseerde devices.

En volgens mij hebben we ook een miscommunicatie over plaintext; dat je verbonden bent met een WPA2-netwerk, wil niet zeggen dat er geen communicatie kan plaatsvinden over plaintext. Dit sterkt dus mijn "eis" dat ik geen ongeauthoriseerde devices wil hebben; sowieso niet om scriptkiddies van mijn netwerk te weren en zakelijke communicatie te onderscheppen.

Ja, je kan op allerlei manieren MAC-adressen spoofen etc. maar je doet nu enigszins voorkomen alsof het wel allemaal veilig en client-side is terwijl de "hack" in de Apple-devices toch echt laat zien dat het niet veilig is.

[Miepermans]

Ik denk dat ik inderdaad snap waar je op doelt, Echter alles wat verzonden word via een WPA2-Enterprise netwerk is versleuteld. Zelfs als pietje vervolgens over http naar de website http://www.ikbengek.nl gaat.

[Dreamvoid]

op een gemiddeld netwerk wil ik helemaal geen wildgroei van iedereen die maar een prive/corporate device meebrengt en dat ding wil laten werken/communiceren met het netwerk.

Dat wil eigenlijk niemand, maar BYOD is de hype van het moment, en je zal daar in de praktijk waarschijnlijk wel in mee *moeten*. Wen er maar aan: je zal elk device binnen je netwerk moeten "harden" alsof het direct aan het internet hangt.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 15:23]

[GekkePrutser]

Dat wil eigenlijk niemand, maar BYOD is de hype van het moment, en je zal daar in de praktijk waarschijnlijk wel in mee *moeten*. Wen er maar aan: je zal elk device binnen je netwerk moeten "harden" alsof het direct aan het internet hangt.

Jawel, de gebruikers willen graag BYOD. En terecht, het is in deze tijd nogal vervelend om met twee telefoons, tablets, laptops e.d. te lopen.

En het "harden" van je netwerk is sowieso een goed plan. Want of je nu BYOD hebt of niet, de shit komt toch wel je netwerk binnen. Consultants die met hun laptops in het datacenter inprikken, virussen via USB sticks waar filmpjes van de bedrijfs BBQ op gedeeld moeten worden, af en toe wellicht zelfs een rogue access point of hackers die ergens een raspberry op weten te hangen.

Het is eigenlijk net zoals de beveiliging van het gebouw, die Group 4 jongens hebben ook liever helemaal geen gasten binnen en zouden graag iedereen bij binnenkomst willen fouilleren en rontgenfoto's maken. Maar zo werkt het (gelukkig) gewoon niet.

Ga er gewoon vanuit dat je netwerk helemaal open is naar internet en je bent ook veilig als er een keer wel iemand van buiten binnen komt die er niks te zoeken heeft.

[haling]

Als beheerder zou ik dus MAC-addressen opnemen aan mijn kant van het netwerk en gebruiken als eerste blokkade voor ongeauthoriseerde devices.

... als er iets makkelijk te spoofen vallen zijn het wel MAC-adressen.

[supersnathan94]

sorry, maar op universiteiten en andere school instellingen is dat dus niet te doen. Met ieder jaar zo'n 2500-4000 nieuwe studenten per locatie/instelling en zo,n 5000 nieuwe devices die allemaal op de eerste dag natuurlijk verbinding maken gaat dat em dus niet worden.

[Mammon]

MAC-adressen whitelisten ga je niks mee opschieten. Het probleem zit hem niet in dat iemand op jouw netwerk kan komen maar juist dat iemand zich voor kan doen als jouw netwerk. Hierdoor overhandigt de eindgebruiker zijn username/password en toevallig ook zijn MAC adres die weer heel makkelijk te spoofen is.

[dcm360]

ten eerste zou je als beheerder van het netwerk toch een extra stukje authenticatie kunnen/moeten implementeren zoals MAC-addressen opnemen in de whitelist.

Dat is schijnveiligheid en is in veel netwerken niet eens fatsoenlijk te implementeren. Een MAC-adres spoofen is kinderspel en een Eduroam of Ziggo (hotspots) moet op 1 of andere manier de withelist met MAC-adressen op alle apparaten zien te krijgen die met het netwerk willen verbinden. Een whitelist aan de accesspoint-kant is helemaal zinloos, aangezien dit een probleem met neppe accesspoints betreft.

[sjongenelen]

Of, is de nodige kennis gewoon niet aanwezig en kost het dus tijd om dat te regelen? Weet niet of de software überhaupt wel gemaakt door Apple of meegeleverd door de producent van de wifi kaart?
Als het laatste waar zou zijn zou de bug ook in andere besturingssystemen aanwezig zijn..

[Diamondo25]

zoals MAC-addressen opnemen in de whitelist

In de mobiel kunnen specificeren welke accesspoints zijn toegestaan dmv MAC address? Jammergenoeg zijn die ook (heel makkelijk) te spoofen...

[pe1dnn]

Leuk dat als voorbeeld van een hotspot wordt genoemd een hotspot met de naam "KPN". Dat bracht mij op de gedachte wat er eigenlijk gebeurt als je een nep hotspot "KPN Fon" noemt.

Heel wat mensen hebben inmiddels de app van KPN om automatisch in te loggen op Fon netwerken.
Die zoeken gewoon continue naar Wifi stations met "Fon" in de naam en als die er is dan meld de app zich aan als de telefoon op dat moment geen Wifi verbinding heeft.

Wat als je de hotspot "KPN Fon" noemt dan trekt dat mobieltjes aan als vliegen naar de stroop. Uiteraard moet je je daarna aanmelden (gaat automatisch) maar hoe dicht zit dat en wat gebeurt er als je nep Fon hotspot gewoon een open onbeveiligde hotspot is en je dus sowieso toegang hebt.

In de binnenstad op op een bedrijven terreinen zijn heel weinig KPN Fon hotspots want die zitten juist bij particulieren in woonwijken (heel erg veel), dus op die locaties ben je bijna de enige dus elke mobiel in de buurt met die app zal proberen te verbinden.

@Dreamvoid Die hotspots zelf zijn gewoon open Wifi punten, iedereen kan daar aan verbinden. Je kan er alleen geen data over sturen zonder aan te melden, dus er zal wel zoiets als een beveiligde IP tunnel gemaakt worden waar je je Fon account voor nodig hebt. Het aanmelden is echter om te voorkomen dat iedereen zo maar Fon kan gebruiken. Maar in het nep geval is het gewoon een open netwerk, aanmelden zal mislukken maar je mobiel is ondertussen toch verbonden en aangezien het gewoon een open netwerk is kan de mobiel ook gewoon data versturen en ontvangen. Niet via Fon maar dat is bij die nepper nu juist ook niet de bedoeling.

[Reactie gewijzigd door pe1dnn op 22 juli 2024 15:23]

[Dorank]

Het aanmelden is echter om te voorkomen dat iedereen zo maar Fon kan gebruiken.

FON (tenminste de laatste keer dat ik er naar keek) is een open netwerk (zoals je ook aangeeft), de gebruiker logt via een portal en vervolgens wordt z'n macadress gewhitelist op het betreffende accesspoint. Vervolgens kan iedereen het mac adress spoofen om zo toegang te krijgen tot het accesspoint. Mocht ik ernaast zitten en heeft FON dit probleem opgelost hoor ik het graag, dan haal ik de fonera weer van zolder.

[pe1dnn]

Ja, maar waar ik het over heb is wat er zou gebeuren al ik een nep Fon hotspot maak, zouden telefoons met die Fon app daar ook automatisch mee verbinden, zodat gebruikers afgetapt kunnen worden terwijl ze denken dat ze met een Fon verbonden zijn...

Overigens als alleen het mac adres gewhitelist wordt maar de verbinding onbeveiligd blijf dan zou je zo mee kunnen kijken met die verbinding. Dat zal toch niet waar zijn, dan lijkt me zo'n Fon hotspot wel heel erg onveilig. Werkt dat echt zo?

[Dorank]

maar waar ik het over heb is wat er zou gebeuren al ik een nep Fon hotspot maak, zouden telefoons met die Fon app daar ook automatisch mee verbinden, zodat gebruikers afgetapt kunnen worden terwijl ze denken dat ze met een Fon verbonden zijn...

Daar heb je helemaal geen nep FON AP voor nodig, dat kan ook met een echte FON hotspot:
-het is open dus iedereen zit wat er in de ether wordt geslingert.
-de operator van de hotspot kan altijd het netwerk sniffen.

Het enige wat de FON user beschermt tegen het lekken van zijn login credentials is de clientside controle op het https certificaat.

Werkt dat echt zo?

Zo was het de laatste keer dat ik FON wilde gebruiken, al een paar jaar geleden. Maar ik kan met niet voorstellen dat de werkwijze veranderd is, gebruikers (die niet weten wat FON is) moeten een mogelijkheid hebben om de werking van de hotspot te achterhalen, zich aan te melden/betalen. Het kan natuurlijk wel met nog een extra SSID maar dat wordt wellicht als te omslachtig gezien.

[rene_fb]

En dan inlogdata loggen? Zo makkelijk zal dat toch hopelijk niet gaan?

[dillic]

In het geval van wpa2-enterprise (met radius) wel, op Defcon 21 is er een mooie presentatie over geweest:

https://www.youtube.com/w...oqMoL452Jvcb7Ip9gFe813Jqz

Ze laten oa. ook het Apple iOS/OSX specifieke 'probleem' zien (wat Apple toen nog geen security issue vond). Onderstaande link is naar het Apple gedeelte

https://www.youtube.com/w...52Jvcb7Ip9gFe813Jqz#t=862

[Damic]

Ik dacht dat ook al dat dit bekent was in 2013. Heb die ook gezien en dacht, goe bezig, Android is een stuk erger, die switcht gewoon.

[Dreamvoid]

Als het netjes is geimplementeerd zou de app enkel naar Fon hotspots met de juiste private key moeten verbinden.

[soulrider]

reactie op verkeerde persoon

[Reactie gewijzigd door soulrider op 22 juli 2024 15:23]

[mutley69]

Voor de auteur een kleine aanvulling: Niet alleen zakelijke omgevingen - ook educatieven omgevingen zoals eduroam zijn vollenbak op wpa2-enterprise geënt.

[digital-IMEI]

Maken de hotspots van Ziggo (en waarschijnlijk ook UPC) hier niet ook gebruik van?

[Miepermans]

Ziggo maakt gebruik van WPA2-Enterprise, en Eap over lan om te authenticeren tegen radius, Dus kort gezegd ja!

[2green]

Nee, ziggo maakt niet gebruikt van deze implementatie.

Alhoewel ziggo WPA2 gebruikt, hebben ze een andere implementatie. Je hebt alleen last van deze bug als je IOS draait. Vermoedelijk bedoelde Miepermans dit, maar nuanceer het toch even.

[Miepermans]

Ziggo levert de service inderdaad, niet specifiek de Apple library... ik dacht dat dat duidelijk was

[--Andre--]

Maar iemand kan zich dus voordoen als Ziggo hotspot om iemand met een apple device aan te vallen, toch?

[Miepermans]

Tot op voorkort kon dat zoiezo, Echter is het natuurlijk wel zo dat als de handshake niet klopt ( en dat lijkt niet gechecked te worden in de apple library ) dat er dan ook nog dataoverdracht dient plaats te vinden.

Nu is het natuurlijk erg raar als ik in het winkelcentrum bij de plaatselijke Hema zit, en mijn laptop verbind ineens met het ssid "Bedrijfsnaam" terwijl ik daar niet in de buurt ben.

Met de Ziggo implementatie zoals die voorheen uitgerold werd, werd aanbevolen certificate checking uit te zetten. Op deze manier kon iemand met een eigen radius server met Accept-Any rule dus mooi mensen laten authenticeren, Dit was echter ook al mogelijk zonder de Apple exploit.

WiFi is per definitie onveilig, Je verstuurt immers data over the air. Het is altijd aan de eindgebruiker om logisch na te denken *Kan het wel kloppen dat ik hier in de hema met *bedrijfsnaam* netwerk verbind ?!*

Er zijn erg leuke tools voor, om WiFi te kraken, zelfs tools die voor iedereen te gebruiken zijn. Interesse? Google eens op de volgende termen :
* AirPcap
* AirCrack-NG
* (Personal favorite) Pineapple

De laatste is een all-in-one wifi "hack" systeem met een diversiteit aan scans, portal's om wachtwoorden te ontfutselen en andere hacking tools.

Let Op: Het toegang verkrijgen tot andermans data, zonder hiervoor expliciete toestemming verkregen te hebben is in Nederland strafbaar. Bovenstaande tooling dient dan ook alleen maar voor experimenteel gebruik op eigen infrastructuur gebruikt te worden.

[DDX]

Toestellen die geen upgrade naar iOS 8 krijgen, zoals de iPhone 4, blijven kwetsbaar.

http://en.wikipedia.org/wiki/IPhone_4

Discontinued
September 10, 2013

Dus een telefoon van een jaar oud en je hebt gewoon pech ?

[badnews.nl]

4 jaar oud toch?
Ondertussen elk jaar upgrade, dus 4s, 5 en 5s en bijna 6

Tegelijk ongeveer met de eerste samsung galaxy, android 2.2 als nieuwste firmware

[DDX]

Maar pas vorig jaar discontinued, dus vorig jaar nog gewoon verkocht ?

[Deem]

Een Gold Master Beta versie van IOS8 lijkt elk moment te kunnen worden uitgegeven. Het lijkt me sterk dat er dus straks bij de eerste release van IOS8 al gepatched is, gezien de releasedate van de final versie (9 september?) steeds dichter bij komt.

[DoubleYouEl]

De ontdekker van dit veiligheidsprobleem heeft al getest met iOS 8 beta. Hiermee bleek de vulnerability niet meer te werken. Het is alleen afwachten wat de uiteindelijke release versie zal geven...

[PeterBezemer]

oplossen in ios8? zou een hotfix moeten zijn voor alle ondersteunde ios versies

[MAX3400]

Uit de studie van Pieter Robyns blijkt dat toestellen onder iOS 6 (.1.6, zoals in de iPod Touch), iOS 7 (.1, zoals in de iPhone 4 en 4S) en onder Mac OS X 10 (.8.2, Mountain Lion) kwetsbaar zijn voor dit veiligheidsrisico. Robyns testte ook toestellen onder Android 2.x (2.3.4), 4.x (4.4.2), Windows Phone 8.0 en Windows 7 (desktop), die evenwel niet onder dit probleem leden (wat andere problemen niet uitsluit). Apple plant het probleem op te lossen in iOS 8, dat momenteel in een bètafase zit en later dit jaar uitkomt.

^ komt van het bron-artikel en geeft jou dus zeker gelijk dat ze e.e.a. moeten oplossen, op korte termijn, voor meerdere devices. Sowieso dat OSX ook getroffen is door dit lek, vind ik minstens zo belangrijk want dan lijkt het erop dat er een probleem zit in de technische inrichting bij Apple zelf en niet alleen in iOS.

[Miepermans]

Apple gebruikt waarschijnlijk gewoon een vulnerable module. Het is dus een kwestie van deze module oppoetsen en opnieuw certificeren en publishen. Het is wel te hopen dat ze dit voor alle IOS versie's als update verstrekken.

[Verwijderd]

Zeker gezien de vele zakelijke gebruikers.

[z1rconium]

Het is een issue ja.

Maar het is nu ook niet weer zo dat er op elke straathoek een "hackertje" staat en dat dan ook nog iemand daadwerkelijk connect met dat "nepnetwerk".

Een beetje relativeren mag best, ook als er Apple in het artikel voor komt.

[NanoSector]

Toestellen die geen upgrade naar iOS 8 krijgen, zoals de iPhone 4, blijven kwetsbaar.

Ik denk dat dat wat kort door de bocht is. Apple kan natuurlijk nog een bugfix-release doorvoeren voordat iOS 8 uit is (of zelfs daarna).

[Stannieman]

OT: Ik denk dat ik 2 jaar geleden nog bij die kerel in de klas heb gezeten.