Onderzoekers slagen erin iMessage-bijlagen te ontsleutelen

Een hoogleraar van de Amerikaanse Johns Hopkins-universiteit heeft samen met studenten een lek in iOS ontdekt, waarmee versleutelde iMessage-bijlagen ontsleuteld kunnen worden. Apple komt met een patch in iOS 9.3.

The Washington Post meldt dat hoogleraar Matthew Green een vermoeden had dat Apples chatapp iMessage onveilig was, nadat hij een beveiligingshandleiding van Apple had gelezen over het encryptieproces van de software. Toen antwoord van Apple op zijn melding uitbleef, lukte het hem met een aantal studenten in enkele maanden om de encryptie te doorbreken. Daarvoor maakten de onderzoekers gebruik van zelfgeschreven software, waarmee zij een Apple-server nabootsten. In het onderzoek werden iPhones gebruikt die niet de laatste versie van iOS draaiden.

Het onderzoeksteam probeerde toegang te krijgen tot een versleutelde link naar een foto op een iCloud-server, die samen met de 64bit-sleutel om de foto de ontsleutelen werd verstuurd naar de server. Het team kon de inhoud van de sleutel niet inzien, maar wist deze te raden door steeds opnieuw een cijfer of een letter te veranderen en deze naar de iPhone terug te sturen. Doordat de telefoon de juiste cijfers of letters accepteerde, wist het team wanneer het een juiste gok had gemaakt. Door dit proces duizenden keren te herhalen kon het uiteindelijk de sleutel achterhalen.

Green vertelt dat de aanval met een aantal wijzigingen ook op nieuwere iOS-versies had gewerkt, maar dat daarvoor middelen nodig zouden zijn die alleen een staatsmacht kan inzetten. Met een succesvolle aanval was het mogelijk om de foto of video van de iCloud-server te downloaden, zonder dat de gebruiker dit in de gaten zou hebben.

Hij voegt daaraan toe dat de ontdekte aanval waarschijnlijk niet door de FBI ingezet kan worden om de gegevens uit te lezen van de iPhone van een van de daders van de aanslag in San Bernardino in december. De precieze beschrijving van de aanval wordt door het team van Green gepubliceerd op het moment dat Apple samen met iOS 9.3 een patch voor de kwetsbaarheid uitbrengt. Deze update wordt maandag verwacht. Volgens Apple was een gedeeltelijke patch al beschikbaar toen iOS 9 werd uitgebracht. Het bedrijf raadt gebruikers aan om de update naar 9.3 uit te voeren op het moment deze beschikbaar komt.

Green stelt dat 'het hem bang maakt dat het Apple met al zijn middelen niet is gelukt om op de juiste manier eenvoudige encryptie toe te passen, vooral op het moment dat er een debat over backdoors aan de gang is'.

Reacties (136)

[bArAbAtsbB]

brute force hack....tja als je oneindig wachtwoorden mag proberen.....dan is brute force toch altijd mogelijk?

[Maurits van Baerle]

Voorzover ik het begrijp heeft dit niets met wachtwoorden te maken. Wachtwoorden brute forcen is dan ook makkelijk te voorkomen met een time-out en/of limiet.

[PdeBie]

Inderdaad. Gewoon een limiet van x keer.
Overschrijd je de limiet, wis je alle data van het toestel.

[Bor]

Overschrijd je de limiet, wis je alle data van het toestel.

Daarmee creëer je je eigen denial of service aanval of kwetsbaarheid. Je hoeft op die manier alleen nog maar expres (in dit geval zelfs remote!) te vaak verkeerde data aan te leveren en het toestel wist zichzelf. Dat is echt geen goed doordachte oplossing.

De oplossing voor een security vulnerability mag nooit de introductie van een andere betekenen in termen van de basis CIA (Confidentiality Integrity Availability).

[Reactie gewijzigd door Bor op 25 juli 2024 19:35]

[PdeBie]

Voor het kraken van een iMessage encryptie wel ja. Ik doelde meer op het inloggen bijvoorbeeld.

Maar ook daarvoor zijn weer betere opties zoals worldcitizen bijvoorbeeld aangeeft: Verwijderd in 'nieuws: Onderzoekers slagen erin iMessage-berichten te ontsleutelen'

[monojack]

Onzin! Dit bericht gaat over iMessage niet over het lockscreen. Je kan het lock screen dan ook niet remote invoeren. Enkel wanneer iemand je telefoon fysiek in handen heeft kan deze het toestel wipen en dat is ook net de bedoeling.

Geef je achteraf het juiste paswoord in wordt alles terug van iCloud op de iPhone gezet in amper een paar minuten tijd.

Het is dus alzeker geen denial of sevice aanval maar een heuse deftig werkende beveiliging.

[mashell]

Enkel wanneer iemand je telefoon fysiek in handen heeft kan deze het toestel wipen en dat is ook net de bedoeling.

Wat is wipen? Want als je naar 3x foute pin een toestel krigt dat naar de fabrieksinstellingen terug gaat dan zegt de dief "dank je wel" dat maakt doorverkopen een heel stuk gemakkelijker.

[Sh4d0wDr4g0n2]

Hij gaat wel terug naar de fabrieksinstellingen maar als je hem wilt gebruiken moet je nog altijd het apple id van de vorige gebruiker opgeven. Heb je dat niet dan heb je gewoon een mooie baksteen vast.

[jeroen7s]

doet me denken aan dit: even iCloud gebruikt als ransomware (als je het iCloud wachtwoord hebt)
https://blog.malwarebytes...be-worse-than-ransomware/

[Verwijderd]

Inderdaad. Gewoon een limiet van x keer.
Overschrijd je de limiet, wis je alle data van het toestel.

Ik ben helemaal niet gecharmeerd van deze beveiliging.
Je kind gaat met je iPhone aan de haal, resultaat, data weg.

Geef mij maar een exponentieel oplopende tijd, dan ben je de data tenminste niet kwijt.

Als er mensen nu zeggen ik heb het toch op de cloud. Dan vraag ik hoe veilig is dat, en als je denkt dat het veilig is, hoe controleer je dat?

[SidewalkSuper]

Vanaf binnenkort is het blijkbaar heel veilig, als we dit nieuwsbericht mogen geloven.

This way, even Apple cannot gain access to your encrypted data, no matter how much it may want to and no matter how many government subpoenas it receives. It can’t honor court orders to provide the data because the company has no way to decrypt it.

Apple to Hand iCloud Encryption Key Management to Account Holders

[monojack]

Dan moet je kind wel heel lang beschikken over je iPhone, Het duurt steeds langer voor je een nieuwe poging kunt wagen na een foute. De tiende keer duurt het zelfs 24uur voor je een nieuwe poging kan ingeven.

En data weg? Je data zit nog steeds in de iCloud dus als je het juiste paswoord ingeeft staat alle data er binnen een paar minuten terug op.

[supersnathan94]

De wis iphone na 10 pogingen moet je expliciet zelf aanzetten. En ook dan zitten er nig een aantal lockdowns tussen.

[Kaastosti]

Voor het inloggen is dat een optie. Voor een check of een sleutel voor een bestand geldig is lijkt me dat niet wenselijk... dikke pret als ik iets weet te onderscheppen en zo door simpelweg drie keer "WOEI" aan te vragen jouw telefoon kan wissen.

