Door Sander van Voorst

Nieuwsredacteur

Krack-aanval op draadloze netwerken

Meeluisteren op wpa2-verbindingen

16-10-2017 • 15:57

140 Linkedin Whatsapp

De Krack-aanval

Wat is er gebeurd?

Maandag waarschuwden onderzoekers, voornamelijk Mathy Vanhoef van de KU Leuven, dat ze een kwetsbaarheid in onder meer wpa en wpa2 hebben gevonden. Deze draagt de naam Krack, wat staat voor Key Reinstallation Attack. Vanhoef presenteerde dit jaar op BlackHat al eerder onderzoek naar de handshake in wpa2 en was vorig jaar betrokken bij de ontdekking van de Heist-aanval op https-verbindingen. In eerste instantie waren de details schaars, maar intussen hebben de onderzoekers hun bevindingen gepresenteerd. Het blijkt dat de aanval voornamelijk draadloze clients treft en een risico vormt voor alle moderne wifinetwerken. Voornamelijk voor Linux en het daarop gebaseerde Android vormt de aanval een probleem. In dit artikel bespreekt Tweakers een aantal vragen rond de gepresenteerde aanval.

fpa krack Airodump-ng scanning, door Christiaan Colen, CC BY-SA 2.0

Wpa2, hoe zat dat ook alweer?

Het wpa2-protocol maakt onderdeel uit van de IEEE 802.11i-standaard en wordt toegepast om draadloze netwerken van beveiliging te voorzien. Wpa staat voor Wi-Fi Protected Access en is in het leven geroepen door de Wi-Fi Alliance om Wired Equivalent Privacy, oftewel wep, te vervangen. Wep werd in 1997 geïntroduceerd en in 2003 kwam wpa ervoor in de plaats omdat bleek dat het algoritme absoluut niet meer geschikt was om draadloze netwerken te beveiligen. In 2006 stelde de Wi-Fi Alliance wpa2 verplicht voor gecertificeerde producten.

Aan de statistieken van Wigle is te zien dat wpa2 halverwege 2010 aan een opmars begon en in de loop van 2012 wep inhaalde als meestgebruikte beveiliging voor wifi-netwerken. Onderzoek van Kaspersky wees vorig jaar uit dat bijna 70 procent van alle onderzochte publieke hotspots was beveiligd met wpa2, terwijl tussenmaatregel wpa en wep gecombineerd op ongeveer tien procent uitkwamen. Het is dus, net als Vanhoef in zijn paper vermeldt, veilig om aan te nemen dat het overgrote deel van de moderne wifinetwerken gebruikmaakt van wpa2. Er is momenteel geen nieuwe standaard beschikbaar, dus met deze versie zullen we het nog even moeten doen.

Was het niet allang bekend dat wpa2 kwetsbaar is?

Nee, er is tot nu toe geen kwetsbaarheid in het protocol zelf vastgesteld. Er zijn wel aanvallen mogelijk die zich richten op andere aspecten, zoals het vastleggen van de handshake en vervolgens offline kraken van een zwak wachtwoord via brute force. Daarnaast zijn er bijvoorbeeld aanvallen die zich op het achterhalen van de wps-pincode richten.

Waar zit het probleem?

Wpa2 maakt gebruik van een zogenaamde 4-way handshake, waarmee een client en een accesspoint authenticatie uitvoeren en een sessiesleutel overeenkomen. Als alles correct verloopt, komt er tijdens de handshake een beveiligde verbinding tot stand. De handshake wordt uitgevoerd zodra een client een poging doet om met een draadloos netwerk verbinding te maken. Tijdens het proces installeert de client een sessiesleutel, waarmee hij gegevens versleutelt. Dit gebeurt zodra hij het derde bericht van de 4-way handshake heeft ontvangen.

