Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 23 reacties
Submitter: DwightKSchrute

Microsoft waarschuwt dat Windows Phone 7.8 en Windows Phone 8 niet standaard controleren of draadloze netwerken die met peap-ms-chapv2 zijn beschermd wel over het juiste certificaat beschikken. Daardoor kunnen logingegevens door kwaadwillenden onderschept worden.

MicrosoftDat peap-ms-chapv2-netwerken kwetsbaar zijn, was al langer bekend: kwaadwillenden kunnen een netwerk nabootsen en zo de logingegevens van gebruikers die er verbinding mee proberen te maken onderscheppen. Dat kan worden omzeild door een certificaat te vereisen voordat er verbinding wordt gemaakt met het netwerk, maar Microsoft waarschuwt nu dat Windows Phone 7.8 en Windows Phone 8 dat standaard niet doen. Overigens doet Android dat standaard ook niet.

Door het vereisen van een certificaat handmatig aan te zetten, kunnen gebruikers voorkomen dat ze het slachtoffer van de aanval worden, benadrukt Microsoft, dat gebruikers verder aanraadt om wifi uit te zetten wanneer ze er geen gebruik van maken.

Peap-ms-chapv2 wordt voornamelijk gebruik in zakelijke omgevingen. Ook Ziggo gebruikt de techniek om zijn publieke wifi-hotspots te beveiligen; van die hotspots was al bekend dat ze na te bootsen zijn, omdat er geen certificaat wordt geserveerd.

Moderatie-faq Wijzig weergave

Reacties (23)

Klinkt serieus. Iemand enig idee hoeveel van die netwerken worden gebruikt? En wat zijn de mogelijke alternatieven dan?
Eduroam bijvoorbeeld maakt hier gebruik van. Bijna elke universiteit en hogeschool in BelgiŽ (en Nederland dacht ik ook) heeft er zo eentje.

Wij moeten ons op Eduroam aanmelden met onze student-id (bvb 123456@khleuven.be) en ons algemeen studentenwachtwoord. Als iemand ergens een valse Eduroam-hotspot opzet kunnen ze in principe gewoon je username en password onderscheppen (bijvoorbeeld als WiFi op je telefoon aanstaat). Op een PC krijg je dan een melding dat je je gaat authenticeren via een niet-vertrouwde server en dan kan je dat gewoon annuleren, maar op Android of Windows Phone wordt die check niet gedaan en ben je dus je logingegevens kwijt.

Als ik er nu over nadenk is dit best wel een groot probleem, op eduroam dan toch zeker. Vrijwel iedereen heeft dat op z'n telefoon ingesteld, en een namaakhotspot opzetten met de juiste configuratie om loginpogingen te onderscheppen is op een kwartiertje gedaan. Ook lectoren gebruiken dit systeem, dus eigenlijk is het voor de gemiddelde informaticastudent heel erg simpel om eventjes de logingegevens van lectoren te achterhalen en jezelf wat betere punten te geven.

[Reactie gewijzigd door AmbroosV op 6 augustus 2013 12:48]

