Een geldige handtekening betekent niet langer veilige code

Secure Boot deed precies waarvoor het gebouwd was, en dat was het probleem. Op 14 juli publiceerde beveiligingsbedrijf ESET onderzoek, geleid door Martin Smolar, dat elf door Microsoft ondertekende bootloaders toont, allemaal in versie 0.9 of lager, die een machine zonder aarzelen uitvoert omdat de handtekening echt is. De code achter die handtekening is een decennium oud en gebrekkig, maar Secure Boot controleert de ondertekenaar, niet de veiligheid van wat er is ondertekend.

Het resultaat is een aanvaller die op vrijwel elke UEFI-computer niet-geverifieerde code kan uitvoeren tijdens het opstarten. ESET meldde de vondst in februari aan het coördinatiecentrum CERT/CC, en Microsoft voegde alle elf bestanden op 9 juni toe aan zijn intrekkingslijst. De kloof tussen een vertrouwde handtekening en betrouwbare code is het hele verhaal, en de patch alleen dicht die niet.

Hoe de omzeiling werkt

De aanvaller breekt niets open; hij levert iets wat al vertrouwd is. De meeste UEFI-systemen dragen het externe certificaat van Microsoft, de Microsoft Corporation UEFI CA 2011, in hun lijst met toegestane ondertekenaars. Een aanvaller kopieert een van de oude ondertekende bootloaders naar de EFI-systeempartitie, het kleine opstartgebied van de schijf, en de firmware accepteert het omdat de handtekening teruggaat op dat vertrouwde certificaat. Er zijn geen beheerdersrechten nodig, alleen de mogelijkheid om dat bestand te schrijven.

Vanaf daar doen drie oude gaten het werk. De bootloaders vertrouwen op verouderde GRUB 2-code met een fout uit 2015 die niet-geverifieerde modules uitvoert; versies onder 0.9 missen de intrekkingslijst die bekende slechte certificaten zou blokkeren; en versies van voor 15.3 negeren SBAT, het nieuwere mechanisme dat kwetsbare binaries moet uitfaseren. Geregistreerd als CVE-2026-8863 en CVE-2026-10797, eindigt de keten met code van de aanvaller die draait voordat het besturingssysteem laadt, de ideale plek om zich te verbergen.

Waarom de patch het makkelijke deel is

Een intrekking beschermt alleen een machine die haar echt heeft ontvangen. De fix van Microsoft van 9 juni voegt de elf bestanden toe aan dbx, de blokkeerlijst van de firmware, en op beheerde Windows-vloten loopt die update via de normale kanalen. Het addertje is dat veel organisaties wijzigingen aan de firmwarelijst bewust tegenhouden, omdat een verkeerde dbx-vermelding een apparaat niet meer kan laten opstarten, en dat risico is groter op oudere of dualboothardware. De intrekking bestaat; of ze uw machines heeft bereikt is een aparte vraag.

Het diepere probleem is tellen. Het openbare shim-review-register begon pas in 2017, en er is geen vergelijkbare lijst van wat daarvoor is ondertekend, dus niemand kan met zekerheid zeggen hoeveel oude, nog vertrouwde bootloaders er rondzwerven. Elf is het getal dat ESET kon noemen, niet het getal dat bestaat. Een maatregel die afhangt van het kennen van elke vertrouwde ondertekenaar is juist daar zwak waar de inventaris ophoudt.

Wat deze week echt te controleren valt

Behandel dit als een taak van intrekkingshygiëne, niet als een enkele patch. Bevestig dat de dbx-update van 9 juni echt over het hele park is toegepast in plaats van het aan te nemen; ESET verwijst naar auditgereedschap en PowerShell-controles die de huidige intrekkingsstatus melden. Trek de controle door voorbij Windows, want Linux-servers en appliances krijgen dezelfde fix via de Linux Vendor Firmware Service, en dualbootlaptops zijn de klassieke blinde vlek.

Voor Europese operators is het kader nu even zeer regelgevend als technisch. Onder NIS2 valt de integriteit van de opstartketen binnen de beveiligingsmaatregelen die een essentiële entiteit moet kunnen aantonen, en een firmware-bootkit is precies het soort persistentie waar een toezichthouder na een incident naar zal vragen. De actie van de eigenaar is eenvoudig te benoemen en makkelijk over te slaan: controleer wat uw firmware nog vertrouwt, en toon aan dat de blokkade is aangekomen.

Lees hierna: 570 Windows-patches op een dag, twee al misbruikt  |  18 jaar oude Cisco-bug: nu een deadline van 3 dagen