Normaal gesproken verstuurt de client dan een bericht dat dit is gebeurd. Als het toegangspunt dit bericht niet ontvangt, verstuurt hij het derde bericht opnieuw waarop de client dezelfde sleutel nog een keer installeert. Vanhoef maakt hiervan gebruik om zijn aanval uit te voeren, door het derde bericht op te vangen en steeds opnieuw te verzenden. Hierdoor installeert de client steeds de nieuwe sleutel en wordt het gebruikte pakketnummer steeds opnieuw gebruikt. Dit geeft de aanvaller vervolgens de mogelijkheid pakketten te ontsleutelen of te vervalsen.

In de paper zegt Vanhoef dat de kwetsbaarheid aanwezig is, hoewel de protocollen voor de handshake en encryptie formele analyse van derde partijen hebben doorstaan en 'veilig' zijn bevonden. Dit lijkt tegenstrijdig, maar dat hoeft het niet te zijn. Cryptograaf Matthew Green zet in een blogpost uiteen dat het volgens hem misging doordat de handshake en de encryptie los van elkaar werden onderzocht en niemand keek naar de onderlinge verbinding.

Wat kan een aanvaller precies?

Krack1Dat is afhankelijk van de gebruikte encryptie. Kort gezegd stelt de methode een aanvaller in staat gegevens tussen de client en het accesspoint te ontsleutelen en in bepaalde gevallen te vervalsen. Dat eerste houdt in dat internetverkeer inzichtelijk is als de client gebruikmaakt van een onbeveiligde verbinding, bijvoorbeeld via http. Verstuurt een gebruiker bijvoorbeeld wachtwoorden, cookies of andere gevoelige gegevens via deze verbinding, dan zijn die door de aanvaller in te zien.

Dat wordt een stuk lastiger, maar niet onmogelijk, als de gebruiker een site met https bezoekt of een vpn gebruikt. In dat geval is de inhoud van het netwerkverkeer alsnog versleuteld en door de aanvaller niet in te zien. Er bestaan scenario's dat dit dan ook een risico oplevert, maar voor de normale gebruiker spelen deze niet snel. Door kwaadaardige code te injecteren, kan een aanvaller bijvoorbeeld malware uitvoeren op een apparaat. Om de aanval uit te voeren, moet een kwaadwillende zich wel in de buurt van zijn doelwit bevinden om in een man-in-the-middle-positie terecht te kunnen komen. Daarvoor lijkt niet veel meer nodig dan een laptop en een geschikt wifi-adapter.

Welke apparaten zijn getroffen?

Krack AndroidDe aanval richt zich voornamelijk op de communicatie tussen een client, bijvoorbeeld een computer of telefoon, en een accesspoint, oftewel een router. Volgens Vanhoef zijn iOS en Windows 7 en 10 niet vatbaar voor de aanval op de 4-way handshake, maar bijvoorbeeld macOS Sierra 10.12 wel.

In het bijzonder zijn Linux- en Android-apparaten getroffen die gebruikmaken van versie 2.4 en 2.5 van wpa_supplicant, een populaire wificlient. Zo zijn Android-toestellen vanaf versie 6.0 kwetsbaar voor de aanval, die er in het geval van deze apparaten voor zorgt dat de encryptiesleutel bestaat uit alleen maar nullen. Hierdoor is deze eenvoudig te voorspellen, wat tot gevolg heeft dat bijvoorbeeld netwerkverkeer is af te luisteren. Ook hier geldt weer dat het gebruik van https of een vpn het netwerkverkeer alsnog beveiligt. Volgens de laatste Google-statistieken heeft 40 procent van de Android-toestellen versie 6.0 of hoger.

Ok, en wat nu?