Op je pc staat een certificaat alleen met windows standaard aan. Zowel op mijn laptop (ubuntu) als op android heb ik de certificaten in moeten stellen. Geen idee hoe het met mac zit.
Je hebt trouwens helemaal gelijk, het is kinderlijk eenvoudig om logingegevens te onderscheppen door het opzetten van een fake hotspot. Je pakt iemands wachtwoord op zonder dat hij/zij het merkt. Als je ergens gaat zitten waar geen of slechte verbinding is, maar waar wel veel studenten komen, kan je zo honderden wachtwoorden onderscheppen in een dagje. Je zal de hash van het wachtwoord daarna nog moeten kraken maar dat gaat met enkele miljoenen pogingen per seconde op consumentenhardware dus kraken is een kwestie van seconden.
Het probleem van eduroam is dat hetzelfde wachtwoord ook gebruikt wordt voor alle andere diensten. Dat betekent dat je je heel makkelijk voor kan doen als iemand anders. Niet alleen krijgt het ip adres waarvanaf je werkt de naam mee van degene die je hebt gehackt, je hebt ook toegang tot zijn/haar officiŽle email. Het is dan ook aan te raden om die certificaten in te stellen (hier te vinden voor tudelft).
Bij eduroam is het dus nog mogelijk om certificaten in te stellen maar voor zover ik weet is dit bij ziggo niet het geval. Als je dus gebruik maakt van ziggo publieke hotspots weet dan wel dat je het risico loopt dat iemand anders onder jouw naam kan gaan internetten. Met de huidige surveillance kan je dan dus ook aangeklaagd worden voor kp. Zeker als je nog ergens een encrypted container op je hd hebt staan waar je het ww van bent vergeten.
Bij ziggo is het minder erg als je wachtwoord wordt gekaapt, het wachtwoord is alleen geldig om op internet te komen. (Al erg genoeg, anoniem internetten op iemands anders z'n naam is zo vrij makkelijk. Who needs TOR? Wel even mac klonen, je weet tenslotte nooit. )

-edit-
Als je het certificaat in wilt stellen voor eduroam: (android 4.2.1)
1. Download het CA certificaat van jouw universiteit naar de sd kaart van je telefoon (zoeken met google brengt je vaak direct naar de goede pagina)
2. Open Settings -> Security.
3. Vink Secure credential storage. Eventueel moet je daar nog een wachtwoord intikken
4. Install from SD card
5. Ga naar je system settings-> wifi
6. long press on eduroam -> modify network
7. vink 'Advanced options' aan
8. Kies onder 'CA certificate' het net geÔnstalleerde certificaat

Op internet kon ik zo snel alleen deze link van bristol university vinden. Die lijkt te kloppen. Natuurlijk wel het juiste certificaat van je uni downloaden.

[Reactie gewijzigd door Berendhoo op 6 augustus 2013 13:38]

Je zal de hash van het wachtwoord daarna nog moeten kraken maar dat gaat met enkele miljoenen pogingen per seconde op consumentenhardware dus kraken is een kwestie van seconden.
Dit is niet waar, het hashen van een wachtwoord gebeurt pas OP de server, wat een client stuurt is een plain password (hopelijk wel over een beveiligde verbinding natuurlijk)

Het zou ook nergens op slaan om client-side al te encrypten, want in feite WORDT het gehashte wachtwoord dan simpelweg het wachtwoord.

Edit: Zoals Berendhoo hieronder opmerkt is het uiteindelijke proces wat complexer.

[Reactie gewijzigd door Argantonis op 7 augustus 2013 20:02]

Dat is incorrect. De client stuurt nooit zijn wachtwoord plaintext naar de server zoals dat wel normaal is bij websites. Al dan niet met een https verbinding die er voor zorgt dat meekijkers niks kunnen zien natuurlijk.

In dit geval gaat het als volgt: de client maakt verbinding met het AP op een manier die vergelijkbaar is met https. Er is dus nog geen wachtwoord verstuurd. Deze verbinding is alleen niet veilig als je zelf het AP spooft, vandaar dat je certificaten nodig hebt. Ook dit is vergelijkbaar met https.

Daarna heb je een inner authentification. Die bestaat uit een challenge response. Afhankelijk van de implementatie kunnen dit oa PAP, CHAP, MSCHAP en MSCHAPV2 zijn.

Een challenge response gaat als feite als volgt: de server stuurt een challenge. De user gebruikt de challenge en zijn wachtwoord om de response uit te rekenen. De server heeft ook het wachtwoord en kan dus ook de response uit rekenen. Als de response van de user overeenkomt met het verwachte antwoord dan moet de client dus wel het juiste wachtwoord hebben.

De response bij bijvoorbeeld CHAP is gewoon de challenge plus het wachtwoord en daar dan een hash overheen. Dat is vrij simpel te brute forcen. In het geval van MSCHAPV2 is het iets ingewikkelder maar het kan nog steeds. Omdat er in dit protocol gebruikt gemaakt wordt van DES is het minder makkelijk te brute forcen maar nog steeds gemiddeld in een halve dag. (uitgaande van een totaal random wachtwoord, maar wel professionele hardware). Voor een goede uitleg klik hier.

[Reactie gewijzigd door Berendhoo op 7 augustus 2013 00:08]

I stand corrected. Interessant, bedankt!
Ik vrees dat "op een kwartiertje" lichtjes overdreven is. tenzij je dagelijks daarmee bezig bent. Heb het snel even opgezocht, en lijkt me toch niet binnen het kwartier te lukken :-)
Tips altijd welkom, wil wel eens weten of we hier veilig bezig zijn in ons ziekenhuis...
Ik schat dat je er al met al een dagje mee bezig bent als je een beetje ervaring hebt met linux en geen ervaring met beveiliging. Dat is dat inclusief het daadwerkelijke kraken van je eigen paswoord. Paswoord kraken van iemand die daar geen toestemming voor geeft is illegaal!
Wat achtergrond kan je in deze slides hier vinden.

