'Krack-aanval treft alle moderne wifinetwerken door lek in wpa2-standaard'

Onderzoekers hebben maandag de details van de Krack-aanval gepubliceerd. Uit het onderzoek blijkt dat de aanval een risico vormt voor alle moderne wifinetwerken en dat Android- en Linux-apparaten het zwaarst zijn getroffen.

De onderzoeker die verantwoordelijk is voor de ontdekking van het lek, Mathy Vanhoef van de KU Leuven, heeft zijn bevindingen beschreven in een paper en op een speciale site. Daar meldt hij dat het gaat om een kwetsbaarheid in wpa2, waarbij de Krack-aanval zich richt op de zogenaamde 4-way handshake, die wordt uitgevoerd als iemand verbinding met een wifinetwerk wil maken. Deze stelt een aanvaller in staat om gevoelige informatie te onderscheppen, zoals wachtwoorden en e-mailberichten. Dat is voornamelijk een risico bij onversleutelde http-verbindingen, al zijn er volgens Vanhoef ook risico's voor https omdat in het verleden is gebleken dat ook deze techniek te omzeilen is. De onderzoeker demonstreert echter geen aanval op https. Het achterhalen van het wifiwachtwoord is niet mogelijk.

Bij de aanval gaat het om een key reinstallation attack. Zodra een client, bijvoorbeeld een smartphone, verbinding wil maken met een wpa2-netwerk, krijgt hij een encryptiesleutel nadat de derde stap van de 4-way handshake is afgerond. Deze sleutel gebruikt de client om informatie te versleutelen. Als het accesspoint, bijvoorbeeld een router, geen bevestiging ontvangt dat de client de sleutel heeft gekregen, stuurt hij hem opnieuw. Elke keer dat de client een dergelijk bericht ontvangt, installeert hij dezelfde sleutel opnieuw. Daarbij worden een pakketnummer of 'nonce' en de receive replay counter steeds opnieuw ingesteld. Volgens Vanhoef is de versleuteling van de verbinding aan te vallen door het derde bericht van de 4-way handshake te onderscheppen en opnieuw te verzenden. Hierdoor kan een aanvaller het hergebruik van een nonce afdwingen. Daarvoor is wel een man-in-the-middle-positie vereist, waarbij de aanvaller een kopie van een accesspoint op een ander kanaal opzet die hetzelfde mac-adres heeft.

Daardoor is het bijvoorbeeld mogelijk om pakketten opnieuw te verzenden of te ontsleutelen als aes-ccmp-encryptie wordt toegepast. Verder zijn tcp-syn-pakketten te ontsleutelen, waardoor een tcp-verbinding over te nemen is. Dit betekent dat bij gebruik van aes-ccmp uiteindelijk kwaadaardige code geïnjecteerd kan worden. Bij gebruik van wpa-tkip of gcmp is het ook mogelijk om pakketten te injecteren en te vervalsen.

De aanval zou ook grote gevolgen hebben voor Linux- en Android-apparaten. Die zouden in veel gevallen gebruikmaken van de wificlient wpa_supplicant, die vanaf versie 2.4 kwetsbaar is voor de aanval. Door de aanval kunnen clients gedwongen worden een encryptiesleutel te gebruiken die alleen uit nullen bestaat, aldus Vanhoef. Daardoor is draadloos netwerkverkeer eenvoudig te onderscheppen en te wijzigen. Alle Android-toestellen met versie 6.0 of hoger van het mobiele besturingssysteem zouden kwetsbaar zijn. Windows en iOS zijn niet kwetsbaar via een aanval op de 4-way handshake, maar wel via de group key handshake, waardoor een aanvaller bepaalde frames kan herhalen.

Vanhoef legt uit dat de aanval zich voornamelijk op clients richt in plaats van op accesspoints. Niet alleen wpa en wpa2 zijn kwetsbaar, maar onder meer ook PeerKey en tdls. Het uitvoeren van patches zou op een backwards compatible manier mogelijk zijn, waardoor het niet nodig is om wpa2 in zijn geheel te vervangen. Zo zou een gepatchte client bijvoorbeeld nog wel met een ongepatcht accesspoint kunnen communiceren, illustreert Vanhoef. Het overstappen naar wep in afwachting van patches is een slecht idee, omdat die techniek al geruime tijd niet meer veilig is. De onderzoekers stelden fabrikanten rond 14 juli op de hoogte van hun bevindingen. Daardoor zouden patches al redelijk snel uit moeten kunnen komen. Voor thuisgebruikers zou de nadruk moeten liggen op het patchen van clients en niet van routers.

Door Sander van Voorst

Nieuwsredacteur

16-10-2017 • 12:22

194 Linkedin Whatsapp

Reacties (194)

194
193
103
15
0
57
Wijzig sortering
Inmiddels heeft Aruba een Security Advisory uitgebracht met het advies te patchen:
http://www.arubanetworks....vices/security-bulletins/
Q: Does this mean WPA2 is broken now?
A: No. The vulnerability is due to implementation flaws (programmers did not anticipate and guard against a particular set of circumstances when writing the code) rather than a protocol-level weakness. Contributing to the problem was insufficient/ambiguous guidance to developers in the 802.11 standard. All vulnerabilities can be mitigated through software updates to affected systems without the need for a change in the protocol.

[Reactie gewijzigd door P1nGu1n op 16 oktober 2017 12:31]

Er staat in het artikel android en linux zijn het meeste getroffen, is Android geen linux? Apple Ios toch ook? Dus moeten zij toch ook vulnerable zijn?
Android is Linux, iOS niet.

"Alle Android-toestellen met versie 6.0 of hoger van het mobiele besturingssysteem zouden kwetsbaar zijn. Windows en iOS zijn niet kwetsbaar via een aanval op de 4-way handshake, maar wel via de group key handshake, waardoor een aanvaller bepaalde frames kan herhalen." source: nieuws: 'Krack-aanval treft alle moderne wifinetwerken door lek in wpa2-stand...
Android is Linux, iOS niet.
Android is Linux zoals een tomaat fruit is. Technisch gezien heb je gelijk, maar in de praktijk zijn ze toch best wel verschillend.

