Unutulan UEFI ara katmanları, Güvenli Önyükleme’yi atlatıyor

ESET araştırmacıları, saldırganların on yıl öncesine ait güvenlik açıklarından yararlanarak UEFI Güvenli Önyükleme’yi atlatmasına olanak tanıyan, Microsoft tarafından imzalanmış 11 adet güvenlik açığı bulunan UEFI ara katman önyükleyicisi keşfetti

ESET araştırmacıları, 0.9 ve daha eski sürümlerdeki 11 adet eski ve unutulmuş UEFI ara katman önyükleyicisini tespit etti. Bu ara katmanlar, yüklü işletim sisteminden (OS) bağımsız olarak, Microsoft’un Microsoft Corporation UEFI CA 2011 üçüncü taraf UEFI sertifika yetkilisi (CA) sertifikasına güvenen herhangi bir UEFI tabanlı makinede UEFI Güvenli Önyükleme’yi atlatmak için kullanılabilir. Bildirilen ara katmanlar, sistem önyüklemesi sırasında güvenilmeyen kodları çalıştırmak için istismar edilebilir; bu da saldırganların, UEFI Güvenli Önyükleme’nin etkin olduğu sistemlerde bile kötü amaçlı UEFI bootkit’leri (Bootkitty, HybridPetya veya BlackLotus gibi) yerleştirmelerine olanak tanır. Bulgularımızı Şubat 2026’da CERT/CC’ye bildirdik ve güvenlik açığı bulunan UEFI uygulamaları, Microsoft’un 9 Haziran 2026 tarihli Patch Tuesday güncellemesinde iptal edildi.

Bildirilen ara katmanları kapsamak üzere bu vakaya iki CVE kimliği atanmış olsa da (CVE-2026-8863 ve CVE-2026-10797), bildirilen her bir ara katmanın istismar edilmesi, bu eski ara katmanlarda doğrudan bulunabilecek bir veya iki hatayla sınırlı değildir. Aslında, saldırı yüzeyi, ara katmanların güvenilir ikinci aşama önyükleyicileri (çoğunlukla GRUB 2) tarafından genişletilmektedir. Bu önyükleyiciler, ara katmanların kendisi gibi, bilinen güvenlik açıkları içeren eski sürümleri barındırabilir. Keşfedilen ara katmanlar, PC tanılama yazılımları, Linux dağıtımları ve diğer UEFI tabanlı yardımcı programlar dâhil olmak üzere çeşitli araçlardan veya yazılım paketlerinden gelmektedir. Önemli bir nokta olarak, saldırganlar Microsoft’un üçüncü taraf UEFI sertifikası kayıtlı herhangi bir UEFI sistemine kendi güvenlik açığı bulunan ara katman kopyalarını yükleyebildikleri için istismar sadece etkilenen yazılım veya işletim sisteminin kurulu olduğu sistemlerle sınırlı değildir.

Bildirilen ara katmanlara dayanan yazılım ürünlerinin tam listesi ve etkilenen sürümleri, CERT/CC’nin Güvenlik Açığı Notu’nda mevcuttur. ESET araştırmacılarının raporuna yanıt olarak, aşağıdaki PE Authenticode hash değerlerine sahip UEFI ara katman önyükleyicileri, Microsoft’un 9 Haziran Salı Güncellemesi kapsamında yayımlanan dbx güncellemesinde iptal edilmiştir:

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

Bu blog yazısının ana noktaları:

• ESET araştırmacıları, UEFI tabanlı sistemlerin çoğunda UEFI Güvenli Önyükleme özelliğinin atlanmasına olanak tanıyan, Microsoft tarafından imzalanmış 11 eski UEFI uygulamasını keşfetti.
• Bu güvenlik açığı bulunan uygulamalardan birini istismar eden bir saldırgan, sistem önyüklemesi sırasında güvenilir olmayan kod çalıştırabilir ve bu sayede kötü amaçlı UEFI bootkit’leri veya diğer kötü amaçlı yazılımların yüklenmesini sağlayabilir.
• Saldırganlar, Microsoft üçüncü taraf UEFI sertifikası kayıtlı herhangi bir UEFI sistemine kendi güvenlik açığı bulunan ikili dosyalarını yükleyebildikleri için istismar sadece etkilenen yazılım veya işletim sisteminin kurulu olduğu sistemlerle sınırlı değildir.
• Microsoft üçüncü taraf UEFI imzalama özelliğinin etkin olduğu tüm UEFI sistemleri bu sorundan etkilenmektedir (Windows 11 Secured-core PC’lerde bu seçenek varsayılan olarak devre dışı bırakılmış olmalıdır).
• Güvenlik açığı bulunan ikili dosyalar, Microsoft tarafından 9 Haziran 2026 Patch Tuesday güncellemesinde iptal edilmiştir.

