image

Makers iPhone-spyware misbruikten onbekende hardwarefunctie Apple-chip

donderdag 28 december 2023, 08:49 door Redactie, 17 reacties

De makers van de TriangleDB-spyware, die volgens antivirusbedrijf Kaspersky jarenlang is gebruikt om iPhone-gebruikers te bespioneren, maakten misbruik van een onbekende hardwarefunctie van Apple-chips, zo stelt de virusbestrijder in een nieuwe analyse. Het bestaan van de spyware werd eerder dit jaar door Kaspersky onthuld, nadat het bedrijf er zelf slachtoffer van was geworden.

IPhones werden door middel van zero-click exploits, zonder enige interactie van slachtoffers, met de spyware geïnfecteerd. Hiervoor werd gebruikgemaakt van een onzichtbaar iMessage-bericht gecombineerd met een reeks zerodaylekken. Eenmaal actief werden slachtoffers onder andere via de microfoon van de telefoon afgeluisterd. De afgelopen maanden maakte Kaspersky meerdere details over de spyware en gebruikte kwetsbaarheden bekend, die inmiddels door Apple zijn verholpen.

Gisteren presenteerde de virusbestrijder tijdens de 37ste editie van het Chaos Communication Congress in Hamburg dat de aanvallers ook misbruik maakten van een onbekende hardwarefunctie van door Apple ontworpen chips. Daardoor konden de aanvallers data naar onbekende hardwareregisters van de chip schrijven die niet door de firmware werden gebruikt. Kaspersky vermoedt dat de functie waarschijnlijk voor debugging of testdoeleinden door Apple-engineers of de fabriek is gebruikt, of per ongeluk is toegevoegd. "Omdat deze feature niet door de firmware wordt gebruikt, hebben we geen idee hoe de aanvallers wisten hoe ze er gebruik van moesten maken", zegt onderzoeker Boris Larin.

Hardwareregisters

Randapparatuur die in de chip van Apple beschikbaar is kan door middel van hardwareregisters met de processor communiceren. Hiervoor worden deze hardwareregisters gemapt naar geheugen dat voor de processor toegankelijk is en bekendstaat als Memory-Mapped I/O, of MMIO-adressen. De MMIO-adressen worden in een speciaal formaat (DeviceTree) opgeslagen en zijn via tooling uit te lezen.

De TriangleDB-spyware maakte voor het omzeilen van de hardwaregebaseerde kernelgeheugenbescherming waarover iPhones beschikken gebruik van onbekende MMIO-adressen die niet in de DeviceTree stonden vermeld en ook niet door de firmware werden gebruikt, zo ontdekten de onderzoekers. De grootste vraag die nog altijd onbeantwoord is, is hoe de aanvallers van het bestaan van deze functie afwisten.

Na het misbruik van de kwetsbaarheid in de Apple-chip hadden de aanvallers hun spyware kunnen uitvoeren, maar besloten dat niet te doen. In plaats daarvan werd een compleet nieuwe aanval uitgevoerd om de iPhone opnieuw te compromitteren. Hiervoor werd Safari in de 'onzichtbare modus' gestart en een malafide webpagina geladen die een volgende reeks exploits uitvoerde. Waarom de aanvallers besloten om een volledig nieuwe exploit uit te voeren nadat ze de iPhone al hadden gecompromitteerd is ook onbekend.

Eerder dit jaar kwam Kaspersky met een tool waarmee gebruikers kunnen kijken of ze doelwit van de spyware zijn geweest. Daarnaast laat de virusbestrijder weten dat de Lockdown Mode van Apple waarschijnlijk bescherming tegen de aanval biedt, waarbij wordt gewezen naar het gebruik van de onzichtbare iMessage. De Lockdown Mode wordt echter pas sinds een jaar aangeboden en de spyware is volgens de onderzoekers al ruim daarvoor ingezet.

Reacties (17)
28-12-2023, 09:29 door Anoniem
De grootste vraag die nog altijd onbeantwoord is, is hoe de aanvallers van het bestaan van deze functie afwisten.