Vanhoef adviseert thuisgebruikers om hun clients te patchen, dus hun telefoons en computers. Daarom is het nu wachten tot fabrikanten deze beschikbaar stellen. Momenteel zijn die er nog niet voor onder meer Android. Microsoft zegt tegen Forbes dat het inmiddels een patch heeft uitgebracht. Het is niet aangeraden om in de tussentijd wep in plaats van wpa of wpa2 te gaan gebruiken, deze variant is allang niet meer veilig. De gevolgen zijn afhankelijk van het risicoprofiel van personen of ondernemingen. Te denken is aan een draadloos netwerk van een bedrijf dat gebruikt wordt om gevoelige gegevens uit te wisselen. Gebruik van https, een vertrouwd vpn of andere encryptie is altijd aan te raden. Beveiligingsonderzoeker Rik van Duijn, van het Nederlandse DearBytes, zegt tegen Tweakers: "De aanval is wel uitvoerbaar en laat afluisteren van netwerkverkeer toe, vergelijk het met een open wifinetwerk. Zolang je goede encryptie gebruikt, lijkt de impact voor particulieren beperkt." Het NCSC blijft wpa2 met aes-ccmp aanraden na de onthullingen. Er is nog geen exploit gepubliceerd.

krack updates Bron: Cert.org

Reacties (140)

140
133
79
14
1
32
Wijzig sortering
Inmiddels gefixed in Ubuntu 16.04 LTS.

Voer sudo apt update && sudo apt upgrade uit en je bent gepatched!