De standaard Linux kernel is aardig verbouwd om te werken in Android. En daar bovenop komen nog een hoop blobs van hardwarefabrikant.
Anoniem: 413211
@mard016 oktober 2017 14:11
De standaard Linux kernel is aardig verbouwd om te werken in Android. En daar bovenop komen nog een hoop blobs van hardwarefabrikant.
Och, dat heb je precies hetzelfde in Windows, Mac en Ubuntu Linux. Op Ubuntu heb je de microcode die je voor de rest laadt, dan de kernel en je dkms drivers van Nvidia of Broadcom (misschien dat jijzelf . Genoeg mensen die dat hebben. Ubuntu heeft daarnaast ook nog eens patches die het bovenop de kernel zet, en wanneer een LTS kernel voor een LTS release niet meer upstream supported is, backporten zij ook nog steeds security patches. Misschien gebruik jijzelf helemaal geen extra blobs, ik wil niet teveel aannemen.

Mac werkt met kernel extensions, Windows met drivers. Nog steeds noem ik de XNU kernel die in een Macbook Air een XNU kernel, net als de kernel in een iMac. Het is dezelfde kernel, maar gebruikt andere blobs/kernel extensions.

Dusja, Android gebruikt de Linux kernel. Een embedded device met Linux, musl en BusyBox in plaats van glibc en GNU, gebruikt nog steeds de Linux kernel. Het is alleen maar een kernel, zelfs op een 2 GB Fedora installatie is de kernel zelf maar een enkele paar MB groot.
Ja, maar Android gebruikt wel wpa_supplicant en hostapd.
Mis, tomaat is fruit

De tomaat wordt als groente gegeten, dit kan zowel rauw als gekookt.
Bron: wikipedia.nl

[Reactie gewijzigd door RobZw op 16 oktober 2017 14:13]

Het hangt er vanaf welke definitie je gebruikt, volgens sommige definities is tomaat wel degelijk een groente. Volgens andere is het inderdaad fruit.

bron: https://nl.wikipedia.org/...l_tussen_groente_en_fruit
Als tomaat fruit is, dan is aubergine, paprika, en mais dat ook.
Tomaat, aubergine en paprika zijn biologisch gezien fruit.
Maïs is een graansoort.
https://nl.wikipedia.org/wiki/Graan


Nevermind, ik ben een dwaas. Maïs is een graan, maar dat produceert uiteraard ook gewoon vruchten.

[Reactie gewijzigd door fluffy1 op 16 oktober 2017 15:48]

Dat iets een vrucht is, maakt het nog geen fruit. Anders zouden ook pompoenen, courgettes, paprika's etc fruit zijn. Een tomaat is bovendien van de nachtschadefamilie (net als de paprika en de aubergine), dat maakt tomaat al per definitie een groente.
Veel verder off-topic kunnen we niet gaan denk ik, maar waarom niet. :-)

Vrucht en fruit zijn synoniemen. https://synoniemen.net/index.php?zoekterm=fruit

Culinair gezien worden tomaten, courgettes, paprika's, enz. als groeten gezien.
Probleem is dat in deze branche groeten en fruit nogal willekeurig gekozen zijn, puur gebaseerd op smaak.

In de biologie worden vruchten als volgt gedefinieerd:
De vrucht is in de strengste betekenis het rijp geworden vruchtbeginsel van een bloem en bevat in het algemeen de na bevruchting uit de zaadknoppen ontwikkelde zaden. Ook andere delen kunnen echter meegroeien, die men dan ook tot de vrucht rekent.[1] De eerste noemt men dan "echte" vruchten, maar bij de "schijnvruchten" vormen andere delen dan het vruchtbeginsel het hoofdbestanddeel. (Bron: https://nl.wikipedia.org/wiki/Vrucht_(plant) )

Als je deze beschrijving volgt, is het voedsel dat je noemt een vrucht. (En dus bijgevolg, fruit)

Niet dat het heel veel uit maakt. Of je het nu groente of fruit noemt, de tomaat blijft nog altijd hetzelfde. :-)
Neeee, dat klopt niet!!!!! Fruit en vrucht zijn niet synoniem! In het engels is het een en hetzelfde woord, in het nederlands hebben ze echter verschillende betekenissen (en wel zo dat een fruit => vrucht, maar andersom niet).
Mis, pompoen, courgette en paprika is ook gewoon fruit want het zijn zadendragende vruchten.
Dat iets culinair als groente wordt gebruikt maat het vanuit wetenschappelijk standpunt nog geen groente
Inderdaad klopt het dat pompen, courgette en paprika's vruchten zijn. Dat is zeker waar. Maar dat wil niet zeggen dat het fruit is. Veel mensen maken die fout doordat in het engels fruit zowel fruit als vruchten zijn. Volgens jouw definitie zijn de vruchten van de maretak, wolfkers en meidoorn ook fruit. Nou, eet smakelijk :)

edit: "van" toegevoegd.

[Reactie gewijzigd door GroeneEend op 16 oktober 2017 16:36]

Is dat jouw persoonlijke definitie of is daar ook een wetenschappelijke c.q. juridische bron van?
Dat wist ik nog niet dat aubergine ook nachtschade is. De nachtschadefamilie is toch een grote familie. Maar als iets bij de nachtschadefamilie hoort, is het per definitie groente? Wat dacht je van de boksdoorn (commercieel ook goji bes genoemd) of de ananaskers (aka kaapse goudsbes)? Zijn dat dan ook groentes?
Knowledge is knowing that a tomato is a fruit.

Wisdom is not putting it in a fruitsalad...
Technisch gezien is een tomaat een vrucht. Vreemd, maar wel juist.
Tomaat is volgens de wetenschappelijke definitie gewoon een fruit: https://www.youtube.com/watch?v=kxo_EOyK7eA
Culinair wordt het als groente gebruikt
Fruit in het engels is zowel vrucht als fruit terwijl in het nederlands die twee verschillende definities hebben. Het heeft dan ook geen zin om een engelstalig filmpje aan te halen, dat zegt niks in deze discussie.
Android en Linux zijn niet het meeste getroffen, wpa_supplicant (de meest gebruikte WPA client voor Linux, die ook door Android gebruikt wordt) en hostapd (de meest gebruikte WPA authenticator voor Linux, die ook door Android gebruikt wordt) zijn het meeste getroffen. iOS gebruikt een BSD kernel.

[Reactie gewijzigd door 526735 op 16 oktober 2017 16:31]