[Reactie gewijzigd door Berendhoo op 6 augustus 2013 14:58]

Eduroam bijvoorbeeld maakt hier gebruik van. Bijna elke universiteit en hogeschool in BelgiŽ (en Nederland dacht ik ook) heeft er zo eentje.
Eduroam is wel wat groter dan BelgiŽ en Nederland: https://www.eduroam.org/index.php?p=where
Ook lectoren gebruiken dit systeem, dus eigenlijk is het voor de gemiddelde informaticastudent heel erg simpel om eventjes de logingegevens van lectoren te achterhalen en jezelf wat betere punten te geven.
Denk je er wel aan dat dit geen "studentengeintje" is, maar een misdrijf? Als je gepakt wordt (en dat zit er dik in; als een docent om welke reden dan ook die cijferlijst later nog een keertje opent en zijn oog valt erop...) dan heb je een enorm probleem.
Zijn er ook redenen dat dit standaard uit staat? Ik bedoel, het zou dan toch gewoon praktisch zijn dat die via een update ofzo standaard wordt aangezet?
Gebruikers zitten toch niet op certificaten te wachten. En eigenlijk zitten gebruikers ook niet op beveiliging te wachten, dat is alleen maar lastig. Dus dat het standaard uit staat is jammer, maar volgens Microsoft kan je het aanzetten, dus ik ga even kijken hoe ik dat aan kan zetten op WP8.

Voor de mensen die de advisory niet willen lezen:
Configuring a Windows Phone 8 to require a certificate verifying a wireless access point:

After receiving the root certificate from Corporate IT, each Windows Phone 8 user performs the following steps:

Delete the previously configured Wi-Fi connection.

In Settings, Wi-Fi, tap Advanced
Tap and hold over the selected Wi-Fi network, and choose delete
Create a new connection and enable server certificate validation.

In Wi-Fi settings, tap on the enterprise Wi-Fi network access point which will open a Sign-in page
Enter username and password
Toggle "Validate Server Certificate" to On
Tap to choose a certificate
In the list of certificates to select, pick the root certificate issued from Corporate IT (for example, "Contoso Corporate Root Certificate"), and tap Done
Dus nee, waarschijnlijk kan dit niet via een update automatisch aangezet worden. En ik denk ook niet dat dat wenselijk is.

[Reactie gewijzigd door HMS op 6 augustus 2013 12:57]

Waarschijnlijk omdat veel clubs een eigen CA gebruiken om die certificaten aan te maken (of self-signed) en je derhalve het certificaat zou moeten installeren op ieder apparaat dat er mee verbind (als je geen meldingen wilt dat het certificaat niet vertrouwd wordt en zelf moet controleren of het de goede is).
Maar dan zou je natuurlijk het vinkje nog steed default aan kunnen zetten, dan moet je in die gevallen alleen de optie niet controleren selecteren. Dat zou bij goed geconfigureerde netwerken al gelijk een stuk veiliger zijn.
Was me ook al opgevallen, alleen hier op het werk kiezen ze er blijkbaar ook nog een keer voor om self-signed certificaten te gebruiken waarmee ze er zelf al voor kiezen om de boel onveilig te maken...

M'n oude symbian had dan ook de grootste moeite om er hier op te komen, daar was certificaat controle verplicht. Dus toen heb ik uiteindelijk het certificaat gekregen.


@Martinspire, ik neem aan dat bij veel grote bedrijven en studentencampussen dit principe gehanteerd wordt.

[Reactie gewijzigd door kippetje01 op 6 augustus 2013 12:42]

Dat ze self-signed zijn wil niet zeggen dat ze onveiliger zijn.

