Apple repareert macOS-lek dat kan leiden tot persistent malware

Apple heeft een lek in macOS gedicht dat kan leiden tot vrijwel onverwijderbare malware. Apple wist van het lek, omdat Microsoft-onderzoekers het ontdekten en hun bevindingen deelden met de macOS-maker.

Apple noemt de Microsoft-onderzoekers in de changelog. Die onderzoekershebben inmiddels ook hun eigen bevindingen online gezet. Zij noemen de exploit Migraine, omdat die gebruikmaakt van Migration Assistant, een tool om gegevens van een eerdere pc over te zetten naar een nieuwe Mac. De exploit maakt het mogelijk om bestanden te plaatsen die dankzij System Integrity Protection of SIP bescherming krijgen tegen verwijdering. Dat maakt het mogelijk rootkits of persistent malware te installeren. Dat is malware die ook op het systeem blijft staan na een herstart. Het is voor zover bekend de eerste kwetsbaarheid die het mogelijk maakt om SIP te omzeilen zonder fysieke toegang tot een systeem.

Migration Assistant draait diverse scripts die het mogelijk maken om willekeurige code uit te voeren. De Microsoft-onderzoekers wisten een aanval van een afstand uit te voeren door de Migration Assistant met enkele parameters te starten, zodat een gebruiker niet uitgelogd hoeft te zijn om hem te starten. Dat maakt het gebruik van een AppleScript mogelijk om de Migration Assistant op te starten en door de stappen heen te loodsen om de code te laden. Er zijn geen aanwijzingen dat de exploit in het wild is misbruikt. Apple heeft de kwetsbaarheid onlangs gefixt in macOS Ventura.

Reacties (46)

[vdws]

Dit is gefixt in Ventura 13.4 (22F66) update van 18 mei. Misschien handig om te vermelden...

[darkpluisje]

Mijn Macbook geeft aan op Venture 13.1 (22C65) te draaien. Bij zoeken naar updates geeft hij echter aan dat de mac up to date is. Kan het zijn dat hij niet gelijktijdig overal beschikbaar is?

[sfranken]

Doe eens een `sudo softwareupdate -i -a -R`

[ThierryCola]

Nou vraag ik mij toch altijd af met dit soort terminal commando's wat dan precies die -i -a -R inhoud. En waarom dan bijvoorbeeld twee kleine letters, maar dat de R dan weer een hoofdletter is. En hoe zou je zoiets makkelijk kunnen leren / dan wel makkelijk kunnen onthouden?

[ddefrenne]

In een terminal: "man softwareupdate" of "softwareupdate -h". Dan zie je dat "-i" staat voor "install", "-a" in combinatie met "-i" installeert alle updates die er beschikbaar is en "-R" doet erna een herstart van het systeem. De reden dat het "-R" is is omdat "-r" a ingenomen is en enkel de recommended updates zal installeren. "man" en/of "-h" werken bij bijna alles.

[ThierryCola]

@ddefrenne , @jj71 , @zambiorix ,
bedankt voor deze verhelderende informatie!

[Reactie gewijzigd door ThierryCola op 23 juli 2024 01:46]

[jj71]

Typ in een terminal gewoon het commando "softwareupdate" (en dan enter) in en hij vertelt je precies welke opties er zijn en wat die betekenen.

-i = install
-a = all (all appropriate updates)
-R = restart (automatically restart if necessary)

[Reactie gewijzigd door jj71 op 23 juli 2024 01:46]

[zambiorix]

type eens

softwareupdate -h

dan krijg je een overzicht van alle CLI opties voor betreffende applicatie (-h werkt voor de meeste applicaties met CLI opties)

Meestal start een CLI optie met een enkele dash + enkel karakter OF een dubbele dash en één of meerdere woorden (gescheiden door een dash).
Dit is geen standaard, maar wordt dikwijls aangehouden.

Bij een enkel karakter wordt meestal het eerste karakter van de beschrijving van de optie gebruikt. In geval meerdere opties met hetzelfde karakter beginnen kan je een hoofdletter gebruiken.

VB voor `softwareupdate`

-h = help
--help = hetzelfde als -h

-i = install update(s)
-r = recommended
--recommended = hetzelfde als -r
-R = restart after install (hoofdletter omdat -r al in gebruik is)
--restart = hetzelfde als -R

enz ....

[Commendatore]

Als dat ding al maanden niet herstart is, zou ik dit eerst eens doen eigenlijk, voor met allerlei terminal-commando’s bezig te gaan. Beginnen bij de simpele stappen.