Het meest voor de hand liggend is dan toch een zwakke schakel in het personeelsbestand van Apple denk ik.
28-12-2023, 10:02 door Anoniem
Is dit niet een uitgebreide omschrijving van wat je ook een "backdoor" kunt noemen?
28-12-2023, 10:21 door Anoniem
Apple maakt die chips vast niet zelf...
28-12-2023, 10:33 door karma4
Door Anoniem: Is dit niet een uitgebreide omschrijving van wat je ook een "backdoor" kunt noemen?
Ja
28-12-2023, 11:36 door Anoniem
Door Anoniem: De grootste vraag die nog altijd onbeantwoord is, is hoe de aanvallers van het bestaan van deze functie afwisten.

Het meest voor de hand liggend is dan toch een zwakke schakel in het personeelsbestand van Apple denk ik.

Dat kan, maar hoeft niet.

Het is indrukwekkend hoeveel dingen _echt_ slimme mensen kunnen uitvogelen door testen, meten en nadenken zonder inside informatie.

lees bv https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf , over het reverse engineeren van microcode updates .
28-12-2023, 11:37 door Anoniem
Door karma4:
Door Anoniem: Is dit niet een uitgebreide omschrijving van wat je ook een "backdoor" kunt noemen?
Ja

...so that other iOS security researchers can confirm our findings and come up with possible explanations of how the attackers learned about this hardware feature...

Backdoor: relating to something that is done secretly or in a way that is not direct or honest

Ook naast kwaadaardig suggestief iets onderbouwd inhoudelijks bij te dragen?
28-12-2023, 11:40 door Anoniem
Door Anoniem: De grootste vraag die nog altijd onbeantwoord is, is hoe de aanvallers van het bestaan van deze functie afwisten.

Het meest voor de hand liggend is dan toch een zwakke schakel in het personeelsbestand van Apple denk ik.

Niet noodzakelijkerwijs, er is ook gewoon proberen mogelijk. Wat doet een CPU met "niet" gebruikte op-codes.
Meestal een nog niet bekend neven effect bedoel of onbedoeld.

Mogelijk kende apple de functie ook niet.
Maar het een gat in specs/test procedures worden onbekende opcodes wel correctv als fout afgehandeld.

En anders wederom een bewijs dat security by obscurity niet werkt.
28-12-2023, 12:28 door karma4
Door Anoniem:...Ook naast kwaadaardig suggestief iets onderbouwd inhoudelijks bij te dragen?
Hoe wil je het anders uitleggen dan een backdoor?
- ontworpen en bewust ingebakken. De mogelijkheden om uit beveiligingen te ontsnappen moet bekend geweest zijn.
Bedenk hardwareregisters zijn er niet zomaar toevallig.
- niet gedocumenteerd, kennis achtergehouden. Security by obscurity.

https://en.wikipedia.org/wiki/Backdoor_(computing) A backdoor may take the form of a hidden part of a program,[3] a separate program (..), code in the firmware of the hardware,[4] or parts of an operating system
28-12-2023, 14:28 door Anoniem
Door karma4:
Door Anoniem:...Ook naast kwaadaardig suggestief iets onderbouwd inhoudelijks bij te dragen?
Hoe wil je het anders uitleggen dan een backdoor?
- ontworpen en bewust ingebakken. De mogelijkheden om uit beveiligingen te ontsnappen moet bekend geweest zijn.
Bedenk hardwareregisters zijn er niet zomaar toevallig.
- niet gedocumenteerd, kennis achtergehouden. Security by obscurity.

https://en.wikipedia.org/wiki/Backdoor_(computing) A backdoor may take the form of a hidden part of a program,[3] a separate program (..), code in the firmware of the hardware,[4] or parts of an operating system
Kan net zo goed zoals ook aangehaald door de onderzoekers een vergeten onderdeel zijn uit een test fase. Zou niet de eerste keer in de geschiedenis zijn dat een hardware leverancier zo iets doormaakt.

Als het echt een leverancier backdoor is dan verwacht je ook dat deze om de lockdown modus heen kan functioneren en de methode geupdate is ervoor. Want wat heb je aan een backdoor als de meestal highprofile targets die iets meer beveiliging maatregelen hebben niet geraakt erdoor worden dan heb je veel goedkopere massa deployment aanvallen om survailance uit te voeren. Dat werken met de lockdown modus aan is echter nog niet vastgesteld.