iOS gebruikt toch een Darwin kernel? Maar zit überhaupt Wpa in de kernel of in de laag erboven? De grote vraag is nu. Is Unix (open Solaris enz. Ook vatbaar?)
Darwin is gebaseerd op BSD. Maar WPA zit i.i.g. bij Linux niet in de kernel, maar de laag erboven in programma's zoals wpa_supplicant en hostapd.
iOS is UNIX en Android draait op Linux.
Wat betreft vulnerability is eigenlijk alles vulnerable, maar Linux en Android net even iets meer.
iOS is afgeleid van BSD, niet UNIX.
Technisch gezien draait het hele Apple eco-systeem op Darwin, wat een afstamt van NeXTSTEP, wat weer een hevig gemodificeerde fork van BSD was.

Dus ja, het is technisch gezien UNIX, zoals Linux ook UNIX is.
Linux is geen UNIX. Er waren ooit grofweg twee smaken: BSD en System V. Zo ongeveer alle UNIX varianten stammen daarvan af. Linux is een UNIX achtige, het lijkt heel erg op Linux maar is geen echt UNIX.
Het artikel gaat sowieso uit de bocht en spreekt van Android, Linux, Apple en Windows. Android is een totaal OS, Linux is een combinatie van een kernel en GNU in verschillende distributievormen, Apple is een bedrijf en Windows is heel veel verschillende operating systems. Volgens mij moeten we die zin dus in abstracte zin lezen.
Apple iOS is gebaseerd op UNIX. Niet op Linux. Ze delen van oorsprong dezelfde UNIX kernel in het verleden, verder is het hedendaags niet meer vergelijkbaar. Daarnaast heb ik geen idee of Apple een eigen WiFi implementatie heeft en of Android gewoon de standaard Linux-based implementatie hanteert waardoor deze ook gevoelig is.
Apple's iOS en macOS hebben een kernel gebasseerd op Darwin wat dan weer een BSD kernel is.
BSD is een UNIX-gebaseerde kernel.
Linux deelt geen code met het klassieke UNIX, Linux is POSIX compatible en gedraag zich er daarom als een, maar ze delen geen code.
Apple iOS is gebaseerd op NeXTStep, en die op zijn beurt weer op de Mach kernel en BSD.
Dus ook geen gemeenschappelijke kernel oid. Wel hebben beide UNIX als "spec" - maar that's it.
Darwin(BSD) UNIX <3
Android is inderdaad op de Linux-kernel gebaseerd net zoals MacOS. Maar het hangt helemaal van de verdere implementatie van het systeem hoe het gebouwd is. Android lijkt dus er geen rekening met een MITM aanval op het protocol zelf rekening te hebben gehouden, terwijl MacOS misschien het daar wel bij gebeurt is. Of misschien hebben ze het niet getest met een Mac/iPad/etc.
macOS is niet gebaseerd op de Linux kernel. Het is gebaseerd op XNU wat weer gebaseerd is op Mach en stukjes van FreeBSD. Er zit geen Linux code in XNU.
Het debian security team heeft zojuist voor jessie, stretch, buster en sid een update uitgebracht.

Ze lijken vooraf geinformeerd te zijn. De patch lijkt van afgelopen zaterdag te zijn (changelog), maar zojuist aangekondigd en uitgebracht.

[Reactie gewijzigd door arendvw op 16 oktober 2017 13:46]

Ze lijken vooraf geinformeerd te zijn. De patch lijkt van afgelopen zaterdag te zijn (changelog), maar zojuist aangekondigd en uitgebracht.
Uiteraard zijn ze dat. Dat staat ook in het artikel:
De onderzoekers stelden fabrikanten rond 14 juli op de hoogte van hun bevindingen. Daardoor zouden patches al redelijk snel uit moeten kunnen komen.
Ze lijken vooraf geinformeerd te zijn. De patch lijkt van afgelopen zaterdag te zijn (changelog), maar zojuist aangekondigd en uitgebracht.
Uit het artikel:
De onderzoekers stelden fabrikanten rond 14 juli op de hoogte van hun bevindingen.
Omdat de impact groot is en het schrijven (en testen!) van patches enige tijd duurt worden eerst de mensen die het op moeten lossen (in het geheim) op de hoogte gebracht, daarna volgt een aankondiging naar de hele wereld (zie ook het eerdere bericht vanochtend) in de trant van "let op, over een paar uur komt er belangrijk nieuws!" en dan op een vooraf afgesproken tijd wordt niet alleen alle informatie publiek beschikbaar gemaakt, maar ook meteen de patches. Als alles goed gaat kan een heel groot deel van "het Internet" gepatched zijn voordat "the bad guys" hun exploits geschreven hebben. Deze manier van werken heet "coordinated disclosure" en is vooral belangrijk bij dit soort lekken waarbij opeens "alles" kwetsbaar is.
Hetjammere is alleen dat de release van de patches wacht tot het openbaar maken van het nieuws. Dat soort pathes moeten juist direct als alles de deur uit kan de deur uit gaan.
Hetjammere is alleen dat de release van de patches wacht tot het openbaar maken van het nieuws. Dat soort pathes moeten juist direct als alles de deur uit kan de deur uit gaan.
Nee, juist niet! Als je de patch kunt bestuderen dan zie je meteen waar de bug zit. Dan weet je nog niet meteen hoe de bug misbruikt kan worden, maar het helpt je wel een enorm stuk op weg. Het is niet voor niets dat de patches tegelijk gereleased worden.
de patches daarvoor zijn inmiddels ook al uit
Hier can de security patch worden gedownload voor Aruba apparaten.
http://support.arubanetwo...ntryId/27269/Default.aspx
Ubiquiti heeft ook een fix uitgebracht :)
De laatste firmware volgens de Controller en de pagina: https://www.ubnt.com/download/unifi/ is de 3.8.14.6780 versie. Weet jij of deze automatisch naar deze AP's zal worden gepushed bij automatische update tzt of waar het ergens te zien is wanneer deze wordt aangeboden aan de controller?

Edit
In het forum staat het antwoord:
https://community.ubnt.co...een-released/td-p/2099370
It has been pushed out to 5.6.16 and later. It has not (yet) been pushed to 5.5.x. I will follow up later today in regards to that.
In het geval de firmware update nog niet beschikbaar is kun je in het geval van de 5.6 het volgende doen:
  • Ga naar 'Settings'
  • Ga in het settings-menu naar 'Maintenance'
  • Klik op de blauwe knop 'Check Firmware Update'
  • Terug naar het 'Devices' scherm zul je daar nu een 'update' knop hebben staan.
