Lek in iOS geeft toegang tot apparaat via ongeopende mail

Er zijn details verschenen van een lek in iOS dat een kwaadwillende toegang geeft tot de mailclient via een mail die gebruikers niet hoeven te openen. Het enige dat gebruikers merken van de aanval is dat de Mail-app tijdelijk trager is. Apple werkt aan een fix.

Lek in iOS-Mail. Bron: ZecOPsDe aanval geeft toegang tot de mails van gebruikers, maar via een ander lek zouden aanvallers ook bredere toegang kunnen krijgen, schrijft beveiligingsbedrijf ZecOps. Het zou gaan om een lek dat misbruikt zou worden voor gerichte aanvallen op bepaalde personen. ZecOps zegt dat het lek is misbruikt voor aanvallen op onder meer topmensen van bedrijven, maar Motherboard heeft dat niet kunnen bevestigen.

Gebruikers hoeven niet te klikken op de mail om de aanval te laten slagen, aldus ZecOps. De inhoud van de mail is te groot voor de software. Hoe groot dat moet zijn, hangt mede af van het werkgeheugen van de telefoon. Daarna kan een aanvaller de mail verwijderen om sporen te wissen.

Apple zal een fix verspreiden met de volgende kleine update van iOS. Die zit nu al in de bèta van iOS 13.4.5. Gebruikers kunnen ook de Mail-app deactiveren. Andere mailclients als Gmail en Outlook zijn niet getroffen en kunnen tot de update dus veilig gebruikt worden. ZecOps zegt Apple in februari op de hoogte te hebben gebracht, maar wilde al publiceren om gebruikers te wijzen op het bestaan van het lek.

Door Arnoud Wokke

Redacteur Tweakers

22-04-2020 • 19:36

69

Submitter: Verwijderd

Reacties (61)

61
60
32
1
0
11
Wijzig sortering
Als je toestel gehackt kan worden zonder dat de mail geopend wordt, waarom dan wachten tot een beta-versie klaar is voor het grote publiek?

En wat kan een hacker precies als je toestel gehackt is: je foto's uitlezen? Je camera activeren?
Q: What does the vulnerability allow:

A: The vulnerability allows to run remote code in the context of MobileMail (iOS 12) or maild (iOS 13). Successful exploitation of this vulnerability would allow the attacker to leak, modify, and delete emails.

Additional kernel vulnerability would provide full device access – we suspect that these attackers had another vulnerability. It is currently under investigation.

[Reactie gewijzigd door CyberMania op 23 juli 2024 05:41]

A: The vulnerability allows to run remote code in the context of MobileMail (iOS 12) or maild (iOS 13).
In welke taal zijn deze apps geschreven? Zou de runtime van iOS apps hier niet tegen moeten beveiligen?
Swift. @SoloH Objective C is de oude taal die gebruikt werd voor Apple devices.

[Reactie gewijzigd door Saeverix op 23 juli 2024 05:41]

Swift bestond nog niet toen mail werd geschreven. Ik ga ervan uit dat ze dat niet hebben omgezet naar Swift, aangezien je Objective C ook nog gebruikt kan worden. Alle Frameworks zijn ook nog gewoon in Objective C geschreven.
Ik heb geen bron maar dacht dat ze veel hebben herschreven in swift en dat er daarom ook zo veel (nieuwe) bugs waren in bepaalde apps.
Mail dus niet, https://blog.timac.org/2019/0926-state-of-swift-ios13/

[Reactie gewijzigd door iAR op 23 juli 2024 05:41]