Dat kennelijk uit te lezen valt welke cijfers/letters geaccepteerd worden maakt het systeem wel een stuk zwakker. Dan heb je met een paar duizend pogingen inderdaad de correcte sleutel wel te pakken.

Als je echter _niet_ weet of een karakter juist is, moet je alsnog alle mogelijke combinaties proberen. Dat duurt vele malen langer en is dus niet heel bruikbaar.

[bArAbAtsbB]

nee want een sleutel om toegang te krijgen kan je echt geen wachtwoord noemen!? ;-)

[Maurits van Baerle]

Het zijn inderdaad twee totaal verschillende zaken. Een wachtwoord is om toegang tot een systeem te verkrijgen terwijl de sleutel is om het transport te encrypten. Zelfs met de hele sleutel heb je nog geen toegang, je kunt alleen het onderschepte verkeer voor dat bestand decrypten. Kennelijk reageert de client anders op verschillende fouten in de sleutel en is zo langzaam aan een beeld te vormen van wat er fout en wat er goed is. Net zo lang tot je de hele sleutel hebt.

Overigens zul je met die sleutel nog geen toegang hebben tot het systeem, je moet het verkeer onderweg onderscheppen. De vraag is dus ook of dit realistisch kan werken met bestanden waarvan je niet weet of ze op de server staan. Je zult toch eerst een verzoek voor dat bestand moeten genereren.

[Reactie gewijzigd door Maurits van Baerle op 25 juli 2024 19:35]

[nst6ldr]

Niet helemaal. Het verschil ligt meer bij de implementatie en use case. Een wachtwoord is over het algemeen iets ter authenticatie, en verbasterd tot de input die een gebruiker geeft om iets vrij te geven (een soort van interface tussen computer en mens). Bij versleuteling is de tekst om iets terug te coderen naar leesbare tekst een sleutel. Hiermee pas je niet per sé authenticatie toe.

[Olaf van der Spek]

Klopt..

[N8w8]

Een andere veel gebruikte manier om bruteforce tegen te werken, is "key stretching" zoals PBKDF2/bcrypt/scrypt.
Dan wordt je wachtwoord met een hoop rekenwerk in een langere, moeilijker te bruteforcen sleutel veranderd.
Elk wachtwoord dat je wilt uitproberen, kost dan (bijvoorbeeld) 1 seconde CPU tijd ipv 1 nanoseconde (en in het geval van scrypt ook een hele hoop RAM), waardoor bruteforcen niet haalbaar is.

Het voordeel daarvan is dat je geen last hebt van omzeilingen van zo'n timeout/probeerlimiet. Want dat is alleen maar wat software, terwijl in het RAM een deel van de geheimen te vinden zijn, waar je met eoa debugger/hack mss bij kan.
Het nadeel is dat elke wachtwoord controle dus (een instelbare) tijd en RAM kost.

edit: maar je kan dat het beste combineren met timeouts/limieten natuurlijk, want de gemiddelde pincode van 4 cijfers (waarvan de eerste twee vaak "19" zijn) heb je dan alsnog in een paar minuten/uur.

[Reactie gewijzigd door N8w8 op 25 juli 2024 19:35]

[monojack]

De laatste iPhones (6 en 6S) zijn zo beveiligd dat je maar 10 kansen hebt en dat na elke verkeerde poging er een tijdsblok bij komt. Bij de 10e poging duurt het zo'n 24 uur voor je het paswoord mag raden.

Je hebt voor een iPhone met 4 cijfers dus 10 pogingen en meer dan een dag nodig om te weten of je tiende gok de iPhone zal openen of voorgoed zal wissen.

Jouw methode zal dus enkel werken bij een iPhone van iemand die je kent of waar je de leeftijd van kan schatten en dan enkel bij een paswoord waarvan de iPhone de gebruiker reeds gewaarschuwd zou hebben dat het geen veilig paswoord is want dat zegt de telefoon bij elk code die begint met 19

[Reactie gewijzigd door monojack op 25 juli 2024 19:35]

[SED]

Begrijp ik hieruit dat je apparaat een volledige dag onbruikbaar wordt in dat geval?
Niet echt goed doordacht die "beveiliging" dan.

[BUR]

Krijgt de gebruiker dan ook een melding via email of sms(naar een ander nummer) dat er foutief is ingelogd op je account? Dat zou wel handig zijn!

[DeerDitch]

Wachtwoorden brute forcen is dan ook makkelijk te voorkomen met een time-out en/of limiet.

Als iedereen een wachtwoord van minimaal 10 random karakters neemt hoeft zo'n time-out en/of limiet helemaal niet toegepast te worden! Succes met het brute-forcen van zo'n ww.

[Buskru1jt]

Daarom is het dus belangrijk om als programmeur het aantal pogingen te limiteren!

[FireDrunk]

Ja, maar niet alleen dat, je moet het (praktisch) onmogelijk maken om te kraken door het te moeilijk te maken om het te ontcijferen. Dus: Sterke encryptie en/of goede hashing algoritmen gebruiken.

Limiteren van aantal invoerpogingen is "Security by Obscurity". (Het helpt wel, maar is niet feilloos).

[Reactie gewijzigd door FireDrunk op 25 juli 2024 19:35]

[.oisyn]

Dit is quatsch, het heeft niets met obscurity te maken, maar met het verhinderen van een mogelijkheid tot brute forcing. Dit idee is ook gewoon verwerkt in bepaalde hashing algoritmes zoals PBKDF2, door het toepassen van meerdere iteraties van een hash functie het hashen zelf tijdrovend te maken, om zo de effectiviteit van een brute force aanval te verkleinen.

Je kan nog zo goed je encryptie implementeren, uiteindelijk heb je toch een bepaalde keyphrase nodig, meestal gekozen door de gebruiker. Je encryptie staat of valt dan ook bij de sterkte van dit wachtwoord. Beter voorkom je dat het gemakkelijk is dat alle wachtwoorden simpelweg geprobeerd worden.

Waarom denk je dat je met je banpas wegkomt met slechts 4 cijfers?

[Reactie gewijzigd door .oisyn op 25 juli 2024 19:35]

[FireDrunk]

Ik begrijp wat je bedoelt, maar wat jij zegt haalt mijn commentaar niet onderuit.
Wat ik bedoel is: Het limiteren van het aantal pogingen an sich is geen goede security. De limitatie zelf zorgt niet voor de encryptie, het zorgt alleen maar voor vertraging bij het kraken, maar maakt het niet technisch onmogelijk. Ik reageerde vooral op Buskru1jt omdat het nu lijkt alsof dat de enige oplossing is. En dat lijkt mij fundamenteel onjuist.

Uiteraard is limiteren an sich een prima praktijk. Ik zal mijn comment iets nuanceren.

[monojack]

Misschien toch nog even nuanceren dat het aantal pogingen limiteren an sich wel juist goede beveiliging is. Zoals Oisin opmerkt is de gebruiker de zwakke schakel in de beveiliging en als de gebruiker niet zo dom is om zijn paswoord op de telefoon te schrijven of geboortejaar te gebruiken dan is zo'n limitering de perfecte beveiliging want het beschermt de telefoon tegen een zwak paswoord (4 digits)

[bozotheclown]

