Nieuwe wifibug in iOS kon ook worden misbruikt zonder tussenkomst van gebruiker

De kwetsbaarheid in iOS waarmee een telefoon kon worden gecrasht door met een bepaald ssid te verbinden, kon ook worden misbruikt voor remote code execution. Apple heeft dat lek inmiddels gedicht na een melding van beveiligingsonderzoekers.

De nieuwe bug werd ontdekt door onderzoekers van beveiligingsbedrijf ZecOps. Die noemen de kwetsbaarheid WiFiDemon. Het is een zero-click kwetsbaarheid, waarvoor dus geen tussenkomst van de gebruiker nodig is. Aanvallers konden een iPhone laten verbinden met een bepaald wifinetwerk en daarmee van een afstand code op de telefoon uitvoeren.

WiFiDemon borduurt voort op een kwetsbaarheid die eerder werd ontdekt in iOS. Met die bug kon wifi op een iPhone worden uitgeschakeld als het verbond met ssid %p%s%s%s%s%n. Later bleken ook andere soortgelijke strings voor bootloops in de wififunctionaliteit te zorgen zodat die crashte. Apple verwijderde de mogelijkheid om met ssid's te verbinden die de %n-string bevatten, maar Zecops zegt dat dat niet de enige mogelijke kwetsbaarheid is.

De onderzoekers wisten een ssid aan te maken met de format specifier %@ die in Objective-C wordt gebruikt. Als een aanvaller een telefoon kan laten verbinden met een ssid-netwerk dat daarmee begint kan het, net zoals in het eerdere lek, een bootloop veroorzaken. Het lek kan daarnaast worden uitgebuit zonder tussenkomst van de gebruiker. Daarvoor moet een aanvaller %@ achter een ssid zetten waar een telefoon al mee verbonden is. Als een gebruiker 'Automatisch verbinden' aan heeft staan voor wifinetwerken, dan verbindt de telefoon automatisch met het foute netwerk. Volgens de onderzoekers kon er vervolgens een use after free worden getriggerd waarmee het mogelijk is code uit te voeren op een telefoon.

Het lek zat in iOS-versies 14 tot en met 14.4. De onderzoekers zeggen dat de zero-click-mogelijkheid is verholpen in iOS 14.6, maar dat het in die versie nog steeds mogelijk is wifi te laten crashen als een aanvaller een gebruiker kan laten verbinden met een uniek ssid. Daarvoor is dan dus wel gebruikersinteractie nodig. Voor oudere versies zouden gebruikers het automatisch scannen naar en verbinden met wifi-netwerken uit kunnen schakelen. De crash heeft geen CVE-code gekregen. Apple bracht deze week iOS 14.7 uit, maar in de releasenotes staat niets specifiek over dit lek.

Reacties (84)

[virtualjoe]

Informeel wordt vermeld dat het lek is gefixed in 14.7: https://twitter.com/ZecOps/status/1417396899750072321

[laptopleon]

Volgens de onderzoekers kon er vervolgens een use after free worden getriggered waarmee het mogelijk is code uit te voeren op een telefoon.

Het artikel laat geheel in het midden hoe die code dan op de telefoon terecht komt, wat het voor code is, wat die code doet, welke app of api het gebruikt…

[thomasmoors]

[...]


Het artikel laat geheel in het midden hoe die code dan op de telefoon terecht komt, wat het voor code is, wat die code doet, welke app of api het gebruikt…

hoe de code op de telefoon komt
Door deze via de wifinaam (SSID) te sturen, op de site noemen ze dat spraying. Deze code komt erin door string formatters te gebruiken. Hier is een plaatje hoe dat er in de praktijk uit ziet (de naam wordt niet perfect weergeven in deze interface trouwens).

wat voor code het is / wat het doet
Dat is wat de aanvaller schrijft, zij hebben enkel een proof of concept dat het kan. Dus wat de aanvaller wil dat het doet.

welke app of api
in het gedeelte wat verbindingen met wifi regelt, blijkbaar heet die wifid, vandaar de naam ook.


Uitgebreid artikel: https://blog.zecops.com/r...hat-was-silently-patched/

[Reactie gewijzigd door thomasmoors op 28 juli 2024 11:00]

[xbeam]

Het is zo jammer dat Tweakers mee werkt aan deze FUD en niet zelf leest en kijkt wat het doel van deze blog er is namelijk helemaal geen nieuwe bug. Het doel van de blog is het verkopen van hun mobile EDR software. De gebruikte oude bug dient als proof of concept om te laten zien wat de gevaren van de huidige WiFi format-string bugs kunnen zijn en hoe hun mobile EDR daar tegen beschermt.

De naam van het blog geeft zelf al aan. Dat het om oude bug gaat

and a Zero-Click Vulnerability That Was Silently Patched

ze geven zelf in hun blog medere malen aan dat een oude om andere oude bug gaat die ze voor deze 0 click aanval hebben gebruikt en dat deze al in b]februari 14.4 is gepatched[/b] door Apple zelf met screenshot naar release not van iOS
https://blog.zecops.com/w...021/07/1-ios144-patch.png

Remotely exploitable, 0-click, under the hood!

Further analysis revealed that:

Attackers did not need to force the user to connect. This vulnerability could be launched as a 0click, without any user interaction. A victim only needed to have your WiFi turned on to trigger the vulnerable code.
This is not a DoS, but an actual RCE vulnerability for both the recently patched 0-click format-strings vulnerability, and the malicious SSID format-strings 0-day vulnerability.
This 0-click bug was patched on iOS 14.4 and credits “an anonymous researcher” for assisting. Although this is a potent 0-click bug, a CVE was not assigned.

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[laptopleon]

Het gelinkte artikel is heel enthousiast geschreven, maar de mogelijkheden zijn nogal beperkt.

Since the SSID length is limited to 32 bytes, we can only put up to 16 Escape characters in a single SSID. Then the Escape characters we placed will process the corresponding data on the stack.

Kortom alleen al doordat de naam van een WiFi-router maar 32 tekens lang kan zijn en er voor elk teken een escape-teken nodig is bij deze trucs. Plus dat er 6 tekens (plus escapes) nodig zijn om iOS te laten crashen, blijft er hooguit 10 karakters over.

Kortom de hele aanval moet passen in 10 lettertekens. Dat is nogal een beperking.

Men heeft het over het aanmaken van een object. Met 10 characters.

Dan nog is het maar de vraag wat hiermee te bereiken is aangezien het inderdaad in een stukje code draait wat de wifi afhandelt.

