Eindhovense onderzoeker kraakt Thunderbolt 3-beveiliging

Een onderzoeker van de Technische Universiteit Eindhoven heeft Thunderspy gepresenteerd, een reeks kwetsbaarheden die de beveiliging van Thunderbolt 1, 2 en 3 doorbreekt. Voor misbruik is wel fysieke toegang en het openen van systemen vereist.

Volgens Björn Ruytenberg, student Computer Science and Engineering bij de TU/e, zijn alle systemen met Thunderbolt die tussen 2011 en 2020 zijn geleverd, kwetsbaar voor Thunderspy. Ook hebben de kwetsbaarheden misschien gevolgen voor op Thunderbolt 4 en usb 4, die gebaseerd zijn op Thunderbolt 3. Volgens Ruytenberg is het verhelpen van de kwetsbaarheden via software-updates niet mogelijk en zijn hardwarematige aanpassingen vereist. De kwetsbaarheden treffen met name Windows en Linux; de gevolgen voor macOS zijn beperkt. De onderzoeker heeft de gratis opensourcetool Spycheck voor Windows en Linux uitgebracht, waarmee gebruikers kunnen vaststellen of hun systeem kwetsbaar is.

Thunderspy kraakt de zogenoemde Security Levels die Intel bij Thunderbolt 2 introduceerde om eerdere zwaktes in de techniek te verhelpen. Security Levels biedt cryptografische authenticatie van vertrouwde Thunderbolt-apparaten om spoofing te voorkomen. Thunderspy omvat zeven kwetsbaarheden met betrekking tot Thunderbolt, waaronder problemen op het gebied van authenticatie van firmware en apparaten, en het gebrek aan Thunderbolt-beveiliging bij gebruik van Boot Camp om Windows op een Mac te draaien. Ruytenberg omschrijft enkele scenario's met proof-of-concepts om de kwetsbaarheden in de praktijk te kunnen uitbuiten.

Met Thunderspy kunnen kwaadwillenden willekeurige 'identiteiten' voor Thunderbolt-apparaten aanmaken en apparaten klonen die gebruikers al hebben goedgekeurd. Daarnaast heeft de onderzoeker een Thunderbolt Controller Firmware Patcher ontwikkeld, waarmee de beveiliging van Thunderbolt is uit te schakelen zonder dat toegang tot het bios of besturingssysteem noodzakelijk is. Ten slotte is er de tool SPIblock om toekomstige firmware-updates te voorkomen en de uitschakeling van de Thunderbolt-beveiliging permanent te maken.

Om de kwetsbaarheden met succes uit te buiten, is wel fysieke toegang nodig tot de kwetsbare systemen. Dit scenario staat bekend als evil maid-aanval, waarbij bijvoorbeeld een laptop die in een hotelkamer is achtergelaten, door een aanvaller onder handen kan worden genomen. De aanvaller moet een systeem openschroeven om de firmware-image van het spi-flashgeheugen van een Thunderbolt-hostcontroller te kunnen bemachtigen. Een systeem kan hierbij in slaapstand blijven en er hoeft ook geen login omzeild te worden.

Systemen met geactiveerde Kernel DMA Protection zijn deels beveiligd tegen Thunderspy. In de praktijk zijn dat enkele systemen die vanaf 2019 zijn geleverd. Ruytenberg noemt de HP EliteBook en ZBook van 2019 en later, de Lenovo ThinkPad P53, X1 Carbon van 2019 en later, en de Lenovo Yoga C940 met Intel Ice Lake-processors. Gebruikers die willen voorkomen dat hun systeem vatbaar is voor Thunderspy, krijgen het advies Thunderbolt in het bios uit te schakelen. Hoe dan ook adviseert de onderzoeker systemen niet in slaapstand onbeheerd achter te laten en alleen vertrouwde Thunderbolt-accessoires aan te sluiten. Bij het afsluiten van het systeem of in hibernation zijn de door hem ontwikkelde tools niet te gebruiken.

Ruytenberg heeft Intel in februari en maart van de verschillende kwetsbaarheden op de hoogte gebracht. De chipfabrikant zou hierna slechts een beperkt aantal partners hebben ingelicht. De onderzoeker omschrijft zijn bevindingen in een document met de titel Breaking Thunderbolt Protocol Security: Vulnerability Report. Tijdens de Black Hat-conferentie later dit jaar presenteert hij meer details. Hij bouwt met zijn onderzoek voort op de Thunderclap-aanval, die een jaar geleden werd onthuld.

Reacties (78)

Het NCSC heeft inmiddels ook gereageerd.

Ik ben benieuwd of de Thunderbold standaard in de toekomst updates gaat krijgen, mede door dit soort onderzoeken. Hierbij moet ik ook denken aan uitspraken van een Microsoft engineer: https://www.theverge.com/...security-concerns-comment

“No Surface device has Thunderbolt. Why not? Because that’s a direct memory access port,” explains the Microsoft employee. “If you have a well prepared stick that you can put into the direct memory access port, then you can access the full device in memory and all data that’s stored in memory. We don’t believe, at this moment, that Thunderbolt can deliver the security that’s really needed from the devices.”

[Reactie gewijzigd door Tomino op 11 mei 2020 09:38]

Ik verwacht meer resultaat van Full-Memory Encryption. AMD en Intel hebben sinds kort de mogelijkheid om het RAM te encrypten, met zelfs per-VM keys. Dan kan Thunderbolt wel toegang hebben tot het geheugen, maar zonder de CPU sleutel is dat irrelevant.

Hoewel het helpt, zal dat geen heilige graal zijn. Door te monitoren welk stukje RAM op welke manier gelezen of geschreven wordt, zullen de meeste side channel attacks in de praktijk goed te doen zijn vermoed ik. Je hebt niet direct toegang tot het geheugen maar een kleine dongel even in de laptop laten zitten terwijl hij uit sleep komt zal vermoedelijk al een hele hoop informatie prijsgeven. Op die manier hoeft er maar een kleine implementatiefout te zijn om de sleutel te lekken.

Processorfeatures zoals memory encryption zouden geen oplossing moeten zijn voor gevaarlijke protocollen. Beide kunnen elkaar versterken, maar je kunt de een niet zomaar vervangen met de ander omdat zelfs perfecte versleutelingsschema's in de praktijk implementatiefouten bevatten (en omdat hardware niet zo makkelijk te patchen is).

DMA geeft je lees- en schrijfrechten op geheugen, maar nog niet de mogelijkheid om te monitoren wat de CPU met het geheugen doet. Je hebt niet de bandbreedte om elke seconde alle geheugen in te lezen en te vegelijken met de snapshot van een seconde geleden.

Het gebruikte algoritme is waarschijnlijk AES of iets vergelijkbaar moderns, dus ook een known-plaintext aanval helpt niet om de sleutel te vinden. Dus ja, bij het uit sleep komen heb je inderdaad meer informatie beschikbaar voor je aanval, maar moderne crypto is ontworpen om ook daartegen veilig te zijn.

Je kunt wel degelijk RAM monitoren omdat het bepaalde patronen vertoont. Dit zal niet direct zijn, maar met een paar minuten zul je als het goed is toch moeten kunnen vinden in welk gedeelte van het fysieke geheugen de kernel draait, en een paar minuten valt makkelijk onder het evil maid scenario.

AES en vrienden zijn inderdaad met moderne implementaties veilig tegen known-plaintext attacks maar in de praktijk bevatten een hele hoop chips kwetsbaarheden voor side channel attacks. Timingsverschillen tussen de schrijfpatronen van bepaalde geïdentificeerde+gepollde geheugenblokken bijvoorbeeld.

Al het geheugen door variabele AES-versleuteling gooien voegt bijvoorbeeld ook latency en bottlenecks toe, niet enorm maar toch genoeg om een impact te hebben. We zien nu al dat NVMe-drives toch met processor-bottlenecks komen te zitten als je ze versleutelt vanwege de enorme bandbreedte die ze gebruiken, en RAM is vaak nog sneller. Om deze beveiliging in te bouwen zullen AMD en Intel dus wat trucs moeten uitvoeren om de snelheid te verhogen, en daar bevindt zich het gevaar voor de versleuteling.

Een alternatief is om versleuteling optioneel te maken, maar dan zie je het alleen terug in datacenters want consumenten zetten graag alles uit dat hun laptop trager maakt (zie alle "registerschoonmakers" voor het bewijs daarvoor).

Ook moet je óf de sleutel ergens delen óf een stuk onversleuteld geheugen behouden wil je normale DMA voor SSD's en videokaarten ondersteunen. Dit kan al genoeg zijn om kwetsbaarheden te misbruiken (zoals men bij Android aangetoond heeft lijken weinig ontwikkelaars zich te verdedigen tegen ingebouwde. Asymmetrische cryptografie is te langzaam om te gebruiken voor het uitwisselen van geheugen, dus ergens moet je de symmetrische sleutel uitwisselen wil je je geheugen helemaal versleuteld hebben.

Een pure mapping van ciphertext naar plaintext zal je inderdaad niet de sleutel geven, maar identificeren van blokken geheugen stelt je wel in staat een hele hoop andere dingen te doen die het zelfde resultaat kunnen hebben.

Kun je die claim ook onderbouwen, dat het in minuten kan?

Je Thunderbolt DMA access kan je laten zien dat sommige pagina's in fysiek RAM niet wijzigen. Dan weet je niet of het code is of veelgebruikte statische data, kernel of usermode.

Van andere data weet je alleen dat die veranderd is tussen je twee lees-cycli. Maar 16 GB geheugen heeft 4 miljoen pagina's van 4 kB elk. Je weet niet eens welke pagina in gebruik is! Je moet dus al die 4 miljoen pagina's kopieren en regelmatig uitlezen. Met de maximale Thunderbolt3 snelheid van 5 GB/s is dat dus elke 3 seconde. Dan heb je dus de timing-resolutie voor je side-channel attack. "Ergens in de afgelopen 3 seconde is deze pagina veranderd, en ik weet niet waarom.". Het zou kunnen zijn dat het virtuele geheugen naar disk geswapt is, of de user heeft een password ingetypt, de patronen zijn niet te onderscheiden.


Voor DMA heb je inderdaad een stuk onversleuteld geheugen nodig. Dat wil zeggen: geheugen waar de CPU de key niet heeft. Als je DMA vanaf een disk doet, en de data op disk is encrypted, dan heeft het OS de sleutel, niet de CPU. De disk-sleutel van het OS staat uiteraard weer in versleuteld RAM.

Patronen herkennen naar dingen als counters zou te doen moeten zijn. Windows doet ASLR maar over het algemeen niet binnen een proces, vooral bij het inladen van de call table, dus structs, classes, en lijsten daarvan zullen snel in dezelfde page worden geallocceerd. Bepaald kernelgeheugen wordt ook niet naar de page file geschreven dus daar kan zo'n tool zich op focussen.

Je zult niet het hele geheugen in een keer kunnen leegtrekken maar dat hoeft ook niet. Je hoeft alleen maar blok voor blok te analyseren of een blok wel of niet relevant is. Dat hoeft niet per page, maar kan wel incrementeel per 50MB voor 100 updates per seconde. Verder is er nog een bepaalde structuur hoe fysiek geheugen wordt ingedeeld, dus er is nog het een en ander te optimaliseren om eerst de meest waarschijnlijke blokken te proberen.

Afhankelijk van hoe dat verloopt zul je enkele seconden tot enkele uren bezig zijn om de juiste blokken te vinden. Vanaf daar begint de daadwerkelijke aanval en hoe goed dat verloopt is natuurlijk afhankelijk van de implementatiefouten die ongetwijfeld met een paar jaar de kop op steken.

Het DMA-verhaal is redelijk veilig maar alleen als de schijf ook goed versleuteld is. Bitlocker kan worden gepauzeerd en dit gebeurt voor sommige updates voor stabiliteit of iets dergelijks. Ik heb zelfs van iemand gehoord dat zijn laptop Bitlocker na een foute update niet meer automatisch inschakelde, waarna dus alle gewijzigde bestanden stiekem onversleuteld waren. Voor leken (lees: 95% van de belangrijke mensen) is dat natuurlijk al snel een risico, want die weten ook niet wanneer Bitlocker aan staat. Niet dat veel mensen überhaupt snappen dat encryptie nodig is, ik heb meermaals mensen geholpen met een account waarvan ze het wachtwoord niet meer wisten (en geen encryptie hadden aan staan) die best wel geschrokken waren van wat je kan met een Kon Boot USB stick en 30 seconden werk.

Daarnaast heb je nog het probleem dat je WiFi-kaart en je grafische kaart ook encryptie moeten kunnen doen, wat al een stuk lastiger is. Vereisen dat die apparatuur dat ondersteunt zou alle PCIe-devices incompatible maken vanaf het moment dat die memory encryption aan staat. Het zal nog jaren duren voordat ieder bedrijf en iedere consument zo'n standaard in huis brengen, als het ooit gebeurt.

Per VM geheugen encrypten is daarentegen wel een bruikbare feature, omdat de host de daadwerkelijke hardware IO doet en op die manier een VM escape niet direct iets kan met het geheugen van een andere VM.

Ik denk dat hardware encryption kan helpen dit soort aanvallen gedeeltelijk te mitigeren, maar voor de volledige bescherming zal men toch op protocolniveau/hardwareniveau het onderliggende probleem oplossen.

Hoe wil je een counter van 4 of 8 bytes herkennen, als je met 3 seconde resolutie kijkt naar een 4kB page? Uiteraard is de encryptie niet op byte-nivo. Dat is een basis-beginsel van encryptie. Je kunt aan de wijziging in een blok niet eens zien welke source bits veranderd zijn, laat staan hoe.

ASLR is niet eens relevant. Zonder ASLR kun je een known-plaintext aanval proberen, maar moderne crypto is ook daartegen bestand.

Het feit dat bepaalde pagina's niet naar swap worden weggeschreven is waar, maar nogmaals: hoe herken je dat ? Over Thunderbolt kun je niet zien wat de NVMe controller doet.

Kortom, je aanval faalt al in stap 1, het lokaliseren van interessante doelen. Het enige wat je kunt onderscheiden zijn fysieke pagina's die gelijkgebleven zijn van fysieke pagina's die zijn veranderd. Uit die ene bit aan informatie kun je geen reden van verandering afleiden.

AES werkt niet op 4kB pagina's maar per block; voor RAM zal ECB performancewinst opleveren omdat het makkelijk te paralleliseren is. Sterker nog, daarmee kun je on demand blokken geheugen decrypten in plaats van hele pages.

In dat geval zijn wijzigingen zichtbaar per blok (128, 192 of 256 bits / 16, 24 of 32 bytes). Met die granulariteit kun je wel degelijk patronen gaan vinden.

Dit is natuurlijk op te lossen door enige andere AES-modus toe te passen, maar dat betekent dat de page serieel in plaats van parallel verwerkt moet worden. Op die manier kun je maar 1 block size aan geheugen inladen per AES-versnelde core, wat toch performanceverlies zal opleveren.

Op 5GB/s kun je een 4kB page uitlezen in 0,0008 oftewel 1250x per seconde (latency daargelaten); die 3 seconden heb je nodig om het hele geheugen te dumpen.

Je hebt gelijk als de geheugenencryptiemodule geen gebruik maakt van ECB. Intel's versie lijkt te werken in XTS modus, dus zou veilig moeten zijn, maar over AMD kan ik alleen vinden dat ze "AES 128 encryption" gebruiken.

Ik noemde ASLR omdat de aanval die ik beschrijf niet mogelijk is als het OS altijd een random plek in zijn applicatiegeheugen kiest voor elke variabele. Dit gaat ten koste van wat caching, maar maakt het volledig onvoorspelbaar waar bepaalde patronen voorkomen in RAM. In de versie die geïmplementeerd wordt is praktisch alleen de base image op een random locatie gezet in de virtuele 64-bit geheugenruimte, wat al genoeg is om brute-force binnen applicaties onpraktisch/onmogelijk te maken.

Ah, vandaar dat de Surface ook geen PCIe heeft...
https://en.wikipedia.org/wiki/Direct_memory_access#PCI

Zonder gekheid; moderne systemen met TB3 hebben als 't goed is 'By Default' DMA-protection aan staan in BIOS (als ook omschreven door researcher). Daarbij hebben beter beveiligde systemen 'BIOS Settings Protection' aan staan, waardoor externe tool SPI niet kan beinvloeden.

EDIT: Link

[Reactie gewijzigd door shufflez op 11 mei 2020 12:43]

pci-e is geen toegankelijke poort voor de meeste gebruikers.

daarnaast, is deze beveiligingstool juist om die hele bios beveiliging te omzeilen tenzij je thunderbolt 3 volledig uitschakelt via de bios. en de SPI gaat niet over de bios zelf, maar over de thunderbolt chip die geupdate wordt met kwaadaardige firmware en daarna niet meer naar SPI luisterd. dat is echt wat anders als je bios.

Ik snap overigens wat je niet bedoelt met "DMA-protection aan staan in de bios". zelf heb ik dit nog nooit gezien maar misschien is dat iets van meer enterprise producten. wel ken ik het princiepe van "Security levels" in de bios bij thunderbolt hosts, maar volgens mij maakt dat geen snars uit juist omdat deze exploit de thunderbolt controller overneemt. die thunderbolt controller zit of direct op de CPU zelf en heeft dus ook gewoon DMA, of hij zit op het moederbord aangesloten op de PCH. Of de PCH via de bios de thunderbolt chip can isoleren van andere PCI-E apparaten doormiddel van bios instellingen weet ik niet, laat staan of dat geimplementeerd is.

De SPI-header waarop onderzoeker de FW laad ook niet echt toch?
Er is hardware-toegang nodig, dan heb je ook toegang tot PCIe.
Het comment mbt PCIe ging me vooral om 't 'security' argument om geen TB3 toe te voegen aan Surface.

Als je de BIOS beveiliging met SPI/ISP programmer kan omzeilen mag je dat m.i. geen beveiliging noemen. Op zijn minst moet BIOS haar eigen code valideren en liever BIOS *ook* de FW van kritieke componenten. Voordat de code uitgevoerd wordt door CPU en onafhankelijk van software-agent dan wel te verstaan.

In mijn BIOS staat "DMA Protection" standaard aan, met de uitleg

When checked, enables DMA redirection using IOMMU for enhanced security. NOTE: Requires Legacy Support disabled and VTd enabled.

Bij mijn weten zijn er geen CPU's met ingebouwde TB-controller, en momenteel ook nog geen chipsets. Dus idd aparte controller op PCH. Volgens mij zit er vergelijkbare controller in het dockingstation dat ik gebruik (Alpine of Titan Ridge wil ik van af zijn).

Geen idee, ik weet niet of een thunderbolt controller te flashen is via de poort zelf,

het is onmogelijk om de bios de FW van andere componenten te laten controleren. dan ben je als moederbord maker afhankelijk van letterlijk elk randcomponent dat geupdate kan worden voor je updates, denk aan dingen als de wifi chip en andere pci-e kaarten. en IOMMU is een soort sandboxxing maar dat hangt dan nogsteeds af van wat er in die IOMMU groep zit. voor hetzelfde geld zit alles in dezelfde IOMMU groep op je moederbord, dan heb je er niet zoveel aan. twee groepen is al beter. maar het liefst heb je alles in een eigen groep, maar dat zie je echt zelden.

Overigens worden thunderbolt 3 chips op cpu's ingebouwt, intel wil al langer naar een SoC architectuur voor hun mobiele platform.
https://fuse.wikichip.org...hunderbolt-3-integration/

Daarnaast gaat zover ik weet PCI-e van thunderbolt vaak VIA de PCH, niet ingebouwt in de PCH. de PCH bevat vervolgens een PCI-e root complex, maar zover ik weet kan je daar geen regels maken voor toegankelijkheid tot verschillende stukken geheugen en schakelt die direct door op de rest van de PCI-E apparaten.

In ieder geval niet in deze kwetsbaarheid, dus je argument "geen toegankelijke poort voor meeste gebruikers" gaat niet op. Lijkt me dat de onderzoeker toch wel via de externe poort de FW had geflasht als dat kon Dat had nog grotere nieuws/hype waarde gehad.

Het is zeker niet onmogelijk om BIOS andere FW te laten verifieren. Waarom zou dat onmogelijk zijn? BIOS verzorgt de eerste communicatie met die componenten en hun FW, derhalve kan deze een validatie doen. Al is het een simpele MD5 check. Moderne BIOS'en zijn zowat volledig OS.

In geval van laptops/desktops van de 3 grote fabrikanten zijn het vrijwel altijd relatief beperkte hoeveelheid samenstellingen en toeleveranciers. Broadcom/Realtek/Intel voor Wifi bijv, Connexant/Realtek voor audio, Synaptics voor touchpad en Intel/AMD voor chipset FW.
Die leveranciers zullen een (volgens hen) stabiele versie van FW aanleveren, welke je vervolgens eenvoudig kan valideren als OEM. Daarmee beveilig je overigens niet tegen slechte FW (je kan immers alleen valideren wat jouw toeleveranciers 'goed genoeg' achtten), maar wel tegen externe modificatie.

Je gaat misschien uit van een zelf gebouwd/samengesteld systeem, daar kan je als mobo-fabrikant met BIOS weinig doen qua peripherals gezien de miljoenen (miljarden?) mogelijke combinaties. Maar iig de on-board FW kan je wel degelijk checken.

Vwb IOMMU; ja en nee. Alle losse devices connecten naar dezelfde MMU, welke na onderhandeling over beschermingsdomein (hoe moderne systemen meerdere 'groepen' maken) door DMAR's (virtuele) address space laten toewijzen. Ik weet niet wat voor systemen jij gezien hebt, maar ik ziet echt heel vaak dat vrijwel alle devices in eigen IOMMU groep zitten.
for a in /sys/kernel/iommu_groups/*; do find $a -type l; done | sort --version-sort

Maar ongeacht of de PCI devices in geisoleerde of gecombineerde groepen zitten (PCIe peer-to-peer wordt beveiligd dmv ACS), gaat het in geval de hier benoemde kwetsbaarheid over DMA; om toegang te krijgen tot de address spaces, en die zijn per definitie uniek per device en 'variabel'. waardoor het dus erg lastig wordt geheugen uit te lezen (zie ook dialoog Gert en MSalters hierboven). Er vanuitgaande dat de ACS én IOMMU goed ontworpen en bug-vrij zijn Je kan vast met bepaalde side-channel wel eea afleiden, en daar is vast een slimme onderzoeker mee bezig.

Mooi om te weten dat sinds Icelake nu TB3 geintegreerd is, maar dat is dus erg recent.
Het artikel waaraan je refereert meldt zelfs hoe kort geleden dat is

Ik weet niet beter dat Thunderbolt PCIe over PCH's eigen 'PCIe kanaal', dwz (OPI) DMI gaat (of ging, iig igv losse controller). Deze is met CPU's PCIe root complex verbonden. Daar waar ook de overige PCIe over eigen kanalen met CPU communiceren (via PCH zou extreem inefficient zijn) en ACS het peer-to-peer gedrag onder controle probeert te houden .

EDIT: IOMMU command

[Reactie gewijzigd door shufflez op 13 mei 2020 12:33]

Het is zeker niet onmogelijk om BIOS andere FW te laten verifieren. Waarom zou dat onmogelijk zijn? BIOS verzorgt de eerste communicatie met die componenten en hun FW, derhalve kan deze een validatie doen. Al is het een simpele MD5 check. Moderne BIOS'en zijn zowat volledig OS.

Omdat je dan md5 checksums gaat moeten whitelisten. wat doe je als het moederbord niet meer geupdate wordt maar je een nieuwe wifi kaart erin stopt? je kan dan dus alleen uitbreidingen kopen die de fabrikant van je moederbord heeft geverifieerd.

En thanks voor de andere info! dat wist ik nog niet!

[Reactie gewijzigd door t link op 13 mei 2020 15:35]

Je hebt helemaal gelijk, je kan onmogelijk alle randapparatuur valideren, zeker 'user replaceable' componenten niet.
Maar alle kleine beetjes helpen, iig componenten waar OEM's wel controle over hebben
Weinig tot niets kan 100% veiligheid claimen/garanderen.
Zelfs je desktop in betonnen bak op de zeebodem zou opgedoken kunnen worden

Mjah firewire en andere bussen voor insteekkaarten waren ook zo'n succes met DMA issues.
Ergens valt het hier voor als nog mee omdat je kennelijk de host-controller moet flashen.

Wat dat betreft blijft zoveel mogelijk "periphal-hygiene" toch verstandig, ook bij bijvoorbeeld USB devices.
En geen slaapstand (in combinatie met full disk encryptie) zou ook een overweging kunnen zijn, meeste OS'en starten tegenwoordig toch aardig rap op.

Beetje een loze uitspraak. Je hebt immers fysieke toegang tot de device nodig. Mensen die met een laptop/tablet van €2500 rondlopen, die houden em heel goed bij zich. Los daarvan is de software (ook als het Linux is) veel makkelijker om de tuin te leiden dan de hardware, en is ook veel interessanter.

Het punt is dat de markt vraagt om TB3-poorten en Microsoft ze niet op hun devices zet. Wat daar de reden voor is, weet ik niet maar security is NIET de reden. Ze kunnen immers ook een switch in het UEFI maken om de TB3-functie uit te zetten en alleen USB-C over te houden, maar dat doen ze ook niet.

Als je access hebt tot een toestel, dan is het meestal al foute boel.
Natuurlijk niet voor jan met de pet, maar wel voor staats-gesubsidieerde instanties of multinationals.

De kwetsbaarheden treffen met name Windows en Linux; de gevolgen voor macOS zijn beperkt

Kan iemand uitleggen wat Apple zo drastisch anders doet?

Uit het onderzoek:

MacOS:Regarding Thunderbolt security, MacOS employs (i) an Apple-curated whitelist in place of Security Levels [7], and (ii) IOMMU virtual-ization when hardware and driver support is available [1][3]. Vulnerabili-ties2–3 enable bypassing the first protection measure, and fully compro-mising authenticity of Thunderbolt device metadata in MacOS “SystemInformation”. However, the second protection measure remains function-ing and hence prevents any further impact on victim system security viaDMA. The system becomes vulnerable to attacks similar to BadUSB [10].Therefore, MacOS is partially affected

Ah en voor IOMMU heb je inderdaad hardware nodig. Verklaart een hoop! En ook waarom het niet werkt in Bootcamp, omdat daar die IOMMU groepen niet gebruikt worden.

IOMMU (wat Apple doet) is sinds Intel's 2019 processoren ook voor andere platformen (pag 36) beschikbaar, mits ondersteund door BIOS en VTd ingeschakeld.

Apple lijmt de boel dusdanig vast dat je het systeem heel moeilijk kunt openschroeven, wat vereist is voor het uitvoeren van deze hack.

(Niet serieus bedoeld, maar het is wel waar. )

Volgens Ruytenberg is het verhelpen van de kwetsbaarheden via software-updates niet mogelijk en zijn hardwarematige aanpassingen vereist.

en

De kwetsbaarheden treffen met name Windows en Linux; de gevolgen voor macOS zijn beperkt.

Dit spreekt elkaar toch tegen? Als het ene OS er meer/minder last van heeft dan het andere, suggereert dit m.i. dat het probleem softwarematig in ieder geval deels op te lossen is.

Apple heeft de security van recente OSX versies "verbeterd", ze hebben bv SIPS (System Integrity Protection Security) geïntroduceerd, daarmee wordt een belangrijk gedeelte van OSX "read only" gemaakt, mogelijk dat ze met bv SIPS dit soort security problemen gedeeltelijk hebben kunnen ondervangen.

Door SIPS is ook verificatie en reparatie van OSX permissies in OSX diskutility "verdwenen"

[Reactie gewijzigd door obimk1 op 11 mei 2020 10:12]

Het gevaar van DMA-aanvallen zoals bij Thunderbolt het probleem zijn is dat het besturingssysteem de geheugentoegang nooit te zien krijgen. MacOS is read-only volgens de kernel maar toch wordt de inhoud van het RAM aangepast.

Hoewel SIPS ongetwijfeld een stap voorwaarts in kernelbeveiliging is, zal het bij DMA-aanvallen niet helpen.

Omdat Apple veel van Thunderbolt gebruik maakt, hebben ze overduidelijk meer moeite gestoken in zorgen dat al hun hardware goede IOMMU-ondersteuning heeft. Waarom dit op Windows niet werkt weet ik eigenlijk niet, aangezien Windows hier normaal wel mee om zou kunnen gaan, maar dat kan een driver-issue zijn (Apple heeft om hele praktische voor hun redenen een hele hoop drivers voor Windows niet of beperkt geïmplementeerd, maar dat is iets dat je zou moeten weten als je Apple koopt).

Het is maar goed dat mijn laptop geen Thunderbolt doet want mijn oude Haswell heeft geen IOMMU support

Volgens HLK heeft Windows wel ondersteuning voor IOMMU: https://docs.microsoft.co...6d-4ab4-9d7f-88b558bf4420

Maar zoals je zegt kan het zijn dat fabrikanten waar Microsoft (deels) van afhankelijk is het niet ondersteunen. In ieder geval hebben ze zelf gekozen voor de goedkopere/veiliger oplossing zonder TB3

Dat zou een reden kunnen zijn waarom macOS minder vatbaar is; maar dat zou ook, zoals ik schrijf, impliceren dat (in ieder geval een deel van) de kwetsbaarheden WEL softwarematig (in het OS) kunnen worden opgelost toch?

Mogelijk, maar opzich een interessante "benadering", als je bepaalde gedeelten van je OS "read only" maakt, en voor deze attack moet je toch eerst fysieke toegang tot een PC hebben, en "over the air" of netwerk attacks zijn nog? steeds niet mogelijk.

Maar het gaat dus niet perse om OSX versies, aangezien ze aangeven dat het geen softwarematige update kan zijn. Het gaat dus echt om dat de hardware iets anders doet of anders geconfigureerd is lijkt me, anders kan ook Windows of Linux softwarematig worden aangepast.

Inderdaad, SIPS is mogelijk sinds 2015 en met APFS (2017?) is het iets veiliger geworden.

Ik denk dat er een soort "low level" redesign voor LINUX en Windows OS'en "nodig" is om die OS'en "read only" te maken.

Ja misschien moeten we lezen "Apple hardware". Het is en blijft Tweakers...

Edit: Die website draait er ook echt gigantisch omheen. Een deel ligt aan de MacOS kernel, een deel is ook in andere moderne laptops opgelost.

Dit is echt weer zo'n typische hype kwetsbaarheid. Mooie website, fancy naam, groot merk onder de bus gooien. Maar dan wel van die dubbelzinnige statements, onduidelijke teksten als "All the attacker needs is 5 minutes alone with the computer, a screwdriver, and some easily portable hardware". Zo van ja, stop er dan gewoon een keylogger in ofzo.

[Reactie gewijzigd door MiesvanderLippe op 11 mei 2020 09:52]

Tja, tweakers lijkt idd niet echt pro-Apple te zijn, om een of andere reden is het lastig uit te leggen dat je meer betaald voor een stuk hardware dan alleen de som der kosten van de fysieke onderdelen.

In praktijk is de situatie van Apple een stuk overzichtelijker omdat ze én de hardware én de software bouwen waardoor het veel beter op elkaar aan te sluiten is.

Daarom is het voor Microsoft veel moeilijker om het veilig te krijgen puur en alleen omdat het scala aan hardware veel breeder is en waarschijnlijk ook omdat hardware fabrikanten ook creatief zijn om hier en daar de kantjes er vanaf te lopen m.b.t. standaarden ondersteuning om een lagere prijs te kunnen realiseren.

Olaf legt het in zijn reactie op mijn comment wel uit. Ik vond/vind het jammer dat het niet n het originele artikel uitgelegd wordt.

Het is hardware omdat het systeem ondersteuning moet bieden voor IOMMU en het is software omdat Apple in haar kernel gebruik maakt van IOMMU om de devices te isoleren ook met DMA.

Ik zou zo zeggen: Follow the money.

Er zijn meerdere flaws. Sommige zijn makkelijker op te lossen.

Dit spreekt elkaar toch tegen? Als het ene OS er meer/minder last van heeft dan het andere, suggereert dit m.i. dat het probleem softwarematig in ieder geval deels op te lossen is.

Nee dat suggereert dat Apple anders heeft geabstraheerd of bepaalde features (nog) niet ontsluit. Het onderliggende probleem is hardwarematig en dus alleen verborgen cq. gemaskeerd.

Wat je stelt is dat morfine een goede en volledige behandeling is voor een acute blindedarmontsteking, want als je er weinig tot niets van voelt ben je genezen. Zo werkt het niet.

Wat je stelt is dat morfine een goede en volledige behandeling is voor een acute blindedarmontsteking

Dat stel ik juist niet

deels op te lossen

[Reactie gewijzigd door stefanass op 11 mei 2020 15:38]

De aanvaller moet een systeem openschroeven om de firmware-image van het spi-flashgeheugen van een Thunderbolt-hostcontroller te kunnen bemachtigen.

Gebruikers die willen voorkomen dat hun systeem vatbaar is voor Thunderspy, krijgen het advies Thunderbolt in het bios uit te schakelen.

Dit lijkt nutteloos omdat met het direct bewerken van de SPI geheugenchip Thunderbolt aangezet kan worden. Het heeft echter wel nut. De aanval gaat uit van een al draaiend systeem. Als een systeem is opgestart en daarna pas Thunderbolt op de SPI geheugenchip wordt ingeschakeld, dan wordt Thunderbolt pas bij de volgende reboot daadwerkelijk ingeschakeld. Het systeem is dan niet meteen kwetsbaar.

Dus een betere mitigatie met bestaande middelen op alle getroffen systemen bestaat uit de volgende maatregelen:

• Gebruik een manier van opstarten dat een vertrouwde staat van het systeem meeneemt in het beschikbaar stellen van de systeemschijf, zoals BitLocker. Dit beschermt tegen ongeautoriseerde wijzigingen in de SPI geheugenchip.
• Schakel Thunderbolt uit in de BIOS. Dit beschermt tegen DMA misbruik van een draaiend systeem.
• Gebruik geen suspend-to-RAM functionaliteit, maar enkel suspend-to-disk. Dit beschermt tegen aanvallen gericht op data in RAM van een systeem in rust (via DMA of anders).

[Reactie gewijzigd door The Zep Man op 11 mei 2020 10:05]

Veel eenvoudiger:
Spray gewoon wat 'plastic spray' over de chip heen.

Lof voor de onderzoeker, maar dit is wel het niveau van een veiligheidsdienst en niet meer van een vervelende collega of broertje/zusje.
Voor een paar tientjes heb je ook gewoon een draadloze keylogger die je tussen het toetsenbord & pc plaatst. Dat is voordeliger en waarschijnlijk ook nog sneller.

Het voorgestelde scenario (schoonmaakster in een hotel) geeft je misschien het idee dat een coating afdoende zal zijn

Het scenario waar je misschien beter aan kunt denken is een gestolen laptop met beveiligde data erop, of een spelconsole. Dus apparaten die je in je fysieke bezit hebt

Lof voor de onderzoeker, maar dit is wel het niveau van een veiligheidsdienst en niet meer van een vervelende collega of broertje/zusje.

Veel ernstige zero-days op dit niveau beginnen met een uiterst hypothetische aanval. MD5 en SHA1 werden stapsgewijs steeds meer uitgekleed door cryptologen tot het punt dat ze uiteindelijk compromised waren tot het punt dat een thuiscomputer binnen uren/dagen een collision kon genereren, dat maakte de eerste weaknesses die het van eeuwen naar tientallen jaren terugbrachten niet minder significant.

Ja, op dit moment is deze weakness nog niet echt praktisch exploitable. Nu is het wachten op een bijpassende weakness in een OS kernel, gecombineerd met een bug in een driver, die alle 3 afzonderlijk weinig nut hebben, maar tezamen een rootkit op je TB3 drive kunnen zetten vanuit userland.

Veel eenvoudiger:
Spray gewoon wat 'plastic spray' over de chip heen.

Succes om dat te doen met duizenden notebooks in een organisatie.

Voor misbruik is wel fysieke toegang en het openen van systemen vereist.

Een laptop die in beslag genomen is van een terrorist of van een pedo welke beschikt over thunderbolt 3 poort kan nu vrij simpel ontgrendeld worden, mits juiste kennis in huis gehaald wordt, lees naspelen van het filmpje.

Onder voorwaarde dat ie al aan staat. Met full disc encryption ben je gewoon alsnog nergens. Het is vrij eenvoudig in te stellen dat je laptop gewoon direct afsluit of zelfs zichzelf wist als ie dicht gaat.

Of een journalist of een politieke tegenstander.

De kwetsbaarheden treffen met name Windows en Linux; de gevolgen voor macOS zijn beperkt.

Dacht gelijk aan MacOS bij het lezen van de titel. Wist niet eens dat Thunderbolt veel gebruikt wordt buiten Mac om.

Maar ik ben blij dat de gevolgen voor mac’s beperkt zijn. In mijn geval dan...

Dat was ook mijn eerste gedachte. Misschien dat ik niet goed rondkijk maar ik ken geen enkele niet apple machine in mijn omgeving die thunderbolt gebruikt. Zelfs de enkeling met een apple machine gebruikt gewoon USB.

HP laptops maken veel gebruik van Thunderbolt 3 voor hun USB-C docks. Ook zijn er nog wel pc's met Thunderbolt 2 aansluiting (zelfde connector als mini displayport, maar dat wil natuurlijk niet zeggen dat elke pc met een mini displayport ook Thunderbolt 2 ondersteund).

Niet helemaal waar, dat moet zijn; HP laptops maken veel gebruik van Thunderbolt 3 voor hun Thunderbolt 3 docks Hun USB-C docks gebruiken USB3.1 voor data en USB-C Alt-mode voor beeld.
Bron: https://www8.hp.com/h2019...nt.aspx?docname=c04168358

Thunderbolt 3 is inderdaad wel al een tijdje standaard aanwezig op zakelijke HP notebooks.
Alleen zijn er (naast docking) voor meeste Windows-gebruikers niet zoveel scenarios waarop de doorvoersnelheid van TB3 nodig is. In de Mac-wereld met veel AV is TB3 randapparatuur 'gewoner'

[Reactie gewijzigd door shufflez op 11 mei 2020 21:03]

https://store.hp.com/Neth...d=2UK37AA&opt=ABB&sel=ACC
Deze gebruiken we waar ik werk, het heet inderdaad een Thunderbolt dock, maar het is wel USB-C.

Die gebruik ik ook. Deze lijkt er veel op, maar gebruikt dus geen Thunderbolt: https://store.hp.com/Neth...x?id=5TW10AA&opt=&sel=ACC

Ik reageerde op feit dat USB-C is niet (altijd) Thunderbolt is en vice versa.
USB-C is wel altijd USB2.0 en 5V 500mA, rest is 'aan de goden overgeleverd'

Veel succes om in 5 minuten mijn macbook Pro open te schroeven en de thunderbolt controller van nieuwe firmware te voorzien. Misschien iets voor een nieuwe James Bond.

Veel succes om in 5 minuten mijn macbook Pro open te schroeven en de thunderbolt controller van nieuwe firmware te voorzien. Misschien iets voor een nieuwe James Bond.

Ik ga gedownmod worden en dat vind ik best in dit geval, maar ik heb je comment even verbeterd. Ondanks dat heb ik zelf een hele boel Apple spul en ben ik er dik tevreden over, maar openschroefbaarheid en modificatiemogelijkheden bij alle Macbooks met TBT poorten is zo goed als nihil.

"You've been... Thunderspied!" klinkt dan toch niet zo heel spannend ten op zichte van het origineel...

[Reactie gewijzigd door CH4OS op 11 mei 2020 10:20]

Als het nodig is om de PC open te schroeven dan kan je neem ik aan ook gewoon een PCI Express-kaart of nieuwe SSD installeren...