Wat klopt en in deze dus niet van toepassing is. Het gaat hier om onderschepte versleutelde data.

[Rafe]

Het team kon de inhoud van de (64bit) sleutel niet inzien, waar wist deze te raden door steeds opnieuw een cijfer of een letter te veranderen en deze naar de iPhone terug te sturen.

Gezien de snelheid ('slechts' duizenden pogingen) waarmee ze het voor elkaar kregen moet het iets anders dan een brute-force attack (gemiddeld 2³² pogingen) zijn. Deze beschrijving doet het me denken aan een padding oracle attack maar ik kan het mis hebben.

Op Twitter zag ik de opmerking dat Apple nog AES-CBC gebruikt voor iMessage en geen authenticated encryption-modus zoals AES-GCM. Het toestel had dan kunnen controleren of het bericht wel echt van Apple kwam, en zo niet daarmee geen enkele vorm van informatie vrij te geven (lekken) die gebruikt kan worden om aanzienlijk sneller de key te ontfutselen.

De details komen rond een uur of half 8 vanavond beschikbaar nadat Apple de patch heeft vrijgegeven, aldus een van de onderzoekers. Ik ben erg benieuwd

[Reactie gewijzigd door Rafe op 25 juli 2024 19:35]

[supersnathan94]

Zo jammer is dat. Ik had liever gezien dat ze nog een dag of twee zouden wachten. Het vrijgeven van een patch is natuurlijk een stap dichter bij het verhelpen van het probleem, maar het daadwerkelijk oplossen vereist wel dat al die miljoenen apparaten de patches ook geïnstalleerd hebben.

[monojack]

Het heeft de onderzoekers maanden gekost en iOS gebruikers zijn snelle updaters dus in deze zie ik het probleem niet zo.

[supersnathan94]

Het heeft ze maanden gekost om het te ontdekken. De uitwerking kan nu echter een stuk sneller omdat alles gedocumenteerd is. Ja iOS eigenaren zijn snel, maar ik ga niet direct updaten. Daarvoor heeft Apple te weinig capaciteit en ik kijk eerst naar de reacties of het allemaal goed werkt. Dus bij mij duurt het een weekje voor het zo ver is.

[Rafe]

De details zijn inmiddels bekend. Het is een ingewikkelde aanval die lijkt op de gelinkte padding oracle-aanval, maar ipv padding wordt gzip gebruikt om byte voor byte de key te achterhalen. Momenteel duurt het 70 uur om deze uit te voeren, maar ze geloven dat het kan worden geoptimaliseerd naar een fractie van een dag. En hoewel Apple een workaround heeft ingebouwd om de aanval te stoppen, raden ze aan het protocol te herzien.

[Anonymoussaurus]

Tenzij de beveiliging zo goed is dat je zelfs met vele servers jaaaaren bezig bent .

[bbob]

Ik lees juist niet dat het een brute force is.

[quote]
Doordat de telefoon de juiste cijfers of letters accepteerde, wist het team wanneer het een juiste gok had gemaakt. Door dit proces duizenden keren te herhalen kon het uiteindelijk de sleutel achterhalen.
[\quote]

Er staat duizenden keren, by brute force denk ik eerder aan miljarden of meer.
als ik het goed lees stuurt men tekens naar de iphone die dan zegt of dat teken wel of niet in de sleutel zit. Op die manier kun je veel tekens wegstrepen en blijven er een aantal over waarmee je sneller resultaat hebt. i.p.v alle combinaties te proberen hoef je er nu maar een fractie te doen.

Daarnaast staat er dat deze patch het probleem niet oplost, alleen zijn er meer middelen nodig om in het vervolg hetzelfde trucje te doen. De publicatie zal dus een geschenk voor overheden zijn die vanuit de publicatie kunnen verder werken met middelen die wel tot hun beschikking staan.

[Maurits van Baerle]

Daarnaast staat er dat deze patch het probleem niet oplost, alleen zijn er meer middelen nodig om in het vervolg hetzelfde trucje te doen.

Als ik het goed begrijp slaat dat op de vorige patch.

Het probleem in dit artikel slaat op oudere iOS versies. Dat was al eerder door Apple gepatched aangezien het in huidige versies aanzienlijk meer moeite kost. Binnenkort (vanavond?) komt er weer een patch uit en die lost het probleem mogelijk definitief op.

[Anonymoussaurus]

Er staat duizenden keren, by brute force denk ik eerder aan miljarden of meer.
als ik het goed lees stuurt men tekens naar de iphone die dan zegt of dat teken wel of niet in de sleutel zit. Op die manier kun je veel tekens wegstrepen en blijven er een aantal over waarmee je sneller resultaat hebt. i.p.v alle combinaties te proberen hoef je er nu maar een fractie te doen.

Hoezo per se miljarden keren? Ligt er ook natuurlijk aan wat voor een apparaat. Een router met WPA beveiliging is bijvoorbeeld veel sneller/makkelijker te kraken dan zo'n iPhone (andere én betere encryptie). Brute force kan namelijk ook maximaal 200 pogingen zijn. Hangt allemaal af van de encryptie en hoeveel bits.

[Armin]

Ik lees juist niet dat het een brute force is.

Het is dus wel brute force. Het was wachten op de officiele release van iOS 9.3 zodat de onderzoekers hun bevindingen ook konden publiceren. Dat was pas enkele uren nadat Tweakers dit artikel schreef.

Het gaat als volgt:

Setup:
- Het slachtoffer stuurt een bericht met een attachement. De aanval werkt niet op iMessages met enkel text. iMessages met een attachment bevatten namelijk een URL naar het attachment op Apple's iCloud servers. Deze is versleuteld, maar ook de key wordt meegezonden.
- De aanvaller registreerd een domein dat lijkt op icloud.com. Hoe dichter in de buurt hoe beter.
- De aanvaller onderschept het iMessage bericht van het slachtoffer.

Brute force - fase 1:
- Je stript de ECDSA hash. Dat is de eerste kwetsbaarheid: Apple gebruikt een ECDSA hash ipv een echte HMAC.
- Je manipuleert een paar bits in de AES payload. Je kunt die niet decrypten, maar wel wijzigen.
- Je maakt een nieuwe ECDSA passende bij jouw gemodificeerde payload. Dit was niet mogelijk geweest bij een échte HMAC zoals in TLS/HTTPS.
- Je stuurt dit naar de oorspronkelijke ontvanger van het bericht, welke het zal decoderen. Je probeert net zo lang totdat de ontvanger een request maakt naar jouw server. In het voorbeeld van Green gebruikt hij i8loud.com. Hoe dichter in de buurt, hoe eerder het lukt om jouw valide domein naam te krijgen.
- Nadat de ontvanger request maakt naar jouw server, kun je zien wat de request URL is. Dus elke keer als een bit wijzigt, kun jij het resultaat zien op jouw eigen domein als binnenkomende request.

Brute force - fase 2:
- Je weet nu welke bit wijziging correspondeerd met welke plain-text. Ga nu met snellere brute force aan de gang om bit voor bit te decrypten van het oorspronkelijke bericht. Immers je hebt al de URL, nu de key nog.
- Zodra je de volledige key hebt, ga je zelf naar die URL en download het attachment.