Aşağıda koordineli açıklama zaman çizelgesi yer almaktadır. Güvenlik açığı açıklama sürecinin koordinasyonunda yardımları için CERT/CC’ye ve güvenlik açığı açıklama ve düzeltme süreci boyunca sorunsuz ve şeffaf iletişim ve iş birliği için etkilenen satıcılara teşekkür ederiz. Sistemlerinizi bu tehdide karşı korumak için en son Microsoft dbx güncellemelerini yükleyin. Bunun nasıl yapılacağına ilişkin talimatlar, Koruma ve algılama bölümünde bulunabilir.

Koordineli açıklama zaman çizelgesi:

• 16 Şubat 2026 – ESET, bulgularını bir kavram kanıtı ile birlikte CERT/CC’ye bildirdi.
• 18 Mart 2026 – dbx güncellemesi ve kamuya açıklama tarihi 19 Mayıs 2026 (Microsoft’un Mayıs Patch Tuesday’i) olarak belirlendi.
• 30 Mart 2026 – dbx güncellemesi ve kamuya açıklama tarihi 9 Haziran 2026’ya (Microsoft’un Haziran Patch Tuesday’i) ertelendi.
• 9 Haziran 2026 – Microsoft’un Haziran Patch Tuesday güncellemesi, CERT/CC Güvenlik Açığı Notu yayımlandı.
• 14 Temmuz 2026 – ESET blog yazısı yayımlandı.

UEFI ara katman önyükleyicisi ve UEFI Güvenli Önyükleme

Bu tür güvenlik açığı barındıran ara katmanların UEFI Güvenli Önyükleme ile korunan sistemler üzerinde yaratabileceği etkiyi anlamak için UEFI Güvenli Önyükleme’nin nasıl çalıştığını ve imzalı UEFI ara katman önyükleyicilerin Güvenli Önyükleme güven zincirini nasıl genişlettiğini anlamamız gerekir. Bu bölümde, UEFI Güvenli Önyükleme’nin temellerini, UEFI ara katmanlarının UEFI Güvenli Önyükleme güven zincirini nasıl genişlettiğini ve ara katmanlarla ilgili iki özelliği ele alacağız: Makine Sahibi Anahtarı (MOK) ve Güvenli Önyükleme Gelişmiş Hedefleme (SBAT). Teoriye zaten aşina olanlar için doğrudan “Eski ara katmanları kullanarak Güvenli Önyüklemeyi atlama” bölümüne geçebilirsiniz.

UEFI Güvenli Önyükleme

Şekil 1 ‘de gösterildiği gibi, UEFI bellenimi bir önyükleme uygulamasını (Windows Önyükleme Yöneticisi veya bir UEFI ara katman gibi) yüklediğinde, ikili dosyayı iki Güvenli Önyükleme veri tabanına göre doğrular:

• db (izin verilen sertifikalar ve Authenticode hash’leri) ve
• dbx (yasaklanmış sertifikalar ve Authenticode hash’leri).

Şekil 1 . UEFI Güvenli Önyükleme basitleştirilmiş şeması (kaynak: UEFI Bootkits and Where UEFI Security Fails, s. 48)

Görüntü, db tarafından güvenilir olarak kabul edilmeli ve dbx’te listelenmemelidir. Aksi takdirde, önyükleme yöneticisi görüntüyü çalıştırmak yerine bir güvenlik ihlali tetikler. UEFI Güvenli Önyükleme’nin etkin olduğu yeni satın alınan cihazlarda bunun kullanıma hazır olarak çalışmasını sağlamak için çoğu OEM, db veri tabanına bir dizi Microsoft UEFI sertifikası kaydeder; bunlar şunlardır:

• Microsoft Windows Production PCA 2011 ve Windows UEFI CA 2023 (Microsoft’un kendi UEFI önyükleme uygulamalarını imzalamak için kullanılır; 2011 tarihli sertifika, BlackLotus ile ilgili güvenlik açıkları nedeniyle yakında dbx’e eklenecektir).
• Microsoft Corporation UEFI CA 2011 ve Microsoft UEFI CA 2023 (Linux ara katmanları, kurtarma araçları ve disk şifreleme yardımcı programları gibi üçüncü taraf UEFI önyükleme yazılımlarını imzalamak için kullanılır).

Bu, önyükleme zamanı yazılımlarının varsayılan olarak UEFI Güvenli Önyükleme ile uyumlu olmasını isteyen herkesin, Windows Donanım Geliştirme Merkezi aracılığıyla imzalama için ikili dosyalarını Microsoft’a gönderebileceği anlamına gelir; onaylandıktan sonra imzalanmış dosyalar, UEFI sistemlerinin büyük çoğunluğunda güvenilir hâle gelir. Sonuç olarak, Microsoft, çoğu UEFI tabanlı cihazın güvenliğini sağlamada merkezi bir rol oynar ve önyükleme sırasında neyin çalıştırılmasına izin verileceğini ve neyin verilmeyeceğini fiilen belirler.

UEFI iptal (dbx)

