ESET ontdekt mogelijk eerste UEFI-bootkit voor Linux

Onderzoekers van beveiligingsbedrijf ESET zeggen de eerste UEFI-bootkit voor Linux te hebben ontdekt. Bootkitty, zoals de malware heet, lijkt een rudimentair proof-of-concept, maar wel een die het mogelijk maakt om het bootproces van Ubuntu te infecteren, mits Secure Boot uit staat.

Onderzoekers van ESET hebben de bootkit gevonden in een sample dat naar VirusTotal werd geüpload. Het lijkt te gaan om een experimenteel proof-of-concept van een bootkit voor Linux, waarmee het meteen wel de eerste bootkit is voor dat besturingssysteem die in ieder geval doet wat een bootkit moet doen: kernelverificatie omzeilen en code op een systeem zetten.

ESET noemt de malware Bootkitty. Dat is overigens niet volledig aan ESET; de bootkit kan een ASCII-file laden die die naam uitschrijft. Het einddoel van de bootkit is om bepaalde binary's in te laden in een besturingssysteem en vervolgens malware in te laden, maar de onderzoekers zeggen dat ze daar geen specifieke aanwijzing voor hebben gezien.

Volgens ESET is Bootkitty nog erg rudimentair en bevat het veel bugs. De malware is zo gemaakt dat het bedoeld is om uiteindelijk Secure Boot te kunnen omzeilen. Bootkitty laadt voordat GRUB opstart en probeert meerdere GRUB-functionaliteiten over te nemen zodat verschillende integrity-verificaties van de kernel worden omzeild. De huidige versie die de ESET-onderzoekers vonden, kan dat nog niet. Die maakt gebruik van een self signed-certificaat, waardoor de malware niet om Secure Boot heen kan. Een andere beperking is volgens de onderzoekers dat de makers heel specifiek aangeven in de code welke functies de malware moet aanpassen, wat erop wijst dat de functionaliteit alleen op een beperkt aantal Ubuntu-releases werkt. Dat betekent volgens de onderzoekers ook dat de malware in de praktijk systemen eerder zal stukmaken dan overnemen.

Omdat Bootkitty nog niet goed werkt, vermoedt ESET dat de bootkit nog niet veel in de praktijk wordt ingezet. Het beveiligingsbedrijf suggereert dat aanvallers echter hun bestaande aanvalsmethodes, met bootkits voor Windows, proberen uit te breiden naar andere besturingssystemen.

Reacties (69)

[84hannes]

Wat houdt zo'n bootkit tegen om vanuit Grub te starten? Ik heb de indruk dat Grub gesigned is, waardoor Secure Boot alleen Grub kan controleren. Controleert Grub vervolgens of je een legitieme kernel start?

edit:
designedgesigned

[Reactie gewijzigd door 84hannes op 29 november 2024 10:00]

[GertMenkel]

Je UEFI firmware controleert de handtekening van de bootloader, de bootloader controleert de handtekening van je kernel en in een perfecte wereld ook het initramfs (bij gebrek aan full disk encryption). Als secure boot goed ingesteld staat, werkt deze bootkit dan ook niet.

Als je echter deze bootkit als eerste opstart, kan deze zich in het geheugen plaatsen en vervolgens Grub uitvoeren met de nodige modificaties om code te injecteren. Zo hoeven de malwaremakers geen drivers voor bestandssystemen mee te leveren of config files in te lezen om het OS zelf te laden. Wel moeten ze Grub in het geheugen aanpassen om niet hun geïnjecteerde code af te wijzen tijdens de verificatiechecks.

Grub kan niet voorkomen dat er mee geknoeid wordt als het niet direct door de firmware wordt opgestart. Zelfs als er allemaal moeilijke checks in gaan, is het een kwestie van If statements omzetten tijdens het laden om die verificatie te omzeilen.

Mocht deze bootkit een certificaat bemachtigen en daadwerkelijk booten, dan is het enige dat je nog kan beschermen tegen deze aanval een combinatie van een versleutelde schijf en gebruik van de TPM. De TPM kan namelijk ingesteld worden zijn sleutel alleen prijs te geven na een vaste reeks signalen/metingen (zoals die tijdens de initalisatie bepaald zijn) en deze op de juiste manier nabootsen is behoorlijk complex. Het is niet onmogelijk, maar een lastige stap om te overbruggen als je TPM alleen je schijfsleutel vrijgeeft als deze metingen in orde zijn.

Dit is ook waarom Bitlocker weiger zichzelf automatisch/met de normale PIN te ontgrendelen als je Windows start vanuit Grub, en je je herstelsleutel nodig hebt; de TPM slaat dicht omdat de signalen niet kloppen en de schijf blijft onbereikbaar.

Al met al is de bootkit momenteel behoorlijk nutteloos mits je secure boot aan laat (wat op de meeste apparaten prima werkt tegenwoordig) en is de malware sowieso nog niet af, maar in de toekomst wordt dat wellicht lastiger.

[B_FORCE]

Het is mij alleen nog niet helemaal duidelijk hoe praktisch een kwaadwillende dit op een PC zou kunnen krijgen en uitvoeren?

Zoals ik het nu begrijp kan dat enkel op een fysieke manier?

[GertMenkel]

Een programma met root/administratorrechten kan de .efi in de EFI-partitie plempen en de UEFI-variabelen aanpassen om hem de standaardbootloader te maken (een keer cp malware.efi /boot/esp/BOOT/grub/malware.efi en dan een keer efibootmgr aanroepen). Dan moet je dus wel een virus hebben dat al root-rechten heeft, of een systeem waar je EFI-partitie niet goed afgeschermd is.

Als je je afvraagt waarom je een bootkit zou injecteren als je toch al root hebt: op een systeem dat beveiligd is met SELinux kan het zijn dat zelfs een proces met root-rechten lang niet overal bij kan, en als je in de kernel zelf zit, is dat te omzeilen. Ook kan een proces dat als root op de achtergrond draait opvallen en gedetecteerd worden, en een in-kernel-virus is een stuk lastiger te vinden. Zo is root-toegang maar heel kort nodig en valt het dus ook minder op bij antivirussoftware.

Fysiek is ook een optie natuurlijk; de EFI-partitie is niet versleuteld. Alle "evil maid"-scenario's zijn van toepassing (hotelkamer, vliegveld, douanehokjes).

[B_FORCE]

Dan moet je dus wel een virus hebben dat al root-rechten heeft, of een systeem waar je EFI-partitie niet goed afgeschermd is

Dat komt dus er praktisch bijna op neer dat het alleen fysiek kan.

En fysiek moet je dan ook eerst door bv een bios-password heen.
Ik weet, die zijn ook de omzeilen, maar alles kost tijd en moeite.
Het beste kun je dan nog een laptop nemen zonder enige fysieke (USB) poorten.
(of die gewoon onklaar maken)

[MrFax]

Dit is dan ook niet meer als een proof-of-concept. Het betekent niet dat er ergens een of ander lek is. Als alles goed ingesteld staat, ben je in principe veilig, zolang de aanvaller geen fysieke toegang heeft tot het apparaat.

Wat wel kan is dat de encryptie van de signatures uiteindelijk eens gekraakt gaan worden, of de private key voor het signeren gelekt wordt. Of als er een lek zit in de bootloader zelf. Maar daar: heb je bootloader blocklists voor: https://uefi.org/revocationlistfile. Dit wordt bij elke Linux-distributie geupdatet en geschreven naar Secure Boot DBX schrijfbare ruimte op de SPI flash.

Er is wel een caveat: De DBX kan ook weer leeggetrokken worden door dbxtool. Als een aanvaller dus al toegang heeft tot je Linux-root, dan kan die in theorie een malifide DBX update doen om zo een geblokte lekke bootloader te activeren en zich daar in te schuilen. Maar ja, als je al toegang hebt tot de root...

[Reactie gewijzigd door MrFax op 29 november 2024 14:46]

[Nightan]

Mooie uitleg. Wat ik me wel afvraag is welke rol het certificaat hierin speelt. Als het self-signed is dan moet die root toch vertrouwd worden?

Ik begrijp dat de malware wellicht een rootcertificaat kan laten vertrouwen, maar om dat probleem op te lossen zijn er volgens mij attestations services. AMD en Intel bieden die opties aan zodat hun vertrouwt worden via remote kanalen

[GertMenkel]

Ja, aangezien het self-signed is gaat geen enkele normale bootloader dit vertrouwen, tenzij je secure boot natuurlijk helemaal hebt uitgezet.

Om zelf secure boot te beheren, heb je een heel stel eigen sleutels. Eentje is de belangrijkste sleutel, die een beetje dient als CA, met daaronder sleutels voor databases, updates, en bootloaders. Tooling als sb-sign genereren die allemaal voor je, maar je kunt ze ook zelf maken als je wilt. Je zet je eigen topsleutel in je moederbord en gebruikt die om een set vertrouwde sleutels toe te voegen (bijvoorbeeld die van Microsoft, of Red Hat, of Canonical). Daarna kan de bootloader worden geverifieerd en opgestart.

De wiki van Arch Linux heeft het stap voor stap uitgewerkt.

Remote attestation zou kunnen helpen om geïnfecteerde systemen te detecteren, maar voor zover ik weet werkt dat doorgaans samen met onder andere de TPM. Dan verlies je het verschil om een geïnfecteerd systeem te onderscheiden van een systeem dat van configuratie is veranderd (bijvoorbeeld vanwege een firmware-update). In een bedrijfscontext zul je die informatie wellicht hebben in je patch managementsysteem, maar als consument heb je er helaas niet veel aan.

[Alfa1970]

Omdat je dat niet wilt, je wilt volledige controle over alles, als je start vanuit grub, dan moet je voldoen aan alles wat grub al dan niet toestaat.
Als je eerder opstart heb je 100% controle over alles en kan je doen en laten wat je wilt.
Dat is het hele punt van eerder opstarten.
En je kan er donder op tegen zeggen dat er al tientallen varianten van dit stukje broddelwerk zijn die al veel verder zijn. Dit is een hele toevallige ontdekking, die waarschijnlijk is gelukt omdat het zulk broddelwerk is.

[84hannes]

als je start vanuit grub, dan moet je voldoen aan alles wat grub al dan niet toestaat.

Dat vermoedde ik, maar wat staat Grub dan allemaal niet toe? Uiteindelijk start Grub een kernel en zou de kernel alles moeten kunnen toch?

[Alfa1970]

Grub laad de kernel in het geheugen, initializeerd hardware en geheugen en start daarna de kernel op.
Maar diat is vrijwel alles wat Grub kan en doet.
Grub kan bijvoorbeeld geen data verzenden en/of ontvangen van het Internet.
En, door als eerste op te starten kan de bootkit bepalen wat Grub ziet aan hardware en geheugen.
De bootkit kan een deel van het geheugen afschermen van Grub en in het verlengede daarvan
van de kernel en dat voor eigen processen gebruiken.
En hoewel de kernel niets kan zien van wat de bootkit doet, kan het omgekeerde wel.
De bootkit kan bijvoorbeeld ook als man-in-the-middle fungeren voor netwerk verkeer.

[OruBLMsFrl]

Een competente bootkit is het meest gevaarlijke dat er maar bestaat. Onzichtbaar voor alle endpoint protection leest die je toetsaanslagen uit en je encryption keys en session tokens direct uit je geheugen. Dan is zo goed als alle security aan die kant van het verhaal game over...

[Alfa1970]

Inderdaad, een bootkit kan letterlijk alles binnen de fysieke beperkingen van een computer.
En doordat het als eerste opstart en niet "gevangen" zit binnen de beperkingen van de kernel van een OS, kan het zichzelf met het grootste gemak verbergen voor die kernel.
Je kan het bijna zien als een hypervisor waar bovenop je OS draait als een virtual machine.
De hypervisor kan doen en laten wat het wil, het OS kan alleen maar volgen wat de hypervisor voorschrijft.

[The Zep Man]

Wat houdt zo'n bootkit tegen om vanuit Grub te starten?

Waarom zou je malware afhankelijk maken van een enkele van de vele beschikbare bootloaders?

Ik heb de indruk dat Grub designed is, waardoor Secure Boot alleen Grub kan controleren. Controleert Grub vervolgens of je een legitieme kernel start?

Mits goed geconfigureerd, ja. Maar waarom zou je GRUB gebruiken om een computer veilig op te starten? Daarvoor gebruik je bij voorkeur een Unified Kernel Image (kernel, initrd, ucode en boot parameters geïntegreerd in een enkele EFI executable). Een stuk simpeler op te zetten en een kleiner aanvalsoppervlak. Al ben je afhankelijk van meerdere boot entries (=meerdere UKI's), dan configureer en kies je die direct in UEFI.

[Reactie gewijzigd door The Zep Man op 29 november 2024 09:34]

[MrFax]

GRUB wordt overal in elke distributie gebruikt om compatibiliteitsredenen. Wat jij zegt klopt, maar is door legacy niet de standaard. Toch is GRUB zelfs voor kritieke doeleinden veilig genoeg. Het support ook gewoon de laatste veiligheidsstandaarden in bootloaders.

Zolang RHEL het blijft gebruiken, dan zal de rest van de wereld het ook blijven gebruiken.

"Withstood the test of time" om zo maar even te zeggen.

[Reactie gewijzigd door MrFax op 29 november 2024 14:51]

[The Zep Man]

GRUB wordt overal in elke distributie gebruikt om compatibiliteitsredenen.

Onwaar. Zo gebruikt Pop!_OS bijvoorbeeld systemd-boot.

Het support ook gewoon de laatste veiligheidsstandaarden in bootloaders.

GRUB is bloat als je UEFI hebt. Des te minder onnodige code tijdens het opstarten, des te beter.

[Reactie gewijzigd door The Zep Man op 29 november 2024 16:18]

[MrFax]

Je hebt vast wel distributies die legacy niet ondersteunen. Maar bij Ubuntu, Debian, Fedora, OpenSUSE wordt vooralsnog gewoon GRUB gebruikt.

En om nou constant F11 te spammen om de boot menu te laten zien is ook niet voor iedereen. En niet elke UEFI implementatie werkt even goed op elk systeem.

Like I said: GRUB withstood the test of time.

[Reactie gewijzigd door MrFax op 29 november 2024 17:25]

[The Zep Man]

Je hebt vast wel distributies die legacy niet ondersteunen.

Zo blijf je discussie voeren zonder ergens heen te gaan.

[MrFax]

Mijn punt staat omdat als iets bestaat in een Linux-omgeving, het natuurlijk ook gebruikt gaat worden. Dat neemt niet weg dat er niks mis met GRUB is. Het wordt in RHEL gebruikt, en dus zelfs in de meest kritieke infrastructuur. Again "GRUB withstood the test of time". Het feit is dat het bijna onmogelijk is om GRUB niet werkend te krijgen op wat voor systeem dan ook.

Mijn hele punt *ging* over legacy (en over dat het ook gewoon veilig is), en dan maak jij ervan dat ik het fout heb omdat er ook distro's zijn die geen legacy ondersteunen? Tuurlijk bestaan die, maar dat gaat totaal niet tegen mijn argument in dat grub zo'n beetje overal nog steeds wordt gebruikt, juist om legacy te ondersteunen, en juist omdat "It Just Works".

Dat was mijn punt, ik snap nu niet hoe je dat nou helemaal hebt omgedraaid en er van wil maken dat ik "het" fout heb?

Het is ook een beetje passief-aggressief reageren zo. Zo laat je alleen maar lijken alsof je iets persoonlijks hebt tegen GRUB.

Maar ik kan net zo goed dat spelletje gaan spelen, om even heel kinderachtig te doen:
Wikipedia: Straw man (ik heb namelijk nooit gezegd *alle* distro's)

[Reactie gewijzigd door MrFax op 30 november 2024 00:55]

[The Zep Man]

(ik heb namelijk nooit gezegd *alle* distro's)

This you?

GRUB wordt overal in elke distributie gebruikt om compatibiliteitsredenen.

[Reactie gewijzigd door The Zep Man op 30 november 2024 09:17]

[MrFax]

Dat was een hyperbool, geen neergelegd feit. Dat lijkt me wel duidelijk denk ik?

Als je niet weet wat een hyperbool is:
Wikipedia: Hyperbool (stijlfiguur)
Een beetje taalbegrip mag je op Tweakers wel verwachten.

Daarnaast is de term "wordt overal en door iedereen gebruikt" een vrij bekende overdrijving. Dat betekent natuurlijk niet letterlijk iedereen.

Maar ik snap sowieso niet waarom je zo extreem passief aggresief reageert. Je vindt GRUB maak niks. Ik snap het. Betekent niet dat je ook gewoon op de inhoud kan reageren.

Wat een levenloze opmerkingen voor iemand met zoveel karma. Sorry hoor. Mag wel wat volwassenheid verwachten van zo iemand denk ik. Dit is gewoon echt heel kinderachtig.

En als laatste: je hebt mijn punt niet verweten, dus die staat.

[Reactie gewijzigd door MrFax op 30 november 2024 11:44]

[Crownable]

Waarom implementeren de meeste Linux distro's eigenlijk geen secure boot? Ubuntu is volgens mij 1 van de weinige die dat wel doet out of the box. Hier zie je, volgens mij, toch echt de voordelen om het wel te hebben.

[readefries]

Dat kan ook met andere disteo’s zoals RedHat, Debian en Arch

[RobertMe]

Keyword in de vraag van @Crownable lijkt mij dan ook "out of the box". Mijn Debian en Arch (en Manjaro) systemen doen dat zeker niet out of the box. (Of Ubuntu het out of the box doet bij een nieuwe installatie weet ik niet).

In ieder geval zal het de installatie mogelijk ook complexer maken, zeker bij dual boot. Aangezien de EFI dan vast weer opnieuw in setup mode gezet mort worden om de additionele keys te kunnen enrollen. Daarnaast lijkt/leek secure boot onder Linux ook "niet" nodig te zijn vanuit security perspectief. Omdat er dus nog geen malware was die zo vroeg op het boot proces inhaakte.

Enige reden waarom secure boot leuk kan zijn onder Linux buiten malware buiten de deur houden is als je full disk encryption gebruikt. Als je dan wilt unlocken op basis van de TPM is secure boot een vereiste. Waarbij de opslag in de TPM ook gekoppeld is aan de signing key. Dus EFI executables die met een andere key ondertekend zijn kunnen dan ook niet de encryptie sleutel uitlezen. Dit is een "oplossing" die ik nu een goed half jaar gebruik op mijn werk laptop, en dat werkt gewoon prima. Onder Manjaro, maar dan wel volledig zelf / handmatig geïnstalleerd (dus op CLI partitioneren, formatteren, packages laten installeren op de juiste partitie, bootloader installeren, ...).

[84hannes]

Aangezien de EFI dan vast weer opnieuw in setup mode gezet mort worden om de additionele keys te kunnen enrollen.

Ubuntu heeft geen additionele keys nodig, omdat ze hun bootloader laten signen door... Microsoft.

In order to boot on the widest range of systems, Ubuntu uses the following chain of trust:

• Microsoft signs Canonical's 'shim' 1st stage bootloader with their 'Microsoft Corporation UEFI CA'. When the system boots and Secure Boot is enabled, firmware verifies that this 1st stage bootloader (from the 'shim-signed' package) is signed with a key in DB (in this case 'Microsoft Corporation UEFI CA')
• The second stage bootloader (grub-efi-amd64-signed) is signed with Canonical's 'Canonical Ltd. Secure Boot Signing' key. The shim 1st stage bootloader verifies that the 2nd stage grub2 bootloader is properly signed.
• The 2nd stage grub2 bootloader boots an Ubuntu kernel (as of 2012/11, if the kernel (linux-signed) is signed with the 'Canonical Ltd. Secure Boot Signing' key, then grub2 will boot the kernel which will in turn apply quirks and call ExitBootServices. If the kernel is unsigned, grub2 will call ExitBootServices before booting the unsigned kernel)
• If signed kernel modules are supported, the signed kernel will verify them during kernel boot

Ik weet niet of bovenstaande tekst nog actueel is, maar waarschijnlijk is het Microsoft die bepaald of je een veilig OS hebt of niet, zelfs als dat OS Linux is

[Hobbit13]

Je hebt altijd een externe partij nodig voor die signing, met MS heb je iig een partij die in staat is om een inhoudelijke audit te doen. Ze hebben echt wel verstand van TPM, bootloaders etc.

MS zit Linux wel in de weg door MS Office niet voor Linux uit te brengen, daar hebben ze geen bootloader certificaten voor nodig.

[RobertMe]

Ik weet niet of bovenstaande tekst nog actueel is, maar waarschijnlijk is het Microsoft die bepaald of je een veilig OS hebt of niet, zelfs als dat OS Linux is

Hoe ik het begreep toen ik hier eerder dit jaar mee bezig was is het een verplichting dat de EFI ondersteuning heeft voor het kunnen enrollen van keys in een setup mode. Daarmee ben je dus niet meer afhankelijk van de keys die default enrolled zijn en heb je dus ook geen "Microsoft signed shim" meer nodig. In mijn geval zijn de EFI executables dan ook gesigned door een unieke key die op mijn installatie staat (die dus encrypted is door de full disk encryption en ook niet te "stelen" is zonder toegang tot het draaiende OS). Waarbij vervolgens dus ook alle EFI executables (bootloader + "UKI" ("Unified Kernel Image", 1 file met zowel de kernel als initramfs)) gesigned zijn met "mijn" key. En dus niet een tussenlaag die weer een andere key moet verifiëren zoals bij Ubuntu dus blijkbaar de shim gesigned is door MS en de shim controleert of grub gesigned is door Canonical.

Waarbij het enablen van de setup mode in de EFI ook wat zaken doet om de boel veilig te houden. Wat IIRC neer komt op alle custom enrolled keys verwijderen. Waardoor dus weer alleen de built-in keys vertrouwd zijn en je 1 custom key kunt enrollen. En de built in keys worden als ik het goed begrijp met enige regelmaat bijgewerkt met bios updates vanuit in dit geval Dell.

[bzzzt]

In mijn geval zijn de EFI executables dan ook gesigned door een unieke key die op mijn installatie staat (die dus encrypted is door de full disk encryption en ook niet te "stelen" is zonder toegang tot het draaiende OS).

Klinkt een beetje onhandig om die key op hetzelfde systeem te hebben, al zal dit in de praktijk zo weinig gedaan worden dat het geen echt risico is. Maar betekent dat niet dat je alle kernel updates die je binnen krijgt zelf moet signen? En hoe bepaal je dan of die kernels vertrouwd zijn?

[The Zep Man]

En hoe bepaal je dan of die kernels vertrouwd zijn?

Een beetje package manager controleert cryptografische handtekeningen van packages voordat deze geïnstalleerd worden. Als je je package manager en de standaard repositories van je besturingssysteem niet vertrouwt, dan moet je niet dat besturingssysteem gebruiken.

[Reactie gewijzigd door The Zep Man op 29 november 2024 12:52]

[RobertMe]

Signen gebeurt automatisch bij het installeren (hook in de package manager). Verder wat @The Zep Man aangeeft. Packages zijn sowieso allemaal gesigned. En als je de repo van het besturingssysteem niet vertrouwd kun je beter een ander besturingssysteem gebruiken.

[bzzzt]

Check, maar voor een aanvaller die al op jouw systeem rondhangt is het dus wel mogelijk een kernel te signen, wat niet werkt als je niet de hele TPM bende bij een andere partij (desnoods Microsoft) had laten staan.

[MainframeX]

Als je een aanvaller op je systeem hebt is het kwaad al geschiedt.

[bzzzt]

Er is verschil tussen toegang hebben en een persistent rootkit (OS modificatie) kunnen installeren. Vooral dat laatste is de aanjager geweest van het hele secure boot verhaal want tegen exploits doet secure boot helemaal niks.

[GertMenkel]

In principe staat het de fabrikant van je computer vrij om meer keys toe te voegen als ze meer mensen vertrouwen. Het probleem daarmee is dat je vervolgens een support-matrix krijgt van "Dell en Lenovo kunnen Ubuntu en Fedora installeren, HP kan Arch en Ubuntu maar geen Fedora, en als je van Medion koopt doet alleen EndeavourOS het" omdat iedere fabrikant dan met iedere distro mag gaan onderhandelen over welke distro's er nou vertrouwd zijn.

Door de shim is al dat werk niet nodig. Deze is ontwikkeld door mensen van verschillende Linux-distro's zodat er maar één project een handtekening van Microsoft hoeft te vragen, wiens sleutels toch al in laptops zitten. Ze tekenen de shim, en de shim kan worden geconfigureerd door de distro's zelf. Zo kun je de shim gebruiken om Arch en zelfs Gentoo op te starten.

Als je Microsoft die controle niet wil geven, zet je simpelweg de sleutels van Microsoft uit en zet je je eigen sleutels erin. Dan bepaal jij wie er wel of niet opstart, en zal er nooit meer zonder toestemming een Windows-bootloader op je computer laden.

Mocht je zelf een distro onderhouden en graag zonder shim willen opstarten, staat het je vrij om alle laptopfabrikanten te benaderen om ze te overtuigen dat je 100% te vertrouwen bent en je sleutels ook voorgeladen moeten worden.

Zoals Debian zegt:

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems. Users can enroll extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.

[Reactie gewijzigd door GertMenkel op 29 november 2024 10:37]

[servies]

Met deze kleine opmerking dat je die keys terug kunt krijgen door de BIOS te resetten... (batterijtje er uit...)

[GertMenkel]

Batterijtje eruit gaat je niet meer helpen, dat spul staat tegenwoordig allemaal in flash weggeschreven, en wel op een manier dat je er niet zomaar bij kunt komen (tot grote ergernis van mensen die hun moederbord gebrickt hebben met de verkeerde instellingen). Om secure boot te togglen heb je het UEFI-wachtwoord nodig.

Nu hebben sommige fabrikanten een achterlijke backdoor laten inbouwen om het "wachtwoord te herstellen" (lees: het wachtwoord in bijna plaintext aan je OS doorgeven, die truc werkt op mijn MSI ook), maar dat zou tegenwoordig niet meer moeten mogen willen ze gecertificeerd worden door Microsoft.

[Reactie gewijzigd door GertMenkel op 29 november 2024 11:42]

[servies]

Ok, dan zal het wel aan die bordjes liggen die we op ons werk hebben getest... Batterij eruit, BIOS/UEFI gereset en oorspronkelijke keys weer terug en ons spul werkte niet meer (verkeerde keys)...

[GertMenkel]

Dat is niet zo mooi, dan heeft een moederbordfabrikant lopen bezuinigen op hun spul. Sowieso moet ik zeggen dat van desktopmachines de UEFI-implementatie zwaar ondermaats is vergeleken met de gemiddelde laptop, maar als je met een batterijwissel je beveiligingsinstellingen kan wissen hebben ze het wel heel goed verpest vind ik.

Dat gezegd hebbende zou je systeem alsnog veilig moeten zijn mits je je schijf met een TPM(+PIN) versleuteld hebt, want die ontgrendelt niet meer zo makkelijk als je de keys eruit gooit of de secure boot status aanpast. Wellicht dat het niet direct opvalt, maar het is te merken dat iemand heeft lopen klooien met je hardware in zo'n scenario.

[servies]

De disks zijn idd niet leesbaar zonder TPM
En wij laten onze eigen keys door de fabrikant in de BIOS zetten, maar bij het uitzoeken/testen kwamen we dit gedrag tegen en nog wel wat meer rare dingetjes...

[servies]

Niet helemaal. MS signed de shim en vanaf daarna is de shim "verantwoordelijk" voor de verificatie van vervolgstappen. Op die manier hoeft er maar 1 shim gesigned te worden en kunnen grub en de kernels door Ubuntu zelf worden gesigned.
Je kunt ook zelf je sleutels in je computer zetten... Voeg je eigen KEK en DB keys toe en je kunt zelf je OS gaan signen. Maar als je de PK niet hebt kun je dat alleen handmatig in de UEFI setup en dat is nou niet echt wat je wilt...

[The Zep Man]

Niet helemaal. MS signed de shim en vanaf daarna is de shim "verantwoordelijk" voor de verificatie van vervolgstappen. Op die manier hoeft er maar 1 shim gesigned te worden en kunnen grub en de kernels door Ubuntu zelf worden gesigned.

En je kan die shim van Ubuntu ook gebruiken voor andere distributies. Je moet alleen eenmalig een Machine Owner Key genereren en de public key importeren in de MOK list van de UEFI firmware. Dit is een handmatige actie waarvoor de gebruiker lokaal aanwezig moet zijn.

Vervolgens kan je met de private key images om te booten ondertekenen, die door de shim doorgestart worden zonder gebruikersinteractie.

[cricque]

Ubuntu doet dit al lang zeer lang.
Voor mij verzekering ICT moet bijvoorbeeld secure boot opstaan. Terwijl ik alleen maar linux gebruik, heb nog een dual boot om heel af en toe eens COD te spelen.

Er is een guide bij Manjaro/Arch over hoe je dit werkende kan krijgen, maar daar heb ik dus echt geen tijd voor om mij daar nog mee bezig te houden. Ik zou het nochthans graag gebruiken. Maar ik blijf dus bij Linux mint wat een Ubuntu derivaat is. Ik snap uiteraard wel dat een distro daar geen verplichting toe heeft, maar het is er, dus waarom het niet gebruiken. Maar het lijkt mij dat je al fysieke toegang zou moeten hebben op die machine om het effectief aan de praat te krijgen. Dat wil niet zeggen dat het later niet mogelijk zal worden om dat ook op een andere manier te doen.

Ik zeg altijd: als iemand je wilt hacken, dan zal deze jou ook hacken. Je kan het alleen maar moeilijker maken en hopen dat iemand het uiteindelijk opgeeft.

[rbr320]

Waarom implementeren de meeste Linux distro's eigenlijk geen secure boot?

Omdat Secure Boot beheert wordt door Microsoft en je dus door wat MS-hoepels moet springen om je bootloader en kernel ondertekend te krijgen. Het had een open standaard moeten zijn, maar door de dominantie van Windows op de desktop is het helaas anders gelopen.

[84hannes]

Omdat Secure Boot beheert wordt door Microsoft

Ik weet niet of die formulering helemaal klopt. Een moederbord-fabrikant moet een sleutel laden op het EUFI omdat je anders geen Secure Boot kunt gebruiken. De meeste consumenten willen zonder gezeik Windows kunnen installeren, dus is het logisch dat ze de key van Microsoft meeleveren. Helaas houdt het daar op. Ze hadden ook Keys van Debian, IBM, Canonical etc. kunnen meeleveren, maar ze werden al moe van het idee. Iemand die Linux wil gebruiken is gewend door hoepels heen te springen. Verschillende Linux-distributies krijgen daarom medewerking van Microsoft om het toch out-of-the-box te laten werken.

[Reactie gewijzigd door 84hannes op 29 november 2024 09:30]

[The Zep Man]

Ik weet niet of die formulering helemaal klopt.

• Fabrikanten leveren enkel sleutels van Microsoft mee.
• Medewerking van Microsoft is nodig om out-of-the-box Secure Boot te laten werken onder Linux.

Formulering:

Omdat Secure Boot beheert [sic] wordt door Microsoft

Ik denk dat die formulering klopt. Ik zie geen enkele fabrikant waarbij ik bij het bestellen van een moederbord mijn eigen sleutelmateriaal kan aanleveren om op te nemen. Effectief is Secure Boot dus een feestje van Microsoft.

Overigens moet je oppassen met aanwezig sleutelmateriaal naast het sleutelmateriaal van Microsoft. Sommige fabrikanten (zoals Lenovo) ondertekenen kritieke OpROMs met hun eigen sleutelmateriaal. Verwijder dat sleutelmateriaal uit NVRAM en de OpROM wordt niet ingeladen als Secure Boot ingeschakeld is. Niet fijn als de OpROM van een embedded videokaart is die nodig is om het systeem te booten (en om bijvoorbeeld Secure Boot uit te schakelen).

[Reactie gewijzigd door The Zep Man op 29 november 2024 12:40]

[GertMenkel]

Secure Boot beheer je zelf, tenzij je zo'n super-duper-vergrendeld apparaat van Microsoft (of met een dure Microsoft Pluton-sticker) koopt. Alles dat tussen jou en het uitschakelen van Microsoft's sleutels staat, is het wachtwoord dat je zelf op de UEFI instelt.

Dat fabrikanten standaard de sleutels van Microsoft inladen omdat 99% van hun klanten Windows draait staat daar verder los van. Als een serieus deel van het klantenbestand Linux zou gebruiken, zou die situatie wellicht anders zijn.

Op hypervisors als libvirt heb je bijvoorbeeld voorgebouwde NVRAM-templates waarin alleen de Red Hat-keys staan, om bootkits te voorkomen binnen virtual machines. Als je in die VM's een Windows-ISO zou proberen te starten, zou je dezelfde foutmelding krijgen als wanneer je probeert Linux te installeren op zo'n supervergrendelde Surface RT.

[servies]

Dat is niet helemaal waar...
Het is alleen dat MS er voor zorgt dat hun KEK en DB keys vaak default in UEFI staan...
Alhoewel op mijn server moederbord thuis de key databases leeg zijn.

[GertMenkel]

Dat doen ze wel, met de sleutel die Microsoft daarvoor beschikbaar heeft gesteld. Ubuntu, Fedora, en een heel stel andere distros zijn daar op voorbereid.

Daar zitten wel wat haken en ogen aan. Zo kan je bijvoorbeeld niet zomaar kernelmodules injecteren als je in lockdown mode opstart (wat Linux automatisch doet als je vanuit secure boot start), iets dat voor mensen met closed source drivers als die van Nvidia een probleem is.

Wat Linuxdistro's meestal niet doen is het implementeren van eigen secure boot keys die je moet inladen. Dat betekent dat je bijvoorbeeld niet kunt instellen dat een boot disk van Fedora niet op je Ubuntu-systeem opstart, en als Microsoft een keer een exploitbare bootloader heeft kan die misbruikt worden tegen Linux. Je kunt dat wel zelf instellen, maar dat vereist wel enkele "enge" BIOS-schermpjes en een heel stel reboots en (momenteel) commando's.

Ik denk dat op dit gebied nog wel veel terrein te winnen is. Helaas zijn veel Linuxgebruikers als de dood voor secure boot omdat ze denken dat het een samenzwering is van Microsoft om alleen Windows op te kunnen starten. Hetzelfde zie je ook met discussies over TPM's. Dat zorgt er toch voor dat er weinig animo is om écht goed van deze technologieën gebruik te maken, en ik vind dat best jammer.

[SillieWous]

Hetzelfde zie je ook met discussies over TPM's.

Ik weet niet welke discussies je op doelt. Waar ik vooral problemen mee heb is TPM als enige key voor disk encryption. Dat is voor mij hetzelfde als een sleutel van de voordeur onder de mat leggen. Je kan dan misschien niet alleen de schijf stelen, maar als de schijf gejat wordt gaat de laptop denk ik ook mee.

[GertMenkel]

Alleen met de TPM is net wat veiliger dan helemaal geen wachtwoord, maar wil je je gegevens veilig hebben dan heb je natuurlijk een PIN op de TPM zitten. En een recovery-key op een veilige plek natuurlijk!

Dat staat wel los van de discussies die ik online zie. Een aantal (behoorlijk luide) mensen lijken te denken dat TPM's en secure boot bij elkaar horen, omdat Microsoft ze allebei van fabrikanten vereist. Alles wat ook maar iets met TPM's te maken heeft wordt op voorhand afgeschoten want voor die mensen zijn TPM's eng en des duivels. Persoonlijk vind ik dat ze prima argumenten hebben (de broncode is gesloten en versleuteld, veel hardware is al kwetsbaar gebleken) maar dat zij het niet vertrouwen betekent niet dat andere mensen die wel TPM's vertrouwen meteen slecht zijn.

[bzzzt]

Je moet die TPM meer zien als een 'lockbox'. De TPM zelf is ook versleuteld en moet eerst ontgrendeld worden voor de interne sleutels gebruikt kunnen worden.
Dus tenzij je laptop niet gelocked is en draaiend meegenomen wordt is je data alsnog veilig.

[SillieWous]

Mits er geen kwetsbaarheden in zitten. Het is een beetje hetzelfde als je TOTP (of de recovery keys) in je wachtwoordmanager te hebben. Technisch gezien heb je dan wel 2FA, maar met 1 exploit kun je binnen zijn.

[bzzzt]

Tenzij die wachtwoordmanager de passwords dan weer uit de TPM haalt na authenticatie

[desalniettemin]

Pop OS kan je niet eens installeren asl Secure boot aanstaat.

[84hannes]

Het kan blijkbaar, maar het lijkt er op dat je tools moet gebruiken om je eigen key toe te voegen. Er is dus een (klein) "window of opportunity" voor malware om zich te installeren voordat jij een key genereert.

[asing]

Fedora hier, en ik heb al tijden Secure Boot aan staan. Secure Boot zet je overigens aan in je UEFI/BIOS instellingen en je OS kan ermee overweg of niet.

Je kan het checken onder instellingen, Privacy en beveiliging, Apparaatbeveiliging (mits Gnome Desktop Environment).

[beerse]

SeucreBoot begint bij de hardware leverancier. Die installeert de eerste sleutel set in de fabriek. Daar zetten ze dan voor het gemak meteen de microsoft sleutels in omdat die op de meeste systemen toch wel komt en ook standaard geïnstalleerd wordt.

In theorie zouden er hardware leveranciers kunnen zijn die keys voor linux in de hardware plaatsen. Maar dan moeten de linux distributies die wel aanleveren. Er is voor zover ik weet geen linux-secure-boot-consortium die dat als 1 key levert.

Wel zijn veel linux distributies bij microsoft in hun sleutel set mee gaan liften. Vooral omdat daarmee niet eerst alle linux distributies bij elkaar moeten komen om tot 1 sleutelset te komen en aan de andere kant ook niet eerst alle hardware leveranciers die sleutels ook moeten oppakken.

[zordaz]

Tja, Secure Boot & Linux heeft een -op zijn zachts gezegd- nogal bewogen verleden. Veel oudere Tweakers herinneren zich dat misschien nog wel. Lees bijvoorbeeld dit artikeltje uit 2013 maar eens als startpunt:
https://www.pcworld.com/a...h-a-secure-boot-plan.html

Nog altijd ben ik het eens met de stellingname van toen dat Secure Boot eigenlijk meer over controle dan over security gaat. Ook het genoemde 'let the user be in control' staat in 2024 wat mij betreft nog fier overeind en zie ik te weinig terug bij secure boot implementaties.

[roelboel]

Bijzonder dat wie hier ook achterzit dit uploadt naar VirusTotal, en daarmee het voordeel van verrassing verliest.

[Jack Flushell]

Wellicht is het niet geupload door de maker. Zomaar een gedachte.

[ahbart]

Wat ik mijn afvraag is hoe zo een bootkit gestart wordt. Want je kiest bij booten een bepaalde bootfile. Hoe komt die bootkit daartussen?
Of weet deze bootkit zich in het daadwerkelijke uefi te nestelen? Wat dan weer hardware / chip niveau is. klinkt weer onwaarschijnlijk.

[servies]

Als secure boot aan staat zou deze er ook niet tussen moeten kunnen komen...

[ahbart]

Nee, maar hoe werkt dat dan als deze uit staat? Wat redelijk gebruikelijk is.

[novasurp]

Jammer dat de Vrije Software-beweging hier waarschijnlijk niets van zal leren en nog steeds het belang van Secure Boot zal ontkennen.

[servies]

Wat is dit nou voor onzin opmerking? Dat belang wordt helemaal niet ontkend... Het is alleen gruwelijk onhandig als je bijvoorbeeld zelf je kernel compileert...

[nvaert1986]

Ik snap nog steeds niet dat zoveel mensen Secure Boot uitschakelen om Linux te draaien. Ubuntu en Fedora ondersteunen het MS UEFI CA certificaat bijvoorbeeld gewoon.

Zelf draai ik dan Gentoo en maak ik gebruik van de shim loader (welke Microsoft gesigned is) en welke vervolgens mijn custom kernels laadt (welke door hetzelfde eigen certificaat gesigned worden). Tevens zijn m'n modules door mezelf gesigned en staat de kernel lockdown mode gewoon aan. Het is een kleine moeite om het te configureren (kost je 5 - 10 min. werk aan eenmalig inrichten). Verder koppel je er een bash script aan (wat er weer voor zorgt dat het grootste gedeelte van de signing automatisch) gaat en de kern van je systeem is gelijk een stuk veiliger (mits je het systeem up-to-date houdt uiteraard).

Tevens het updaten van de dbx via fwupd zou men gewoon automatisch aan moeten zetten. Dan zijn problemen zoals dit snel uit de wereld geholpen.

Ik snap dat wat ik doe niet voor de gemiddelde gebruiker is weggelegd, maar er zijn meer dan voldoende distributies tegenwoordig, welke gewoon Secure Boot ondersteunen.

[SemLRaug]

Het schijnt - in zn huidige vorm - nog niet heel spannend te zijn:

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

[desalniettemin]

Hoe raak je eigenlijk 'besmet' met zo'n bootkit?

[mutley69]

Dus secure boot ging veilig zijn? Wie zit daar achter? Intel/Microsoft? Dus de zoveelste failure!