Wordt nog steeds gebruikt voor Apple devices hoor. Je kunt gewoon nog een nieuw Objective-C project starten in Xcode, debuggen op een iPhone en uploaden naar de store.
Dat wel ja, maar dat is denk ik meer om ontwikkelaars niet teveel tegen de benen te schoppen. Want een groot project van een aantal jaar Objective C code zet je niet zomaar even om in Swift.
Maar er gaat vrijwel zeker een moment komen dat ze een requirement in de App Store zetten dat de Apps alleen goedgekeurd worden wanneer ze in Swift geschreven zijn.
Apple gaat tijdens app reviews (afaik) nooit weten welke taal je hebt gebruikt, je stuurt immers een binary op, geen sources. Ze kunnen deze binary wel afchecken aan de hand van testen, om te weten welke API’s worden aangesproken, maar ik vermoed niet dat ze hier snel een verplichting op gaan afdwingen. Swift en Objective-C kan je combineren, dus achterliggend compiled dat naar hetzelfde. Als je die lijn doortrekt, zou het een beetje hetzelfde zijn dat Google plots Kotlin zou verplichten in plaats van Java.
Totale onzin, er zijn nog heel veel redenen te bedenken om (deels) Objective-C te gebruiken, waaronder traploze integratie met C en C++. Apple zelf heeft nog bakken met software die echt niet herschreven hoeft te worden.

Objective-C blijft zolang Apple blijft.
Dat lijkt me sterk, aangezien Apple zelf ook al minder investeert in Swift en nu zelfs andere talen gaat gebruiken terwijl Swift ook op genoemd platform beschikbaar is: https://www.phoronix.com/...m&px=Apple-From-C-To-Rust
Het ziet er naar uit dat het gaat om C wat gebruikt wordt binnen een Objective-C methode als ik naar de code en naamgeving kijk. De -> wordt alleen gebruikt in C en C++.

Het Objective deel van Objective-C zelf is redelijk veilig maar er wordt - zeker in het verleden - vaker C of C++ gebruikt voor de performance gevoelig stukken code, of simpelweg omdat er al een library bestand in C die bepaalde functionaliteit had.
Die paar weken maken nu ook niet meer uit, blijkbaar is de eerste exploit al in januari 2018 gedaan.

Maar specifiek, lijken ze dus niets te kunnen:
These bugs alone cannot cause harm to iOS users – since the attackers would require an additional infoleak bug & a kernel bug afterwards for full control over the targeted device.

[Reactie gewijzigd door SinergyX op 23 juli 2024 05:41]

Maar specifiek, lijken ze dus niets te kunnen:
Mijn mail bevat toch echter wel echt gevoelige zaken en/of kan gebruikt worden voor password reset voor diensten (ik heb zoveel mogelijk 2-factor, maar niet alles heeft 2-factor).

Als het ook om bedrijfsmail gaat...

Ik vind het overigens ontzettend onkies dat ze publiceren, *terwijl* er een fix in aantocht is.
Waarom onkies?
Grote kans dat het lek al gebruikt werd (Zoals ook aangegeven in het artikel)
Als je weet dat er een lek in zit, dan kun je overstappen naar een andere client, zodat je niet meer kwetsbaar bent.
Het probleem hier is dat veel gebruikers om een of andere reden denken dat Apple veel veiliger is dan andere fabrikanten (onterecht in mijn ogen, maar oké). Daardoor zullen gebruikers dus niet op het idee komen om de moeite te nemen andere apps te gaan gebruiken.
En precies door dit soort berichtgeving kan je die misvatting over Apple veiligheid recht trekken
Hoe bedoel je alle gebruikers over 1 kam scheren?