UEFI Güvenli Önyükleme’nin iptal tasarımı basittir: Daha önce güvenilir kabul edilen bir önyükleme uygulamasının (PE Authenticode hash’i veya onu imzalayan sertifikanın db’de mevcut olduğu bir uygulama) güvenlik açığı olduğu ortaya çıktığında, bu uygulamanın PE Authenticode hash’i, Microsoft tarafından yönetilen yasaklanmış imzalar veri tabanı olan dbx’e eklenir (dbx’in en son içeriği genellikle Microsoft’un GitHub deposunda yayımlanır). Sertifikaların kendileri ise yalnızca nadiren iptal edilir.

Güvenli Önyükleme’nin tanıtıldığı dönemde, güvenlik açığı bulunan tek tek ikili dosyaları hash değerlerine göre iptal etme fikri makul görünebilirdi; ancak BootHole ve BlackLotus gibi vakalar, bu yaklaşımın ideal olmaktan uzak olduğunu göstermektedir. Temel sorun ölçekle ilgilidir ve bu durum, Red Hat Önyükleyici Ekibi’nin SBAT önerisi/spesifikasyonunda çok iyi bir şekilde ifade edilmiştir:

Son zamanlarda meydana gelen “BootHole” güvenlik olayı CVE-2020-10713 kapsamında, popüler x64 mimarisinde UEFI Secure Boot iptal veri tabanı dbx’e 3 sertifika ve 150 görüntü hash’i eklendi. Bu tek iptal olayı, UEFI platformlarında genellikle mevcut olan 32 kB’lik iptal depolama alanının 10 kB’sini, yani yaklaşık üçte birini tüketmektedir. UEFI’nin iptal listelerini birleştirme şekli nedeniyle bu olay ve önceki iptal olayları bir araya geldiğinde dbx’in boyutu neredeyse 15 kB’ye ulaşarak kapasitenin %50’sine yaklaşabilir.

BlackLotus ile ilgili güvenlik açığı bulunan Windows Önyükleme Yöneticisi ikili dosyalarının kullanımdan kaldırılmasıyla dbx kapasitesi üzerindeki aynı baskı tekrar ortaya çıktı. Bu iki durum, Microsoft’u iş ortaklarıyla birlikte, yaygın olarak kullanılan iki Güvenli Önyükleme uyumlu önyükleyiciden birine bağlı olan, sürüm tabanlı ek iptal mekanizmaları getirmeye sevk etti:

• Secure Boot Advanced Targeting (SBAT) – Linux için bir UEFI önyükleyici olan ara katman tarafından 15.3 sürümünden itibaren kullanılır.
• Microsoft’un Güvenli Önyükleme Güvenlik Sürüm Numarası (SVN) – Windows Önyükleme Yöneticisi tarafından kullanılır (Nisan 2024’te yayımlanmıştır) – Bill Demirkapi’nin *Booting with Caution* adlı kitabının 62. sayfasında “Gömülü Güvenli Sürüm Bilgisi Yoluyla İptal (REVISE)” olarak da anılmaktadır; ancak bu isim ve kısaltma, resmî Microsoft belgelerinde kullanılmıyor gibi görünmektedir.

Kısacası, dbx ikili dosyaları iptal ederken SBAT ve Microsoft’un Güvenli Önyükleme SVN’si sürümleri iptal eder. Bu sürüm tabanlı iptal mekanizmalarından birini destekleyen bir UEFI uygulamasında bir güvenlik açığı bulunduğunda, gerçekten engellenmesi gereken şey, sorunlu sürüm dâhil olmak üzere ona kadar olan tüm derlemelerdir – ve bu, uzun bir hash listesinden çok daha kolay bir şekilde bir sürüm numarasıyla tespit edilebilir. SBAT hakkında daha fazla bilgiyi, Secure Boot Advanced Targeting (SBAT)bölümünde bulabilirsiniz.

UEFI ara katman önyükleyicisi ve UEFI Güvenli Önyükleme

UEFI Güvenli Önyüklemeyi destekleyen Linux dağıtımlarında, yukarıda açıklanan ve Microsoft anahtarları üzerine kurulu Güvenli Önyükleme mekanizması bazı zorluklar yaratır. Her Linux dağıtımı kendi önyükleyici ikili dosyalarını oluşturur ve her birinin farklı bir hash değeri vardır. Her Linux önyükleyicisinin doğrudan Microsoft tarafından imzalanmasını sağlamak, tüm Linux dağıtımları genelinde sürdürülmesi açısından yavaş, bürokratik ve pratik olmayan (hatta imkânsız) bir işlem olurdu.

Bu sorunun çözümü bir “ara katman”dır. Microsoft’un tek seferlik olarak inceleyip imzalayabileceği, küçük ve minimal bir ilk aşama önyükleyicidir; bu önyükleyici, daha sonra Linux dağıtımına özgü önyükleme yığınının geri kalanı için – genellikle GRUB 2 ve Linux çekirdeği – ikincil bir güven dayanağı oluşturur. Bu güven dayanağı, Microsoft tarafından imzalanmadan önce ara katman ikili dosyasına eklenen ve “satıcı sertifikası” (dağıtım satıcısı tarafından yönetilen) olarak adlandırılan başka bir sertifikadır.