In het geval van de 5.5 Controller versie kun je nog even wachten, daarvoor hebben ze de update nu nog niet beschikbaar gemaakt.

[Reactie gewijzigd door mrdemc op 16 oktober 2017 14:15]

Je edit klopt, maar je kan ook de download link kopiëren en plakken in de custom upgrade:

Configuration (in de device tab) -> Manage device... dan bij custom upgrade de link plakken en op de upgrade knop klikken.
Dat klopt, tenzij je automatische updates aan hebt staan. Dan zul je de automatische update functie eerst moeten uitschakelen, firmware via een custom update aanleveren en dan weer inschakelen. Persoonlijk wacht ik dan liever tot deze aangeboden wordt via de automatische updates :)
Na het opnieuw inschakelen van auto-update stond er bij mij gewoon weer een upgrade knop die naar de vorige versie ging. Ik activeer het later wel weer als de update naar iedereen is uitgerold :) .
Nu verwacht ik niet dat ze lang zullen wachten die voor iedereen uit te rollen.
Klopt, elke versie die anders is dan de release die bekend is triggered een update knop in de GUI die je in dit geval downgrade. Daarom gebruik ik zelf liever ook niet de Custom update, die gaat in de weg zitten met de interface. Zodra de release branch echter weer gelijk loopt met jouw firmware versie zal de knop vanzelf verdwijnen, maar het blijft dan toch even verwarrend.
Zelfs op oudere versies kan je makkelijk een upgrade forceren:
  • klik op de downloadpagina op de laatste firmware, kies dan copy url.
  • Ga naar je controller homepage.
  • Klik je access point aan, ga naar configuratie -> apparaat beheren
  • Vul de url in, en bevestig.
Je AP is nu aan het updaten
Dat is dus gewoon een custom update wat @SupaHotFire hier ook zegt:
SupaHotFire in 'nieuws: 'Krack-aanval treft alle moderne wifinetwerken door lek...

Maar dan krijg je dus ook situaties zoals @MClaeys hier aangeeft:
MClaeys in 'nieuws: 'Krack-aanval treft alle moderne wifinetwerken door lek i...
Of deze:
https://community.ubnt.co...89/highlight/true#M255000

Ik doe het liever niet op die manier, maar ik draai zelf 5.6 :)

[Reactie gewijzigd door mrdemc op 16 oktober 2017 19:57]

Ondertussen heeft Ubiquity aangegeven dat de firmware als stable zal worden gereleased vandaag:
Thank you all for your valuable testing efforts! We will likely be rolling this out as the stable release for all UAPs tomorrow (minus the UAP-AC-v1/2, which is not affected, and will stay on 3.8.14).
Voor de duidelijkheid: alleen je APs patchen is niet goed genoeg. Je clients moeten ook gepatched zijn.
Anoniem: 30722
@Finwe16 oktober 2017 14:30
Zoals ik hem las moet 1 van de 2 kanten bijgewerkt zijn. Dus met alleen je AP's zou je veilig zijn, ware het niet dat beide kanten patchen natuurlijk beter is. (nadeel is dat dat bij sommige vendoren wel even gaat duren of zelfs nooit komt)
Waar lees je dit? Op de site van KRACK kan ik dit zo niet vinden, en als ik kijk naar hoe de aanval werkt dan lijkt het me logisch dat alleen de AP niet genoeg is: onderdeel van de attack is om de client te dwingen met een andere AP verbinding te maken. Ook een mod op het forum van Ubiquiti zegt dat de fix alleen de "STA mode" betreft, dus als de AP zelf een client is.

[Reactie gewijzigd door Finwe op 16 oktober 2017 14:39]

Dit begrijp ik ook, ik weet niet hoe je ap patchen dit probleemt verhelpt.

Hooguit dat als je op dat ap bent aangemeld je tijdelijk niet vatbaar bent voor een aanval.

Voor bedrijven wel relevant lijkt mij, voor privepersonen is de eigen client (telefoon!) patchen veel belangrijker.
Voor de extra duidelijkheid: De Unify controller client moet updated zijn, of even wachten tot later vandaag, dan komt de FW ook uit voor de huidige stable (5.5.x) Unify controller.
[opluchting-modus] Wat ben ik blij dat ik dat als systeem heb ipv een oplossing zonder eco-systeem erachter! Enorm voordeel! [/opluchting-modus]

Anderen zullen waarschijnlijk snel volgen! Wel mooi getimed die patches, fabrikanten hadden lang de tijd en nu komen dus de eerste fixes na bekendmaking. Nu kan je wel mooi zien wie dit serieus nemen en wie niet...
Mijn debian-router is anders ook al gefixed hoor. Geen proprietary oplossingen voor nodig.
Dat is zo, debian kan ook dingen. Maar mijn punt is dat vaak fabrikanten veel te laat met patches komen. Vaak is het zo dat alleenstaande producten vaak geen ondersteuning krijgen. Wanneer een product mee kan genieten van een eco-systeem, de support vaak stukken beter is. Reden is dat zo een product geen uitzondering op de dagelijkse business is.
Voor gebruikers van LEDE (Openwrt) zal eveneens een patch worden uitgebracht:

https://forum.lede-projec...bility-found-krack/7450/4

Wachten is op versie 17.01.4
Bij T-Mobile Thuis ook al een forum post.
Deze twee sites houden bij wat de patch status is van verschillende fabrikanten:

https://www.fixkrack.com/

https://github.com/kristate/krackinfo
Iemand die in normaal begrijpelijk Nederlands kan uitleggen wat dit betekend voor de allerdaagse huis-tuin-keuken gebruikers met smartphones en Windows of Mac notebook?

Wat kan een Firewall, Antivirus, Malwarebytes Anti-Exploit hier tegen beginnen?
Is de Windows Mail app hier tegen bestand, Mozilla Thunderbird en Outlook 2016? Is e-banking nog veilig via de app op de smartphone?
Zijn alle miljoenen modems die bij de verschillende huishoudens staan die afkomstig zijn van de internetproviders kwetsbaar?

[Reactie gewijzigd door Yooo Kerol op 16 oktober 2017 13:06]