En dat laatste verbaasd me wel enigzins dat er nog geen conclusie vanuit Kaspersky is over de effectiviteit van de lockdown modus bij deze specifieke aanval.

Kan het een backdoor zijn mogelijk, is het bewezen nee.
Komende dagen, weken zal er wel meer duidelijkheid om komen als andere bedrijven hun zegje erover doen. Heb iedergeval onze contacten bij ESET gevraagd er ook naar te laten kijken en risico voor onze bedrijven en klanten te laten beoordelen.
28-12-2023, 16:05 door Anoniem
Door Anoniem:
Door Anoniem: De grootste vraag die nog altijd onbeantwoord is, is hoe de aanvallers van het bestaan van deze functie afwisten.

Het meest voor de hand liggend is dan toch een zwakke schakel in het personeelsbestand van Apple denk ik.

Dat kan, maar hoeft niet.

Het is indrukwekkend hoeveel dingen _echt_ slimme mensen kunnen uitvogelen door testen, meten en nadenken zonder inside informatie.

lees bv https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf , over het reverse engineeren van microcode updates .

Even de URL van de researchers ook zichtbaar quoten (maar staat ook in de redactie samenvatting)

https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/

Ook boeiend - en best te volgen als je wat weet van hardware en kernel architectuur.

In een notendop : DMA - direct memory access , is wanneer een perifere chip (video, disk, ethernet controller) rechtstreeks data in of uit ram haalt .

De CPU schrijft de de begin en eind adressen in registers van die chip, schrijft een "doe je ding" opdracht, en krijgt een interrupt als de perifere chip klaar is. (of - pollt een status register bijvoorbeeld).
Old skool - Amiga 'blitter' en 'copper' chips waren daar een voorbeeld van dat misschien herkenbaar is.
(en mainframes deden het al decennia )/
Moderde hardware kan het gewoonlijk ook , maar daar hebben waarschijnlijk minder mensen mee ge-hobby-programmeerd op dat niveau.

Die DMA access gaat helemaal buiten de MMU, virtueel geheugen en page protectie om , dat is normaal .
Het is aan de CPU + OS om de geheugen regio (goed) aan te wijzen en te alloceren - en te mappen naar het proces dat de data wil hebben , of beschikbaar stelt .

Hier is het - waarschijnlijk - de video chip die (ook) DMA-capable is (dat is heel erg te verwachten) , maar waarvan de register _wel_ bereikbaar waren voor de cpu, maar verder niet gebruikt werden.
En met een ketting van vier zero-day exploits kon er genoeg code gedraaid worden om die DMA-chip geheugen te laten lezen (of schrijven) dat niet leesbaar was voor de exploit code .
28-12-2023, 16:12 door Anoniem
De researchers van GReAT hebben er ook een presentatie over gegeven. Erg intressant om te volgen: https://www.youtube.com/watch?v=7VWNUUldBEE

Een van de vragen vanuit het publiek is ook of het een backdoor is of niet. Maar ze willen niet speculeren over de oorsprong als ze er geen bewijs voor hebben, en dat is in dit geval dus de conclusie.
28-12-2023, 16:54 door Anoniem
En nog een boeiende followup :

https://social.treehouse.systems/@marcan/111655847458820583

Poster met , naar het lijkt (ah . meneer Asahi Linux . No shit dat het iemand is Apple hardware nogal goed snapt) , serieuze ervaring in dergelijke hacking - herkent/stelt dat de magische 'hash functie' die gebruikt wordt een ECC (error correcting code) generator is .
Logisch dat dat nodig is als je (erg low level) zelf ecc-protected geheugen moet beschrijven,

Meer achtergrond omtrent Apple hardware protectie features hier
https://blog.svenpeter.dev/posts/m1_sprr_gxf/