Ara katman kullanan, Güvenli Önyükleme özelliği etkin bir Linux sistemindeki basitleştirilmiş önyükleme akışı, adresindeki Şekil 2 gösterilmiştir.

Şekil 2 . Linux sistemlerinde basitleştirilmiş UEFI önyükleme akışı

UEFI bellenimi, ara katmanı yükler ve imzasını bellenimde depolanan Microsoft CA’sına (db değişkeni) göre doğrular. Ardından ara katman devreye girer ve ikinci aşama önyükleyiciyi (genellikle GRUB 2) kendi gömülü satıcı sertifikasına göre doğrular. Örneğin, Debian için Debian’ın UEFI anahtarı, Ubuntu için Canonical’ın UEFI anahtarı veya RHEL ve Fedora için Red Hat’in anahtarı. GRUB 2 ise kontrolü devretmeden önce aynı satıcı sertifikasını kullanarak çekirdeği doğrular. Her adım, kendinden önceki adım tarafından kriptografik olarak onaylanır.

Bu dolaylı yapı, bir Linux dağıtımının her güncelleme için Microsoft’a başvurmaya gerek kalmadan, önyükleyici ve çekirdek güncellemelerini kendi satıcı anahtarıyla imzalayarak hızla yayımlayabileceği anlamına gelir. Yalnızca ara katman (shim) Microsoft’un imzasını gerektirir ve bu da nadiren değişir.

Satıcı sertifikasına ek olarak, ara katman genellikle yalnızca o belirli ara katman derlemesi/ikili dosyasıyla ilişkili başka bir yerleşik sertifika içerir. Bu sertifika genellikle “ara katman sertifikası” olarak adlandırılır ve ara katmanın derleme aşamasında oluşturulabilen yardımcı programlarının (örneğin, MOK’ları yönetmek için kullanılan ve aşağıda daha ayrıntılı olarak açıklanan MokManager veya ara katmanın yedek mekanizması gibi) bütünlüğünü imzalamak ve doğrulamak için kullanılır.

Makine Sahibi Anahtarı (MOK)

Ara katmanlardan bahsederken bir ara katmanın kullanıcı tarafından yönetilen ve Makine Sahibi Anahtarları (MOK’lar) olarak bilinen harici anahtarları kullanmasına olanak tanıyan bir başka önemli mekanizmayı da göz ardı edemeyiz. Bir MOK izin listesi (bunu UEFI db veri tabanının ara katmana özgü bir “uzantısı” olarak düşünün), MokList adlı önyükleme amaçlı bir NVRAM değişkeninde saklanır; yasak listesi ise (UEFI dbx veri tabanının ara katmana özgü “uzantısı”) MokListX adlı önyükleme amaçlı bir NVRAM değişkeninde saklanır; UEFI Güvenli Önyükleme’nin etkin olduğu bir sistemde her iki değişkeni de değiştirmek için fiziksel erişim gereklidir. (sadece önyükleme amaçlı değişkenler, işletim sistemi yükleyicisi UEFI önyükleme hizmetleri işlevi ExitBootServices’i çağırmadan önce, yalnızca önyükleme sırasında değiştirilebilir). Listeleri yönetmek için ara katman, MokManager UEFI uygulamasını kullanır. MOK’ların nasıl yönetileceğine dair bir kılavuz burada bulunabilir. Şekil 3 , bir MOK’un ara katmanın UEFI Güvenli Önyükleme güven zincirini nasıl genişlettiğini göstermektedir.

Şekil 3 . Linux sistemlerinde basitleştirilmiş UEFI önyükleme akışı (Makine Sahibi Anahtarı ile)

BlackLotus ve Bootkitty ile ilgili bulgularımızda da belirttiğimiz gibi, MOK mekanizması tarafından kullanılan, yalnızca önyükleme sırasında etkin olan NVRAM değişkenlerinin kimlik doğrulaması gerektirmeyen yapısı nedeniyle bootkit’ler UEFI Güvenli Önyükleme’yi başarıyla atlattıktan sonra kalıcılık sağlamak amacıyla MOK’ları kötüye kullanma eğilimindedir.

Güvenli Önyükleme gelişmiş hedefleme (SBAT)

SBAT’ı destekleyen her UEFI uygulaması (bileşeni), PE dosyasının özel bir .sbat bölümünde, ikili dosyanın kendisiyle aynı imzayla korunan küçük bir meta veri parçası taşır. Meta veri, bileşene bir ad verir (örneğin, shim veya grub) ve ona, her güvenlik düzeltmesi yayımlandığında artan bir nesil numarası atar.

