Bootkitty: Linux için ilk UEFI önyükleme setinin analizi

ESET araştırmacıları Linux sistemleri için tasarlanan ilk UEFI bootkit’i analiz etti. Karşınızda Bootkitty.

Geçtiğimiz birkaç yıl içinde UEFI tehdit ortamı, özellikle de UEFI önyükleme kitleri önemli ölçüde gelişti. Her şey 2012 yılında Andrea Allievi tarafından açıklanan ve modern UEFI tabanlı Windows sistemlerinde bootkitlerin dağıtımının bir gösterimi olarak hizmet eden ilk UEFI bootkit kavram kanıtı (PoC) ile başladı ve bunu diğer birçok PoC izledi (EfiGuard, Boot Backdoor, UEFI-bootkit). İlk iki gerçek UEFI önyükleme kitinin keşfedilmesi birkaç yıl aldı (ESPecter, 2021 ESET; FinSpy bootkit, 2021 Kaspersky) ve güncel sistemlerde UEFI güvenli önyüklemeyi atlayabilen ilk UEFI bootkit olan kötü şöhretli BlackLotus‘un ortaya çıkması iki yıl daha sürdü (2023, ESET). 

Kamuoyunca bilinen bu bootkit’ler arasındaki ortak nokta Windows sistemlerini özel olarak hedeflemeleriydi. Bugün, en son keşfimizi açıklıyoruz: Linux sistemleri için tasarlanmış ilk UEFI bootkit, yaratıcıları tarafından Bootkitty olarak adlandırıldı. Bu bootkit’in yalnızca bir kavram kanıtı olduğuna inanıyoruz ve telemetrimize dayanarak, aslında konuşlandırılmadığını düşünüyoruz. Bununla birlikte varlığı önemli bir mesajın altını çizmektedir: UEFI önyükleme kitleri artık yalnızca Windows sistemleriyle sınırlı değil.

Bootkit’in ana hedefi çekirdeğin imza doğrulama özelliğini devre dışı bırakmak ve Linux init süreci (sistem başlangıcı sırasında Linux çekirdeği tarafından yürütülen ilk süreç) aracılığıyla henüz bilinmeyen iki ELF ikilisini önceden yüklemektir. Analizimiz sırasında, bootkit ile aynı yazar(lar) tarafından geliştirilmiş olabileceğini düşündüren işaretlerle birlikte, analizimiz sırasında bilinmeyen başka bir çekirdek modülünü yüklemekten sorumlu bir ELF ikilisini dağıtan, muhtemelen ilgili imzasız bir çekirdek modülü keşfettik.

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

• Kasım 2024’te, daha önce bilinmeyen bootkit.efi adlı bir UEFI uygulaması VirusTotal‘a yüklendi.
• İlk analizimiz, yaratıcıları tarafından Bootkitty olarak adlandırılan ve şaşırtıcı bir şekilde Linux’u, özellikle de birkaç Ubuntu sürümünü hedefleyen ilk UEFI önyükleme kiti olan bir UEFI önyükleme kiti olduğunu doğruladı.
• Bootkitty kendinden imzalı bir sertifika ile imzalanmıştır, bu nedenle saldırganların sertifikaları yüklenmediği sürece UEFI güvenli önyükleme etkinleştirilmiş sistemlerde çalışamaz.
• Bootkitty, UEFI güvenli önyükleme etkin olsun ya da olmasın, GRUB çalıştırılmadan önce bütünlük doğrulamasından sorumlu gerekli işlevleri bellekte yamaladığı için Linux çekirdeğini sorunsuz bir şekilde önyüklemek üzere tasarlanmıştır. 
• bootkit.efi, bunun aktif bir tehdit aktörünün çalışmasından ziyade bir kavram kanıtı olduğunu gösteren birçok eser içerir. 
• BCDropper adını verdiğimiz ve başka bir çekirdek modülünü yüklemekten sorumlu bir ELF programını dağıtan, muhtemelen ilişkili bir çekirdek modülü keşfettik.

Linux için BOOTKITTY’ye genel bakış