Iemand die in normaal begrijpelijk Nederlands kan uitleggen wat dit betekend voor de allerdaagse huis-tuin-keuken gebruikers met smartphones en Windows of Mac notebook?
Voer zo snel mogelijk als ze beschikbaar zijn de security-patches uit voor je Mac of Windows laptop. Zorg dat je op de meest recenten versie zit.

Waar het op neer komt: Totdat je bent gepatcht, moet je je thuiswifi nu eigenlijk op dezelfde manier gaan benaderen alsof je op een onbeveiligd wifi in de koffiebar zit.
Wat kan een Firewall, Antivirus, Malwarebytes Anti-Exploit hier tegen beginnen?
Niet veel. Het probleem zit hem in de communicatie tussen je Wifi-chip en de router. Daar kan iemand tappen, omdat er op een manier gepraat wordt die af te luisteren vat.
Is de Windows Mail app hier tegen bestand, Mozilla Thunderbird en Outlook 2016? Is e-banking nog veilig via de smartphone app?
"Dat hangt er van af". Maak je gebruik van een 'secure' protocol (dus TLS of https) dan kan er wel iemand meeluisteren, maar snapt nog niet wat je op de lijn zet.

Vergelijk het met een geldwagen die gekraakt is. Ligt het geld er los in, dan kunnen de boeven er nu bij. Zit er nog een koffer met dik slot omheen, dan is het alweer moeilijker.

De meeste moderne apps (Zoals degene die jij noemt) communiceren in principe 'secure'. Ze maken gebruik van extra versleuteling. Je e-banking via de smartphone werkt *zeker* secure (bij alle grote NL-banken). Die kun je dus nog steeds veilig gebruiken.
Zijn alle miljoenen modems die bij de verschillende huishoudens staan die afkomstig zijn van de internetproviders kwetsbaar?
Ja, hopelijk gaan de providers dan ook voor updates zorgen.

[Reactie gewijzigd door Keypunchie op 16 oktober 2017 13:48]

In principe zijn alle websites met TLS (slotje in adresbalk) veilig, tenzij ze geen Strict Transport Security (HSTS) ondersteunen. Anders kan je namelijk de TLS beveiliging strippen, maar dan zie je als gebruiker geen slotje meer in de adresbalk dus dat valt sommigen wel op.

Met deze tool kan je zien of een website HSTS ondersteunt. Tweakers.net ondersteunt het bijvoorbeeld, maar match.com wat in het filmpje als voorbeeld wordt gebruikt ondersteunt het niet.
In principe zijn alle websites met TLS (slotje in adresbalk) veilig, tenzij ze geen Strict Transport Security (HSTS) ondersteunen. Anders kan je namelijk de TLS beveiliging strippen,
Tenzij een site op een HSTS preload list staat maakt HSTS het nog steeds mogelijk dat er een MitM aanval plaats vindt op de eerste verbinding met een domein, waar de HSTS headers nog verstuurd moeten worden.
Die kans is alleen vrij klein op een apparaat zoals smartphone of laptop bij sites als die van banken. Die worden vaak snel bezocht binnen een aantal dagen na aankoop.
Terechte vragen. Ik ga m'n best doen.

Het gaat hier om een kwetsbaarheid waarmee data afgeluisterd kan worden en in sommige gevallen data die onderweg is naar jou aangepast kan worden.

Een firewall zal hier niets tegen kunnen doen omdat dit verkeer is wat normaal gesproken door je firewall niet tegen gehouden zal worden en je device niet weet dat er wordt afgeluisterd of aangepast.
Antivirus/antimalware kan je deels beschermen tegen vormen die dit lek gebruiken om een virus of malware via vertrouwde websites je device in te krijgen, maar beschermt je niet tegen het uitlekken van informatie die over het wifi netwerk gaat.

Veel internetverkeer wordt inmiddels via https beveiligd. Ook email kan via beveiligde verbindingen worden opgehaald. Als je het hebt over clients zoals Thunderbird, Outlook en de windows mail app, dan hangt dit dus volledig af van welke email servers je mee verbind en of die een beveiligde verbinding gebruiken.

Internet bankieren loopt altijd via een encrypted verbinding (https), of je nu de app of de website gebruikt. Er is geen enkele bank die hun verbinding afhankelijk zouden laten zijn van hoe veilig het netwerk is. Het advies voor openbare netwerken is echter wel altijd om die niet te gebruiken voor zaken als internet bankieren. Eigenlijk zou je deze kwetsbaarheid kunnen zien als het downgraden van je eigen netwerk tot een openbaar netwerk. Je zou in de tussentijd 4G kunnen gebruiken ipv wifi.

Bijna alle wifi devices zijn op dit moment kwetsbaar voor op z'n minst een deel van de kwetsbaarheden die gevonden zijn. Echter lijdt dit nog niet bij alle devices tot een lek waarmee de verbinding in zijn geheel afgeluisterd kan worden. Omdat het probleem voort komt uit een issue in de originele omschrijving van de standaard is de kans heel groot dat er op z'n minst een laag van de beveiliging afgepelt kan worden. Dit zal hacks eenvoudiger maken. De modems van providers zullen dus waarschijnlijk ook kwetsbaar zijn. Voor zover ik kan bepalen is het updaten van de clients wel voldoende om je tegen dit lek te beschermen.

Waarschijnlijk nog niet het helemaal complete antwoord waar je naar op zoek bent. Maar de info is nog vers, er zal nog wel een duidelijkere omschrijving beschikbaar komen. Tot die tijd, update je devices zodra er updates beschikbaar zijn. En laten we hopen dat Android fabrikanten dit serieus nemen.
Rustig maar, er moet al een boef in een auto voor je deur zitten om een aanval zoals dit uit te voeren. Het gaan om de encryptie tussen je router en apparaat. Je apparaat kan nu getrickt worden om een encryptie code te gebruiken die gebroken kan worden. Dan kan een aanvaller het verkeer tussen je router en apparaat afluisteren en manipuleren. Maar dit werkt alleen bij websites die SSL op een verkeerde manier implementeren, bij websites die het juist implementeren krijg je een SSL waarschuwing. Maar deze aanval is dus alleen mogelijk als een aanvaller dicht genoeg bij je apparaat en router is dat hij kan praten met je apparaat en je router. Als je buiten de deur met je telefoon al geen verbinding meer met je eigen router kunt maken dan ben je dus veilig.