Bu numaraları bir iptal mekanizmasına dönüştüren şey, UEFI sisteminin kendisindeki bir eşleştirme politikasıdır. SbatLevel adlı, yalnızca önyükleme sırasında kullanılan bir UEFI değişkeni, bilinen her bileşen için kabul edilebilir minimum nesil numarasını kaydeder. Önemli olan nokta, bu değişkenin firmware tarafından değil, ara katman tarafından yönetilmesi ve uygulanmasıdır; bu da dbx güncellemesine kıyasla daha hızlı iptal güncellemeleri yapılmasına olanak tanır. Ara katman, bu kuralı kendi içine gömer; bu sayede uygulama yalnızca harici değişkene bağlı kalmaz ve SbatLevel aracılığıyla sağlanan daha yeni kuralları da dâhil eder. Her önyüklemede ara katman, kendi SBAT meta verilerini kuralla karşılaştırarak doğrular, böylece güncel olmayan bir ara katmanın kendisini reddetmesi sağlanabilir. Ve ardından yüklediği her ikili dosyaya aynı testi uygular; nesil numarası kuralın gerektirdiği minimum değerin altına düşen her şeyi reddeder.

SBAT iptal örnekleri Şekil 4 adresinde gösterilmiştir. Bunlar, SBAT iptallerinin tek kaynağı olan ara katman deposunda bulunan SbatLevel_Variable.txt dosyasından alınmıştır.

Şekil 4 . Shim deposundaki en son SBAT iptalleri

Uygulanan seviye işletim sisteminden gizlenmez – ara katman, SbatLevel’ın salt okunur bir kopyasını SbatLevelRT adlı bir çalışma zamanı değişkeninde yayımlar. İşletim sistemi, o anda hangi iptal politikasının yürürlükte olduğunu inceleyebilir ancak bunu değiştiremez. Windows’ta aynı bilgiye HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevel kayıt defteri değeri aracılığıyla da ulaşılabilir.

Eski ara katmanlarını kullanarak UEFI Güvenli Önyükleme’yi atlatma

Önceki bölümde bir ara katmanın Güvenli Önyükleme güven zinciri hakkındaki teori açıklandığından, artık unutulmuş ve eski ancak güvenilir olan UEFI ikili dosyalarının UEFI sistem güvenliği üzerinde yaratabileceği pratik etkiye odaklanabiliriz.

Bunu, bildirilen ara katmanlardaki birkaç spesifik sorunu inceleyerek açıklayacağız. Bu sorunlar kolayca istismar edilebilir ve ortaya çıkardıkları saldırı yüzeyinin genişliğini vurgular.

Güvenlik açığı bulunan ikinci aşama önyükleyiciler

Bildirilen her bir ara katman, ara katmanın ikinci aşama önyükleyicileri veya yardımcı programları için bir güven dayanağı görevi gören hem satıcı tarafından yönetilen hem de yerleşik bir ara katman sertifikası içerir: GRUB 2 ikili dosyaları, MokManager, yedek yükleyiciler ve zaman zaman güven zincirini daha da genişleten diğer satıcı tarafından imzalanmış ara katmanlar. Belirli bir ara katman tarafından güvenilen ikili dosyaların sayısı değişkenlik gösterir: Özel ve niş yazılımlar söz konusu olduğunda ondan azken tanınmış Linux dağıtımlarında bu sayı yüze yakındır.

Bildirdiğimiz ara katmanların güvendiği uygulamaların imza ve derleme zaman damgaları 2013 ile 2025 yılları arasında değişmektedir; bu da bu ikili dosyaların önemli bir kısmının eski olduğunu ve GRUB 2 örneğinde daha önce bahsedilen BootHole dâhil olmak üzere, kamuoyunda bilinen çok sayıda güvenlik açığından etkilenmiş olabileceğini doğrulamaya yeterlidir. Bu güvenilir bileşenlerin çoğu, bir miktar güvenlik riski taşıyacak kadar eski olsa da GRUB 2 en zayıf halka gibi görünmektedir. GRUB 2, karmaşık bir yazılım parçasıdır ve eski sürümlerinde buna bağlı olarak güvenlik açıkları birikmektedir.

Bildirdiğimiz ara katmanlar arasında yer alan Oracle Linux’taki ara katmanı ele alalım. Bu ara katman, Oracle Corporation adına düzenlenmiş bir sertifika ile imzalanmış ikili dosyalara güvenmektedir (SHA-1 parmak izi:2E434A724B4759C981E4189AA5AD3D635096DD2F). Bu sertifika ile imzalanmış ikili dosyalardan biri, Oracle Linux 7.1 kurulum ISO’sunda (V74844-01.iso) bulunan bir GRUB 2 ikili dosyasıdır. Ayrıca bu ikili dosya, CVE-2015-5281 güvenlik açığından etkilenmektedir; güvenlik açığı notunda belirtildiği üzere, bu güvenlik açığı “UEFI sistemlerinde kullanıldığında, yerel kullanıcıların amaçlanan Güvenli Önyükleme kısıtlamalarını atlamasına ve özel olarak hazırlanmış (1) multiboot veya (2) multiboot2 modülü aracılığıyla doğrulanmamış kod çalıştırmasına olanak tanır”. Bahsedilen her iki modül, yani multiboot ve multiboot2, sistem başlangıcı sırasında aynı adlı komutlar kullanılarak imzalanmamış kodun yüklenmesine izin verir ve tasarım gereği UEFI Güvenli Önyükleme’yi atladıkları için imzalı UEFI Güvenli Önyükleme uyumlu GRUB 2 ikili dosyalarında yasaklanmalıdır.

Bu istismar yöntemi basittir: Tetiklenecek bellek bozulması hataları yoktur, oluşturulacak ROP zincirleri yoktur ve karmaşık ters mühendislik gerektirmez. Tek ön koşul, özel, imzasız ve multiboot2 uyumlu bir çekirdek görüntüsü oluşturmaktır. Pratikte bu, gerekli başlıkları ve birkaç başka ayrıntıyı içeren bir ELF ikili dosyasından biraz daha fazlasıdır. Saldırgan bu ikili dosyayı oluşturup, güvenlik açığı bulunan ara katman ve GRUB 2 ile birlikte EFI Sistem Bölmesine (ESP) kopyaladığında, Secure Boot etkin olsun ya da olmasın, önyükleme sırasında tek bir GRUB 2 multiboot2 komutu kullanılarak bu dosya yüklenip çalıştırılabilir. UEFI Secure Boot’un etkin olduğu (en son Microsoft yamalarının uygulanmadığı) bir sistemde, daha önce bildirilen eski Oracle Linux ara katmanı aracılığıyla CVE-2015-5281’in istismar edildiğini gösteren bir kavram kanıtı (proof of concept), aşağıdaki videoda gösterilmektedir:

Yeni özelliklerin eksikliği

Yıllar içinde, UEFI ara katman önyükleyicisi doğal olarak gelişmiş ve üst akış UEFI ara katman deposunun ardışık sürümlerinde yeni iyileştirmeler ve güvenlik özellikleri eklenmiştir. Aynı zamanda, birçok üçüncü taraf satıcı, ara katman kaynak kodunun mevcut sürümlerini kullanarak kendi ikili dosyalarını oluşturmuş ve bunları daha sonra imzalanması için Microsoft’a sunmuştur. Bu davranış beklenen bir durumdur ve ara katmanların orijinal tasarımıyla uyumludur. Ancak Microsoft tarafından imzalanmış ve artık geçerliliğini yitirmiş ara katmanların iptal edilmesine yeterince önem verilmemiştir; bu ara katmanların çoğu, tasarımları gereği, daha yeni güvenlik mekanizmalarını atlatmak için kullanılabilir. Bu açığı birkaç somut örnekle açıklıyoruz.

MOK engelleme listesinin uygulanması

MokList (MOK tabanlı izin listesi), neredeyse en başından beri (sürüm 0.3) üst akış UEFI ara katman tarafından desteklenmektedir. Ancak MOK iptalleri (MokListX) sürüm 0.9’da uygulanmaya başlanmıştır. Bu neden bir sorundur? Aşağıdaki senaryoyu ele alalım…

Bir kuruluş, ağında dağıttığı özel UEFI araçlarını ve önyükleyicilerini imzalamak için kendi MOK’unu kaydetmiştir. Bu ikili dosyaların birçoğunda bir güvenlik açığı ortaya çıkmış ve buna karşılık olarak yöneticiler, eski imzalama sertifikasını MOK engelleme listesine (MokListX) ekleyerek iptal etmiştir. Ardından, yeni bir MOK kaydetmiş ve etkilenen ikili dosyaların yamalanmış sürümlerini yeni anahtarla yeniden imzalamışlardır. Eski, güvenlik açığı bulunan ikili dosyalar artık ara katman tarafından reddedilirken yeni imzalanmış olanlar düzgün bir şekilde yüklenir; böylece kuruluşun cihazları güvenli görünür. Eski sertifika MokList’te hâlâ mevcut ve güvenilir olarak kalır ancak daha yüksek öncelikli bir kural olarak uygulanan MokListX’te iptal edilir.

Bu senaryoda bir saldırgan, kurbanın güncel ara katmanlarını raporumuzda yer alan daha eski, Microsoft tarafından imzalanmış bir UEFI ara katmanlarıyla değiştirebilir – örneğin, Finlandiya Matriculation Examination Board için Microsoft tarafından imzalanmış Abitti 1 yazılımının 0.8 sürümü. Bu ara katman, eski MOK sertifikasının hâlâ geçerli olduğu kurbanın MokList değişkeninde depolanan sertifikalara güvenmeye devam eder. Ancak MOK engelleme listesi uygulamasının devreye girmesinden önce oluşturulduğu için MokListX’i yok sayar. Sonuç olarak, saldırganın ara katmanı, kısıtlama olmaksızın güvenlik açığı bulunan ikili dosyaları yüklemek için kullanılabilir ve bu da rastgele kod yürütülmesine veya kötü amaçlı bir UEFI bootkit’in yüklenmesine olanak tanır.

SBAT uygulaması

Aynı sorun SBAT için de geçerlidir. SBAT desteği, ara katman sürüm 15.3’te ana dalda (upstream) eklenmiştir; dolayısıyla daha eski ara katman sürümleri bu mekanizmayı tanımamaktadır: SbatLevel iptal politikasını okumazlar veya yükledikleri ikinci aşama önyükleyicinin .sbat bölümünü incelemezler. Sonuç olarak, güvenlik açığı bulunan bileşenleri engellemeyi amaçlayan daha sonraki SBAT iptallerini göz ardı ederler.

Bu durumda bir saldırı senaryosu şu şekilde olabilir: Bir saldırgan, Microsoft tarafından imzalanmış v15.3 öncesi bir ara katman alır – örneğin, raporumuzda yer alan Red Hat Enterprise Linux 7.2’deki 0.9 sürümü ara katman gibi –, bunu ara katmanın hâlâ güvendiği ancak SBAT tarafından çoktan iptal edilmiş olan çeşitli GRUB 2 ikili dosyalarından biriyle eşleştirir ve ardından her ikisini de ESP’ye kopyalar. Sistem önyüklemesi sırasında ara katman, GRUB 2 ikili dosyasını kendi gömülü sertifikasına göre doğrular, SBAT’a asla danışmaz ve herhangi bir uyarı vermeden güvenlik açığı bulunan ikili dosyayı yükler; bu da saldırganın söz konusu GRUB 2 ikili dosyasındaki herhangi bir güvenlik açığını istismar etmesine olanak tanır.

Bilinen ara katman güvenlik açıkları

Son olarak, eski ara katmanlar basitçe eski kodlardır ve çoğu eski kodda bilinen güvenlik açıkları bulunur. Bunu açıklamak için 0.9 ve daha eski sürümlerdeki ara katmanları etkileyen eski bir sorunun örneğini kullanıyoruz. Bu güvenlik açığına, raporumuz yayımlanana kadar bir CVE kimliği atanmamıştı – oysa bu sorun, neredeyse tam on yıl önce ara katman deposunun bir üst akış commit’i olan d241bbb’deki mesajda düzeltilmiş ve ayrıntılı bir şekilde açıklanmıştı. Artık CVE-2026-10797 olarak takip edilmektedir.

Sorun, Authenticode ile imzalanmış bir PE ikili dosyasının, imzasının uzunluğunu iki ayrı konumda kaydetmesidir:

• PE başlığının veri dizini (IMAGE_DIRECTORY_ENTRY_SECURITY) ve
• imzayı kapsayan WIN_CERTIFICATE yapısı.

Etkilenen ara katmanlarda, iptal kontrolü ile imza doğrulama işlevleri, hangi boyut değerine güvenmeleri gerektiği konusunda farklılık gösteriyordu. İptal kontrolü, imza başlığındaki değeri kullanırken imza doğrulama işlevi ise PE başlığındaki değeri kullanıyordu.

Böylece, ikinci aşama önyükleyicinin WIN_CERTIFICATE yapısını tahrif ederek, iptal işlevinin dbx ve MokListX’i önyükleyicinin gerçek imzası yerine sahte verilerle karşılaştırmasını sağlayarak iptal mekanizmasını atlatmak mümkündür.

Basitçe ifade etmek gerekirse ikinci aşama önyükleyicinin sertifikası dbx veya MokListX’te iptal edilmiş olsa bile ara katman bunu fark edemez. Burada iki önemli not bulunmaktadır:

• bu atlama yöntemi yalnızca sertifika tabanlı iptal işlemlerinde (hash tabanlı iptal işlemlerinde değil) işe yarar ve
• ikinci aşama önyükleyicinin, ara katmana gömülü bir sertifika ile imzalanmış olması gerekir (bu, ara katmanın derleme sürecinde oluşturulan yerleşik sertifika veya satıcı sertifikası olabilir).

Bu sınırlamalar, hash tabanlı iptal işlemlerinin ve gömülü olmayan sertifikaların (MokList ve db’den gelenler) kodun başka bir yerinde kontrol edildiği ve bu sorundan etkilenmediği gerçeğinden kaynaklanmaktadır.

Süresi dolan Microsoft UEFI sertifikaları bu sorunu çözmez mi?

Mevcut Microsoft UEFI sertifika son kullanma tarihlerini göz önünde bulundurursak (Şekil 5 ’te gösterildiği üzere, Microsoft Corporation UEFI CA 2011 sertifikasının son kullanma tarihi 27 Haziran 2026’dır), bu süresi dolmuş sertifika ile imzalanmış güvenlik açığı bulunan UEFI uygulamalarının rapor edilmesinin sadece gereksiz bir gürültüye yol açıp açmadığını merak edebiliriz.