1. Niet alle Apple gebruikers zijn zo
2. Niet alleen Apple gebruikers kunnen zo zijn
3. Is het dan beter om dit soort berichtgeving te vermijden?
4. Het lijkt eerder alsof jij last hebt van cognitieve dissionatie en dus bovergenoemde feit 1 en 2 zal negeren
1 Ja klopt, maar de meeste wel. Anders zou er wel meer kritiek uit die hoek komen.
2 Dat zei ik al, beter lezen. (Apple gebruikers hebben een ongewoon grote last...). Dus niet 'Alleen Apple gebruikers hebben last...'
3. Want?
4. Zie uitleg hiervoor.
1. Heb je bronnen hiervoor, want anders kraam je gwoon onzin uit. Dat het de vocale meerderheid is in jouw kringen kan zo zijn, maar om zulke algemene uitspraken te doen zie ik graag je bron voor
2. Ga zelf beter lezen. Ik het t over de "ongewoon grote last van cognitieve dissonantie" dat non-Apple user ook zo kunnen zijn, dus ook ongewoon grote last van cognitieve dissonantie kunnen hebben. Dat je toegeeft dat andere mensen daar last van hebben staat er buiten. Ik het t over ongewoon grote last ervan hebben en het blijkt nergens uit je woorden dat je zegt dat non-apple users daar ook last van hebben in ongewoon grote mate.
3.T was een vraag. Zie je dit soort nieuws liever niet of wel?
1. Verkoopcijfers van Apple.
2. Jijbakken negeer ik.
1. Dus elk sucesvol product dat jij niet koopt komt voort uit cognitieve dissonantie? Ik hoop dat je de ironie hiervan inziet in watvoor mentale gymnastiek jij hier moet uitvoeren om je eigen troep te geloven. DAT is nou eens een voorbeeld van cognitieve dissonantie. En dat bewijst gelijk punt 2
2. Jij bent een voorbeeld van een non-Apple user die lijdt aan een ongewoon hoge mate van cognitieve dissonantie. Jij bent voor (waarschijnlijk) Android users precies hetgeen je niet leuk vindt aan die Apple users die je beschrijft.

[Reactie gewijzigd door WORPspeed op 23 juli 2024 05:41]

1. Jijbakken negeer ik
2. Herhaling van standpunten negeer ik ook. Als je het echt wil weten scroll je maar omhoog.
Ik negeer jou wel gewoon. Als je niks zinnigs kan zeggen, gaat dit nergens over
Dat maakt natuurlijk wel uit. Nu het algemeen bekend is geworden is de kans dat het misbruikt gaat worden veel groter.
En ook de hoop dat Apple het dus sneller zou patchen.
We hope that with making this information public it will help to promote a faster patch so the attackers would stop abusing these vulnerabilities for the collective safety of all iOS users.
Apple heeft al een patch, die gaat nu alleen door de betafase. Als Apple nou op de handen zou zitten...

Het is makkelijk scoren ten koste van de reputatie van een ander.


* Keypunchie heeft overigens wel per direct de Beta geinstalleerd.

En dan nog is voor ‘gewone’ gebruikers een beta installeren ingewikkeld. Ik heb voor mijn familie met Apple overal ‘automatisch updaten’ aangezet. Maar zelfs na release kan het dan nog wel even duren voordat patches worden opgepakt.
Controle over je mailbox zonder dat je iets doorhebt is toch aardig wat. Helemaal als je bedenkt wat voor data je daarmee kan binnen halen.

Een CEO van een groot bedrijf zal vast wel wat leuke prive emails van andere personen in zijn mailbox hebben.

De getroffen personen zullen ook zeker een interessante inbox hebben:
  • Medewerkers van een Fortune 500 bedrijf uit de US
  • Europese journalist
  • "VIP" uit Duitsland
  • Executive van japans telecom bedrijf
  • Paar security service providers uit Saudi Arabia/Israel

[Reactie gewijzigd door Loggedinasroot op 23 juli 2024 05:41]

Omdat het waarschijnlijk handiger is om dit soort mails al op de mail server af te vangen. Grote mails, mails met onrealistisch veel multiparts, gekke RTF constructies.
Voor de doorsnee gebruiker zal de mailserver of spamfilter dit soort mails al blokkeren.
Het niet hoeven te openen ligt genuanceerder. In het ZecOps artikel staat nl. dat het afhankelijk is van de IOS versie:
Q: Do end users require to perform any action for the exploitation to succeed?
A: On iOS 13 – no. On iOS 12 – it requires the victim to click on an email.
Ben benieuwd of er ook een patch komt voor IOS 12.
Ik vraag me af in hoeverre dit in de praktijk uitmaakt. De meeste mensen zullen gewoon de mail openen, om vervolgens te zien dat er niks in staat.
Dan is het kwaad al geschied.
Hopelijk komt de patch ook nog uit vor de vorige versie van IOS.
Waarschijnlijk wel. De iPhone 5S krijgt nog steeds patches, ook al heeft deze nog iOS 12.
Kwalijke zaak. Dit toont maar weer de noodzaak aan van beveiligingsupdates over een periode van de gemiddelde levensduur van een toestel. Bij Apple is dat in orde.
Apple zal een fix verspreiden met de volgende kleine update van iOS.
Dit is toch wel de kracht van iOS. Snelle updates die bijna alle iPhones bereiken. Top.
Dit heeft toch niks met security updates voor het OS te maken? De bug zit in de mail app.

Het verbaast mij eerder dat Apple dit niet via de App Store (kan?) update(n).

[Reactie gewijzigd door Caayn op 23 juli 2024 05:41]

Dat heeft alles met security updates te maken aangezien het met een iOS update wordt gefixed. Het lek zit dus waarschijnlijk in iOS.
Je leest vrij slecht. Het lek zit in de iOS mail app. Dat die niet bijgewerkt kan worden via de app store is erg jammer en een nadeel. Je moet nu een hele iOS update pushen voor een kleine fix in een app.

Er zit daarnaast waarschijnlijk nog een gaatje in de kernel wat zorgt voor de sandbox escape, maar die is nog niet bekend bij deze partij.
Waarom zou die niet via de Appstore bijgewerkt kunnen worden? Je kunt de app gewoon verwijderen en via de Appstore weer downloaden, dan moet een update toch ook wel kunnen? Maar zelfs als dat niet kan, dan is het toch nog geen probleem? De update komt wel, en die duurt meestal ook niet zo lang.

[Reactie gewijzigd door mjz2cool op 23 juli 2024 05:41]

Ze signen het hele iOS-image inclusief systeemapps (zoals mail). Als je alleen een update van mail zou uitbrengen, zou het image niet meer als integer worden gezien, je moet dus het hele image opnieuw uitbrengen.

De vraag is of Mail nog wel een systeemapp zou moeten zijn.
Je kunt de Mail app verwijderen (13.4.2). Dus is het wel een systeemapp? Verwijderen en opnieuw installeren zou dan eenvoudiger zijn?
Als je systeemapps "verwijdert", wordt vziw. alleen het icoontje niet meer getoond en bepaalde api-calls geblockt. Hij is niet echt weg.

[edit]
Hmmm. Schijnt te zijn veranderd sinds iOS 10:
iOS 10: https://support.apple.com/en-gb/HT204221
iOS 12 en hoger: https://support.apple.com/en-gb/HT204221

Beetje vaag over wat er nou echt gebeurd bij 'delete'... want anders zou je inderdaad gewoon een losse update moeten kunnen doen, zou je zeggen.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 05:41]

Bij iOS werkt dat inderdaad zo dat systeemapps niet afzonderlijk worden geüpdatet. Software van derden kan inderdaad wel via de App Store. Zolang je systeemupdates uitgeeft is dat ook niet relevant.

Daarnaast zijn veel systeemapps nauw verweven met het os. Door alleen de apps te updaten kunnen lekken in het os niet altijd gedicht worden.
Eerste exploits waarschijnlijk sinds begin 2018.

Snel? Top?
Heeft het toch nog nut, 16gb ram in je telefoon.