Nee, thuisgebruikers lopen niet zo heel erg veel risico hoor. Boeven in auto's met laptop die je Wifi proberen te kraken in de hoop dat je hele erg kostbare data op je systeem hebt staan komen niet zo erg veel voor. Het is voor een boef een stuk intressanter om geld te verdienen van achter zijn computer zonder te hoeven reizen, zodat hij anoniem kan blijven en via het internet overal in de wereld elke systeem kan proberen aan te vallen.
Rustig maar, er moet al een boef in een auto voor je deur zitten om een aanval zoals dit uit te voeren.
Niks 'rustig maar'.

Het enige wat er nodig is, is dat er ergens in de directe omgeving van jouw WiFi netwerk een ander WiFi netwerk is waar al een gecompromiteerd apparaat op zit. Bijvoorbeeld bij de half-digibete buurman die het niet zo nauw neemt met de beveiliging en overal "Ja" op klikt.

Dit soort hacks kan gestart worden vanaf een geinfecteerde machine met een c&c server ver, ver op afstand, en vervolgens gebruikt worden om razendsnel de invloed uit te breiden en met verdere exploits binnen te dringen op geografisch omliggende systemen.

En niet alleen via thuis-netwerken!

Er hoeven maar een paar mobiele telefoons geinfecteerd te worden die vanuit de lokale 'zwerm' vertrekken om door hun eigenaren de halve stad mee doorgenomen te worden, en voor je het weet heeft het botnet weer een nieuw jachtgebied aangeboord.


Een lek als dit is juist zeer gevaarlijk vanwege de potentie die het biedt om snel en makkelijk andere exploits doorgedrukt te krijgen en grote golven apparatuur in de wijde omgeving massaal over te nemen. Leuk voor bijv. digitaal aangelegde terroristen-in-spe, die hiermee op commando de stekker uit het digitale leven kunnen trekken van een hele stad.

[Reactie gewijzigd door R4gnax op 16 oktober 2017 20:15]

In Jip en Janneketaal, ze kunnen meeluisteren met het verkeer tussen een device (laptop/telefoon/tablet/etc) en de router en zo wachtwoorden proberen te achterhalen.
Ze kunnen ook het verkeer tussen een device en router aanpassen, b.v. Jij tiept als URL www.tweakers.net in en de hacker past het aan dat je op een site komt die op Tweakers lijkt maar een backdoor heeft draaien.
Of, ze presenteren een pop-up met de vraag “voer uw draadloos netwerk code in om te verbinden”
Gros zal dit netjes doen, en voila, ze hebben je WPA2 code, zeker als de pop-up lijkt op het scherm dat ze normaal krijgen om te verbinden met draadloze netwerken.

Firewall, Antivirus, malwarebytes en anti-exploit kunnen hier niets tegen doen, het verkeer tussen een device en router wordt onderschept.

Miljoenen modems onveilig, JA, tot er en update uitgebracht wordt wel ja.

[Reactie gewijzigd door Goldwing1973 op 16 oktober 2017 13:05]

Ligt het aan mij of is het statement dat dit een client-side issue is (al dan niet prive) een beetje onorthodox?
Zo hangt het dus van de patchstatus van de client af of er een issue is? Hoe beheers je dat op hoger niveau? Gastnetwerken bijvoorbeeld (al dan niet omdat je iedereen gewoon je wifi code geeft), of BYOD omgevingen?
Zou het niet de access point moeten zijn die deze aanval onmogelijk moet maken? Dat is toch de enige manier om zeker te weten dat je netwerk niet zo'n backdoor bevat ook als er oude hardware/software aan hangt? Je hebt immers verre van altijd de regie over wie er op inlogt.

[Reactie gewijzigd door Koffiebarbaar op 16 oktober 2017 13:59]

Zo hangt het dus van de patchstatus van de client af of er een issue is?
Dat klopt.
Hoe beheers je dat op hoger niveau?
Op precies dezelfde manier waarop je beheerst dat er geen malware op je clients staat (of nou ja, dat er een virusscanner draait). En ja, als je geen controle hebt over de clients dan wordt dat: "niet".
Zou het niet de access point moeten zijn die deze aanval onmogelijk moet maken?
De kern van het probleem is dat een aanvaller een packet van AP naar client herhaalt. Jouw AP moet dat originele packet wel sturen (da's onderdeel van hoe WPA werkt), kan niet voorkomen dat een aanvaller dat packet ook opvangt en kan niet voorkomen dat een aanvaller het daarna nog een keer opnieuw verstuurt. Er is letterlijk niets wat een AP hiertegen kan doen. Het is de client die moet constateren "hey, wacht eens even, exact dat packet heb ik al een keer gezien... dan hoef ik er dus niets mee te doen --> negeren die hap".
Dat is toch de enige manier om zeker te weten dat je netwerk niet zo'n backdoor bevat ook als er oude hardware/software aan hangt? Je hebt immers verre van altijd de regie over wie er op inlogt.
Security bugs worden helaas niet ontworpen op manageability...
“Alle Android-toestellen met versie 6.0 of hoger van het mobiele besturingssysteem zouden kwetsbaar zijn.”

Eerdere versies niet? :?
What changed?

Trouwens, “men moet zich richten op het patchen van clients, niet AP’s”. Haha... Mja, good luck with that. Het updatebeleid bij veel Android-toestellen is juist een groot probleem. :/ Die krijgen geen patches...

[Reactie gewijzigd door WhatsappHack op 16 oktober 2017 12:34]

Zo'n update zou Google dus zelf moeten pushen via de PlayStore.
Heeft in principe niks met de softwareschil van de fabrikanten te maken en zo ja, dan hebben die een probleem.
Maar zo werkt het dus niet... Met Stagefright waren er ook vele miljoenen toestellen die met een kwetsbaarheid achterbleven.
Je vergeet een ding, namelijk de wifi controllers van telefoons en tablets. Google kan dat niet ruiken en hoeft het dus niet per definitie aan te passen, al zou het wel mooi zijn natuurlijk. Wellicht als het een driver vanuit de kernel is, maar dan is updaten moeilijker (en is het aan de beheerder van de kernel) en Google gebruikt enkel met mayor updates een nieuwe kernel, als die beschikbaar is, naar mijn weten.

[Reactie gewijzigd door CH4OS op 16 oktober 2017 13:22]

Ok sergeant ;)
*Major
Het zou super zijn als dat zou kunnen, maar aangezien het hier over het subsystem voor wifi gaat, wat een vrij low level onderdeel van het OS is, is dat niet geheel realistisch.