[sfranken]

Ik merk het met mijn macs dat ze zelfs dan niet altijd updates die er wel zijn tonen. Met het commando werkt het altijd

[Commendatore]

Dan loop je serieus achter. Wanneer heb je die computer voor het laatst herstart?

[darkpluisje]

Ja zo simpel kan het zijn, maar had niet gedacht dat dit nodig was als je hem ook handmatig naar updates laat zoeken. Hij hangt altijd aan de stroom via mijn beeldscherm dus het herstarten was al wel ff geleden

[Boy]

Ik heb net ook maar weer eens uptime getikt en zit ook weer op 40 dagen met m'n MacBook.
Zolang hij niet raar gaat doen, klap ik 'm dicht en gewoon open...herstart is gewoon niet vaak nodig. Ik zit op 13.2.1, toch maar eens updaten maar

[vdws]

Dat is gek. Staat bij "System Settings" > "Software update" de optie Automatic Updates aan?

Bij mijn beide Macs (iMac en Macbook) is de update beschikbaar (en geïnstalleerd).

[darkpluisje]

Ja stond aan en ook handmatig zoeken had geen zin, maar hij was al een tijdje (zeg waarschijnlijk weken) niet opnieuw opgestart. Dat gedaan en hij begon meteen de updates te downloaden.

[ThierryCola]

Toch handig om erachter te komen door zo'n nieuwsartikel dat er inmiddels al "een tijdje" een update beschikbaar is. Bij mij staat hij altijd ingesteld voor updates met 'check voor updates', 'download nieuwe updates wanneer beschikbaar'. Maar krijg ik er vervolgens nooit melding van dat er dus een update klaar staat voor installatie. Ik heb het toch liever altijd zelf in de hand of ik wel of niet de update installeer (bijvoorbeeld vanwege wel of niet ondersteunende software), maar als ik daar vervolgens geen melding van krijg schiet het natuurlijk ook niet op.

Edit: ook opmerkelijk is dat hij de update nu alsnog eerst nog moet downloaden. Terwijl ik dus aangeef dat hij het wel alvast mag downloaden, maar dit blijkbaar dus niet doet. Weet iemand daar toevallig wat meer van met hoe of wat en waarom dit gebeurd?

[Reactie gewijzigd door ThierryCola op 23 juli 2024 01:46]

[PTR]

@arnoudwokke

Apple heeft de kwetsbaarheid onlangs gefixt in macOS Ventura.

Dit is niet alleen in ventura gefikst, ook in big sur (11.7.7) en monterey (12.6.6)

[Zezura]

[kevlar01]

Toch mooi dat uitgerekend MS dit meldt bij Apple. Ze hadden er ook voor kunnen kiezen om het niet te melden en Apple mogelijk negatieve reputatieschade te kunnen laten oplopen.
Echter is het oplossen van dit soort malware een grotere prioriteit.

[WhatsappHack]

Microsoft, Apple, Google, META, etc. doen allemaal mee aan responsible disclosure. Dus ook onderling. Samenwerken aan elkaar veilig houden is beter dan elkaar proberen te naaien en gebruikers de dupe te laten worden. En wie de bal kaatst… Etc. Dat zien ze zelf ook, dus wisselen onderling waarschuwingen over elkaar uit. En credits leveren PR op, zoals dit artikel.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 01:46]

[Relief2009]

Google? Je bedoelt de vele malen keren dat Google publiekelijk melding maakt van lekken zonder Microsoft de tijd geven een patch uit te brengen?

https://grahamcluley.com/...ed-windows-vulnerability/

https://www.forbes.com/si...atch-tuesday-fix-failure/

In het laatste geval gaat het niet eens om een critical bug.

[Reactie gewijzigd door Relief2009 op 23 juli 2024 01:46]

[GertMenkel]

Google geeft Microsoft toch telkens weer drie maanden om een patch uit te brengen. 90 dagen is bij responsible closure de norm.

In het eerste aangehaalde artikel heeft Microsoft besloten om een kwetsbaarheid die in november gemeld is toch niet in februari uit te brengen. In het tweede bleek later dat de patch van Microsoft niet goed werkte.

In beide gevallen is het toch Microsoft die beter hun werk had moeten doen.

[Blokker_1999]

Er is nergens een wet of een regelgeving die zegt dat je na 90 dagen de informatie moet openbaren. Als er goede communicatie is met het bedrijf dat voor een oplossing moet zorgen, en zij tonen aan dat ze er ook effectief aan werken dan kan je zelf ook even langer wachten totdat er ofwel een fix is openbaar gemaakt of de communicatie/vooruitgang lijikt gestopt te zijn.

Er zijn vroeger meerdere meldingen over Google's team geweest waarbij zij wel even langer hadden kunnen wachten.

[GertMenkel]

Er is ook nergens een wet dat je een bedrijf 90 dagen moet geven. Dat is nu eenmaal de norm die in de infosecwereld normaal aangehouden wordt.

Persoonlijk vind ik juist dat de strikte deadlines goed werken. Het zorgt ervoor dat stap 1 van het proces het vinden van een patch is, niet het onderhandelen van zes maanden extra tijd voor publicatie.

Google maakt hier genoeg fouten in (ze zouden die 90 dagen beter ook voor hun eigen spul moeten aanhouden, maar helaas loopt dat niet zo goed) maar in principe moet drie maanden genoeg zijn om een kritiek lek te patchen. Heel af en toe komt het voor dat een heel subsysteem moet worden ongeschreven, zoals de printer spooler, maar daar wordt dan normaal ook verlenging op gegeven.

In dit soort gevallen zou drie maanden meer dan genoeg tijd moeten zijn.

[WhatsappHack]

In dat laatste geval staat de reden ook vermeld in het artikel zelf. Niet bepaald kritiek noch complex en dus de termijn van 3 maanden voor release (dat is wel iets meer dan “geen tijd gegeven” ).

Project Zero heeft echter in het verleden zichzelf inderdaad weleens misdragen/is zeer onredelijk geweest puur om (zoals het leek) anderen even lekker af te zeiken, maar heb daar de laatste jaren geen voorbeelden meer van gezien/gehoord - dat beleid lijkt fors verbeterd te zijn, ik gok zomaar omdat Google het andersom ook niet wilde ervaren op die manier. Maar dit is dan imho wel een slecht voorbeeld om te geven van hoe het verkeerd zou zijn gegaan; gezien ze zichzelf hier gewoon aan de procedure hebben gehouden, het simpel op te lossen moet zijn geweest en Microsoft ruim de tijd had gehad om het te fixen en daarnaast afwisten van de publicatiedatum.

[ikweethetbeter]

Google maakt alle gemelde bugs na 90 dagen openbaar.

[Hakulaku]

Betreffende je eerste link:

"Google first informed Microsoft of the flaw in March 2016, warning that a hacker could exploit it to elevate their privileges. Microsoft responded by rolling out a patch in June (MS16-074)." De openbaring van deze vulnerability was pas op 16 november.

https://bugs.chromium.org...zero/issues/detail?id=992

Betreffende je tweede link:

De bug is geregistreerd op 20 mei 2020 en pas geopenbaard midden augustus (nadat Microsoft een fix had uitgebracht die het niet fixte).

https://bugs.chromium.org...ero/issues/detail?id=2039

Volgensmij is 90 dagen meer dan netjes. Een bedrijf bashen is 1, maar zorg dan tenminste voor goede voorbeelden.

[DutchKevv]

Heb je een paar recente voorbeelden waar Apple researchers publiekelijk Microsoft / Google hielpen met security fixes?

[Arrogant]

Microsoft heeft Apple in het verleden in leven gehouden.

[pBook]

Vooral om zichzelf in te dekken voor monopoly claims 😅

[ikweethetbeter]

Microsoft heeft Apple in het verleden[/url] in leven gehouden.

Ja, uit puur eigenbelang!

[novasurp]

Dit is niet waar. https://youtu.be/r5TdqfNE1QU

[Arrogant]

Goede video.
Het was dom van me om de leugens van Ballmer te geloven.

[Muncher]

Ik heb liever dat die partijen concurreren op de kwaliteit van hun producten en diensten ipv. op de beveiliging van hun producten. Dus ja, het is juist fijn dat ze dit met elkaar delen!

[Menesis]

Op welke manier zou je hiervan slachtoffer kunnen worden? In mijn naïeve hoofd: alleen als je unsigned software installeert, of signed software (als de software maker eerst is geïnfecteerd en het stiekem in de broncode is gestopt voor distributie)?

[GertMenkel]

Je zou bijvoorbeeld malware uit de app store kunnen hebben geïnstalleerd die nog niet door Apple gevonden is. Als malware een lek als dit misbruikt, zal het ook wel een sandbox escape beschikbaar hebben.

In het verleden is er ook een hele reeks malware in de iOS app store verschenen doordat iemand een virus in de compiler gestopt had en die in China verspreid had (waar XCode downloaden niet zo snel en makkelijk ging). Alle code die de ontwikkelaar kon zien was schoon, maar het eindresultaat was alsnog geïnfecteerd.

Dan heb je nog het risico met apps als Discord, die Electron gebruiken en daarmee externe Javascript kunnen uitvoeren met de mogelijkheid om binaries te starten en API calls te doen. Een domeinovername of remote code execution bug zou daar een virus kunnen verspreiden. Bij 3CX was het probleem dat iemand de bibliotheek voor het decoden van media had geïnfecteerd, daarmee werd met hun handtekening en alles malware naar klanten verspreid.

Een virus oplopen kan gebeuren, ongeacht welk platform je gebruikt. Doorgaans is dit niet zo'n enorm probleem omdat antivirusbedrijven redelijk snel zijn met het opsporen van wijdverspreide virussen, maar als zo'n virus zich in het systeem heeft weten te nestelen achter SIP dan kan alleen Apple het van je systeem verwijderen via een speciale bootmodus (en dan moet je geluk hebben dat het virus zichzelf niet inlaadt tijdens deze bootmodus).

[nst6ldr]

(als de software maker eerst is geïnfecteerd en het stiekem in de broncode is gestopt voor distributie)?

Het komt eerder voor dat een ontwikkelaar per ongeluk private keys opneemt in z'n project en die mee deployed. Dan kunnen anderen zelf de software signen, en vaak duurt het nog best lang voordat iemand er achter komt.

[bzzzt]

Op welke manier zou je hiervan slachtoffer kunnen worden? In mijn naïeve hoofd: alleen als je unsigned software installeert, of signed software (als de software maker eerst is geïnfecteerd en het stiekem in de broncode is gestopt voor distributie)?

Of als software gebruik maakt van een andere zero-day om uitvoerrechten op je computer te krijgen en dan deze malware installeert.

[Bulkzooi]

Op welke manier zou je hiervan slachtoffer kunnen worden? In mijn naïeve hoofd: alleen als je unsigned software installeert, of signed software (als de software maker eerst is geïnfecteerd en het stiekem in de broncode is gestopt voor distributie)?

aangezien het probleem zich openbaart in de migratie phase is alles mogelijk.

Er gebeurd dan zoveel wat de gebruiker niet ziet, via unsigned child processes, en met AppleScript valt dat prima te automatiseren.

ik denk dat de naam migraine dan ook geïnspireerd is op de unattended installatie methode, die niet lekker voelt en alle bellen laat afgaan zonder dat de gebruiker ook maar enige invloed op het process kan uitoefenen.

Alsof de buschauffeur je het ravijn inrijdt terwijl de passagiers het al lang van te voren zien aankomen. Maar je kan die passagiers moeilijk kwalijk nemen dat ze op vakantie gingen. Het probleem ligt aan de buschauffeur.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 01:46]

[ikweethetbeter]

Beetje onsamenhangend artikel, zie de eerste en laatste regels:

Apple heeft een lek in macOS gedicht...
...
Apple heeft de kwetsbaarheid onlangs gefixt in macOS Ventura.

Gaat het in beide gevallen over macOS Ventura, of gaat het in het eerste geval over (een) macOS versie(s) voor Ventura?

Lijkt me een snelle vertaling van niet gelinkte Engelstalige nieuwsbron...

Had in de eerste zin Ventura genoemd, dan had de laatste zin kunnen worden weggelaten.

[Prosperot]

noem idd in het artikel gewoon de versies waarin het gerepareerd is...

[Bozebeer38]

Migraine is wel leuk bedacht.

[FGras]

Hup gelijk downloaden en installeren.

[Carlos0_0]

Doe ik vrijdag wel weer een keer, batterij is dan wel weer op een punt dag die opgeladen moet worden .

[le1337]

Als je naar nalatigheid en ernstige verwaarlozing kijkt denk ik eerder aan Windows.

Bij MacOS is een security incident redelijk zeldzaam en op Windows is het gewoon "bekend" dat je een virus kan krijgen bij je software.

Het is ook best logisch als je kijkt naar de userbase verhouding dat virus makers sneller voor Windows kiezen.

Op MacOS en iOS heb je om die reden ook niet echt een virusscanner nodig.

Ik ga er ook van uit dat er letterlijk niemand hier op Tweakers is dit slachteroffer hiervan is geworden.