Sterker nog, als ik zelf certificaten aanmaak en importeer die netjes op mijn eigen apparaten (en verwijder alle anderen - inclusief de CA's dus) is dat zelfs veiliger. Krijgt dan wel vervelende meldingen als je naar de bank surft e.d. - maar dat is mijn netwerk niet.

Het enige dat verandert is de controle (je zal - om het te controleren - het certificaat zelf moeten installeren (het publieke deel dan)). De encryptie verandert in het geheel niet.

Het aantal misverstanden rondom self-signed certificates is echt enorm. Persoonlijk heb ik minder vertrouwen in 70+ CA's die mijn computer standaard vertrouwd dan mijn eigen certificaten, maar goed... Het probleem zit hem in de controle. Ik mag dan wel weten wat mijn certificaat is, jij weet dat niet. Daar zijn die CA's voor, maar die je moet dus wel vertrouwen.

En ik snap bijv. nog steeds niet wat ik met de Turkmenistan CA moet, noch wat ze daar met de staat der nederlanden CA moeten (of waarom onze overheid zichzelf uberhaupt belangrijk genoeg vond om CA te worden en wereldwijd overal in te moeten zitten met hun CA certificaatje)...
En ik snap bijv. nog steeds niet wat ik met de Turkmenistan CA moet, noch wat ze daar met de staat der nederlanden CA moeten (of waarom onze overheid zichzelf uberhaupt belangrijk genoeg vond om CA te worden en wereldwijd overal in te moeten zitten met hun CA certificaatje)...
Da's best handig als je een veilige verbinding op wil zetten met de ambassade van Turkmenistan om een visum aan te vragen bijvoorbeeld.

De reden dat Nederland zelf een CA wil zijn is waarschijnlijk vooral om alles zelf in de hand te hebben (beter dan afhankelijk zijn van DigiNotar...).
Met onveilig bedoel ik dan ook dat het certificaat niet verstrekt wordt en dus iedereen geforceerd word om de controle uit te schakelen.

De data encryptie is inderdaad gewoon in orde, maar helaas is dan je wachtwoord al verstuurd naar een theoretisch onbekende partij.

Voor mijn prive mail, en https sites draai ik ook self-signed certificaten die ik inderdaad gewoon trust op mijn devices ;)

[Reactie gewijzigd door kippetje01 op 6 augustus 2013 12:58]

Het certificaat wordt altijd verstrekt. Het publieke deel van het certificaat krijg je namelijk altijd bij iedere SSL connectie. Het enige verschil is dat dat publieke deel (of een van de hogere certificaten die dat publieke deel ondertekend heeft) niet in je store staat en het automatisch vertrouwen er daarom niet is (of dat vertrouwen terecht is even daargelaten).

En dat het private gedeelte niet verstrekt wordt mag ik hopen ;). Heb het zelf niet gezien in deze situatie, maar bijv. je browser heeft prima mogelijkheden om jouw het certificaat te laten zien voordat deze meer info naar de server gaat sturen. Als je hier een pop-up krijgt dat het certificaat niet vertrouwd is (wat ze eigenlijk gewoon standaard hadden moeten doen) had je gewoon dezelfde mogelijkheden gehad.

Het probleem zit hem dus meer in deze implementaties die het klaarblijkelijk niet nodig vinden om dit te melden - dan bij self-signed certificates.

Dat is dan ook de reden van de waarschuwing, beetje jammer alleen dat ze zelf niet melden waarom ze het zo gedaan hebben. En veel erger - haal hier ook niet uit dat ze het willen verbeteren...
PEAP-MS-CHAPv2 wordt ook gebruikt voor het 'eduroam' netwerk van universiteiten en hogescholen.

Waarbij (volgens mij) het eduroam netwerk in principe bij elke hogeschool of universiteit in Nederland uitgerold is. Hierdoor kunnen studenten bij elke hogeschool of universiteit gebruik maken van het draadloze netwerk.

[Reactie gewijzigd door HMS op 6 augustus 2013 12:44]

Met ActiveSync is ook een leuke. Windows Phone vereist root en servercertificaat. Meest veilig.
Voor iOS alleen server certificaat (half veilig) en voor Android mogen beide missen (helemaal niet veilig)
Wazig dat verschillende toko's een verschillende opvatting hebben net als met peap-ms-chapv2.
Is die ook niet iets wat je op server kan regelen?
Zo moest ik op mijn windows mobiele 6,5 telefoon eerst een certificaat installeren voordat ik verbinding kon maken met het wifi netwerk.
Wel erg lastig en omslachtig, maar misschien wel zo veilig.
SHIT, P.R.I.S.M. IS COMING BACK

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True