Het is wel mogelijk dat via Project Treble dit soort updates in de toekomst makkelijker door fabrikanten uit te rollen zijn. Overigens is de kans ook vrij groot dat dit als een kleine maandelijkse security patch doorgevoerd kan worden die de schillen van fabrikanten ook niet raakt. Helaas heeft nog niet elke fabrikant zich gecommit aan het doorvoeren van maandelijkse security patches, maar de meeste grote fabrikanten inmiddels wel.

Het ziet er een stuk beter uit dan in het pre-stagefright tijdperk. Maar we zijn er helaas nog niet. 1 voordeel is dat zit soort kwetsbaarheden de fabrikanten nog maar eens het belang laten zien van regelmatige beveiligingsupdates. Mijn advies, check of een fabrikant hier aan mee doet voor je een Android telefoon koopt.
Nee, want de wifi stack is onderdeel van de Linux kernel.
WPA gebeurt via wpa_supplicant. Dat is gewoon software die losstaat van de kernel en gepatched kan worden.
What changed?
wpa_supplicant. Versie 2.4 en hoger is makkelijker te "Krack"en
Trouwens, “men moet zich richten op het patchen van clients, niet AP’s”. Haha... Mja, good luck with that. Het updatebeleid bij veel Android-toestellen is juist een groot probleem. :/ Die krijgen geen patches...
Zelfde geldt voor veel AP's...
wpa_supplicant.
Ach ja, natuurlijk!
Soms is het antwoord zo simpel dat je er niet meteen aan denkt. :) Dank!
Trouwens, “men moet zich richten op het patchen van clients, niet AP’s”. Haha... Mja, good luck with that. Het updatebeleid bij veel Android-toestellen is juist een groot probleem. :/ Die krijgen geen patches...
Ik ken maar bar weinig toestellen die niet gewoon de maandelijkse security updates van Google krijgen.....

Het update beleid van grote versies is niet ideaal. Security updates worden nogsteeds uitgebracht voor Android 5 (zeg ik uit ervaring; ik weet niet of ze het wellicht ook nog voor 4 doen).
Zijn er tal die ze niet (meer) krijgen of (flink) achterlopen.
Ik ken maar bar weinig toestellen die niet gewoon de maandelijkse security updates van Google krijgen.....
Alles Android TV van Sony.

Als je geluk hebt krijg je eens in het half jaar een flinke feature update van een paar GB groot die een tiental of zo bugs verhelpt (en vrij consistent het dubbele aan nieuwe introduceert, dus YMMV). Maar security fixes? Zou niet weten of en hoeveel die er bij zitten. Geeft Sony geen nette disclosure over.

Je kunt het hele smart gebeuren op die TVs door Sony's wanbeleid eigenlijk gewoon niet veilig gebruiken. En elke update presteren ze het om zaken nog verder te slopen en nog instabieler te maken met nog meer vastlopers en spontane reboots tot gevolg.

(Eigenlijk zou ik de mijne gewoon terug bij de BCC in hun strot moeten rammen onder het conformiteitsbeginsel.)

[Reactie gewijzigd door R4gnax op 16 oktober 2017 19:56]

als je geen patches krijgt, was je sowieso al de pineut met allerlei andere lekken. Ik zie gelukkig wel verbetering bij bijvoorbeeld Samsung op patch-gebied.
Het updatebeleid bij veel Android-toestellen is juist een groot probleem. :/ Die krijgen geen patches...
Ach, dat wilt ook wel eens meevallen. Mijn drie jaar oude Samsung Galaxy Note 4 krijgt nog elke maand security patches.
Maar zoals ik het lees, moet er dus een man-in-the-middle zijn, werkt een OS bij connectie met Wifi uitsluitend met een combinatie van mac/SSID om 'automatisch' verbinding te maken? Als ik bv een wifi-netwerk spoof (en elk user/ww accepteer), gaat een toestel gewoon verbinding maken omdat hij denkt dat het het origineel is?
Zoiets vroeg ik mij ook al af... als je toch een fake AP moet opzetten waar een client tegenaan praat dan ben je sowieso toch al t haasje mbt tot verkeer af tappen....
En daarom moet je dus openbare wifi netwerken, zoals 'McDonald's Free Wifi en 'Wifi in de trein', vermijden... alsook Snackbar Sjonnie waarbij het wachtwoord op het bonnetje staat. Maak is voor de grap een netwerk aan met een bekende naam en je zal zien dat er al heel veel clients verbinden. En dan ben jij de man in the Middle

(Open(bare) wifi netwerken smijt je dus het liefst nu nog van je telefoon, helaas voor de iOS users is er nog geen fatsoenlijke manier om je bekende netwerken te zien, en moet je ofwel alles verwijderen of eerst met al die punten verbinden, maar Android, Windows en MacOS users: bekende netwerken opzoeken en wegsmijten die handel)

[Reactie gewijzigd door xFeverr op 16 oktober 2017 13:17]

onzin.

WPA2 is een security protocol op fysiek (en mac) niveau van het OSI model. Jouw applicaties maken echter gebruik van protocollen de presentatielaag, en deze hebben over het algemeen geen weet van de onderliggende hardware.

Ofwel: als je applicaties via beveiligde protocollen zoals https, ldaps, ftps enzovoort babbelen, dan zijn je verbindingen nog steeds "veilig". Tussen quotes, want er zijn wel een paar risico's verbonden aan (incorrect) certificaatmanagement.
Als ik mijn router vervang en hetzelfde SSID en WPA2 password gebruikt gaat er geen een client miepen en connecten ze allemaal. Dat was dus mijn punt, dat staat los van bovenstaand bericht, maar was een reactie op @Powermage om te melden dat een fake AP sowieso al mogelijk is.
Ik zit in het kamp met dr claw, alle applicaties op mijn telefoon die privacy gevoelig zijn sturen geen cleartext over het internet en of wifi accesspoint. Of de wifi nog versleuteld is of niet maakt niet zoveel uit.

Natuurlijk zijn er nog een handjevol sites zonder https maar zo die verwerken ook niet echt relevante data.

[Reactie gewijzigd door SpiceWorm op 16 oktober 2017 17:01]

Wat is onzin?