Apple's tegenzetten:
- sinds iOS 9.0 weigert Apple te praten met andere servers dan hun eigen. De brute force blijft echter mogelijk, want dit maakt het enkel moeilijker om jouw public keys te krijgen. Green en zijn studenten onderscheppen de provider APN, maar dat is niet iets wat een simpele aanvaller kan doen. Dus geen simpele WiFi hotspot onderschepping.
- sinds iOS 9.3 (vandaag dus) weigert Apple herhaalde iMessages. Dus de brute force is niet langer mogelijk waardoor de aanval volledig beblokkeerd is.

[BonzO]

De hele leak van de foto's van celebs was ook gewoon een brute force hack (in de API kon je gewoon oneindig een login retry'en). Het probleem is dan ook dat het überhaupt mogelijk is om te brute forcen en dat er geen limiet op zit.

[Blokker_1999]

Die leak was geen brute force attack maar simpelweg social engineering.

[supersnathan94]

Combinatie van de twee. Door social engineering werd het aantal pogingen echter enorm beperkt. Alle data van FB, instagram, twitter en weet ik het allemaal is gemined en in een soort rainbow table verwerkt. Hierdoor zijn enkele honderden tot duizenden opties mogwlijk en niet 25 miljoen miljard. De tijd die het kost wordt hiermee aanzienlijk verkleind.

[monojack]

Huh? Zoals jij het doet uitschijnen was het een gesofisticeerde aanval terwijl het gewoon een kerel was die beroemdheden naar een fake google of Apple site leidde en zo toegang kreeg tot de paswoorden van gmail en iCloud en uit die gegevens daar verder aan de slag ging.

Er kwam dus zelfs geen social engineering aan te pas. Het was gewoon phishing.

Ryan Collins: 5 Fast Facts You Need to Know

[supersnathan94]

Het schijnt inderdaad niet te gaan om de brute force methode daar deze daarvoor al was gepatched, maar wel degelijk social engineering:

After more than 40 hours of investigation, we have discovered that certain celebrity accounts were compromised by a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the Internet. None of the cases we have investigated has resulted from any breach in any of Apple’s systems including iCloud® or Find my iPhone.

- Apple press statement http://www.theverge.com/2...celebrity-nude-photo-hack

[monojack]

Dat was geen brute force. Het was phishing. Die kerel (Ryan Collins) stuurde gewoon nep mails naar beroemdheden om hun paswoord in te voeren bij een fake site van iCloud en Google. Zo kreeg hij de paswoorden in handen en kon hij gewoon bij alle data van die beroemdheden.

Die kerel staat daar nu dus ook voor terecht. Best bizar dat dat incident bekend staat als de iCloud hack vermits er veel meer Gmail accounts gehackt waren dan iCloud accounts.

[Aikon]

Dit is geen echte brute force aanval. Bij een echte brute force moet je alle mogelijkheden van het gehele wachtwoord proberen tot je de goede hebt. Nu hoef je slechts per karakter alle mogelijkheden uit te proberen, na slechts duizenden keren waren alle mogelijkheden getest. Normaliter heb je over meervouden van miljarden mogelijkheden.

Overigens wordt hier gezegd dat een limiet een brute force aanval kansloos maakt. Dit hoeft zeker niet altijd, als je bijvoorbeeld de hash in je bezit kan krijgen, kan je deze op eigen systemen brute-forcen. Hierna heb je slechts één inlogpoging nodig in het te kraken systeem.

[Verwijderd]

Encryptie kraken is altijd een soort van brute-force. Het verschil zit hem in de zwaktes te gebruiken om je brute-force tijd te verkleinen. Een iphone die de server verteld dat bepaalde karakters goed zijn is een gigantische zwakte.

[winwiz]

@ de meesten hierboven.

Essencieel in het verhaal is dat er een oude iOS versie werd gebruikt. Bij een up to date versie:

Green vertelt dat de aanval met een aantal wijzigingen ook op nieuwere iOS-versies had gewerkt, maar dat daarvoor middelen nodig zouden zijn die alleen een staatsmacht kan inzetten.

Dus om nou te zeggen dat de beveiliging brak is van Apple

[Dahwe]

Helaas hebben redelijk wat mensen met oudere (8GB) iphones geen goede updatemogelijkheid door chronisch ruimtegebrek. Nu gaat het dan misschien niet om het meest kritieke lek, maar een volgend lek kan dat wel zijn.