Maar zonder dollen, dit is een zeroday die vast misbruikt is. Er is nu eenmaal een levendige handel in dit soort leaks, voor verschillende OSen.
Er is een verschil tussen geheugen (ram) en opslag (de 16 GB waar jij naar refereert) |:(
Als je zo graag slim wil overkomen, dan moet je wel zorgen dat je de feiten op een rijtje hebt he. ;)
Er zijn telefoons met 16GB RAM. RAM als in werkgeheugen.
Alleen is er geen enkele iPhone die 16GB aan RAM heeft.
Nee want dan was deze hack moeilijker geweest. Dat was mijn grap. Dat er nu telefoons zijn met 16gb waar geen praktisch nut voor te verzinnen is, omdat het met 6 of 8 gb ook helemaal prima gaat. Het 1e praktisch nut zou nu kunnen zijn dat deze hack lastiger zou zijn als de iphone meer ram had gehad. Dat was de grap. Flauw, ik weet het, maar dat meerdere mensen de link niet snapten verbaasd mij nogal.
Vandaar dat de buffer overflow ook makkelijker is, je hebt minder GB nodig om dat uit te voeren
We hebben het toch duidelijk over iphones hier? Maar goed ik begrijp je punt ;)

[Reactie gewijzigd door pdukers op 23 juli 2024 05:41]

Toucé! Daar heb je gelijk in. :)

Hoe groot dat moet zijn, hangt mede af van het werkgeheugen van de telefoon.
ik weet dat er phones zijn met 16GB ram, maar geen daarvan was een iPhone, toch?.

[Reactie gewijzigd door Pim0377 op 23 juli 2024 05:41]

Ik waan mij niet (geheel) veilig op internet Zelfs niet achter mijn vpn. Is mijn wifi veilig? Wie binnen wil komen, en voldoende midddelen heeft, lukt het vast wel. Dat houd ik in mijn achterhoofd.
Blij met m’n iPad Pro, maar ik gebruik werkelijk nooit die mail app, werkt eigenlijk nooit en geen idee waar dat aan ligt.

Dus dan maar Outlook en Gmail en die werken precies zoals het hoort.
De mail app gebruik ik zelf niet eens binnen iOS/ipadOS. De outlook app geeft mij dan net wat meer functionaliteiten en notificaties...

Hopelijk hebben ze snel een fix gevonden voor dit security issue..
https://blog.zecops.com/v...lemail-maild-in-the-wild/

Impact & Key Details (TL;DR) :
The vulnerability allows remote code execution capabilities and enables an attacker to remotely infect a device by sending emails that consume significant amount of memory
The vulnerability does not necessarily require a large email – a regular email which is able to consume enough RAM would be sufficient. There are many ways to achieve such resource exhaustion including RTF, multi-part, and other methods
Both vulnerabilities were triggered in-the-wild
The vulnerability can be triggered before the entire email is downloaded, hence the email content won’t necessarily remain on the device
We are not dismissing the possibility that attackers may have deleted remaining emails following a successful attack
Vulnerability trigger on iOS 13: Unassisted (/zero-click) attacks on iOS 13 when Mail application is opened in the background
Vulnerability trigger on iOS 12: The attack requires a click on the email. The attack will be triggered before rendering the content. The user won’t notice anything anomalous in the email itself
Unassisted attacks on iOS 12 can be triggered (aka zero click) if the attacker controls the mail server
The vulnerabilities exist at least since iOS 6 – (issue date: September 2012) – when iPhone 5 was released
The earliest triggers we have observed in the wild were on iOS 11.2.2 in January 2018
FAQ
Goh wat heb apple tog ineens veel lekages, deze betrouwbar en enige die zogenaamd privacy geef ,
ik zie laatste jaren niks anders dan problemen van lekages of overname van buiten af,
betalen we de devs hier voor? Zelfs android is veiliger als dit zo door gaat,
mja de apple devs zijn echt hele slimme mensen, te slim om iedereen te overtuigen “ neem onze producten, wij bieden beste privacy, onze producten zijn top notch” echt he,
weten , al die slimme kinderen die voor apple programeren komen nu aan hun eind van ontwikkelen, en maken meer lekages en gaten dan andere

Op dit item kan niet meer gereageerd worden.