Gerçek şu ki UEFI sertifikasının son kullanma tarihi, Güvenli Önyükleme (Secure Boot) doğrulama süreci üzerinde hiçbir etkiye sahip değildir. Microsoft Corporation UEFI CA 2011 sertifikası db’de kalırsa ve dbx’te iptal edilmezse bu süresi dolmuş sertifika ile geçerli bir şekilde imzalanmış tüm önyükleyiciler, hash ile açıkça iptal edilmedikçe güvenilir olarak kalır. Microsoft’un, son kullanma tarihine kadar yeni gönderimleri eski sertifika ile imzalamaya devam etmesinin nedeni budur.

Şekil 5 . Microsoft Corporation UEFI CA 2011 sertifikası

Koruma ve algılama

Bu güvenlik açığına sahip ara katmanlar, Microsoft’un en son UEFI iptal listeleri uygulanarak engellenebilir. Windows sistemleri otomatik olarak güncellenmelidir. Şekil 6 Windows sisteminizde gerekli iptal listelerinin yüklü olup olmadığını kontrol etmek için (yükseltilmiş izinlerle çalıştırılması gereken) PowerShell komutlarını göstermektedir.

Şekil 6 . UEFI iptallerini kontrol etmek için PowerShell komutları

Linux sistemleri için güncellemeler, Linux Vendor Firmware Service aracılığıyla sağlanmalıdır ve iptal durumu uefi-dbx-audit komut dosyası kullanılarak kontrol edilebilir.

Bilinmeyen, güvenlik açığı bulunan imzalı UEFI önyükleyicilerin kötüye kullanılmasına ve UEFI bootkit’lerin dağıtımına karşı nasıl korunulacağına (veya en azından bunların nasıl tespit edileceğine) ilişkin daha genel öneriler için “UEFI Güvenli Önyükleme’nin Gizemi: CVE-2024-7344’ün Tanıtımı” başlıklı blog yazımıza bakın.

Sonuç

Bu eski ara katmanları tehlikeli kılan şey yeni bir güvenlik açığı değil; UEFI Güvenli Önyükleme’yi atlatmak için yeni bir güvenlik açığına gerek olmamasıdır. Bir saldırganın karmaşık istismar yöntemlerine ihtiyacı yoktur, sadece eski, hâlâ güvenilir ancak iptal edilmemiş bir ara katman ikili dosyasının bir kopyası ve UEFI ara katmanlarının nasıl çalıştığına dair temel bir anlayış yeterlidir. Bu, UEFI Güvenli Önyükleme gibi hayati bir güvenlik özelliğini atlatmak için yeterlidir.

Bu 11 ara katmanın iptal edilmesi acil sorunu çözmüş olsa da daha köklü bir sorun hâlâ devam ediyor: Görünürlük. Ara katman imzalama süreci, 2017 yılında “shim-review” deposunun devreye girmesiyle önemli ölçüde daha şeffaf hâle geldi; bu depoda, satıcıların gönderdiği ara katmanlar Microsoft tarafından imzalanmadan önce bakım sorumluları tarafından inceleniyor. O zamandan beri onaylanan her ara katman belgelenmiştir; ancak daha önce imzalanmış olanlar belgelenmemiştir ve kimse bu eski, hâlâ güvenilir kabul edilen ara katmanlardan kaç tanesinin kaldığını kesin olarak söyleyemez. Tam ve şeffaf bir şekilde kataloglanmamış olan şeyler etkili bir şekilde kullanımdan kaldırılamaz.

Olumlu bir not olarak, eğilimin doğru yönde ilerlediğine inanıyoruz. Bunun gibi her bir açıklama, unutulmuş ara katman havuzunu küçültür ve ara katman imzalama şeffaflığının artması ve SBAT gibi mekanizmalar sayesinde, hangi ara katmanların iptal edilmesi gerektiğini takip etmek ve bunları etkili bir şekilde iptal etmek, geçmişte olduğundan çok daha verimli bir şekilde gerçekleştirilebilir. Bir sonraki adım, Microsoft’un üçüncü taraf UEFI imzalama ekosistemindeki bu şeffaflık düzeyini, ara katman içermeyen üçüncü taraf UEFI uygulamalarına da genişletmektir; bu uygulamalar, defalarca gösterildiği üzere (örn. CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …) UEFI Güvenli Önyükleme’yi atlamanın basit bir kaynağı olarak işlev görebilir.

IOC’ler

Güvenlik açığı bulunan ara katmanlar, bu yükleyiciler aracılığıyla hiçbir zaman güvenliği ihlal edilmemiş binlerce sistemde potansiyel olarak bulunabilen meşru yazılım paketlerinin bir parçası olduğundan, büyük çaplı yanlış tanımlamaları önlemek amacıyla saldırı göstergeleri sunmuyoruz. Bunun yerine, güvenlik uzmanları Koruma ve tespit bölümündeki tavsiyelere uymalıdır.