Alles bij elkaar is het niet heel waarschijnlijk dat hier ooit daadwerkelijk kwaadaardige code mee uitgevoerd kan worden.

De auteur heeft dit waarschijnlijk ook wel gezien en bedacht, dus waarom dit niet gewoon meegenomen in het artikel?

[GertMenkel]

Kwaadaardige code uitvoeren is heel triviaal, alleen ben je natuurlijk beperkt door die tien bytes. Dat wordt ook in het verkoopverhaal/artikel genoemd: het sprayen van genoeg uitvoerbare code is een "exercise for the reader".

In theorie kun je natuurlijk gewoon vierduizend wifi-netwerken spoofen en met veel moeite genoeg code execution krijgen om de rest van de exploit van internet te pakken. Dat hebben de auteurs van het blog niet gedemonstreerd.

De WiFi-daemon zal tijdens het exploiten constant crashen en herstarten op de achtergrond, dus bij het uitvoeren moet de telefoon in iemands zak zitten of uitstaan bijvoorbeeld. Als je lang genoeg wacht, kun je er waarschijnlijk wel genoeg code in krijgen om hem daadwerkelijk uit te voeren.

Dat kan handig zijn voor bijvoorbeeld politie, die geen moeite heeft met zo'n apparaat een week in een Faradaykooi en een aanvalsapparaat te leggen als ze aan bewijsmateriaal willen komen. In het dagelijks leven is zo'n aanval natuurlijk niet praktisch en heeft ieder OS genoeg lekken die wel direct uit te voeren zijn als je het scherm kan aanraken, maar het is niet compleet onmogelijk om hier wat mee te doen.

[Reactie gewijzigd door GertMenkel op 28 juli 2024 11:00]

[xbeam]

Het probleem is dat je geen 4000 duizend WiFi netwerken kan spoofen omdat de benodigde bug al in februari is gedicht.

De blog is een advertorial met een hypothese.
De gebruikte bug is 3 updates teug in februari al gedicht.

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[GertMenkel]

In het gelinkt blog wordt het tegendeel beweerd, en met geheugendumps ook gedemonstreerd. Er wordt een functiepointer overschreven die wordt aangeroepen. De uitdaging zit hem nu om genoeg data in RAM te krijgen om daar wat nuttigs mee te doen, maar code execution is bewezen. Het afmaken van de exploit chain hebben de adverteerders/onderzoekers inderdaad niet gedemonstreerd, maar er zit doorgaand een structuur in de manier waarop apparaten dit soort dingen in het geheugen opslaan en een SSID bestaat uit 32 bytes zonder verdere structuur. Je kunt dus blokken van 32 bytes op relatief voorspelbare plekken in het geheugen inladen (dat gaat gewoon ergens een list in). Als je exploit mislukt, crasht het proces en begint de aanval van voor af aan.

Dat de bug al opgelost is, ontken ik niet. Voor mensen met gejailbreakte iOS kan het alsnog een risico zijn, omdat die niet per se een veilige versie van iOS willen draaien, en sommige mensen weigeren op de updateknop te drukken uit angst dat dingen veranderen op hun telefoon.

[xbeam]

Dat snap ik maar het wordt overal gebracht als of het een nieuwe bug en alle iPhones nu kwetsbaar zijn.

Terwijl de onderzoekers zelf in hun blog aangeven dat zero click chain gebouwd is met al in februari gedicht bug waardoor momenteel alleen bekende denial of service attack mogelijk.

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[GertMenkel]

Tja, ik vind het ook wat overdreven. Ik zou het wel als nieuwe but classificeren want Apple heeft al een poging gedaan om het probleem te patchen (maar is toen bepaalde formatters vergeten), en dit is volgens mij het eerste blog dat daadwerkelijk een flow naar code execution laat zien, maar in de media wordt de impact inderdaad zwaar overdreven.

[laptopleon]

Bij de gepatchte versie lukt deze aanval sowieso niet meer. Deze ‘nieuwe’ bug is de oude bug maar blijkt meer te ‘kunnen’ dat eerst bekend gemaakt.

[xbeam]

Klopt. Alleen voor de rollingen SSID aanval die ze uitvoeren heb je dus die oud al in februari geplette bug nodig.

Wat alleen nu nog speelt is inderdaad de storing format bug. Waar 1 malig Max 30 (2 van dr 31 tekens %@ zijn al in gebruik ) tekens kan gebruiken en de gebruiker moet ook nog eens zelf op klikken.

Technisch is dus niets nieuws of anders dan 2 weken terug. Behalve dat er nu met een oude reeds gedicht Bug een proof of concept is. Wat een bedrijf gebruikt om zijn Mobil EDR te promoten. Niets mis mee.

Het stoort mij alleen dat veel media het brengen als of er een gevaar/bug is en dat alle iPhone direct gevaar lopen en dat direct auto join moet uitzetten. terwijl dat helemaal niet zo is.

[laptopleon]

Netto kun je maar 10 tekens schrijven en dan nog alleen op één plaats – die je niet zelf kunt kiezen – in de code die wifi-verbindingen maakt.

En dan nog, zoals je zegt in het ram-geheugen. Als de app herstart, zal een verse instance van de app worden aangemaakt. Die bevat de code van de vorige keer niet..

Kortom ook stukje bij beetje met 10 bytes per keer de wifi-daemon aanpassen kan simpelweg niet op deze manier.

Zelfs als dat wel zou kunnen, zou je precies moeten weten dat een bepaalde iPhone contact gemaakt heeft en met welke van de waarschijnlijk tientallen, zoniet honderden ssid’s die je daarvoor nodig hebt, zodat je steeds de juiste / het juiste stukje code voor kunt schotelen.

[GertMenkel]

De 10 bytes zijn alleen nodig voor code execution, de rest van de SSIDs kunnen gewoon willekeurige data bevatten. Op zich nog steeds niet veel, natuurlijk.

Of het praktisch is of niet, er wordt hier onder de streep kwaadaardige code uitgevoerd, al is het maar omdat de kwaadaardige code je WiFi kapot maakt. Kwaadaardige code betekent niet dat je een hele exploitchain hebt, een enkele INC of JMP voldoet al om zo genoemd te worden.

Als je hier wat mee wilt, zou je dit bijvoorbeeld voor privilege escalation kunnen gebruiken. Installeer een app op het apparaat die veel (kernel) geheugen alloceert en gebruik de WiFi-exploit om genoeg willekeurige sprongen mogelijk te maken dat je root/system/whatever hebt. Wie weet kun je Safari gek genoeg krijgen om dat geheugen te alloceren in zo'n hotspotpagina, en de exploit aanzetten nadat iemand met Safari een bepaald groot plaatje o.i.d. heeft opgevraagd, ik noem maar wat.

[laptopleon]

De 10 bytes zijn alleen nodig voor code execution, de rest van de SSIDs kunnen gewoon willekeurige data bevatten.

Na die eerste 10 bytes crasht de app. Daarna herstart hij. De herstart bevat de 10 bytes niet meer want na een crash herlaad je de app, dus de aanvaller moet weer bij nul beginnen. Je komt nooit verder dan 10 bytes op dezelfde plek in de code.

Bovendien probeert je iPhone met dezelfde ssid weer contact te maken, dus waarom zou hij netjes de volgende ssid nemen, met het volgende stukje code?

Daarnaast is het niet de eerste keer dat zoiets geprobeerd wordt. Er zitten daarom al voorzorgsmaatregelen in iOS zoals Address Space Layout Randomization (ASLR) en vast nog veel meer leuke trucs, waar Apple niet het achterste van haar tong over laat zien.

[GertMenkel]

Je kunt natuurlijk eerst een hele hoop SSID's uitzenden en na een paar seconden, als de telefoon die al in de lijst van beschikbare netwerken heeft, de exploit sturen.

Hoe dan ook, mijn punt is dat hier wel degelijk willekeurige code door een aanvaller kan) wordt uitgevoerd, hoe beperkt de vrijheid van de aanvaller ook is.

ALSR is inderdaad aanwezig, maar ALSR wordt ook bij iedere exploit chain weer omzeild. Het beschermt misschien tegen micro-injecties, maar het is niet voldoende om RCE tussen verschillende memory boundaries te voorkomen. Je hoeft maar 1 geheugenadres te vinden en je hebt ASLR verslagen, dus wie weet kun je de RCE gebruiken voor privilege escalation. Als je uit de browser een geheugenadres kan lekken, hoef je maar 1 jump (4 bytes) te krijgen om de nodige schade toe te doen.

[xbeam]

Hiervoor gebruiken ze dus die oude bug die in februari al is gedicht

[xbeam]

Hiervoor gebruiken ze dus die oude bug die in februari al is gedicht

Die bug maakte het mogelijk dat je een bestaande reeds verbonden ssid kon gebruiken en daar dus een @ + string achter kon zetten en de iPhone dus gewoon verbond. Dat is de zero click die ze gebruiken om met rollingen SSID’s code te injecteren.

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[boolean]

Als je ook maar een heel klein beetje bekend bent met de jailbreak scene, weet je dat veel exploit mogelijkheden alsnog worden gepatched door tweak developers.

[Kenhas]

Misschien is dat door de onderzoekers gewoonweg niet vrijgegeven. Ze melden dat er een kwetsbaarheid is maar meer details niet om misbruik te voorkomen

Ik zeg maar iets

[david-v]

Eh ja, het is nog niet gepatched, dus hoe minder je over het probleem verteld aan de massa hoe beter. Apple heeft waarschijnlijk wel de volledige informatie, want die moeten het fixen.

[WhatsappHack]

Als ik zo lees is het wél gepatcht en gebruikt men een oudere iOS-versie voor de PoC van deze exploit

[david-v]

Ik las dit stukje en dacht juist dat het nog niet helemaal ok is:

De onderzoekers zeggen dat de zero-click-mogelijkheid is verholpen in iOS 14.6, maar dat het in die versie nog steeds mogelijk is wifi te laten crashen als een aanvaller een gebruiker kan laten verbinden met een uniek ssid

Ik denk ook dat ze pas openheid geven als het merendeel van de iOS devices de nieuwe versie hebben geïnstalleerd.

[xbeam]

Staat duidelijk in de blog dat sinds 14.6 alleen de 1click bug denial of services bug nog werkt en dat zero click in februari al is gedicht is.

Wat @WhatsappHack zegt klopt.

[david-v]

Heb je het nou over de tekst hier in Tweakers of over de bron?. Ik reageerde namelijk alleen op wat hier geschreven was en dat is niet helemaal duidelijk. Als het in de bron wel volledig beschreven staat dan is het uiteraard een ander verhaal, zo ver heb ik niet gekeken

[xbeam]

Nee de blog waar het artikel naar verwijst. Neem het jou ook niet kwalijk. Waarschijnlijk heeft Tweakers gewoon het Forbes bericht van afgelopen zaterdag overgenomen en daardoor niet zelf aandachtig de blog gelezen.

https://www-forbes-com.cd...w-iphone-ios-upgrade/amp/

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[Verwijderd]

Om zo'n situatie te voorkomen, is het advies van Adrian Kingsley-Hughes (de auteur van dit ZDNet artikel) om in de WiFi instellingen van iPhones (en iPads) "Verbind met hotspot" te wijzigen van "Automatisch" in "Vraag om verbinding" of "Nooit".