wpa (2.4-0ubuntu6.2) xenial-security; urgency=medium
* SECURITY UPDATE: Multiple issues in WPA protocol
- debian/patches/2017-1/*.patch: Add patches from Debian stretch
- CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087,
CVE-2017-13088
* SECURITY UPDATE: Denial of service issues
- debian/patches/2016-1/*.patch: Add patches from Debian stretch
- CVE-2016-4476
- CVE-2016-4477
* This package does _not_ contain the changes from 2.4-0ubuntu6.1 in
xenial-proposed.


Opmerkelijk genoeg is het als urgency=medium aangemerkt.
Het vereist natuurlijk alsnog wel toegang tot het lokale netwerk. Ik weet niet wat voor criteria ze precies hanteren voor medium vs high, maar ik kan me wel voorstellen dat daardoor het medium-label kreeg.
Eh, nee toch. De aanvaller krijgt toegang zonder het password nodig te hebben. Maar je moet wel in de buurt zijn, als je dat bedoelt.
Inderdaad, ik bedoelde 'fysieke' toegang, of zoals jij zegt: in de buurt zijn. Dat houdt het natuurlijk alsnog wat vaag, maar het is niet zo dat je met een botnet ineens al het wifi-verkeer kan aflezen :)
Een beetje botnet is wijd verspreid tegenwoordig :)

Maar het lijkt dat je wel speciale apparatuur (HackRF) nodig hebt voor een aanval en dat een simpel Wi-Fi adaptertje het niet kan.

[Reactie gewijzigd door Jan121 op 17 oktober 2017 11:59]

Als je Wifi chipset in AP modus kan dan lijkt het erop dat je gewoon de aanval kunt uitvoeren.
Anoniem: 36675
@EraYaN23 oktober 2017 17:06
En dat zijn heel veel WiFi adapters tegenwoordig...
Je was mij voor ;-) Zelfde patches zojuist in Mint ontvangen.
Mogelijk is het aangemerkt als "urgency=medium" omdat er nog geen exploits zijn. Als de gebruiker de beveiliging in orde heeft dan zullen gevoelige gegevens alsnog via een ander protocol versleuteld zijn.

Je kan als tegenargument noemen dat veel gebruikers hun security niet in orde hebben, maar in dat geval is er toch geen beginnen meer aan
"Opmerkelijk genoeg is het als urgency=medium aangemerkt."

Dit komt doordat ubuntu het veld urgency niet gebruikt, en dus de standaardwaarde (uit Debian) gebruikt wordt.

https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
De aanval richt zich voornamelijk op de communicatie tussen een client, bijvoorbeeld een computer of telefoon, en een accesspoint, oftewel een router. Als één van de twee een patch heeft ontvangen, dan werkt de aanval al niet meer.
Waar hebben jullie deze informatie gevonden? Volgens mij klopt dit niet: in de aanval wordt een rogue AP opgezet, die een MITM attack uitvoert tussen de client en het echte AP. Voor zover ik kan lezen kan het echte AP geen onderscheid maken tussen de client en de malicious AP, en kan het echte AP er dus ook niks aan doen. Ook bijvoorbeeld op het forum van Ubiquiti wordt gezegd dat de patch alleen helpt voor STA mode (als de AP zelf een client is, bijvoorbeeld in een Mesh netwerk).

[Reactie gewijzigd door Finwe op 16 oktober 2017 16:52]

Dat is mijn interpretatie van het stuk over routers in de q&a op de site. https://www.krackattacks.com/#faq ik pas het aan en kijk er nog eens naar.
Goed artikel man! Doet me goed om af en toe nog eens een degelijk schrijfsel op de frontpage tegen te komen. Time well spend!
Time well spend!
Als je dan toch Engels wil gebruiken, doe het dan juist. Het is “Time well spent”.
kan het echte AP geen onderscheid maken tussen de client en de malicious AP
Een acces point kan niet communiceren met een clone van zichzelf. Die geclonde AP heeft hetzelfde BSSID als de echte AP. Deze aanval kan een aantal dingen doen:

1) Kan versleuteld draadloos verkeer in real time ontsleutelen

2) Kan versleutelde packetje data die van de AP komen ontsleutelen, die data veranderanden en vervolgens de fake AP deze valse packetjes laten uitenzden. De client ontvangt nu gemanipuleerde data zonder dat de client dat weet.

3) Hetzelfde als drie maar nu kan de AP als een gateway gebruikt worden om injection te doen in de richting van elke client op dezelfde AP.

Hier is de impact table
Ed: Stom, BSSID met SSID verward; dus dan maar de volgende onnozele vraag:

Is het mogelijk je BSSID te 'verstoppen' (hidden), zodat een kwaadwillende geen MITM kan uitvoeren?

[Reactie gewijzigd door kidde op 17 oktober 2017 00:32]

Ook u verwart SSID's met BSSID's (zucht van opluchting, ik ben niet de enige ;) )

SSID =~ WiFi 'naam',
BSSID =~WiFi AP MAC

Heb het nog verder uitgezocht, maar het is praktisch onmogelijk je MAC adres geheim te houden; MAC-adres schijnt ook een 'hash' te zijn van fabrikant / type.
Oh ja, klopt helemaal wat je zegt.
Nee, je MAC kan je niet verbergen, dat heeft de DATALINK layer (OSI Model, layer 2) nodig om te kunnen communiceren op dat niveau :)
Bedankt, scheelt me tijd want dan hoef ik niet verder te zoeken :)
Een acces point kan niet communiceren met een clone van zichzelf. Die geclonde AP heeft hetzelfde BSSID als de echte AP.
Ja, om precies te zijn volgens het artikel:
As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a channel-based MitM position). However, this MitM position does not enable the attacker to decrypt packets! This position only allows the attacker to reliably delay, block, or replay encrypted packets. So at this point in the attack, he or she cannot yet decrypt packets. Instead, the ability to reliably delay and block packets is used to execute a key reinstallation attack. After performing a key reinstallation attacks, packets can be decrypted.
Maar dit verandert niks aan de conclusie dat je AP patchen dus niet helpt tegen de client-targeted attacks.
Volgens mij klopt dit niet: in de aanval wordt een rogue AP opgezet, die een MITM attack uitvoert tussen de client en het echte AP. Voor zover ik kan lezen kan het echte AP geen onderscheid maken tussen de client en de malicious AP, en kan het echte AP er dus ook niks aan doen. Ook bijvoorbeeld op het forum van Ubiquiti wordt gezegd dat de patch alleen helpt voor STA mode (als de AP zelf een client is, bijvoorbeeld in een Mesh netwerk).
Mij lijkt dat een MITM attack alleen kans van slagen heeft wanneer beide kanten de MITM accepteren. wanneer de cliënt gepatcht is, zodat hij de MITM niet meer accepteert, maakt het niet uit dat de MITM wel door het access point geaccepteerd wordt. De MITM kan dan geen 'brug' meer vormen tussen cliënt en access point.
De site zelf is hier nu eindelijk duidelijk over:
Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!
'all attacks'

Dus er blijft nog watt ruimte over voor een breekijzer wanneer slechts één deel gepatcht is. Dat is op zich zorgelijk, omdat het erg onwaarschijnlijk is dat alle cliënts en access points gepatcht worden.
Gelukkig is de aanval bewerkelijk genoeg om het onwaarschijnlijk te maken dat deze ongericht wordt uitgevoerd. Iedereen die interessant genoeg is voor een gerichte aanval zal zich wel zorgen moeten maken.
Gelukkig is de aanval bewerkelijk genoeg om het onwaarschijnlijk te maken dat deze ongericht wordt uitgevoerd. Iedereen die interessant genoeg is voor een gerichte aanval zal zich wel zorgen moeten maken.
Dat ben ik met je eens, de kans dat je als particulier hier slachtoffer van wordt is niet zo groot, maar targeted attacks is idd een heel ander verhaal.

Het scheelt wel dat als je AES-CCMP gebruikt, de attacker alleen het (un-encrypted) verkeer van de vulnerable client kan afluisteren; hij kan niet zelf packets injecten op het netwerk, etc. Dus dan vind ik het bijvoorbeeld niet zo erg dat mijn Wifi weather station unpatched blijft, kan me niks schelen wat ze daarmee doen :)
Ik zie dat zowel Dell met hun Powerconnect W-series als HPE met ArubaNetwork (dezelfde apparaten waarbij Dell de Aruba producten onder eigen naam verkoopt (PCW) via een OEM deal met Arubanetworks voordat HPE de tent overnam) inmiddels (jl donderdag al) nieuwe firmware heeft uitgebracht. Sinds donderdag kan je op download.pcw-del.com versies downloaden met een patch:
Controller-based:
AOS 6.3.1.25
AOS 6.4.4.16
AOS 6.5.1.9
AOS 6.5.3.3
AOS 6.5.4.2
IAP based:
InstantOS Release 6.4.4.8-4.2.4.9
InstantOS Release 6.5.1.0-4.3.1.6
InstantOS 6.5.3.3
InstantOS 6.5.4.2

Versienummers voor Aruba en Dell zijn gelijk - al kunnen er van Aruba ook nog aanvullende versies beschikbaar zijn die niet als Dell firmware bestaan.

Dus de grotere aanbieders waren er redelijk optijd bij (patch beschikbaar voor publiek maken van de zwakte)
het lelijke is, dat je er dan nog niet bent, alle clients moeten ook gepatched worden :(
LEDE heeft ook meteen een patch uitgebracht, mits je de trunk-versie zelf compileert (of wacht tot de aankomende nightly). https://git.lede-project....de2a43a39f772cfec2e82a9a5
"Volgens Vanhoef zijn iOS en Windows 7 en 10 niet vatbaar voor de aanval op de 4-way handshake, maar bijvoorbeeld macOS Sierra 10.12 wel."

Waar halen jullie dit vandaan? Zou dit graag verifieren. Op de website https://www.krackattacks.com staat: "During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks.".
In de paper onder paragraaf 3.2, er staat daar ook een tabel.
Paper is hier het correcte woord. Een proefschrift is een thesis dat ingediend wordt, om een doctoraatstitel te kunnen verkrijgen. Een paper echter, is een wetenschappelijk artikel over onderzoek dat iemand heeft uitgevoerd, dat (na peer review) gepubliceerd kan worden in vaktijdschriften.
Nee, "proefschrift" is incorrect taalgebruik aangezien dit document dat niet is. Deze dingen worden sinds jaar en dag papers genoemd, google maar eens op "paper cve"
Je zou het 'publicatie' kunnen noemen, maar in de praktijk zie je paper steeds meer gebruikt worden.
Dat was het woord wat ik zocht. Thnx
Ah oke, het gaat in het artikel dus enkel over 1 van de mogelijke aanvallen. En windows is kwetsbaar voor een andere variant op de aanval.
Duidelijk, dankjewel!
Windows is moeilijker aan te vallen maar niet onmogelijk, MS staat niet voor niets ook op het lijstje van CERT (waar je zelf naar linkt) en heeft niet voor niets ook een patch uit gebracht.

Edit: en de reden dat *iedereen* kwetsbaar is is omdat de fout in het protocol zit, de reden dat ervoor kan worden gepatcht is dat de verandering in gedrag om het te voorkomen niet echt afwijkt van het oorspronkelijke protocol.

[Reactie gewijzigd door Keeper of the Keys op 16 oktober 2017 22:21]

Windows en iOS zijn niet vatbaar voor de kwetsbaarheid in de 4-way handshake omdat ze kennelijk een een replay van dat 3e bericht niet toestaan. De Group Key handshake heeft echter eenzelfde kwetsbaarheid (CVE-2017-13080 & CVE-2017-13081 ) waar ze beide dan weer wel vatbaar voor zijn, dus "some variant of the attacks." klopt wel redelijk.
De hele paper omschrijft een stuk of 10 CVE's, waarvan de 4-way handshake maar een deel is.

[Reactie gewijzigd door D_el_p op 16 oktober 2017 16:24]

Maar als Windows en IOS niet vatbaar zijn, waarom stelt Microsoft dan dat er al een patch is, en is het wachten op een IOS Patch (dixit het Tweakers artikel) ?
Zoals Defractal schrijft, de kwetsbaarheid voor de 4-way handshake werkt niet op windows, maar de group key handshake attack wel. Vandaar dat er een Windows update voor nodig is.
Omdat Microsoft daarmee waarschijnlijk de Group Key handshake patched. Er kan geen key reinstallation attack (KRACK) worden uitgevoerd op de 4-way handshake, maar dat is dus maar een deel. De Group Key handshake is wel kwetsbaar op beide. Op iOS is ook de FT-handshake kwetsbaar. Dus ook daar zullen nog patches moeten komen.
Lees nou wat Defractal zegt:
De Group Key handshake heeft echter eenzelfde kwetsbaarheid (CVE-2017-13080 & CVE-2017-13081 ) waar ze beide dan weer wel vatbaar voor zijn
Als er een stuk of 10 kwetsbaarheden gevonden zijn en je bent voor 1 niet vatbaar, is er nog altijd reden genoeg om een patch uit te brengen om voor de andere 9 ook niet vatbaar te zijn. Klinkt mij in ieder geval erg logisch in de oren. De verwarring wordt gezaaid door de focus op 1 kwetsbaarheid. Geen idee waarom de focus daarop ligt, aangezien ik er technisch echt niet genoeg van af weet :)
de focus op 1 kwetsbaarheid. Geen idee waarom de focus daarop ligt
Da's voor een groot gedeelte niet technisch, maar commercieel. "Linux is lek!" doet 't wel aardig als click bait
"During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks.".
Er staat ook:
Although this paper is made public now, it was already submitted for review on 19 May 2017. After this, only minor changes were made. As a result, the findings in the paper are already several months old. In the meantime, we have found easier techniques to carry out our key reinstallation attack against the 4-way handshake. With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper.
Kan iemand mij uitleggen of een aanvaller toegang moet hebben tot het netwerk? Moet deze zelf al ingelogd zijn op het netwerk of is in de buurt zijn voldoende?
In de buurt zijn is al voldoende. De attacker installeert een "nep access point", en stuurt berichtjes naar de client om hem te proberen te dwingen te reconnecten met het nep access point (op sommige clients werkt dit niet als het echte access point een hogere signal strength heeft).

[Reactie gewijzigd door Finwe op 16 oktober 2017 16:56]

Dat je kunt communiceren met een acces point wil nog niet zeggen dat je kunt communiceren met een client ook al kan de acces point wel communiceren met de client. Wifi attacks in realiteit zijn een stuk lastiger dan op papier en je moet al physiek aanwezig zijn. De moeite waard als je probeert binnen te breken bij een groot bedrijf en via het internet lukt het niet helemaal. Niet de moeite waard om een dagje in je auto voor de deur van een oma te zitten. Wel de moeie waard om met je laptop bij macdonalds iedereen die verbonden is met de gratis wifi proberen af te luisteren. Nu kan dat al zo erg makkelijk want dat zijn meestal open AP's waar de packetjes onversleuteld door de lucht vliegen. Er zijn echter ook open hotspots die TOCH versleutelde packetjes versturen. En bijvoorbeeld zoiets als een universiteit waar je gebruikers naam en pw nodig hebt om verbinding met een WPA2 netwerk te maken. In die situaties, waar een aanvaller niet opvalt als hij midden tussen de studenten zit met zijn laptop. Daar zit het gevaar. De gewone thuis gebruiker hoeft zich echt geen zorgen te maken. Zowieso als iemand voor je deur een hele dag op zijn laptop zit is dat al verdacht.
Nou, als je in een flatgebouw woont en één van je buren is een nieuwsgierige puber, dan zou ik het toch af en toe even willen checken
Dank je wel. Vond die lijst al zo klein.
Ben benieuwd of de router van providers (zoals de KPN Experiabox) binnenkort ook een firmware update krijgen. Hopelijk zien we er over een paar weken een Tweakers artikel met risico apparaten die nog geen update hebben gehad voor deze aanval.
Dergelijke routers zijn geen WiFi clients (hoewel in theorie met root zou je ze wel kunnen gebruiken als WiFi client). Repeaters daarentegen die je gebruikt in je huishouden wel.
Ik betwijfel dat er updates komen voor routers. Misschien de Experiabox(is die verplicht?), maar alle oude routers die bij iedereen staan gaan hopeloos verouderen(mits ze dat niet al waren).
Het ding is vooral dat modems van providers ook bij mensen staan die er niet veel van weten en er vanuit gaan dat wanneer het werkt het goed is. Juist daar zit hem het gevaar: wanneer er geen updates meer worden gemaakt terwijl deze apparaten gewoon wel blijven draaien zit je dus met een hoop klanten die bijvoorbeeld hun bankzaken regelen via een verbinding die blijkbaar dus onveilig is.

Nu worden modems van providers meestal wel automatisch geüpdatet, maar volgens mij is er geen beleid voor modems die gewoon wel werken maar geen beveiligingsupdates meer krijgen.
Ik denk als er al 30% word "gepatcht" van de gewone gebruiker mag je serieus in de handjes wrijven. De gewone burger trekt er zich geen *** van aan, ik wil al die basis Android of oudere iPhone toestellen wel eens zien updates uitbrengen. Heb je geen high end phone/tablet vergeet uw patch maar.

[Reactie gewijzigd door Tr1pke op 16 oktober 2017 19:48]

ik hoop dat er een update komt voor ddwrt en openwrt. Mijn router en acces points draaien deze.
Ik heb net openwrt vervangen door lede i.v.m. onstabiliteit. Ondanks alle toezeggingen over een remerge van de codebases zie ik nog weinig gebeuren bij openwrt. De lede branch doet het overigens prima.
Raar, ik heb juist openwrt omdat het de router juist stabiel maakt.
Waarschijnlijk hangt dat af van het type router. Met OpenWRT had ik continu disconnects, die zijn nu weg.
Dat geloof ik graag, wel gepost op openwrt forum?
Dat zal een kwestie van uren zijn, arch is ook al geupdate
Tot mijn grote verbazing stelt KPN dat hun routers niet gevoelig zijn voor het lek.
Ik vind dit persoonlijk een nogal dubieuze uitspraak van KPN, miljoenen apparaten vatbaar, maar toevallig ALLE routers van KPN niet.
Ze verplaatsten gewoon de issue naar je apparaten en doen stiekem remote updates. Of ze denken letterlijk dat het niet aan hun stuff ligt.
Anoniem: 30722
@Gijs00716 oktober 2017 16:31
Mij is nog steeds niet helemaal duidelijk of de router updaten helpt. Dit zou volgens sommige bronnen alleen zijn als de router wifi als client gebruikt (wat bijna niemand doet, zeker niet bij ziggo/kpn modems)

Dus als iemand dat nog helder kan krijgen..... is alleen de router upgraden genoeg?
Dit zou volgens sommige bronnen alleen zijn als de router wifi als client gebruikt

Dat klopt betreft d ehoofd-aanval. Omdat in bepaalde complexe scenarios een router als client kan fungeren (wireless repeaters, wireless bridge, etc) is is een update gewenst.

Maar er zijn een aantal aanvallen op andere sleutesl in andere WiFi protocollen die ook potentieel kwetsbaar zijn voor een soortgelijke aanval. Dasarom moet ook een router potentieel geupdate worden.
Ik ben benieuwd hoe snel LEDE/OpenWRT hier een fix voor uit gaat brengen.
Hiermee lijkt het nog niet in de standaard releases te zitten?

Als ik naar de bestandsdatum kijk:
14:44 04-10-17 voor een lede-17.01.3-ar71xx-generic-wndr3700-squashfs-sysupgrade.bin dan heeft 'ie 'm nog niet.

Dit is een mooi moment om met een verse install te beginnen maar dan moet 'ie er wel inzitten :)


Update:
ik kom dit tegen op het forum:

Will this be addressed in this release?

dlang 7h
no, it will be fixed in v17.01.4, it wasn’t known in 17.01.3

David Lang

[Reactie gewijzigd door zaadstra op 16 oktober 2017 22:09]

Je kunt de development builds ook downloaden/installeren als je niet op de release wil wachten:
http://downloads.lede-project.org/snapshots/targets/

Zoals het ook in de thread staat:
"the lede-17.01 branch now contain these fixes" ( https://git.lede-project.org/?p=source.git;a=summary)
In hoeverre kan MAC adres filtering een oplossing bieden?
Helpt niet, de attacker spooft gewoon het mac address van de echte client.
In hoeverre kan MAC adres filtering een oplossing bieden?
In feite is dat niet meer dan een extra hobbel. Een MACadres is ook zo te spoofen immers.
MAC adressen zijn niet veilig, deze zijn te sniffen en te spoofen.
MAC filtering is ook echt alleen maar een ding om script kiddies te stoppen.
In het filmpje bij jullie artikel https://tweakers.net/nieu...ek-in-wpa2-standaard.html word wel duidelijk dat https te ontsleutelen is. Het zal niet voor alle sites gelden. Maar dat https alles beveiligd zoals boven wordt genoemd klopt dus niet.
Op zich staat dat los van deze aanval. SSL strip is iets wat je toepast in welke MiTM (man in the middle) aanval dan ook. HTTPS gebruiken (en verifiëren dat je HTTPS met het juiste cert krijgt aangeboden) is dus zeker wel een valide opmerking.
SSL strip werkt alleen flawless op websites die hun SSL niet helemaal goed implementeren. Anders krijg je in de browser een waarschuwing dat er iets aan de hand is.

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