Makers iPhone-spyware misbruikten onbekende hardwarefunctie Apple-chip
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.
Het meest voor de hand liggend is dan toch een zwakke schakel in het personeelsbestand van Apple denk ik.
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 .
...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?
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.
- 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
- 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
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.
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 .
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.
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 ?)
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 ?)
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
[..]
(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 ?)
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 ).
[..]
(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 ?)
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 ).
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.
Niet aan het wijzen door wie van wiet etc.
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.
Je bent niet ingelogd 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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