Of het volgende verstandig is weet ik niet zeker, maar ik heb tevens "Vraag om verbinding" op mijn iPhone op "Uit" gezet. Er wordt dan nog steeds automatisch verbinding gemaakt met "bekende netwerken" (dus SSID's van WiFi access points waar het toestel eerder een geslaagde verbinding mee had, zoals je thuisrouter), maar als er alleen onbekende netwerken (of geen enkele) binnen bereik zijn, gebeurt er niets (geen meldingen of vragen dus; je moet dan, indien gewenst, handmatig naar je instellingen om een nieuw netwerk toe te voegen).

(PS ik schreef dit ook op security.nl).

[GertMenkel]

Hoewel je met deze instelling wel het aanvalsoppervlak verkleint en wellicht andere exploits voorkomt, kun je ook gewoon je telefoon bijwerken naar de nieuwste versie van iOS. Zelfs als je telefoon kwetsbaar is, is de aanval nog steeds enorm moeilijk omdat je ongeveer tien bytes per keer aan code kan uitvoeren en dat maakt het exploiten in de praktijk zeer moeilijk. Het enige nut dat je hier denk ik uit kan krijgen is dat je de iPhone in een gare staat kan krijgen waarin hij niet meer kan verbinden met WiFi, een denial of service dus, zoals de bug origineel gerapporteerd is.

De impact van de bug wordt zwaar overdreven. De auteur van de blog-post doet dan ook zijn of haar best om je een security-product aan te smeren. Als dit het is qua beveiligingsproblemen, zou ik me er niet zo druk over maken.

Als je telefoon niet meer ondersteund wordtniet kan of wil updaten, is dit natuurlijk een redelijke workaround, maar ik denk dat je op dat moment al genoeg andere, ernstigere, veel bruikbaardere lekken hebt klaarliggen in je software.

[Reactie gewijzigd door GertMenkel op 28 juli 2024 11:00]

[Verwijderd]

De impact van de bug wordt zwaar overdreven.

Eens. Ik schat de kans op RCE (Remote Code Execution) op bijna nul.

Het risico is vooral DoS, met name de tweede door Carl Schou gepubliceerde SSID (bron):
%secretclub%power
liet of laat WiFi op iPhones zo vastlopen dat herstel erg lastig kan zijn.

[GertMenkel]

Herstel is gelukkig slechts eenvoudig maar vervelend, je moet namelijk je netwerkinstellingen resetten (of de hele telefoon) en dan is de DoS weer weg. Heel vervelend als een trol het doet, maar niet onoverkomelijk.

[Verwijderd]

Herstel is gelukkig slechts eenvoudig maar vervelend, je moet namelijk je netwerkinstellingen resetten (of de hele telefoon) ...

Carl Schou:

[...]
Resetting network settings is not guaranteed to restore functionality.

Zie ook zijn bijdragen daaronder.

[GertMenkel]

Ah, ik zie het. Apart, aangezien anderen in de replies aangeven dat bij hun het probleem wel makkelijk op te lossen is. Dat maakt het verhaal wel wat lastiger, maar ik heb geen idee hoeveel lastiger aangezien het systeem niet betrouwbaar faalt.

[Reactie gewijzigd door GertMenkel op 28 juli 2024 11:00]

[Verwijderd]

Tnx voor jouw reply!

Als mijn veronderstelling klopt, en een printf()-achtige functie een extra parameter op de stack verwacht - terwijl daar onverwachte (mogelijk onvoorspelbare) bytes staan, is het erg lastig om te voorspellen wat er daarna gebeurt.

Ook weten we niet wat Carl Schou eerder allemaal geprutst heeft met z'n iPhone, corruptie op corruptie kan de zaak verergeren.

Natuurlijk is het verstandig om de laatste updates (iOS versie) te installeren, maar voor zover ik weet heeft Apple niet gepubliceerd dat deze bug(s) gefixt is (zijn).

Dus is het mijn advies om het zekere voor het onzekere te nemen, en de WiFi instellingen op zo veilig mogelijk te zetten - zeker bij eigenaren die niet "handig" zijn met iPhones.

[xbeam]

Nog makkelijker delete het het wifi netwerk uit je keychain en je wifi werkt weer.

[laptopleon]

Als je telefoon niet meer ondersteund wordt,

Die situatie komt niet voor, want je iPhone ondersteunt versie 14.x of niet.

Dus of je hebt 13 en dan lukt deze truc niet, of je hebt 14 en dan kun je updaten naar de gepatchte update.

[GertMenkel]

Goed punt, ik zal het weghalen.

[WhatsappHack]

Grappig, heb dat sinds het begin uitstaan omdat het sowieso bloedirritant is.

[Verwijderd]

Grappig, heb dat sinds het begin uitstaan omdat het sowieso bloedirritant is.

Ik zie twee instellingen:

1) Vraag om verbinding (Uit, Meld, Vraag)

2) Verbind met hotspot (Nooit, Vraag om verbinding, Automatisch)

Die tweede had ik al lang op "Nooit" staan, met het advies van Adrian Kingsley-Hughes hoefde ik dan ook niks te doen.

Die eerste stond op mijn iPhone nog niet op "Uit", mogelijk omdat ik de tekst erbij destijds niet goed gelezen/begrepen had, maar het kan ook dat deze instelling na een update "spontaan" is gewijzigd (Bluetooth staat, ongevraagd, na updates vaak ook weer aan).

Overigens vermoed ik dat het niet om een bug in de WiFi-stack gaat, maar dat de SSID niet sanitized wordt voordat deze in een melding gedisplayed wordt.

Dan helpt natuurlijk het zoveel mogelijk voorkomen dat iOS probeert die string te "printf()'en", dus lijkt het uitzetten van beide instellingen mij het verstandigst. Ik heb (nog) geen WiFi problemen gehad met die settings, maar zet WiFi meestal helemaal uit als ik de deur uitga (als ik dat niet vergeet )

Terzijde, op m'n OnePlus 6 regelt de app WiFi Magager dat voor mij door te kijken of bekende GSM masten in de buurt zijn (da's één van de privacy friendly apps van SECUZO, voorheen TU Darmstadt).

Edit: "Ik zie zijn twee -> "Ik zie twee"

[Reactie gewijzigd door Verwijderd op 28 juli 2024 11:00]

[Loekie]

Wat ik uit deze opmerking haal: "Daarvoor moet een aanvaller %@ achter een ssid zetten waar een telefoon al mee verbonden is. Als een gebruiker 'Automatisch verbinden' aan heeft staan voor wifinetwerken, dan verbindt de telefoon automatisch met het foute netwerk."
Is dat je dan nog steeds gecompromiteerd kan worden(je auto-joined nog steeds bekende netwerk).

[Verwijderd]

"Daarvoor moet een aanvaller %@ achter een ssid zetten waar een telefoon al mee verbonden is.

Dat is niet wat ik begreep uit de tweets van Carl Schou, die lijken te wijzen op wildvreemde accesspoints.

Zoals ik zojuist schreef aan Whatsapphack: vermoedelijk gaat het mis bij SSID's die jouw iPhone jou ongevraagd toont (of als je, binnen bereik van een AP met foute naam, in de instellingen naar een bekend netwerk zoekt en dus iOS ook die foute naam probeert te tonen).

Mocht je gelijk hebben: als iemand die jij kent jou zoiets flikt, kun je haar of hem (gezien het weer) uitnodigen voor een zeiltochtje en dan kielhalen o.i.d.

[IThom]

Is het niet tijd voor een verdiepingsartikel over al die exploits voor iOS die zowat wekelijks naar buiten komen? De NSO Group heeft ook na elke patch gewoon weer een andere manier om iPhones binnen te komen.
Heeft het te maken met Niet-patchbare bootrom-jailbreak komt uit voor iPhone 4S tot en met iPhone X waardoor code nu toegankelijk is en onderzocht kan worden door beveiligingsonderzoekers?

[Reactie gewijzigd door IThom op 28 juli 2024 11:00]

[TijsZonderH]

Is het niet tijd voor een verdiepingsartikel over al die exploits voor iOS die zowat wekelijks naar buiten komen?

Dit klinkt meteen heel breed, wat zou je hier specifiek voor je zien? Lijkt me supervet om in iOS te duiken maar dan moet het wel een duidelijk kader hebben denk ik.

[IThom]

Ik weet het niet helemaal zeker, maar voor mijn gevoel kom ik steeds vaker nieuws tegen over weer een nieuwe exploit voor iOS: vaak voor remote code-execution en eens in de zoveel keer zelfs zonder tussenkomst van de gebruiker benodigd. Dan moeten wij logischerwijs ook nog ervan uitgaan dat er nog andere exploits zijn die ofwel nog niet bekend zijn bij Apple dan wel momenteel nog niet gepatched zijn.

Een verdiepingsartikel zou denk ik kunnen bevatten:
- Een tijdlijn met exploits in het verleden (die dus inmiddels gepatched zijn
- Een vergelijking met aantal exploits in eerdere iOS versies
- Wellicht iemand van FoxIT oid die wat meer kan vertellen over het ontstaan van de exploits, misschien een beetje over wat diegene denkt of / en wat Apple hier aan moet doen.
- Het feit dat o.a. Zerodium al meerdere keren de inkoop van nieuwe exploits (tijdelijk) heeft stopgezet / de inkoopprijzen heeft verlaagd voor sommige soorten iOS exploits omdat ze overstroomt werden met exploits. (En momenteel geen aanhoudende exploits inkoopt, die blijven werken na een herstart van het toestel)
- Een reactie van Apple (als ze die willen geven)

Er valt vast nog wel meer te verzinnen

[TijsZonderH]

Het probleem is dat iOS natuurlijk een erg aantrekkelijk doelwit is en er dus veel geld en kennis in wordt gestopt om exploits te vinden, net als bij Windows. Je kunt inderdaad kijken naar data (dus aantallen exploits nu vs vroeger), maar dat levert denk ik al snel verkeerde conclusies op omdat je het moet vergelijken met het stijgende gebruik en veel andere factoren.

Het lijkt me wel zeker interessant nog eens naar de markt van exploits te kijken. Dat is inmiddels al een beetje uitgekauwd maar van de andere kant zijn er wel veel ontwikkelingen gaande in de laatste jaren. Dat ga ik zeker eens bespreken tijdens onze volgende redactievergadering ja! Een reactie van Apple zou ik echter niet verwachten, die zijn nooit heel happig om commentaar te geven

[IThom]

Daar heb je inderdaad gelijk in, en een direct verband is natuurlijk lastig / niet aan te tonen. Wel zou misschien aangetoond kunnen worden of er een significante toename in het aantal (bekende) exploits is geweest in relatie tot bepaalde gebeurtenissen, o.a. de bootrom exploit, Apple's vernieuwde bugbounty programma. Ik denk dat dat soort informatie wel beschikbaar is bij cybersecurity bedrijven.
Als je moet beveiligen moet je niet alleen reageren maar ook kunnen ageren. Die moeten dus kunnen weten uit welke hoek bepaalde bedreigingen vandaan komen.

Inderdaad staat Apple er niet om bekend dat ze een reactie geven op zulk soort dingen, ik ben wel erg benieuwd wat hun kijk hierop is.
Ervan uitgaande dat ik niet de enige ben die zich hierover zorgen maakt, moeten er mogelijk dingen gedaan worden om klanten / investeerders e.d. gerust te stellen?
(Ik ben nu wel een beetje aan het speculeren, vind het in ieder geval een interessant onderwerp.)

[laptopleon]

Als je alleen al kijkt naar deze week, zijn er op tweakers ook nieuwsberichten over exploits in Windows, Android en zelfs Linux beveiliging.

En dan bedoel ik ‘zelfs Linux’ als in: Terwijl dat op maar 1% of zo van de desktops gebruikt wordt en het een probleem is wat (ook) op desktops speelt. Dus bedoel het niet als in: Linux is zeldzaam maar Linux is zeldzaam als desktop-OS — en toch speelt het daar ook.

[laptopleon]

Ik zou ook wel eens zoiets willen zien en dan meteen ook een vergelijking met andere systemen maar vooral toegespitst op de ernst ervan.

Anders krijg je de decennia-oude discussie dat bij het ene systeem sowieso meer exploits gevonden worden, omdat het populairder dus interessanter om te hacken is.

Bijvoorbeeld de hack uit dit artikel – hoe knap gevonden ook – is in de praktijk niet bruikbaar. En dat geldt voor de meeste kwetsbaarheden. Dus ja, daar ga je er meer van vinden bij Windows, ook als Linux evenveel gaten heeft, omdat Windows interessanter is om te hacken.

Veel interessanter is het, om te weten hoeveel hacks er zijn per systeem, waarmee iemand op afstand bijvoorbeeld je computer binnen kan komen, bestanden kan manipuleren, etc.

[GertMenkel]

Hoewel er zeker genoeg exploits voor iOS voorbij komen, is het niet veel kwetsbaarder in de praktijk dan andere besturingssystemen. Als je een lijst van exploitbare bugs wilt zien, kun je gewoon de changelog van iedere security-update doorlezen. Daar staan vaak namen bij in de credits, als je die Googlet kom je heel snel op een blog-post waar details beschreven worden. Lang niet altijd, omdat Apple liever heeft dat je hun privé-issuetracker gebruikt en omdat niet iedereen de tijd heeft of de moeite wil nemen om zo'n bug uit te schrijven, maar gelukkig zijn veel van dit soort onderzoekers gemotiveerd om het wel te doen (onder andere uit carrière-overwegingen, "ik heb iOS gehackt" staat nu eenmaal goed op je CV).

De meeste exploits die het nieuws halen zijn op dat moment niet of net gepatcht. iOS is behoorlijk goed beveiligd, net als Android overigens, dus daarom halen dit soort dingen het nieuws vaker. Het feit dat iPhones onder andere een prestige-apparaat zijn en het feit dat Apple-fanboys en Apple-haters veel reageren op dit soort nieuws drijft de nieuwsmolen wel flink.

Hoewel het misschien saaier is en minder kliks absorbeert, zou ik persoonlijk juist meer over Android-exploits in de praktijk willen lezen. Wie herinnert zich bijvoorbeeld nog Stagefright, een bug die code execution op telefoons kom krijgen met een simpele MMS, die nooit op grote schaal is toegepast?

iOS is tegenwoordig behoorlijk open voor onderzoekers, terwijl Android juist in de belangrijke laag, namelijk op driverniveau, juist enorm gesloten is door Qualcom, MediaTek en vrienden. Ook is de kans dat je iPhone een update krijgt veel groter dan de kans dat je Android een update krijgt. Mijn telefoon heeft bijvoorbeeld eergisteren bijvoorbeeld mijn kwartaalse beveiligingsupdate gehad, die lekken repareerde die al twee-en-een-halve maand open staan. Ook de combinatie van oude Androids, de Covid-tracker en de Bluetooth-exploit die makkelijk uit te buiten is, is een kanshebber voor virussen die je in de iPhone-wereld eigenlijk niet veel voorbij ziet komen.

Ik denk persoonlijk dat zo'n artikel snel te breed wordt en niet echt verdiepend zal zijn, meer een samenvatting van nieuws, maar ik zou denk ik geen nee zeggen tegen zo'n artikel.

[Macboe]

Ten eerste: mooi dat het lek gedicht is. Wat gebeurde er nu precies dan nadat de telefoon crashte? Dit is mij niet helemaal duidelijk.

Aanvullend op IThom, apart artikel plus meldingsbericht is/ was dat m.b.t. de jailbreak.

1: Men zei unthetered (tot op de dag van vandaag nog niet)
2: Geen hogere iOS te jailbreaken dan 14.3, dus ook geen iOS 15 Beta.

Dus is Checkra1n wel een echte "Niet-patchbare bootrom-jailbreak". Ik zit nog steeds op iOS 14.2 met mijn iPhone X

[IThom]

beetje off-topic maar toch even een reactie:
- Er heeft nergens gestaan dat Checkra1n een untethered jailbreak was of zou worden, dat is ook vanaf het begin gezegd
- Dat er nog geen jailbreak is komt niet doordat de exploit nu gepatched is, maar omdat dat gewoon tijd kost. Zolang toestellen die kwetsbaar zijn voor de exploit (Tot en met iPhone X) updates krijgen, kan er een jailbreak gemaakt worden die gebruik maakt van de bootrom exploit.

Wat dat betreft was de titel van dat artikel dus niet juist: de bootrom is niet de patchen omdat het om hardware gaat. Er zijn wel degelijk softwarematige aanpassingen mogelijk waardoor er elke keer een nieuwe jailbreak gemaakt moet worden.

[Raymond Deen]

Dat plaatje met decompiled code voegt mi niets toe.
Ik zie liever een iets uitgebreidere uitleg hoe je jezelf kan wapenen tegen dit soort dingen totdat er een patch beschikbaar is.

[Kenhas]

Euhm, "automatisch verbinden" uitzetten. Ligt toch beetje voor de hand, dacht ik

[Raymond Deen]

Ik kom op veel plekken met voor mij vertrouwde WiFi-netwerken, maar als ik dan lees dat een kwaadwillende de naam van zo’n netwerk kan aanpassen met %@ erachter waarbij die aanpassing er dan voor zorgt dat een reeds eerder vertrouwd netwerk mijn mobiel alsnog kan lamleggen dan doe ik dat misschien wel.
In mijn ogen is dat dus niet een echt werkbare oplossing en ben ik op zoek naar een betere.

[laptopleon]

Het is al maanden gepatched dus waarom zou je een ‘oplossing zoeken’ anders dan updaten van je systeem?

[Raymond Deen]

Pas in 14.7 (nog niet zo heel oud) loopt je mobiel wellicht ook echt niet meer vast; daarvoor dus nog wel en dat is wat ik bedoel.

[xbeam]

Nee in februari all staat in de duidelijk in blog met verwijzing naar Apple en de release note

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[Raymond Deen]

Dan klopt dit artikel niet met jouw bron en ik ging van dit artikel uit.

[xbeam]

Dit artikel verwijst gewoon naar de bron (blog) waar dat vermeld wordt

This 0-click bug was patched on iOS 14.4

met daar onder een screenshot van de release not van iOS 14,4 en bug fix datum februari

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[Raymond Deen]

In het artikel staat ook:

Het lek zat in iOS-versies 14 tot en met 14.4. De onderzoekers zeggen dat de zero-click-mogelijkheid is verholpen in iOS 14.6, maar dat het in die versie nog steeds mogelijk is wifi te laten crashen als een aanvaller een gebruiker kan laten verbinden met een uniek ssid.

De bug is dus nog niet volledig verholpen en in de release notes van 14.7 wordt er niets over gezegd.

[xbeam]

Klopt maar dat is andere bug dan zero click waar dit artikel over gaat.

Wat nog niet gefixt is in 14.7 is de 1 click “string format bug” wat alleen een denial of service aanval mogelijk maakt.
De auto join (zero click) bug wat een rolling Ssid aanval zoal het attikel omschrijft mogelijk maakt. Kan dus sinds februari niet meer.

[Reactie gewijzigd door xbeam op 28 juli 2024 11:00]

[Sietse1990]

Het automatisch verbinden met gekoppelde netwerken kan uiteraard nog prima.

Je moet zorgen dat de "Auto-Join Hotspot" (onderste optie bij je WiFi instellingen) niet op "Automatic" staat. Iets wat bij mij al niet zo staat, dus weet niet of het standaard aan of uit staat. In dit geval zou hij geen problemen moeten hebben tot je zelf klikt op het netwerk.

[Raymond Deen]

Ook je reeds gekoppelde netwerk kan dus dat achtervoegsel aan de naam krijgen waarna je mobiel dus kwetsbaar wordt omdat die niet op naam koppelt, maar op ssid.
Bij mijn nog niet handmatig geconfigureerde iPhone wordt bij een onbekend ap gevraagd of ik ermee wil verbinden dus dat is wel veilig, maar het gaat me dus om dat bovenste…

[monojack]

Maar je moet echt al wel heel onbetrouwbare contacten hebben als je het gevaar loopt dat hun netwerk is aangepast.

[Raymond Deen]

Ik kan me de routers met van hun ssid afleidbare wachtwoord nog goed herinneren en ook zijn er nog regelmatig nieuwsberichten dat er beveiligingsproblemen in routers zijn opgelost. Het kan dus best veel mensen overkomen.

Edit, alsof de duvel ermee speelt: https://tweakers.net/nieu...d-door-kwetsbaarheid.html

[Reactie gewijzigd door Raymond Deen op 28 juli 2024 11:00]

[monojack]

Maar wie gebruikt er eigenlijk nog andermans wifi? Ik denk dat het al 10 jaar geleden moet zijn dat ik nog eens iemand's wifi paswoord nodig had

[Raymond Deen]

Haha we zijn niet allemaal tweaked met ongelimiteerde bundels! 😏

[david-v]

Zie het als een tijdelijke oplossing. De werkbare oplossing (fix) moet iOS leveren in een volgende iteratie als dat lukt.

[Kenhas]

Tja, het kan evengoed zijn dat er momenteel geen betere oplossing is tot er een patch is.

Als je daarmee beschermd bent voor de tijd dat er nog geen patch is, dan maar "automatisch verbinden" uitzetten. Zie niet direct wat er niet werkbaar aan is. Als je geen verbinding hebt met het wifi netwerk, doet je telefoon gewoon verder op mobiele verbinding.
Als je wifi nodig, geef je toestemming om verbinding te maken. Op dat moment ga je dan zelf zien of er een %@ achter staat.

Je kan er natuurlijk van uit gaan dat je die wifi netwerken echt wel vertrouwt. Dat je zeker bent dat mensen geen SSID gaan aanpassen om mensen in problemen te brengen.

Ik kom op een vier à vijf plaatsen per dag met een netwerk waar automatisch verbinding mee wordt gemaakt. Dat automatisch verbinden uitzetten voor alles behalve mijn eigen thuisnetwerk. De rest moet dan maar via mobiel internet

[Tintel]

Voor oudere versies zouden gebruikers het automatisch scannen naar en verbinden met wifi-netwerken uit kunnen schakelen

Automatisch scannen uitzetten is ook niet zo voor de hand liggend....

[Kenhas]

in het artikel staat

Voor oudere versies zouden gebruikers het automatisch scannen naar en verbinden met wifi-netwerken uit kunnen schakelen

Ik veronderstel dus dat het geen zo'n enorme taak zal zijn om het scannen uit te zetten.
Of iOS updaten.

Kan te simpel gedacht zijn. Ik heb geen iphone dus kan het niet eens bekijken

[WhatsappHack]

Nee is idd simpel, gewoon een setting onder het kopje WiFi.

[monojack]

Ik snap het niet goed. Hoe kan een wifi netwerk verbinden met mijn iPhone zonder toestemming?

[R4gnax]

Ik snap het niet goed. Hoe kan een wifi netwerk verbinden met mijn iPhone zonder toestemming?

Andersom; jouw iPhone kan zonder jouw tussenkomst verbinden met openstaande WiFi netwerken in de omgeving, als je nog geen WiFi verbinding actief had. Dat is een systeem-instelling, maar omdat het gros van de Apple-gebruikers a-technisch en gemakzuchtig is, zal die optie om aan hen tegemoet te komen wel standaard aan staan.

[monojack]

Ik weet niet of het standaard aan staat. Ik vermoed idd van wel, kan me herinneren die ooit uitgeschakeld te hebben. Maar ik dacht dat die ondertussen standaard uit zou staan omdat publieke wifi netwerken sowieso niet betrouwbaar zijn

[Reactie gewijzigd door monojack op 28 juli 2024 11:00]

[Velvus]

Apple verwijderde de mogelijkheid om met ssid's te verbinden die de %n-string bevatten, maar Zecops zegt dat dat niet de enige mogelijke kwetsbaarheid is.

Als dit de zogenaamde 'oplossing' is dan kun je wel verwachten dat er nog versie 2.0 en 3.0 van deze exploit komen. Het onderliggende probleem is door Apple niet opgelost.

[Iblies]

Als een aanvaller een telefoon kan laten verbinden met een ssid-netwerk dat daarmee begint kan het, net zoals in het eerdere lek, een bootloop veroorzaken. Het lek kan daarnaast worden uitgebuit zonder tussenkomst van de gebruiker. Daarvoor moet een aanvaller %@ achter een ssid zetten waar een telefoon al mee verbonden is.

De media moet leren dit taalgebruik achterwege te laten.


Er is geen sprake van “aanval” oid.

Apple verkoopt hardware icm software en die doet niet wat die belooft, je een veilige verbinding garanderen.
Als met sullige code het als een kaartenhuis in mekaar stort dan ben je het simpel gezegd genaaid.

Het beeld dat vervolgens geschetst wordt dat er “slechte” mensen bestaan betekent niet dat het probleem ineens verdwijnt als die mensen ineens worden nagejaagd. De software is nog steeds een rommeltje.

En daar waar Apple staat, kan net zo goed Android of Microsoft staan, dat is om het even. Zowel media, bedrijven, politici, burgers moet beter beseffen dat software veredelde gatenkaas is en ophouden met mensen/andere partijen af te doen als negatief/slecht/aanvaller/(terrorist)/etc . Het wordt een glijdende schaal waar stupidity de boventoon gaat voeren waarbij de aandacht verlegd wordt en het daadwerkelijke probleem niet wordt aangepakt.

[GertMenkel]

De reden om dit op te lossen, is om te zorgen dat andere mensen niet je telefoon hacken. Termen als "attacker" en "malicious actor" worden in de industrie gebruikt om aan te duiden dat het gaat om de exploitende, niet de geëxploitte. Dit onder andere omdat er genoeg exploits zijn waar je als eindgebruiker op een knop moet klikken om de boel te laten lukken, dus termen als "uitvoerende" worden snel verwarrend.

Als je zo'n bug gebruikt om je telefoon te jailbreaken of om meer informatie uit je OS te trekken is er geen sprake van een aanval, maar in de praktijk zijn er maar weinig bugs die zo'n impact hebben en waar je zelf wat aan hebt.

Andere mensen hacken is een aanval, een aanval op hun persoonlijke informatie, een aanval op de beschikbaarheid van hun apparaat, een aanval op hun levenssfeer. De terminologie lijkt mij perfect voor het probleem dat ontstaat met een kwetsbaarheid in de code. Als je met andermans apparaten klooit, ben je negen van de tien keer een hacker en een crimineel, alhoewel de pakkans door de politie nihil is. Daar zit geen marketing achter.

Let wel dat de beveiligingsonderzoeker niet per se de aanvaller is. De aanvaller is iemand die een beveiligingslek uitbuit, iemand die een lek vindt en netjes rapporteert (of het geheim meeneemt naar haar graf) wordt niet met de term bedoeld (buiten demonstraties dan, om verwarring te voorkomen). Daarom worden dit soort dingen altijd beschreven als "een aanvaller kan/moet/zou...", niet "de aanvaller doet". Er wordt een theoretisch scenario geschetst waarin je telefoon door een hacker wordt aangevallen, het is geen samenvatting van wat er in de praktijk met je telefoon gebeurt.

[laptopleon]

Zowel media, bedrijven, politici, burgers moet beter beseffen dat software veredelde gatenkaas is en ophouden met mensen/andere partijen af te doen als negatief/slecht/aanvaller/(terrorist)/etc . Het wordt een glijdende schaal waar stupidity de boventoon gaat voeren waarbij de aandacht verlegd wordt en het daadwerkelijke probleem niet wordt aangepakt.

Hoe moet dit dan wel omschreven worden in de media? Ik ben het helemaal met je eens dat er van alles overdreven wordt, maar juist daarom maakt het op lange termijn dus weinig uit welk woord men gebruikt voor een fout.

Vroeger was mijn vader boer. Later werd hij ‘landbouwer’ genoemd. Toen agrariër. Al die mooipraterij helpt maar heel even. Zodra je het drie keer gehoord hebt, een agrariër gewoon weer een boer.

Sowieso kan de media niets aan de software veranderen, maar wel helpen de druk te verhogen op de versntwoordelijken die er wél over gaan.

[Reactie gewijzigd door laptopleon op 28 juli 2024 11:00]

[pietje63]

Wat is er dan mis met iemand die doorbewust een telefoon laat crashen of er ongevraagd code op uitvoert een aanvaller te noemen? Dat is toch de gebruikelijke terminologie? Dat de software (naar jouw mening) als een kaartenhuis in mekaar stort staat toch los van de term aanvaller?

[Tintel]

Beide zaken bestaan toch los van elkaar? Dat software matig is kun je ook lezen als: de software is op zich niet slecht maar niet helemaal af of het betreft mogelijkheden waar nog geen rekening mee gehouden is. Foutloze software is al moeilijk te maken - software die met alles mogelijke storingen en scenario's rekening houdt, is nog moeilijker.

Let wel dat software steeds meer een paradox op zichzelf is: connectivity overal en altijd tegenover altijd veilig. Oftewel: De deur staat altijd open maar niet voor mensen met nare bedoelingen...

Vervolgens stel je dat iedereen slecht kan zijn (of worden). Slecht is een relatief begrip. Dat het voor de 1 niet slecht is en de ander wel komt doordat sprake is van strijdige belangen. Vanuit de ogen van de aanvaller is het niet slecht. Maar in dit geval kun je wel degelijk stellen dat de term correct is vanuit de ogen van de eigenaar van een iPhone.

Waarom is het verloren energie om een aanvaller te willen uitschakelen? Ook al was de beveiliging/software slecht, dan nog is het niet onverstandig dit te doen. Dat het beter is om ook de software/beveiliging te verbeteren is wel duidelijk.

[Iblies]

https://watson.brown.edu/...war-afghanistan-2001-2021

Since invading Afghanistan in 2001, the United States has spent $2.26 trillion on the war, which includes operations in both Afghanistan and Pakistan. Note that this total does not include funds that the United States government is obligated to spend on lifetime care for American veterans of this war, nor does it include future interest payments on money borrowed to fund the war.
….
The figures for Afghanistan are part of the larger costs of the U.S. post-9/11 wars, which extend to Iraq, Syria, Yemen, Somalia and elsewhere. The numbers are approximations based on the reporting of several data sources.

Microsoft/Apple/Google zijn commerciële bedrijven die een product verkopen. Op het moment dat dat product faalt in welk opzicht ook,
dan zijn zij het eerste aanspreekpunt.

Op het moment dat overheden met de vingers gaan wijzen dat landen “eng” zijn zoals Rusland, China, Iran, etc met de mededeling dat ze “westerse” landen aanvallen, is het een kwestie van tijd voordat er een omgeving wordt gecreeerd waarbij vergelding legitiem lijkt te zijn met alle gevolgen van dien.

De focus kan beter worden verlegt naar de bedrijven.
Less is more,
zo heeft China een aangepaste windows waarbij er geen data naar microsoft-servers wordt verstuurd. Verkeer van en naar je ict wordt dan makkelijker controleren, bijbehorende zwakkere punten kunnen sneller worden opgemerkt.

[GertMenkel]

Huh? Ik ben het niet met je eens dat we vromer dan de paus doen op het gebied van cyberoorlog, maar in dit artikel wordt helemaal niks gezegd over wie door wie wordt aangevallen. De FUD haal je er nu zelf bij.

Offtopic, maar: wij vallen Rusland, Iran, Noord-Korea, en China aan, en in ruil daarvoor vallen Rusland, Iran, Noord-Korea, China, Amerika en Engeland ons aan. Er worden daadwerkelijk cyberaanvallen gepleegd door overheden, alleen zullen weinig overheden toegeven dat ze een andere overheid hebben aangevallen aangezien dat een aanleiding kan zijn tot internationale oproer of zelfs fysieke, dodelijke oorlog. Soms zijn wij in het westen de aanvaller, soms zijn we het slachtoffer, dat is nu eenmaal de realiteit. We willen natuurlijk liever dat onze infrastructuur het blijft doen, dus als een Brit in het communicatienetwerk van Belgacom zit, is dat de aanvaller. Als een Chinees of Rus dat doet, is dat niet anders.

Dat we minder aanvallen rapporteren vanuit de Amerikanen en andere bondgenoten is omdat die minder reden hebben om ons aan te vallen, en ook andere soorten aanvallen doen. De kans dat wij een Stuxnet tegen ons krijgen gegooid, is kleiner dan de kans dat we een WannaCry tegen ons gebruikt zien worden. Als wij of onze bondgenoten in Nederland opereren, is dat meestal om bewijs tegen iemand te krijgen (politie of AIVD, met toestemming) of om te spioneren op anderen (Belgacom en KPN zijn grote spelers op de netwerkmarkt, en bepaalde andere landen zouden maar wat graag verkeer naar Iran af willen tappen).

[Tintel]

dan zijn zij het eerste aanspreekpunt.

Dat is toch ook zo?

kwestie van tijd voordat er een omgeving wordt gecreeerd waarbij vergelding legitiem lijkt

Dat landen onderlingen rommelen is niet nieuw en vergelding treedt pas in werking als het verlies te groot dreigt te worden. Het naar elkaar wijzen en elkaar bespioneren is een spel dat al zo lang gespeeld wordt als er grenzen zijn.

En dan raak je me kwijt... focus verleggen naar bedrijven? Dus landen mogen het 'spel' niet meer spelen?

Less is more

Jij denkt toch niet echt dat het niet doorsturen van data vanuit het Windows-OS, bedoeld is om beter zwakkere punten te vinden?
China houdt alle informatie graag binnen z'n eigen grenzen.
En als ze dat niet zouden doen? Bij het zoeken kun je filteren...