Zelfs met '16GB' kan het al snel krap worden waardoor mensen eenvoudigweg niet meer updaten. (Klaar met zoektocht naar MB's). Misschien bij een major iOS upgrade..

[winwiz]

Sinds iOS 9 is dat probleem er ook niet meer. Er wordt tijdelijk ruimte vrijgemaakt...

http://www.icreatemagazin...apps-weg-voor-ios-update/

[me_mrtn]

Dat is al een tijdje geen probleem meer. Apps worden tijdelijk verwijderd voor het updaten van iOS, en worden daarna weer automatisch gedownload en geïnstalleerd, zonder verlies aan data.

[Verwijderd]

De beveiliging is brak. Dat is wederom aangetoond. De huidige versie van iOS is zelf ook een update van de versie ervoor en toch niet veilig. Wie zegt dat de volgende update die uitkomt wel veilig is?
Het mag toch wel duidelijk zijn dat ook Apple niet de heilige graal op veiligheidsgebied is. Roepen dat het bij anderen slechter is (zoals velen hier doen) maakt het niet opeens wel veilig.
Het is simpelweg allemaal onveilig.

[kimborntobewild]

Dus om nou te zeggen dat de beveiliging brak is van Apple

Ja.
Criminelen kunnen nl. 'gewoon' een miljoen gebotnette PC's 'aanschaffen'; om die het rekenwerk te laten doen. Net zoals een staat het doet met een miljoen CPU's in een rack.

[dutchgio]

En toch zit de patch pas in het nog uit te brengen 9.3 waarvan geadviseerd wordt om deze zo snel mogelijk te installeren, helemaal dicht is het dus niet.

[DR!5EQ]

Dit bericht is compleet uit zijn verband gerukt. Het gaat namelijk helemaal niet om berichten, het gaat om bestanden die middels iMessage verstuurd worden. Tenzij iemand mij anders kan vertellen?

Daarnaast is Matthew Green een van de meeste interessante personen die je kunt volgen op Twitter. Ook dan had je kunnen weten dat het Green absoluut niet om Apple gaat, maar om het toepassen van encryptie in het algemeen. Zo laat hij ook in zijn tweets weten:

https://twitter.com/matth...status/709919253097484288
https://twitter.com/matth...status/709919895002042368

Beetje slordig Tweakers...

[Rafe]

Je hebt gelijk dat de bron alleen foto en video noemt, maar het lijkt breder te zijn dan tot nu toe over is bericht:

The attack is more interesting than just attachments and affected more than just iMessage. Apple had to fix other apps, but won't say what.

Vanavond komen de details.

[DR!5EQ]

Ah Thanks! Zat ik er dus toch naast.

[smartbit]

Tijd voor andere chat, video, conference software alhoewel de integratie & kwaliteit van iMessage & FaceTime (Audio) onovertroffen is. Ik ga de komende tijd Wire.com proberen. Anders dan bij Signal kan ik zelf kiezen of ik de App toegang verleen tot mijn adresboek. Zie deze tabel voor een snelle vergelijking en hier een uitgebreide discussie over Wire.com.

[FreshMaker]

Ja, vooral paniekvoetbal spelen.
En dan op een 'systeem' overstappen waar je bij de "early adopters" gaat behoren, oftewel proefkonijnen.

[ultimasnake]

Ik vraag me dan nu ook sterk af wat de haalbaarheid is naast dat er niet genoemd wordt hoeveel werk het is om nu de software er is om een nieuwe telefoon te 'hacken' want je moet verkeersgegevens omleiden, je moet de iphone naar mijn idee fysiek in je bezit hebben voor in/output, de iphone communiceert met 'nep-servers' waardoor je berichten niet aankomen die je pushed wat snel zal opvallen en je moet een oud IOS er op hebben staan.

De haalbaarheid op een directe target/misbruik lijkt me erg laag, maar alsnog erg knap van de studenten en de ontdekker

[supersnathan94]

De communicatie onderscheppen is niet zo moeilijk. Zet in een random café een hotspot op met een snelle uitgaande verbinding en er zijn genoeg mensen die er op gaan zitten internetten. Communicatie omleiden via een interne DNS en je bent klaar wat dat betreft. De rest is inderdaad een stuk minder eenvoudig.

[Robbemans]

Dit is nou echt tweakers/hackers nieuws. Maanden ploeteren en pielen om een bericht te ontcijferen. Bijna op bitniveau een reverse-engineering stap maken.

Helaas voor Apple dat hier uit naar voren komt dat de beveiliging brak is. Daar is dan we een patch voor. Misschien is dit dan toch WEL de backdoor waar de FBI op hoopt, al geeft de hoogleraar aan dat deze methode waarschijnlijk niet werkt.

[Verwijderd]

Dit is nou echt tweakers/hackers nieuws. Maanden ploeteren en pielen om een bericht te ontcijferen.

Helaas voor Apple dat hier uit naar voren komt dat de beveiliging brak is

Je spreekt jezelf nogal tegen. Als er maanden voor nodig is geweest om überhaupt een fout te kunnen vinden, dan kun je moeilijk zeggen dat de beveiliging brak is

Immers alles valt te kraken met genoeg tijd en middelen.

[Robbemans]

Was niet duidelijk genoeg. Ik doelde op het feit dat ze zelf een patch hebben uitgebracht om het gat te dichten en dat ze dat dus wel moesten patchen. Met een select gezelschap ontsleutelen - hetgeen dan een paar maanden kost - dat spreek de rest toch niet tegen? Geeft alleen aan dat als dit groepje het lukt, het anderen ook zou (kunnen) lukken met beperkte middelen. Dan kun je stellen dat de beveiliging brak is.

[Verwijderd]

Alleen kun je exact dat argument voor iedere software wel geven. Dat maakt het nog niet bij definitie brak. Ik wil jouw de beveiliging wel eens zien kraken, kijken hoe brak je hem dan vind

[Verwijderd]

Dus als hij het niet kan breken maar een groepje wel dan is het opeens veilig.

[Verwijderd]

Nee natuurlijk niet, maar Robbemans doet alsof het onveilig is maar dat is het ook niet in verhouding tot overige software. Maar goed, we vallen in herhaling.

[supersnathan94]

Nee maar ook niet per se direct brak. Dat zou het zijn in het voorbeeld van een bericht van een week terug waarin je met siri heel eenvoudig de passcode zou moeten kunnen omzeilen (dikke hoax natuurlijk maar iedereen trapte erin).

[kimborntobewild]

Immers alles valt te kraken met genoeg tijd en middelen.

Nee hoor. Een juiste encryptie implementatie van een one-time path of quantumencryptie is niet te kraken (voordat de zon de aarde opslokt).

[Reactie gewijzigd door kimborntobewild op 25 juli 2024 19:35]

[Maurits van Baerle]

Een backdoor is bewust toegevoegd en dat zal dit sowieso niet zijn. Verder gaat het hier om iMessage verkeer terwijl de FBI de inhoud van een telefoon wil hebben. De FBI zal hier dus weinig aan hebben.

[MarcoC]

Hoezo helaas voor Apple? Apple publiceert hun encryptiemethodes op de website van Apple. Door deze transparantie weten wij als doodgewone burgers dat Apple net zo menselijk is als elk ander bedrijf. Als Apple überhaupt geen documentatie online had geplaatst, dan was de kans groot dat informatie zoals deze in handen bleef van een select gezelschap. De kans is verder groot dat Apple dit soort berichtgeving zal gebruiken om de encryptie van hun diensten verder aan te scherpen. Uiteindelijk resulteert dit dus in betere beveiliging, dus dat is alleen maar positief voor Apple.

Bij vrijwel elke iOS-update zie je overigens een changelog waarbij hackersgroepen credits krijgen voor het vinden van lekken iOS. Je kan als bedrijf nog zoveel resources hebben, de community zal altijd sneller zijn in het vinden van gaten.

[Anonymoussaurus]

Er komt steeds meer naar buiten dat Apple minder goed beveiligd is dan andere grote bedrijven zoals Google. Google patched denk ik ook wat vaker.

Ik vind wel dat er nogal wat moeite gedaan moest worden om die berichten in te zien. Bij een lek moet ik meer aan een wat eenvoudiger iets denken, maar ja, ook lekken heb je in alle soorten en maten.

[Zavantas]

Er komen verhalen naar buiten... maar of deze ook op een "neutrale" manier worden geschreven of beschreven... dat is nog maar de vraag.

De fameuze "iCloud hack" waar vele celebrities tot hun verrassing hun foto's zagen verschijnen op het net bleek niets meer te zijn dan phishing en gokken... Helaas worden dit soort berichtgevingen dan weer niet gepubliceerd, en blijft de gemiddelde gebruiker met een vals beeld achter.

[Anonymoussaurus]

De fameuze "iCloud hack" waar vele celebrities tot hun verrassing hun foto's zagen verschijnen op het net bleek niets meer te zijn dan phishing en gokken... Helaas worden dit soort berichtgevingen dan weer niet gepubliceerd, en blijft de gemiddelde gebruiker met een vals beeld achter.

Ja, dat weten we inmiddels (ik tenminste). Echter is het zo dat als de hacker continu blijft gokken/raden, dat Apple dan de functie in moet bouwen voor het maximaal aantal pogingen (bijvoorbeeld 5 keer).

[SidewalkSuper]

De hacker had de wachtwoorden en logins gephisht. Hij had helemaal geen 10x proberen nodig om erin te komen.

Daarbij komt dat zo'n limiet als bekende gebruiker nogal onhandig is. Er zijn vast genoeg grappenmakers die je willen pesten na bijv een foute uitspraak en expres een paar keer fout inloggen, zodat je er zelf niet meer bij kan zonder speciale handelingen te verrichten. Zeer vervelend.

[Anonymoussaurus]

De hacker had de wachtwoorden en logins gephisht. Hij had helemaal geen 10x proberen nodig om erin te komen.

Daarom zeg ik

Echter is het zo dat als de hacker continu blijft gokken/raden

[xoniq]

En je oplossing is dan? Dit werkt bij ALLES.

[DRaakje]

Over de iCloud hack, daar konden ze inderdaad bruteforcen op het password.
Onbeperkte inlog pogingen mogen doen is een redelijke beveiligingsblunder, dit soort dingen hoor je minder van google.

[Reactie gewijzigd door DRaakje op 25 juli 2024 19:35]

[mkools24]

Dat slaat ook nergens op want je kon gewoon onbeperkt user/password combinaties blijven proberen, dat is dus wel degelijk de fout van Apple.

Als Google software lek is dan is het onveilig en moet je het niet gebruiken, als Apple software lek is dan is het FUD.

[iAR]

Niets is wateridcht. Software wordt natuurlijk steeds complexer. Het lijkt me dat de kans dat er wat mis gaat ook groter wordt. Apple fixt dit soort zaken ook in updates.

[blottle]

Volledig mee eens. Iedere software is mijn inziens te hacken, hoeveel tijd je er ook in stopt. Er zal overal wel een gaatje zitten. Vooral in die complexe systemen zoals deze, of gehele besturingssystemen. Niets is perfect, en zeker niet op softwaregebied.

[Anonymoussaurus]

Klopt, niets is ook waterdicht, ben ik het mee eens. Het valt me alleen op dat Apple steeds vaker en meer lekken heeft dan andere grote bedrijven. Dit bewijst ook weer dat je geen Apple hoef te nemen, omdat de beveiliging niet zo heel goed is. Nu wil ik niet zeggen dat dat van Android nou niet lek is hoor. Maar, nu kunnen de fanboys van Apple in ieder geval niet meer zeggen "neem Apple. Is beter beveiligd. Google volgt je maar overal". Tot op heden werd altijd maar gedacht dat als je Apple draaide, je direct beveiligd bent tegen virussen/hackers.

[Reactie gewijzigd door Anonymoussaurus op 25 juli 2024 19:35]

[mddd]

Ik denk dat het er ook veel mee te maken heeft dat Apple van veiligheid een speerpunt heeft gemaakt. Zowel intern als in de marketing van hun producten. En hoge bomen vangen veel wind. Als je zegt dat je heel veilig bent, dan is het inderdaad groter nieuws wanneer er een gat in zit, dan wanneer je dit überhaupt nooit hebt gezegd.

[Ome Kor]

Inderdaad, bij Apple wordt het al gauw een ...gate.
Bij Microsoft hoor er nauwelijks iets over. Zoek maar eens op:
MS16-009, MS16-011, MS16-012 of MS16-015.
Maw. security is hard.

[Anonymoussaurus]

Naja, Google pakt het stukken slimmer aan. Apple zijn naar mijn inzien echt gieren. Veel vragen waar je minder voor krijgt bij de concurrent. Maar ja, dat is wel een slimme marketingtruc. Google beloont mensen met geld als zij lekken vinden in bijvoorbeeld Chrome. Dat zie ik Apple niet echt doen (of ik heb iets gemist).

[Webgnome]

Google pakt het helemaal niet slimmer aan? Hoeveel android apparaten zijn er en hoeveel van die aparaten draaien de laatste versies/patches? Nuff said. Wat dat betreft heet Apple het een heel stuk beter voor elkaar ( en dat zeg ik als Android gebruikert).

Dat er dingen mis gaan bij Apple is niet heel anders dan bij Google of welke andere speler dan ook. Ik vraag mij ook serieus af of je claim dat Apple meer lekken zou hebben op feiten zijn gebaseerd of meer een op gevoel?

[Anonymoussaurus]

Google pakt het helemaal niet slimmer aan? Hoeveel android apparaten zijn er en hoeveel van die aparaten draaien de laatste versies/patches? Nuff said. Wat dat betreft heet Apple het een heel stuk beter voor elkaar ( en dat zeg ik als Android gebruikert).

Dat is echt Apples ( ) met peren vergelijken. Hoeveel verschillende iOS devices zijn er? En hoeveel verschillende Android devices?

Plus dat het ook nog zo is dat veel smartphonemakers, een extra softwarelaag eroverheen gooien, die ook lekken kan bevatten. Je vergelijking is dus niet helemaal eerlijk naar mijn mening.

[AlphaBlack_NL]

En hoeveel verschillende windows 10 computers zijn er? Je geeft dus zelf al aan dat er in praktijk meer kwetsbare Android devices zijn. Waarom dat komt heb je als consument weinig mee te maken lijkt me. Device encryption staat op de meeste Androids helaas ook uit.

[FreshMaker]

En hoeveel verschillende windows 10 computers zijn er?

nul ....

Aangezien het niet een windows10 computer is, maar een stuk hardware IN STAAT om windows10 te draaien.

Apple ondersteunt een paar devices, en na verloop van tijd vervalt support net zo hard.
Of ben je vergeten dat een iPhone 4 wel de IOS upodate kreeg, maar geen Siri ?
Dat is evengoed ondersteuning, Apple devices krijgen updates, maar functionaliteit blijft uit, of vervalt gewoon.

Zo heb je Samsung die 18 maanden support levert, maar omdat 'het volk' de S6 ook na 1 jaar nog steeds koopt, wil niet zeggen dat Samsung máár 6 maanden support geeft.

De S4 van mijn oudste kreeg gisteren nog een update via play-services, terwijl die al een tijdje niet meer 'geupdate' wordt.
Dat hij geen Android M krijgt via Samsung is ook helemaal geen issue verder

[supersnathan94]

Dat is echter wel naar een jaar of vier vijf. Dat is iet anders dan de 18 maanden bij high end samsungs. Bovendien duren patches en updates vaak veel te lang voor dat ze uitgerold worden.

Google heeft het in dat opzicht dus helemaal niet beter voor elkaar. Het update beleid van Android in z'n algemeen is exht niet okee. Google houd de touwtjes strak in handen met de nexus series dus het kan wel, maar alle andere vendors gooien er echt wel met de pet naar.

[AlphaBlack_NL]

Een Android smartphone is ook een stuk hardware instaat om Android te draaien. Alleen ben je dus helaas al snel toegewezen op customs roms(inclusief de bugs) omdat de fabrikant zijn variant van Android heel traag of helemaal niet meer updatet naar de laatste versie.

[mkools24]

Dat ligt niet aan Google, Google brengt gewoon elke maand security updates uit. Als je CM of AOSP draait krijg je die gewoon elke maand netjes mee, dat fabrikanten als Samsung die niet doorvoeren ok maar dat is niet de schuld van Google.

En bij iOS patchen ze wel maar als je je oudere iPhone maar blijft updaten wordt deze op een gegeven moment zo traag dat je weer een nieuwe moet kopen.

[Webgnome]

De redenen die je opgeeft doet niets af aan de situatie? Ik heb alleen mijn twijfels bij het statement dat Google het beter voor elkaar heeft of niet.

[xiphoid]

Volgens mij doet Apple alleen aan HoF credit, niet aan uitbetalen; https://bugcrowd.com/list-of-bug-bounty-programs

[iAR]

Veel vragen waar je minder voor krijgt bij de concurrent.

Je zult je opmerkingen echt moeten onderbouwen. De miljoenen mensen die Apple's producten komen zijn het namelijk niet met je eens.
Of draai het om: Google moet mensen belonen om lekken door te geven omdat ze het anders niet doen?! Apple gebruikers doen dat graag omdat de loyaliteit beter is. En laat het ook nog heel makkelijk zijn om Apple van feedback te voorzien (op www.apple.com/feedback).

[Tweaker1234]

Alleen komt het inmiddels simpelweg te vaak voor. Ja, dan wordt marketing belangrijk Waar maar al te graag in gelooft wordt voor de peace of mind. Kan daar niet bij.

[mddd]

Alleen komt het inmiddels simpelweg te vaak voor.

Inderdaad te vaak, want elke kwetsbaarheid is er 1 te veel. Maar ondanks die kwetsbaarheden is het volgens mij nog steeds zo dat iOS veiliger is dan Android. Windows weet ik te weinig vanaf om over te oordelen.

Er zijn volgens mij echt twee dingen aan de hand die je niet door elkaar moet halen:
- hoe vaak is er nieuws over kwetsbaarheden
- alles bij elkaar, welk systeem is nu het veiligst (of misschien wel beter: het minst onveilig want niets is echt veilig).

Het antwoord op de tweede vraag is volgens mij nog steeds dat iPhone / iOS de veiligste keuze is.

[Tweaker1234]

iMessage is niet alleen iOS maar ook OSX.

Pak ik puur mobiel, dan is WP/W10M onomstotelijk de veiligste keuze. Wordt ook minder gebruikt. Dat scheelt ook. Pak je Windows op tablet enz, de x86/x64 versie, dan wordt het een ander verhaal omdat die dominerend in die markt is.

[mddd]

Natuurlijk maar de discussie ging inmiddels niet echt meer over iMessage maar over iOS en Android.

[doom71]

https://www.cvedetails.com/top-50-products.php?year=2015

[SunnieNL]

Dat is hetzelfde als dat Windows vroeger steeds vaker en meer lekken had in het verleden. Geloof me, Apple heeft het niet meer of minder dan Windows of Linux.

Het probleem wat Apple nu echter heeft is dat ze veel populairder zijn dan pakweg 4-6 jaar geleden. Dat zorgt voor een verschuiving van hackers en security mensen. Kijken die eerst naar de grote groep Windows gebruikers, nu is Apple veel interessanter aan het worden.
Punt 1 omdat zowel Apple, maar meer hun gebruikers, nog op de roze wolk leven met dat de beveiliging zo goed is. Wij hebben nooit last van virussen ideeen die nog rondzwerven.
Punt 2 omdat veel mensen nu Apple gebruiker en de Apple devices meer persoonlijke informatie bevatten dan de meeste Windows machines bij mensen thuis.

[mddd]

Het probleem wat Apple nu echter heeft is dat ze veel populairder zijn dan pakweg 4-6 jaar geleden. Dat zorgt voor een verschuiving van hackers en security mensen.

Wel grappig, datzelfde argument hoorde je 4-6 jaar geleden ook al regelmatig.

Wij hebben nooit last van virussen ideeen die nog rondzwerven.

Volkomen correct. Daar hebben we ook nooit last van. Gelukkig is het tegenwoordig in de Windows wereld ook vele malen beter dan vroeger.

omdat veel mensen nu Apple gebruiker en de Apple devices meer persoonlijke informatie bevatten dan de meeste Windows machines bij mensen thuis

Volkomen waar. Niet alleen Apple trouwens. Mensen maken natuurlijk net zo hard filmpjes en chatten net zoveel met hun Android devices. Het feit dat je mobiel zo veel van je persoonlijke informatie bevat maakt al deze apparaten een groot doelwit voor allerlei kwaadwillenden.

[Tweaker1234]

Volkomen correct. Daar hebben we ook nooit last van.

Onzin, moet je toch eens beter het nieuws volgen.
Dat is past tense.

[mddd]

Ransomware? Trojans? Absoluut. Maar virussen? OS X is nog steeds goed beschermd tegen zichzelf verspreidende malware. Voor zover ik weet, gaat het steeds om malware die meelift op iets wat je als gebruiker zelf installeert.

[Tweaker1234]

Ga aan een gebruiker uitleggen wat voor hem/haar het verschil is. Gaat niet werken.

[Olaf van der Spek]

Android devices zijn een grote gatenkaas vergeleken met iOS devices..

[Anonymoussaurus]

Klopt. Ik zeg ook niet dat Android lekvrij is . Lees m'n tekst anders even opnieuw.

[monojack]

Je suggereert op basis van hoeveel nieuws je hoort of iets veilig is. Maar je moet je juist de vraag stellen waarom je dat nieuws hoort.

Is het nog nieuws als er malware wordt gevonden voor Android of Windows? Niemand kijkt daar nog van op. Het is net als Flash niemand is verbaasd als er weeral eens een lek is gevonden. Het kan de mensen nog weinig schelen want dat vinden ze toch om de haverklap.

Apple heeft gewoon het imago van heel te veilig te zijn dus is het echt wel nieuws als iemand de beveiliging kan omzeilen. Bekijk dan ook eens goed de methodes. en de gebruikte OS versies en je zal dan zelfs moeten besluiten dat het meestal een storm in een glas water is. Ofwel is de methode te omslachtig ofwel is het enkel toepasbaar op oudere versies.

Dus nee er komt niet steeds meer naar buiten dat Apple zijn beveiliging minder goed zou zijn dan die van andere tech bedrijven. Het komt er op neer dat het geen nieuws is bij andere tech bedrijven omdat het er schering en inslag is.

[Reactie gewijzigd door monojack op 25 juli 2024 19:35]

[watercoolertje]

Dus nee er komt niet steeds meer naar buiten dat Apple zijn beveiliging minder goed zou zijn dan die van andere tech bedrijven. Het komt er op neer dat het geen nieuws is bij andere tech bedrijven omdat het er schering en inslag is.

Het is echt onzin om te doen of een (bekend geworden) lek bij Android niet op tweakers/nu.nl komt ofso, dat komt het namelijk wel...

Het is wel heel makkelijk om te zeggen dat er minder nieuws over Android lekken is omdat het vaker voorkomt. Meer nieuws = vaker/meer stront aan de knikker.

[Reactie gewijzigd door watercoolertje op 25 juli 2024 19:35]

[FreshMaker]

Android devices zijn een grote gatenkaas vergeleken met iOS devices..

Als het zo ernstig zou zijn als je nu stelt, loopt elke android gebruiker dus met een virus / malware of bankhack op zak ?

De Belgische snelwegen zijn ook een gatenkaas, maar toch kun je er veilig over navigeren

[supersnathan94]

En toch heb ik die ene keer dat ik twee jaar terug door belgië en frankrijk reed meer lekke banden en kapotte assen gezien dan in een heel jaar in nederland.

Veilig: ja opzich wel. Er is niemand dood gegaan.
Veel schade: ja dat zeker.


Om terug te komen op android. Ik denk zeker dat de gemiddelde android gebruiker zeker wel een behoorlijk lek op z'n telefoon heeft.

[FreshMaker]

Tja, als je als Nederlander ( lees simpele gebruiker ) gewoon door crossed zonder op te letten, dan loop je inderdaad schade op.

ik zit bijna wekelijks op de E19, en weet dat het kan gebeuren.
Dus ga ik niet met 140KM/u doorgassen, maar hou me aan het overige verkeer, en ontwijk tijdig obstakels.
Net zoals ik al bijna 8 jaar Android gebruik, naast andere apparaten, en op geen van de device's is het uit de hand gelopen.

Geluk ?
Nee, opletten en navigeren ...

[iAR]

Dat is ook niet helemaal waar als je dat niet met cijfers kunt onderbouwen. Dat iets vaker in het nieuws is wil niet zeggen dat het ook zo is.
Wat mddd al zegt, Apple heeft de focus extreem op veiligheid en privacy. Dus elke misser is gelijk nieuws.

[GekkePrutser]

Ach als je dit nieuwsbericht van dit weekend over Android ziet, ook heel recent en een veel groter probleem. Dat is een remote root exploit terwijl de hack in het artikel slechts toegang geeft tot enkele iMessage foto's.

Reken dan ook nog mee dat veel Android telefoons niet de laatste versie draaien omdat de fabrikanten achterlopen, en je ziet dat Apple veel goed doet ten opzichte van de concurrentie.

[Anonymoussaurus]

Zoals ik in een ander bericht al zei:

Dat is echt Apples ( ) met peren vergelijken. Hoeveel verschillende iOS devices zijn er? En hoeveel verschillende Android devices?

Plus dat het ook nog zo is dat veel smartphonemakers, een extra softwarelaag eroverheen gooien, die ook lekken kan bevatten. Je vergelijking is dus niet helemaal eerlijk naar mijn mening.

[monojack]

Je bedoelt dat lekken bij Apple meer pers halen zeker? Dat komt omdat men constant lekken vindt bij andere tech bedrijven en dat niemand er nog van opkijkt.

Een lek in Android of Windows daar staat niemand nog verbaasd van. Een lek bij Apple? Dat is nieuws. Daarom lijkt het voor jou dat er bij Apple meer veiligheidslekken zouden zijn niet omdat het effectief zo is.

Waarom staat de FBI voor de deur van Apple te zwaaien met een bevel? Er liggen honderden telefoons te wachten om unlockt te worden. Is er ooit maar één vraag geweest om een Google toestel te unlocken? Geen enkel? Waarom denk je? Omdat ze daar geen problemen mee ondervinden om er in binnen te dringen. Dat zijn gewoon zaken waar we al gewoon aan zijn geworden en waar we ons zelfs geen vragen meer bij stellen.

[Tweaker1234]

Beveiliging en volgen zijn niet synoniem.
Volgen: Google volgt je inderdaad overal. Waar je als Google gebruiker mee instemt. Enige oplossing is geen Google account te gebruiken. Kan je beter een Apple of Microsoft account gebruiken.

Beveiliging: Die is nergens meer heilig. Niet technisch en ook niet door menselijke acties.
Kan je dus op 1 hoop gooien. Alleen hoe meer gebruikt des te groter groter de moeite is die genomen wordt.

[Verwijderd]

Jij praat nu andere struisvogels na.
Wil jij echt dat je hele privéleven op straat komt te liggen? Dat men misbruik maakt van die gegevens?
Toch niet? Dan moet je ook tegen volgen zijn.

[Verwijderd]

Het ene sluit het andere niet uit. Nee, ik wil niet dat mijn privegegevens op straat komen te liggen. Ja, wat maakt het uit dat er anonieme statistieken worden bijhouden van mij. Als ik dan toch reclame moet zien liever reclame waar ik ook nog daadwerkelijk iets aan heb. Maar dat wil niet automatisch zeggen dat mijn hele privéleven op straat ligt. Dát is pas andere struisvogels napraten

[Anonymoussaurus]

Dat slaat ook nergens op. Veilig opgeslagen op de Google servers is niet hetzelfde als "op straat liggen". De definitie van "op straat liggen" betekent meer dat IEDEREEN het kan zien. Je doet nu dus overkomen dat iedereen maar kan zien wat je wachtwoorden, bankgegevens etc etc zijn.

[AlphaBlack_NL]

Veilig op Google servers is vrijwel synoniem aan in de handen van de Amerikaanse overheid. Patriot act etc.

[SidewalkSuper]

Encryptie is gewoon heel heel moeilijk. Dat mag toch wel duidelijk zijn. Apple is er al heel goed in en het is dus heel interessant voor onderzoekers om daar naar te kijken en problemen te vinden.

Google heeft niet iets vergelijkbaars qua encryptie, dus het is niet zo raar dat er geen berichten van komen.

Moet je nagaan wat er gebeurt als er nog een backdoor bij in geprogrammeerd moet worden. Dat maakt het nog weer veel lastiger en kwetsbaarder.

[Reactie gewijzigd door SidewalkSuper op 25 juli 2024 19:35]

[supersnathan94]

En dat valt dus wel mee. Whatsapp en iMessage zijn in dat opzicht net zo veilig. Beide bedrijven gebruiken een set private keys en publieke keys. Apple gebruikt per device een setje wat het opslaat op de server dus als je meerdere apparaten hebt dan staan er dus netjes meerdere publieke keys op die server. Bij WA is het er maar 1 per telefoonnummer.

Het is dus kinderlijk eenvoudig om er een toe te voegen waarvan de NSA en private key heeft. 😱

[Mic2000]

Het zou ook kunnen dat de overheid wel degelijk het voor elkaar heeft om 'gaten' in de beveiliging in te bouwen en juist deze poppenkast op poten heeft gezet om burgers een veilig gevoel te geven.

[Iblies]

Er komt steeds meer naar buiten dat Apple minder goed beveiligd is dan andere grote bedrijven zoals Google. Google patched denk ik ook wat vaker.
...

We moeten hier geen Apple/google/Facebook flamewar gaan starten.

Google werkt in heel veel gevallen gewoon mee. En daar zijn ze redelijk eerlijk in want ze publiceren de gegevens (grotendeels ?). En ik zet het tussen haakjes want instanties als de AIVD zijn zeer terughoudend, maar Google zou zo eerlijk moeten zijn? Ik weet het niet.

En dat er landen zijn met een bepaalde reputatie die ook gegevens krijgen toegereikt zou je achterdochtig moeten maken, wetende dat Google Corp ongelooflijk veel informatie heeft, en de verzoeken theoretisch oneindig lang door kunnen gaan. Als er al een deel is versleuteld, dan nog hebben ze ziekelijk veel info over je dat ze kunnen opvragen.

https://www.google.com/tr...erdatarequests/countries/

[xiphoid]

Dat komt o.a. omdat ook daadwerkelijk vaker iets te patchen hebben..

[Anonymoussaurus]

Of ze doen er gewoon meer aan, en steken er meer energie in .

[Verwijderd]

Kun je dat beargumenteren? Want Apple staat over het algemeen bekend juist wel veel aan beveiliging te doen. Ze gaan er in ieder geval stukken beter mee om dan bijvoorbeeld Microsoft.

Root rechten nodig? Even op ja klikken. Bij Apple root rechten nodig? Wachtwoord invoeren svp. om maar even een voorbeeldje te noemen.

[AibohphobiA BoB]

Jazeker, want ze hebben namelijk aangegeven dat ze nu pas de cloud gaan beveiligen. Ook was het hele debacle van de FBI nooit mogelijk geweest als ze ervoor hadden gezorgd dat de firmware van een gesloten telefoon niet bijgewerkt kon worden.

Dus argumenten genoeg.