Giriş bölümünde de belirtildiği gibi, Bootkitty aktif olarak kullanılan bir kötü amaçlı yazılım yerine bir kavram kanıtı ile karşı karşıya olabileceğimizi düşündüren birçok eser içermektedir. Bu bölümde, bu eserlere ve bootkit ile ilgili diğer temel bilgilere daha yakından bakacağız.

Bootkitty, çalıştırılması sırasında ekrana özel dizeler yazdırabilen iki kullanılmayan işlev içerir. Çıktısı şu şekilde gösterilen ilk fonksiyon Şekil 1, bootkit’in olası bir adını temsil ettiğine inandığımız ASCII resmini yazdırabilir: Bootkitty.

Şekil 1. Bootkit içine gömülü ASCII sanatı

İkinci işlev, aşağıda gösterilen metni yazdırabilir Şekil 2 olası bootkit yazarlarının ve geliştirilmesine bir şekilde katılmış olabilecek diğer kişilerin listesini içerir. Resimde belirtilen isimlerden biri GitHub’da bulunabilir ancak profilde bir UEFI önyükleme seti projesi içeren veya bundan bahseden herhangi bir genel depo yoktur; bu nedenle önyükleme setinde belirtilen isimlerin gerçekliğini ne doğrulayabilir ne de reddedebiliriz.

Şekil 2. Bootkit’e gömülü isimlerin listesi (redakte edilmiştir)

Her önyükleme sırasında Bootkitty ekrana aşağıda gösterilen dizeleri yazdırır Şekil 3.

Şekil 3. Bootkitty’nin hoş geldiniz mesajı

BlackCat adına daha sonra açıklanan yüklenebilir çekirdek modülünde de atıfta bulunulduğuna dikkat edin. İsme rağmen, ALPHV/BlackCat fidye yazılımı grubuyla bir bağlantı olmadığını düşünüyoruz. Bunun nedeni BlackCat’in araştırmacılar tarafından kullanılan bir isim olması ve Bootkitty’nin C dilinde geliştirilmiş olması, grubun ise kendisini ALPHV olarak adlandırması ve kötü amaçlı yazılımlarını yalnızca Rust dilinde geliştirmesidir.

Daha önce de belirtildiği gibi, Bootkitty şu anda yalnızca sınırlı sayıda sistemi desteklemektedir. Bunun nedeni, bellekte değiştirmek istediği işlevleri bulmak için kodlanmış bayt kalıplarını kullanmasıdır. Bayt deseni eşleştirme, bootkit’ler söz konusu olduğunda yaygın bir teknik olsa da yazarlar birden fazla çekirdek veya GRUB sürümünü kapsamak için en iyi desenleri kullanmamışlardır; bu nedenle bootkit yalnızca sınırlı sayıda yapılandırma için tamamen işlevseldir. Bootkit’in kullanımını daha da sınırlayan şey, sıkıştırılmış Linux çekirdeğini yamalama şeklidir: gösterildiği gibi Şekil 4 Çekirdek görüntüsü açıldıktan sonra Bootkitty kötü niyetli yamaları çekirdek görüntüsü içindeki sabit kodlanmış ofsetlere kopyalar. 

Şekil 4. Bootkitty kodu, çalıştırılmadan önce sıkıştırılmış çekirdeğin yamalanmasından sorumludur

Bootkit’in gerçek çekirdek yamalama işlemini nasıl yaptığını daha sonra açıklayacağız. Linux çekirdeği görüntü sıkıştırma kancasıbölümünde gösterilen işlevde çekirdek sürümü kontrollerinin olmaması nedeniyle şimdilik Şekil 4 Bootkitty, bu sabit kodlanmış ofsetlere tamamen rastgele kod veya veri ekleme noktasına gelebilir böylece sistemi tehlikeye atmak yerine çökertebilir. Bu, kavram kanıtını destekleyen gerçeklerden biridir. Öte yandan, kötü niyetli tehdit aktörleri tarafından oluşturulan kötü amaçlı yazılımın üretime hazır olmayan ilk sürümü de olabilir.

Son olarak, bootkit ikili dosyası şu adreste gösterilen kendinden imzalı sertifika tarafından imzalanır Şekil 5.

Şekil 5. Bootkitty’yi imzalamak için kullanılan kendinden imzalı sertifika

Teknik analiz

Şurada gösterildiği gibi Şekil 6 Bootkitty’nin yürütülmesine genel bir bakışla başlıyoruz. İlk olarak, ana işlevselliği kısaca açıklıyoruz ve sonraki bölümlerde daha fazla ayrıntı paylaşacağız. 

Odaklandığımız üç ana bölüm var:

• Bootkit’in çalıştırılması ve meşru GRUB önyükleyicisinin yamalanması (4. ve 5. noktalar Şekil 6).
• Linux çekirdeğinin EFI saplama yükleyicisinin yamalanması (6. ve 7. maddeler Şekil 6).
• Sıkıştırılmış Linux çekirdek görüntüsünün yamalanması (8. ve 9. noktalar Şekil 6).

Şekil 6. Bootkitty yürütmeye genel bakış

Başlatma ve GRUB kancası

Bootkitty shim tarafından çalıştırıldıktan sonra SecureBoot UEFI değişkeninin değerini inceleyerek UEFI güvenli önyüklemenin etkin olup olmadığını kontrol eder ve etkinse UEFI kimlik doğrulama protokollerinden iki işlevi kancalamaya devam eder (bu işlem Şekil 7):

• EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication: bu işlev ürün yazılımı tarafından UEFI PE görüntülerinin bütünlüğünü ölçmek ve doğrulamak için kullanılır. Bootkitty’nin kanca işlevi bu işlevin çıktısını her zaman EFI_SUCCESS döndürecek şekilde değiştirir, yani doğrulamanın başarılı olduğu anlamına gelir.
• EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState: bu işlev, farklı kimlik doğrulama durumu değerlerine yanıt olarak platforma özgü bir politika yürütmek için ürün yazılımı tarafından kullanılır. Yine, bootkit’in kancası bunu her zaman EFI_SUCCESS değerini döndürecek şekilde değiştirir, yani ürün yazılımı dosyayı gerçek kimlik doğrulama durumundan bağımsız olarak kullanabilir.

Şekil 7. UEFI güvenlik kimlik doğrulama protokollerinin kancalanması

UEFI güvenli önyükleme durumunu kontrol ettikten sonra Bootkitty, EFI sistem bölümündeki kodlanmış yoldan meşru GRUB’u yüklemeye devam eder: /EFI/ubuntu/grubx64-real.efi. Bu dosya, saldırgan tarafından meşru bir GRUB’un oluşturulmuş bir yedeği olmalıdır. GRUB yüklendikten sonra (henüz çalıştırılmamış), bootkit yama yapmaya ve GRUB’un belleğine aşağıdaki kodu bağlamaya başlar:

• peimage GRUB modülü (GRUB içine gömülü bir modül) içindeki start_image işlevi. Bu işlev önceden yüklenmiş bir PE imajını başlatmaktan sorumludur ve Linux çekirdeğinin EFI saplama ikilisini (genel olarak vmlinuz.efi veya vmlinuz olarak bilinir) başlatmak için GRUB tarafından çağrılır. Kanca işlevi, kancanın çalıştırıldığı anda vmlinuz’un zaten belleğe yüklenmiş (ancak henüz çalıştırılmamış) olmasından yararlanır ve vmlinuz içindeki gerçek Linux çekirdek görüntüsünü açmaktan sorumlu işlevi yamalar (bazı durumlarda, Linux çekirdeğinin derlenme şekli nedeniyle yamalanan işlevin tam adını bulmak oldukça zor olabilir; ancak bu sefer bunun zstd_decompress_dctx işlevi olması gerektiğine inanıyoruz). Sıkıştırmayı açma kancası hakkında daha fazla ayrıntıyı Linux çekirdeği görüntü sıkıştırma kancası bölümünde bulabilirsiniz.
• GRUB içindeki shim_lock doğrulayıcı mekanizmasının bir parçası olan shim_lock_verifier_init işlevi – UEFI güvenli önyükleme etkinleştirilirse otomatik olarak etkinleştirilmelidir. Sağlanan dosyaların (örneğin GRUB modülleri, Linux çekirdeği, yapılandırmalar…) önyükleme sırasında doğrulanması gerekip gerekmediğine karar vermekten sorumludur. Bununla birlikte, kurulan kanca bir şekilde kafa karıştırıcıdır ve yazarın niyeti belirsizdir çünkü shim_lock_verifier_init’in çıktısını, sağlanan herhangi bir dosya türü için çıktı bayrağını GRUB_VERIFY_FLAGS_SINGLE_CHUNK (değer 2) olarak ayarlayacak şekilde değiştirir. GRUB kılavuzuna göre güvenliği daha da güçlendirin. İlginç bir şekilde, bir sonraki noktada açıklanan kanca nedeniyle bu shim_lock_verifier_init işlevi önyükleme sırasında bile çağrılmaz, böylece önemsiz hale gelir.
• grub_verifiers_open işlevi. Bu fonksiyon GRUB tarafından her dosya açıldığında çağrılır ve yüklü GRUB dosya doğrulayıcılarının (yukarıda açıklanan shim_lock doğrulayıcısı da buna dahildir) yüklenen dosya için bütünlük doğrulaması gerektirip gerektirmediğini kontrol etmekten sorumludur. İşlev bootkit tarafından herhangi bir imza kontrolüne geçmeden hemen geri dönecek şekilde bağlanır (bunun daha önce bağlanan shim_lock_verifier_init işlevini bile çalıştırmadığı anlamına geldiğini unutmayın).

Linux çekirdeği görüntü sıkıştırma kancası

Bu kanca, sıkıştırılmış Linux çekirdek görüntüsünün yamanmasından sorumludur. Kanca, çekirdek görüntüsünün sıkıştırması açılmadan hemen önce çağrılır, bu nedenle kanca orijinal sıkıştırma açma işlevinin baytlarını geri yükler ve çekirdek yamasına geçmeden önce çekirdek görüntüsünün sıkıştırmasını açmak için orijinal işlevi çalıştırır. 

Artık çekirdek sıkıştırılmamış olduğundan ve bellekte dokunulmadan durdukça (hala çalıştırılmamıştır), kanca kodu onu sabit kodlanmış uzaklıklarda (yalnızca bellekte) yamalar. Özellikle, aşağıda gösterildiği gibi Şekil 8:

• Çekirdek sürümünü ve Linux başlık dizelerini BoB13 metni ile yeniden yazar (bunun sistem üzerinde önemli bir etkisi yoktur).
• module_sig_check işlevini kancalar.
• init sürecinin ilk ortam değişkenine işaretçi/adres ekler. 

Şekil 8. Bootkitty’nin vmlinuz içindeki kernel-decompression kancası

module_sig_check işlevi her zaman 0 döndürmek üzere yamalanmıştır. Bu fonksiyon modülün geçerli bir şekilde imzalanıp imzalanmadığını kontrol etmekten sorumludur. Fonksiyonu 0 dönecek şekilde yamaladığınızda çekirdek imzayı doğrulamadan herhangi bir modülü yükleyecektir. UEFI güvenli önyüklemenin etkin olduğu Linux sistemlerinde, çekirdek modülleri yüklenmek isteniyorsa imzalanmalıdır. Çekirdek CONFIG_MODULE_SIG_FORCE etkinleştirilerek oluşturulduğunda ya da Linux çekirdeği belgelerinde açıklandığı gibi module.sig_enforce=1 bir çekirdek komut satırı argümanı olarak geçildiğinde de durum böyledir. Muhtemel senaryo, aşağıdaanaliz edilen damlalık gibi en az bir kötü niyetli çekirdek modülünün daha sonraki bir aşamada yüklenmiş olmasıdır.

Linux çekirdeğinin çalıştırdığı ilk işlem, komut satırı argümanları ve ortam değişkenleriyle birlikte çalışan ilk kodlanmış yoldan (initramfs’den /init ile başlayarak) init’tir. Kanca kodu ilk ortam değişkenini LD_PRELOAD=/opt/injector.so /init ile değiştirir. LD_PRELOAD, ELF paylaşılan nesnelerini diğerlerinden önce yüklemek için kullanılan ve işlevleri geçersiz kılmak için kullanılabilen bir ortam değişkenidir. Saldırganlar tarafından kötü amaçlı ikili dosyaları yüklemek için kullanılan yaygın bir tekniktir. Bu durumda, init işlemi başladığında /opt/injector.so ve /init ELF paylaşılan nesneleri yüklenir. Burada niyet daha az açık hale gelir, özellikle de /init ikinci dizesinin neden LD_PRELOAD’un bir parçası olduğu.

Bu, muhtemelen kötü amaçlı ELF paylaşılan nesnelerinden hiçbirini keşfetmedik ancak bu blog yazısı yayımlanmak üzere son haline getirilirken raporumuzda belirtilen eksik bileşenleri açıklayan bir yazı yayımlandı. Artık sadece başka bir aşamayı yüklemek için kullanıldıkları da açıktır.

Linux sistemlerde etki

Bootkitty, bilinmeyen ELF paylaşılan nesnelerini yüklemenin yanı sıra sistemde ayak izleri bırakır. Bunlardan ilki, gerekli olmasa da çekirdek sürümü ve Linux başlık dizelerinin değiştirilmesidir. İlki uname -v çalıştırılarak görülebilir (Şekil 9) ve ikincisini dmesg (Şekil 10).

Şekil 9. Uname çıktısında BoB13 dizesi

Şekil 10. dmesg çıktısında BoB13 dizesi

Analizimiz sırasında, dmesg komutunun çıktısı init sürecinin nasıl çalıştırıldığına ilişkin ayrıntıları da içeriyordu. Şekil 11’de gösterildiği gibi işlem LD_PRELOAD ortam değişkeniyle çalıştırıldı (başlangıçta HOME=/ idi ve bootkit tarafından LD_PRELOAD=/opt/injector.so /init ile değiştirildi).

Şekil 11. dmesg çıktısındaki init süreci argümanları ve ortam değişkenleri

Şekil 11’de  ilk satırdaki /init kelimesinin, initramfs’de bulunan ve varsayılan Ubuntu kurulumlarında kontrolü systemd’ye devreden meşru programa karşılık geldiğini görebilirsiniz. LD_PRELOAD ortam değişkeninin varlığı /proc/1/environ dosyası incelenerek de doğrulanabilir.

Test ortamımızda Bootkitty ile bir sistemi başlattıktan sonra, çekirdeğin kusurlu olarak işaretlendiğini fark ettik (komut Şekil 12 kusurlu değeri kontrol etmek için kullanılabilir), bootkit olmadığında durum böyle değildi. UEFI güvenli önyüklemenin etkin olduğu sistemde bootkit’in mevcut olup olmadığını anlamanın bir başka yolu da çalışma zamanı sırasında imzasız bir kukla çekirdek modülü yüklemeye çalışmaktır. Eğer mevcutsa modül yüklenir; değilse çekirdek modülü yüklemeyi reddeder.

Şekil 12. Sistem Bootkitty ile başlatıldıktan hemen sonra kusurlu durum

Bootkit’ten kurtulmak için basit bir çözüm önerisi, meşru /EFI/ubuntu/grubx64-real.efi dosyasını /EFI/ubuntu/grubx64.efi olan orijinal konumuna geri taşımaktır. Bu, shim’in meşru GRUB’u çalıştırmasını sağlayacak ve böylece sistem bootkit olmadan açılacaktır (bunun yalnızca bootkit’in /EFI/ubuntu/grubx64.efi olarak dağıtıldığı senaryoyu kapsadığını unutmayın). 

Linux için BCDropper ve BCObserver

Bootkit’e ek olarak, BCDropper adını verdiğimiz, VirusTotal’e bootkit ile aynı zamanda ve aynı gönderici kimliği ile yüklenen ve bootkit ile aynı yazar tarafından geliştirilmiş olabileceğine dair ipuçları içeren, muhtemelen ilişkili bir imzasız çekirdek modülü keşfettik:

• Şekil 13‘de gösterilen modinfo komutunun çıktısındaki bir BlackCat dizesi,
• Şekil 14‘de gösterilen modülün ikili dosyasındaki hata ayıklama yollarında blackcat dizesinin başka bir varlığı,
• Dizin listelerinden belirli girdileri gizleyen kullanılmayan bir dosya gizleme işlevi içerir. Şekil 15 ‘de gösterildiği gibi bu girdileri filtrelemek için kullanılan kodlanmış dosya adı dizesi öneklerinden biri injector’dur (Bootkitty’nin /opt/injector.so yolundan bir paylaşımlı kütüphaneyi önceden yüklemeye çalıştığını unutmayın).

Bununla birlikte sunulan kanıtlarla bile çekirdek modülünün Bootkitty ile ilgili olup olmadığını (veya aynı geliştirici tarafından oluşturulup oluşturulmadığını) kesin olarak söyleyemeyiz. Ayrıca belirtilen çekirdek sürümü Şekil 13 (6.8.0-48-generic) bootkit tarafından desteklenmemektedir.

Şekil 13. Damlalık modülü bilgileri

Şekil 14. Blackcat’i referans alan dropper hata ayıklama sembolleri

Şekil 15. Damlalıkta gizlenecek dosyaların listesi

Adından da anlaşılacağı gibi, çekirdek modülü BCObserver adını verdiğimiz gömülü bir ELF dosyasını özellikle /opt/observer dosyasına bırakır ve /bin/bash (Şekil 17) aracılığıyla çalıştırır. Bunun da ötesinde, modül, modül listesinden girişini kaldırarak kendini gizler. Çekirdek modülü ayrıca dosyaları, süreçler ve açık bağlantı noktaları gizlemek gibi rootkit ile ilgili diğer işlevleri de uygular (Şekil 15) ancak bunlar damlalık tarafından doğrudan kullanılmaz.

Şekil 16. Hex-Rays derlenmiş damlalık kodu

BCObserver, görüntü yöneticisi gdm3 çalışana kadar bekleyen ve ardından finit_module sistem çağrısı aracılığıyla /opt/rootkit_loader.ko adresinden bilinmeyen bir çekirdek modülünü yükleyen oldukça basit bir uygulamadır. Kod, görüntü yöneticisinin başlamasını bekleyerek, sistem tamamen açıldıktan sonra çekirdek modülünün yüklenmesini sağlar.

Şekil 17. Hex-Rays derlenmiş gözlemci kodu

Damlalığın bootkit ile bir şekilde ilişkili olup olmadığını ve eğer öyleyse nasıl çalıştırılacağını doğrulayamasak da bootkit’in module_sig_check işlevini bir nedenle yamaladığından ve imzasız bir çekirdek modülünün (burada açıklanan damlalık gibi) yüklenmesinin kesinlikle mantıklı olacağından eminiz.

Sonuç

Bir kavram kanıtı olsun ya da olmasın, Bootkitty UEFI tehdit ortamında ilginç bir ilerlemeye işaret ediyor ve modern UEFI önyükleme kitlerinin Windows’a özel tehditler olduğu inancını kırıyor. VirusTotal’daki mevcut sürüm şu anda Linux sistemlerinin çoğunluğu için gerçek bir tehdit oluşturmasa da gelecekteki potansiyel tehditlere karşı hazırlıklı olmanın gerekliliğini vurgulamaktadır.

Linux sistemlerinizi bu tür tehditlere karşı güvende tutmak için UEFI güvenli önyüklemenin etkin olduğundan sistem yazılımınızın ve işletim sisteminizin güncel olduğundan ve UEFI iptal listenizin de güncel olduğundan emin olun. 

IOC’ler

Kapsamlı bir uzlaşma göstergeleri (IoC’ler) listesi ve örnekleri GitHub depomuzda bulunabilir.

Dosyalar

MITRE ATT&CK teknikleri

Bu tablo MITRE ATT&CK çerçevesinin 16. sürümü kullanılarak oluşturulmuştur.