(weer moet ik de eerste (/enige ?) zijn die hier wat relevante achtergrond informatie uit het Internet trekt, tussen alle wannabe's die meteen op de conspiracy toer gaan. Zijn er hier echt geen andere mensen die ook wat echte kennis kunnen toevoegen ?)
29-12-2023, 01:17 door Anoniem
Door Anoniem: En nog een boeiende followup :

https://social.treehouse.systems/@marcan/111655847458820583

Poster met , naar het lijkt (ah . meneer Asahi Linux . No shit dat het iemand is Apple hardware nogal goed snapt) , serieuze ervaring in dergelijke hacking - herkent/stelt dat de magische 'hash functie' die gebruikt wordt een ECC (error correcting code) generator is .
Logisch dat dat nodig is als je (erg low level) zelf ecc-protected geheugen moet beschrijven,

Meer achtergrond omtrent Apple hardware protectie features hier
https://blog.svenpeter.dev/posts/m1_sprr_gxf/

(weer moet ik de eerste (/enige ?) zijn die hier wat relevante achtergrond informatie uit het Internet trekt, tussen alle wannabe's die meteen op de conspiracy toer gaan. Zijn er hier echt geen andere mensen die ook wat echte kennis kunnen toevoegen ?)
Ik denk dat de mensen met echte relevante kennis aan de aanvalsoort hun tijd nu eenmaal niet gaan verspillen aan het leveren van informatie die enkel interesant is voor de mensen met soort gelijke kennis en zeker niet in een regulier forum. Er is een reden waarom we congressen hebben. Of denken we nu werkelijk dat alle lezers hier of ook maar een groot deel uberhaubt snapt wat er gebeurt in de aanval laat staan opervlakkige interesse erin hebben.

Wat voor gemiddelde ITer belangrijk is de mitigation en CVE en dat ze gauw patchen niet dat ze begrijpen hoe de aanval in elkaar zit maar risico inschatting inperking en voorkomen waar mogelijk.

En bij deze dan ook de betrokken CVE's
CVE-2023-41990
CVE-2023-32434
CVE-2023-32435
CVE-2023-38606
29-12-2023, 13:47 door Anoniem
Door Anoniem:


[..]
(weer moet ik de eerste (/enige ?) zijn die hier wat relevante achtergrond informatie uit het Internet trekt, tussen alle wannabe's die meteen op de conspiracy toer gaan. Zijn er hier echt geen andere mensen die ook wat echte kennis kunnen toevoegen ?)
Ik denk dat de mensen met echte relevante kennis aan de aanvalsoort hun tijd nu eenmaal niet gaan verspillen aan het leveren van informatie die enkel interesant is voor de mensen met soort gelijke kennis en zeker niet in een regulier forum. Er is een reden waarom we congressen hebben. Of denken we nu werkelijk dat alle lezers hier of ook maar een groot deel uberhaubt snapt wat er gebeurt in de aanval laat staan opervlakkige interesse erin hebben.

Congressen zijn er om een uitje te hebben naar een meestal leuke plaats, met goede catering en een avondprogramma ;-)

Ik heb inderdaad een lage dunk van de gemiddelde poster hier, maar het blijft jammer.

Voor degenen met een ietwat serieuze interesse , dan wel ambitie om later in de IT/security te gaan werken - het is echt niet moeilijk om wat meer achtergrond informatie naar boven te halen en de relevantie/risico's van een nieuwsbericht als dit beter te duiden .
En het zijn er zo weinig die dat doen.

Wat voor gemiddelde ITer belangrijk is de mitigation en CVE en dat ze gauw patchen niet dat ze begrijpen hoe de aanval in elkaar zit maar risico inschatting inperking en voorkomen waar mogelijk.

En bij deze dan ook de betrokken CVE's
CVE-2023-41990
CVE-2023-32434
CVE-2023-32435
CVE-2023-38606

Voor de nog meer gemiddelde ITer is zelfs dat niet nodig - gewoon 'patchen zodra er iets beschikbaar is waar bij staat 'security patch' . Welke CVE, boeiuh.

(het wordt pas relevant als je moet gaan inschatten of je anders/niet wilt mitigeren/patchen wegens impact/risico op verstoring ).
29-12-2023, 17:34 door Anoniem
Door Anoniem:
Door Anoniem:


[..]
(weer moet ik de eerste (/enige ?) zijn die hier wat relevante achtergrond informatie uit het Internet trekt, tussen alle wannabe's die meteen op de conspiracy toer gaan. Zijn er hier echt geen andere mensen die ook wat echte kennis kunnen toevoegen ?)
Ik denk dat de mensen met echte relevante kennis aan de aanvalsoort hun tijd nu eenmaal niet gaan verspillen aan het leveren van informatie die enkel interesant is voor de mensen met soort gelijke kennis en zeker niet in een regulier forum. Er is een reden waarom we congressen hebben. Of denken we nu werkelijk dat alle lezers hier of ook maar een groot deel uberhaubt snapt wat er gebeurt in de aanval laat staan opervlakkige interesse erin hebben.

Congressen zijn er om een uitje te hebben naar een meestal leuke plaats, met goede catering en een avondprogramma ;-)

Ik heb inderdaad een lage dunk van de gemiddelde poster hier, maar het blijft jammer.

Voor degenen met een ietwat serieuze interesse , dan wel ambitie om later in de IT/security te gaan werken - het is echt niet moeilijk om wat meer achtergrond informatie naar boven te halen en de relevantie/risico's van een nieuwsbericht als dit beter te duiden .
En het zijn er zo weinig die dat doen.

Wat voor gemiddelde ITer belangrijk is de mitigation en CVE en dat ze gauw patchen niet dat ze begrijpen hoe de aanval in elkaar zit maar risico inschatting inperking en voorkomen waar mogelijk.

En bij deze dan ook de betrokken CVE's
CVE-2023-41990
CVE-2023-32434
CVE-2023-32435
CVE-2023-38606

Voor de nog meer gemiddelde ITer is zelfs dat niet nodig - gewoon 'patchen zodra er iets beschikbaar is waar bij staat 'security patch' . Welke CVE, boeiuh.

(het wordt pas relevant als je moet gaan inschatten of je anders/niet wilt mitigeren/patchen wegens impact/risico op verstoring ).
Tenzij je de luxe hebt om vendor patches te gebruiken waarbij je gebasseerd op de CVE code kan controleren in je terminal via grep of find of de patch ook daadwerkelijk draait op je clusters. Dan wordt het wel interesant om CVE nummers te weten.

Naast dat het van belang is omdat sommige restart van services vergen en je wel zeker wilt zijn dat het belangrijk genoeg is direct uit te voeren of het kan wachten tot volgende maintenance window.
31-12-2023, 09:25 door karma4
Door Anoniem:Kan net zo goed zoals ook aangehaald door de onderzoekers een vergeten onderdeel zijn uit een test fase. Zou niet de eerste keer in de geschiedenis zijn dat een hardware leverancier zo iets doormaakt.
Eens, ik had enkel neergezet dat het backdoor was.
Niet aan het wijzen door wie van wiet etc.

Als het echt een leverancier backdoor is dan verwacht je ook dat deze om de lockdown modus heen kan functioneren en . ....... Dat werken met de lockdown modus aan is echter nog niet vastgesteld.

Er is onbekende functionaliteit met onvermoede mogelijkheden. Kan door kopieren van delen van chip-ontwerpen komen.
Dan heb je hetzelfde gebeuren als kopiëren van hele softwarebibliotheken waar een deel van actief is en een deel niet.
Dan kom het de segmentatie in het systeem / programma ontwerp om risico's in kaart te krijgen en te mitigeren.

Heb ieder geval onze contacten bij ESET gevraagd er ook naar te laten kijken en risico voor onze bedrijven en klanten te laten beoordelen.
Die blijft lastig in het meest algemene concept heb je enkel een stukje gedeeld geheugen waarbij twee programma's zich niets van een afscherming aantrekken. Het lampje dat als datastroom bij fysiek gescheiden systemen of de vooruit uitgevoerde instructies in een processor zijn verder gezochte opties waar bewijs moeilijk is..
21-01-2024, 22:33 door Anoniem
Security by obscurity houdt het gevaar in, dat je snel in eigen voet kan schieten. Apple zal het gaatje wel even weten te fixen, maar vroeg of laat komt er een omzeilingstool & dan is het hek weer van de dam. Dit was niet zo'n goed ideetje van Apple - denk ik dan.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.