in een ideale wereld zou idd elke client app netjes versleuteld en veilig communiceren, maar we leven niet in de ideale wereld, thuis of op kantoor maakt je nasje gewoon gebruik van onversleutelde communicatie en misschien staat er nog wel een oude SMB versie aan, of je web verkeer (zoals in de demo van de onderzoeker) kan over SSL, maar zonder SSL opent die webpage met login prompt ook netjes.

Waar t mij om gaat is dat dit lek vrij groot gebracht word, maar eigenlijk deze mitm op veel plekken al kan omdat het WPA password gewoon bekend is, dus een fake AP opzetten met zelfde SSID en PW zorgt er al voor dat clients connecten waar je dan al makkelijk MITM attacs kan uitvoeren, nu gaat het nog een stapje verder dat je zonder het PW te weten ook die keys kan kraken (of eigenlijk opnieuw kan laten verzenden)
Dit is onzin: "En daarom moet je dus openbare wifi netwerken, zoals 'McDonald's Free Wifi en 'Wifi in de trein', vermijden"

Dit is namelijk hetzelfde als zeggen: je moet niet meer van de openbare weg gebruik maken omdat je een kou kan oplopen. Daarvoor heb je toch passende kleding?

Je voorbeeld over het thuisnetwerk waar onversleutelde gegevensstromen zijn is in zoverre relevant dat het nu inderdaad mogelijk is om in die netwerken in te breken. Maar ook daar zeg ik: je bent als beheerder van je thuisnetwerk zelf verantwoordelijk voor de veiligheid van wat er daarbinnen afspeelt. Er zijn zat security patches die je kunt uitvoeren, elk huis tuin en keuken protocol heeft tegenwoordig een secure variant. Nalatigheid is geen excuus.

Winter is coming. Dus zorg dat je voorzieningen de juiste jas aan hebben.
Helemaal mee eens hoor, alhoewel ik liever probeer te zorgen dat clients en al gewoon veilig communiceren (https/ssl/vpn etc) maar hoe dit probleem nu gebracht word is alsof het iets wereldschokkends is terwijl voor het misbruiken hiervan (eigen AP opzetten) je eigenlijk al zat simpelere oplossingen kan misbruiken om t zelfde MITM resultaat te krijgen voor 99% van de wifi netwerken.
Ja maar je kunt geen fake AP opzetten met dezelfde WPA2 encryptie als je het password niet weet. Nu heb je dat password niet meer nodig met deze aanval want je kunt een client dus tricken om sleutels te gebruiken die je kunt kraken. Alle geintjes die je op openbare Wifi hotspots kunt uitvoeren waar packetjes onversleuteld door de lucht vliegen en dus alleen https bescherming bied tegen het lezen van je data die kunnen nu dus ook op WPA2 netwerken worden uitgevoerd. Vooral bedrijfsomgevingen en scholen zijn nu dus kwestbaar voor een boef met een laptop.
Een OS kijkt alleen naar het SSID omdat er soms meerdere AP's kunnen zijn (dus meerdere mac's), alleen moet het AP volgensmij het wachtwoord weten om de 4 way handshake af te kunnen maken. (kan ernaast zitten)
Niet helemaal. Het is namelijk niet mogelijk om te zeggen 'accepteer elk wachtworod maar', omdat WPA2 met een Pre-Shared-Key werkt.
Als je dus een netwerk wilt spoofen, zal je het wachtwoord moeten weten van het originele netwerk. Dan zal je dezelfde key genereren, en zal de client verbinden.
Open netwerken zijn daardoor helaas wel super makkelijk te spoofen, want dan verbind je gewoon op basis van de SSID zonder ook maar een beetje controle.
Ik haal iit dit artikel dat je verbinding gehijacked kan worden. Betekent dit dan ook dat mijn networkshares open zijn thuis?
SMB/CIFS (wat door Windows en de meeste home NAS systemen wordt gebruikt), heeft geen encryptie (SMB v3 wel denk ik, maar staat meestal niet aan).

Als je dus files (documenten, foto's) aan het openen bent op een fileshare, kan dit in principe gesnoopt worden, als ik de kwetsbaarheid goed begrepen heb).
Ja precies, maar dan moet ik actief de share gebruiken. En zoals Goldwing1973 hieronder aangeeft kunnen ze eventueel inloggen op mijn gmail, maar dat vliegt in mijn geval niet ivm 2-factor authentication.
Dat vliegt sowieso niet omwille van HTTPS.

Zo te zien kan je de impact het best omschrijven door te benoemen dat je nu thuis, in theorie, dezelfde risico's loopt als bij shared/open wifi punten in een café.
Dat is evengoed ruk natuurlijk omdat thuis, i.t.t. een café, in principe als vertrouwd netwerk wordt gezien door van alles en nog wat met bijbehorende extra dingen zoals een NAS die je in een café niet zo snel aan het netwerk hangt, maar als je niet direct een reden hebt om te vermoeden dat iemand dit op je zou willen gaan toepassen hoef je volgens mij niet accuut stress te hebben, mits de nodige partijen nu wel hard gaan lopen of dit reeds aan het doen zijn om patches de ether in te vuren. (hallo Google en Samsung (e.d.))

De massamedia nemen er wel weer mooi een loopje mee...

[Reactie gewijzigd door Koffiebarbaar op 16 oktober 2017 13:42]

Ja precies, maar dan moet ik actief de share gebruiken.
Aangezien ze in kunnen breken op een verbinding en zelf het verkeer kunnen manipuleren en extra packets kunnen injecteren, hoeven veel mensen hun shares niet eens actief aan het gebruiken te zijn. Die staan doorgaans, helaas nog steeds bij velen, gewoon open voor guest gebruikers.
Ja en nee,
Ze kunnen in eerste nstantie alleen maar “meeluisteren” maar zodra jij inlogt op een eenmalig kunnen ze je gegevens onderscheppen en ook inloggen op jouw webmail account en vervolgens zoeken naar wachtwoorden.
Als jij ergens nog een mailtje hebt staan waarin jij je WPA2 code hebt staan kunnen ze inloggen op je draadloos netwerk.
Zelfde geldt voor cloud diensten.
En in het vorige artikel was ook al aangegeven dat ze data tussen de AP en client kunnen manipuleren, dus in theorie kunnen ze een request naar een site met een Java backdoor sturen om zo via jouw device op het netwerk te komen.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee