Elfeledett UEFI shim-ek ássák alá a Secure Boot védelmét

Beküldte kami911 - 2026. júl. 16. 19:12

Az ESET kutatói 11 régi, elfelejtett UEFI shim bootloadert azonosítottak 0.9-es és annál régebbi verziókból, amelyekkel meg lehet kerülni a UEFI Secure Boot védelmét bármelyik olyan UEFI-alapú gépen, amely elfogadja a Microsoft Corporation UEFI CA 2011 harmadik féltől származó UEFI tanúsítványát, függetlenül a telepített operációs rendszertől. A bejelentett shimeket úgy lehet kihasználni, hogy a rendszerindítás során nem tRustett kód fusson le, így a támadók rosszindulatú UEFI bootkiteket (például Bootkitty, HybridPetya vagy BlackLotus) telepíthetnek még olyan gépekre is, ahol a UEFI Secure Boot engedélyezve van. Eredményeinket 2026 februárjában jelentettük a CERT/CC-nek, a sebezhető UEFI alkalmazásokat pedig a Microsoft 2026. június 9-i Patch Tuesday keretében vonta vissza.

Bár az esetre két CVE azonosítót osztottak ki a bejelentett shimek lefedésére, CVE-2026-8863 és CVE-2026-10797, az egyes shimek kihasználása nem pusztán egy-két közvetlenül bennük található hibáról szól. A támadási felületet tovább növelik a shimek által tRustett, második lépcsős bootloaderek (többnyire a GRUB 2), amelyek – akárcsak maguk a shimek – szintén lehetnek elavultak, ismert sebezhetőségekkel. A felfedezett shimek különféle eszközökből és szoftvercsomagokból származnak, többek között PC-diagnosztikai programokból, Linux disztribúciókból és más UEFI-alapú segédprogramokból. Fontos, hogy a kihasználás nem korlátozódik azokra a rendszerekre, amelyekre az érintett szoftvert vagy operációs rendszert telepítették: a támadók bármely UEFI rendszerre magukkal vihetik a sebezhető shimek saját példányát, ha azon be van jegyezve a Microsoft harmadik féltől származó UEFI tanúsítványa.

A bejelentett shimekre támaszkodó szoftvertermékek és érintett verzióik teljes listája a CERT/CC Vulnerability Note dokumentumban olvasható. Az ESET kutatóinak jelentésére reagálva a következő PE Authenticode hashsel rendelkező UEFI shim bootloadereket vonták vissza a dbx frissítésben, amely a Microsoft június 9-i Patch Tuesday csomagjának része volt:

AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

Ennek a blogbejegyzésnek a legfontosabb pontjai:

Az ESET kutatói 11 régi, Microsoft által aláírt UEFI alkalmazást fedeztek fel, amelyekkel a legtöbb UEFI-alapú rendszeren meg lehet kerülni a UEFI Secure Boot védelmét.

Ha egy támadó kihasználja valamelyik sebezhető alkalmazást, a rendszerindítás során nem tRustett kódot futtathat, így rosszindulatú UEFI bootkiteket vagy más kártevőt telepíthet.

A kihasználás nem korlátozódik azokra a rendszerekre, amelyekre az érintett szoftvert vagy operációs rendszert telepítették, mert a támadók bármely UEFI rendszerre magukkal vihetik a sebezhető binárisok saját példányát, ha azon be van jegyezve a Microsoft harmadik féltől származó UEFI tanúsítványa.

Minden olyan UEFI rendszer érintett, ahol engedélyezve van a Microsoft harmadik féltől származó UEFI aláírása (a Windows 11 Secured-core PC-ken ez az opció alapértelmezés szerint tiltva van).

A sebezhető binárisokat a Microsoft a 2026. június 9-i Patch Tuesday frissítésben visszavonta.

Az alábbiakban a koordinált közzététel időrendje látható. Köszönjük a CERT/CC segítségét a sebezhetőség közzétételének összehangolásában, valamint az érintett gyártók gördülékeny és átlátható kommunikációját és együttműködését a sebezhetőség közzététele és elhárítása során. A rendszerek védelméhez telepíteni kell a legújabb Microsoft dbx frissítéseket. A telepítés menetét a Protection and detection fejezet ismerteti.

Koordinált közzétételi idővonal:

2026-02-16 – Az ESET a bizonyító erejű példával együtt jelentette a felfedezést a CERT/CC-nek.

2026-03-18 – A dbx frissítés és a nyilvános közzététel dátumát 2026. május 19-re tűzték ki (Microsoft májusi Patch Tuesday).

2026-03-30 – A dbx frissítés és a nyilvános közzététel dátumát 2026. június 9-re halasztották (Microsoft júniusi Patch Tuesday).

2026-06-09 – Megjelent a Microsoft júniusi Patch Tuesday frissítése, a CERT/CC Vulnerability Note publikálva.

2026-07-14 – Megjelent az ESET blogbejegyzése.

UEFI shim bootloader és UEFI Secure Boot

Ahhoz, hogy megértsük, milyen hatással lehetnek az ilyen sebezhető shimek a UEFI Secure Boot által védett rendszerekre, először át kell tekinteni, hogyan működik a UEFI Secure Boot, és a Microsoft által aláírt UEFI shim bootloaderek miként hosszabbítják meg a Secure Boot tRust láncot. Ebben a részben áttekintjük a UEFI Secure Boot alapjait, a shimek szerepét a Secure Boot tRust lánc kiterjesztésében, valamint két shimhez kapcsolódó funkciót: a Machine Owner Keyt (MOK) és a Secure Boot Advanced Targetinget (SBAT). Akik már ismerik az elméleti hátteret, azoknak azt javasoljuk, hogy ugorjanak közvetlenül a Bypassing UEFI Secure Boot using old shims fejezetre.

UEFI Secure Boot

Ahogy az 1. ábra mutatja, amikor a UEFI firmware betölt egy bootalkalmazást – például a Windows Boot Managert vagy egy UEFI shimet –, a binárist két Secure Boot adatbázis alapján ellenőrzi:

db (engedélyezett tanúsítványok és Authenticode hashek), és
dbx (tiltott tanúsítványok és Authenticode hashek).

A képfájl csak akkor számít tRustettnek, ha szerepel a db-ben, és nincs benne a dbx-ben – ellenkező esetben a boot manager biztonsági hibát jelez, és nem futtatja. Hogy az újonnan vásárolt, UEFI Secure Bootot használó eszközök azonnal működjenek, a legtöbb OEM gyártó előre bejegyez néhány Microsoft UEFI tanúsítványt a db adatbázisba, nevezetesen:

Microsoft Windows Production PCA 2011 és Windows UEFI CA 2023 (ezekkel írják alá a Microsoft saját UEFI bootalkalmazásait; a 2011-es tanúsítványt a közeljövőben felveszik a dbx-be a BlackLotus-hoz kapcsolódó sebezhetőségek miatt).
Microsoft Corporation UEFI CA 2011 és Microsoft UEFI CA 2023 (ezekkel írják alá a harmadik féltől származó UEFI boot szoftvereket, például a Linux shimeket, helyreállító eszközöket, lemeztitkosító segédprogramokat).

Így bárki, aki azt szeretné, hogy a rendszerindításkor futó szoftvere alapértelmezés szerint kompatibilis legyen a UEFI Secure Boottal, beküldheti a binárisait a Microsoftnak aláírásra a Windows Hardware Dev Centeren keresztül. Ha a Microsoft jóváhagyja, az aláírt fájlokat a legtöbb UEFI rendszer tRustettnek fogja tekinteni. Ennek következtében a Microsoft központi szerepet játszik a legtöbb UEFI-alapú eszköz védelmében: gyakorlatilag ők döntik el, mi futhat a bootfolyamat során, és mi nem.

UEFI visszavonás (dbx)

A UEFI Secure Boot visszavonási mechanizmusa egyszerű: ha egy korábban tRustett bootalkalmazásról – amelynek PE Authenticode hashét vagy az azt aláíró tanúsítványt a db tartalmazza – kiderül, hogy sebezhető, akkor a PE Authenticode hashét felveszik a dbx-be, a Microsoft által kezelt tiltott aláírások adatbázisába (a dbx aktuális tartalmát általában a Microsoft GitHub tárolójában teszik közzé). Magukat a tanúsítványokat csak ritkán vonják vissza.

Amikor a Secure Bootot bevezették, még ésszerűnek tűnhetett az egyes sebezhető binárisok hash alapján történő visszavonása, a BootHole és a BlackLotus esete azonban jól mutatja, hogy ez a megközelítés messze nem ideális. A fő gond a méretezhetőség, amit a Red Hat Bootloader Team SBAT javaslata/specifikációja is jól capturál:

A közelmúltbeli „BootHole” biztonsági incidens (CVE-2020-10713) részeként 3 tanúsítványt és 150 képfájl-hasht vettek fel a UEFI Secure Boot dbx visszavonási adatbázisába a népszerű x64 architektúrán. Ez az egyetlen visszavonási esemény 10 kB-ot használ el a tipikusan 32 kB-os, vagyis nagyjából egyharmadnyi visszavonási tárhelyből, amely a UEFI platformokon rendelkezésre áll. Az UEFI visszavonási listák egyesítésének módja miatt ez – a korábbi visszavonási eseményekkel együtt – azt eredményezheti, hogy a dbx mérete majdnem 15 kB-ra nő, vagyis megközelíti az 50%-os kapacitást.

Ugyanez a nyomás a dbx kapacitásán a BlackLotushoz kapcsolódó, sebezhető Windows Boot Manager binárisok visszavonásakor is jelentkezett. Ezek a tapasztalatok vezettek oda, hogy a Microsoft a partnereivel együtt további, verzióalapú visszavonási mechanizmusokat vezetett be a két legelterjedtebb, Secure Boot-kompatibilis bootloaderhez kapcsolódva:

Secure Boot Advanced Targeting (SBAT) – a shim, vagyis a Linuxhoz készült UEFI bootloader használja 15.3-as verziótól.
A Microsoft Secure Boot Security Version Number (SVN) – a Windows Boot Manager használja (2024 áprilisában jelent meg) – Bill Demirkapi „Booting with Caution” című anyagában (62. oldal) Revocation via Embedded Secure Version Information (REVISE) néven is említik, de ez az elnevezés és rövidítés a hivatalos Microsoft dokumentációban nem tűnik elterjedtnek.

Röviden: míg a dbx konkrét binárisokat von vissza, az SBAT és a Microsoft Secure Boot SVN verziókat von vissza. Ha egy olyan UEFI alkalmazásban találnak sebezhetőséget, amely támogatja valamelyik verzióalapú visszavonási mechanizmust, akkor minden olyan buildet ki kell tiltani, amelyik az érintett, hibás verzióig bezárólag készült – ezt pedig egy verziószámmal sokkal könnyebb leírni, mint egy hosszú hash-listával. Az SBAT működését részletesebben a Secure Boot Advanced Targeting (SBAT) fejezetben ismertetjük.

UEFI shim bootloader és Secure Boot

A UEFI Secure Bootot támogató Linux disztribúciók esetében a fent leírt, Microsoft kulcsokra épülő Secure Boot mechanizmus több kihívást is felvet. Minden Linux disztribúció saját bootloader binárisokat készít, és mindegyiknek más a hash értéke. Ha minden Linux bootloadert közvetlenül a Microsoftnak kellene aláírnia, az lassú, bürokratikus és a disztribúciók teljes körére nézve gyakorlatilag kezelhetetlen lenne.

Erre a problémára a shim ad megoldást: egy kicsi, minimális első lépcsős bootloader, amelyet a Microsoft egyszer átvizsgál és aláír, és amely aztán másodlagos tRust horgonyt hoz létre a Linux disztribúció-specifikus boot stack számára – jellemzően a GRUB 2 és a Linux «TERM0

A shim bootloader egy olyan UEFI alkalmazás, amelyet a Microsoft aláír, és amelyet a Linux disztribúciók használnak Secure Boot mellett. A shim feladata, hogy a Microsoft által aláírt, megbízható kódból átadja a vezérlést a disztribúció saját, már a saját kulcsaival aláírt boot stackjének. Ide tartozik jellemzően a GRUB 2 és a Linux «TERM0» kernel is.

A shim tehát egy köztes réteg a firmware és a Linux-specifikus bootfolyamat között. A firmware a Microsoft kulcsait ismeri, a shim pedig a disztribúció kulcsait. A shim tartalmazza a disztribúció saját tanúsítványait vagy kulcsait, és ezek alapján ellenőrzi a további bootloadereket és a kernelt. Így a Microsoftnak nem kell minden egyes Linux bootloadert és kernelt külön aláírnia, elég a shimre koncentrálnia.

A Secure Boot szempontjából a shim különösen érzékeny pont. Ha a shimben sebezhetőséget találnak, akkor a támadó a teljes Secure Boot láncot megkerülheti, hiszen a shim után már a disztribúció saját bizalmi lánca érvényesül. Emiatt a shim binárisok visszavonása (revocation) kulcsfontosságú, ha kiderül, hogy egy adott verzió sérülékeny.

A Microsoft a visszavonást a dbx (forbidden signatures database) segítségével oldja meg. A dbx egy UEFI-adatbázis, amelyben a visszavont, tiltólistára tett binárisok hash értékei szerepelnek. Ha egy bináris hash-e bekerül a dbx-be, a firmware többé nem indítja el azt Secure Boot mellett. A dbx tartalmát firmware-frissítésekkel vagy külön Secure Boot frissítésekkel terjesztik.

Az ESET kutatói 11 régi, 0.9-es vagy annál korábbi shim verziót azonosítottak, amelyekkel meg lehet kerülni a Secure Boot védelmét. Ezeknek a sebezhető shim binárisoknak a hash értékei az alábbiak:

'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',

'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',

'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',

'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',

'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',

'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',

'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',

'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',

'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',

'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',

'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'

A kutatók azt is megvizsgálták, hogy ezek a hash-ek szerepelnek-e a dbx-ben. Ehhez a Windows PowerShellben a következő scriptet használták:

$hashes = @(
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'
)
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

A script először egy tömbben felsorolja a sebezhető shim binárisok hash értékeit. Ezután a Get-SecureBootUEFI cmdlettel kiolvassa a rendszer UEFI dbx adatbázisát, és hexadecimális karakterlánccá alakítja. A Where-Object szűrővel összeveti a saját listáját a dbx tartalmával, és megkeresi azokat a hash-eket, amelyek nem szerepelnek a tiltólistán. Ha talál ilyeneket, kiírja, hogy „Hash not revoked: …”, ha pedig mindegyik hash benne van a dbx-ben, akkor az „All hashes revoked in dbx!” üzenetet jeleníti meg.

Az ESET vizsgálata szerint több hash sem szerepelt a dbx-ben, vagyis bizonyos régi, sebezhető shim binárisokat a Secure Boot továbbra is elfogadott. Ez azt jelenti, hogy egy támadó, aki ilyen régi shim binárishoz hozzáfér, még mindig meg tudja kerülni a Secure Boot védelmét olyan gépeken, ahol a firmware nem tartalmazza a megfelelő, naprakész dbx frissítéseket.

A probléma gyökere, hogy a dbx frissítése lassan és széttagoltan jut el a felhasználókhoz. Sok gyártó ritkán ad ki firmware-frissítést, a felhasználók pedig gyakran nem telepítik ezeket. Emiatt a Secure Boot ökoszisztémában hosszú ideig megmaradnak olyan régi, sebezhető binárisok, amelyeket elvileg már rég tiltólistára kellett volna tenni. A shim esetében ez különösen veszélyes, mert a teljes Linux bootlánc ezen keresztül épül fel.

6. ábra. PowerShell parancsok a UEFI visszavonások ellenőrzéséhez

Linux rendszereken a frissítések a Linux Vendor Firmware Service szolgáltatáson keresztül érhetők el, a visszavonási állapotot pedig a uefi-dbx-audit script segítségével lehet ellenőrizni.

Általánosabb ajánlásokért – hogyan lehet védekezni az ismeretlen, sebezhető, aláírt UEFI bootloaderek kihasználása és a UEFI bootkitelek telepítése ellen, illetve ezeket legalább észlelni – érdemes elolvasni a Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344 című blogbejegyzésünket.

Következtetés

Azért veszélyesek ezek a régi shim-ek, mert nem kell hozzájuk új sebezhetőség: a UEFI Secure Boot megkerüléséhez nincs szükség új hibára. A támadónak nem kellenek bonyolult kihasználási technikák sem – elég egy régi, még mindig Rustelt, de vissza nem vont shim bináris, és az, hogy nagyjából értse, hogyan működnek a UEFI shim-ek. Ennyi elég ahhoz, hogy megkerülje a UEFI Secure Boot ilyen alapvető biztonsági funkcióját.

Az a tény, hogy ezt a 11 shim-et visszavonták, megoldotta a közvetlen problémát, de maradt egy mélyebb gond: az átláthatóság hiánya. A shim aláírási folyamata 2017-ben lett jóval átláthatóbb, amikor létrehozták a shim-review tárolót. Itt a karbantartók átnézik a gyártói beküldéseket, mielőtt a Microsoft aláírja őket. Azóta minden jóváhagyott shim dokumentált – a korábban aláírtakról viszont nincs ilyen nyilvántartás, és senki sem tudja megbízhatóan megmondani, hány régi, még mindig Rustelt shim maradt forgalomban. Amit nem katalogizáltak teljesen és átláthatóan, azt nem lehet hatékonyan nyugdíjazni.

Van azonban biztató fejlemény is. Úgy látjuk, a trend jó irányba halad. Minden ilyen nyilvánosságra hozatal tovább csökkenti az elfelejtett shim-ek számát, és a javuló shim-aláírási átláthatóság, illetve az SBAT-hoz hasonló mechanizmusok mellett sokkal könnyebb nyomon követni, mit kell visszavonni, és ezt ténylegesen, hatékonyan meg is tenni. A következő lépés, hogy a Microsoft harmadik féltől származó UEFI aláírási ökoszisztémájában ugyanezt az átláthatósági szintet kiterjesszék a nem shim jellegű, harmadik féltől származó UEFI alkalmazásokra is. Ezek – ahogy azt számos eset (például CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250 stb.) újra és újra megmutatta – szintén egyszerű kiindulópontot jelenthetnek a UEFI Secure Boot megkerüléséhez.

IoC-k

Mivel a sebezhető shim-ek legitim szoftvercsomagok részei, és potenciálisan több ezer olyan rendszeren is jelen vannak, amelyeket soha nem támadtak meg ezekkel a loaderekkel, nem adunk meg kompromittálódásra utaló jeleket, hogy elkerüljük a tömeges téves riasztásokat. A védelmi oldalon dolgozóknak inkább a Protection and detection szakaszban leírt tanácsokat érdemes követniük.

További hivatkozások: