UEFI Bootkit: Bootkitty pada Linux dan warisan BlackLotus

Informatec Digital » Linux » UEFI Bootkit: Bootkitty pada Linux dan warisan BlackLotus

The Kit but UEFI telah menjadi salah satu vektor yang paling mengganggu dalam landskap ancaman moden: mereka berjalan sebelum sistem pengendalian, boleh melumpuhkan pertahanan, dan mencapai kegigihan dengan keistimewaan yang tinggi. Dalam beberapa tahun kebelakangan ini, kita telah pergi dari semata-mata Bukti konsep kepada kes aktif sebenar seperti BlackLotus pada Windows, dan kini reka bentuk berorientasikan Linux pertama muncul, dipanggil Bootkitty, yang membuka peringkat baharu untuk ekosistem perisian percuma.

Artikel ini menyusun dan menyusun maklumat penting daripada berbilang sumber yang diiktiraf untuk menerangkan cara Kit but UEFI, apakah yang membezakan Bootkitty pada Linux, mengapa BlackLotus menandakan sebelum dan selepas dalam Windows, apakah penunjuk kompromi yang perlu diberi perhatian dan apa langkah-langkah pertahanan memohon. Selain itu, kes yang berkaitan seperti LoJax, ESPecter, MoonBounce dan MosaicRegressor dibincangkan, serta peraturan dan taktik pengesanan MITRE ATT&CK yang berkaitan.

Apakah itu bootkit UEFI dan mengapa ia menimbulkan risiko yang serius?

Kit but UEFI ialah kod berniat jahat yang dijalankan pada peringkat awal but, apabila perisian tegar memulakan komputer dan sebelum sistem operasi mengambil kawalan. Dengan beroperasi pada tahap yang begitu rendah, mereka boleh menghalang mekanisme seperti pengesahan tandatangan atau memuatkan pemacu yang sah, menggunakan muatan dalam mod kernel atau pengguna dan kekal tersembunyi daripada banyak tindakan balas tradisional.

Adalah penting untuk membezakan antara tahap perisian hasad but yang berbeza: implan firmware (cth. LoJax pada 2018) mengubah suai secara langsung denyar SPI, manakala bootkit biasanya terletak pada partition sistem EFI (ESP) yang lebih mudah diakses, tetapi dengan keupayaan sama seperti mengambil kawalan awal proses permulaan.

Evolusi kelemahan baru-baru ini dalam UEFI dan kekurangan pembatalan tepat pada masanya Perduaan yang rosak dalam pangkalan data pembatalan (dbx) telah memudahkan pelaku serangan menyalahgunakan komponen yang ditandatangani tetapi terdedah kepada memintas Boot Selamat, seperti yang berlaku dengan eksploitasi CVE-2022-21894 (Baton Drop) dalam kes BlackLotus.

Konteks sejarah: daripada PoC pada Windows kepada kes di alam liar

Demonstrasi awam besar pertama a Kit but UEFI Pembangunan moden bermula sejak 2012, apabila Andrea Allievi mendokumentasikan PoC yang mampu berjalan dalam persekitaran Windows dengan UEFI. Ini diikuti dengan ujian lain—EfiGuard, Boot Backdoor, UEFI-bootkit—yang menunjukkan kemungkinan teknikal pendekatan tersebut.

Selepas peringkat pertama percubaan itu, ia mengambil masa bertahun-tahun untuk ancaman aktif pada sistem sebenar. Pada tahun 2021, ESPecter (disiasat oleh ESET) dan bootkit FinSpy (dianalisis oleh Kaspersky) telah dikeluarkan, dan pada tahun 2023, BlackLotus, bootkit pertama yang diketahui untuk memintas UEFI Secure Boot, telah dikeluarkan. peralatan yang dikemas kini sepenuhnya dengan Windows 11.

Sehingga baru-baru ini, semua kes ini mempunyai satu persamaan: mereka berorientasikan secara eksklusif WindowsParadigma ini dipecahkan dengan penemuan Bootkitty, tertumpu pada Ubuntu dan, oleh itu, pada dunia Linux.

Bootkitty: bootkit UEFI pertama memfokuskan pada Linux

Pada November 2024, aplikasi UEFI yang tidak diketahui (bootkit.efi) yang, selepas analisis, ternyata Bootkitty, bootkit UEFI pertama direka untuk Linux, khusus untuk versi Ubuntu tertentu. Menurut telemetri yang ada, tiada bukti penyebaran di alam liar; semuanya menunjuk kepada a bukti konsep awal, dengan pelbagai artifak pembangunan.

Kemas kini penting: Pada awal Disember 2024, pengesahan muncul bahawa ini adalah projek akademik yang dibangunkan oleh peserta dalam program Korean Best of the Best (BoB). Objektif yang dinyatakan ialah tingkatkan kesedaran tentang risiko dan menggalakkan langkah proaktif. Sekeping ini sesuai dengan apa yang diperhatikan oleh penganalisis: kit but berfungsi tetapi dengan sokongan terhad dan tanda-tanda PoC, bukan senjata siap untuk kempen besar-besaran.

Keserasian PoC, tandatangan dan isyarat

Bootkitty ditandatangani dengan a sijil yang ditandatangani sendiri, jadi ia gagal dijalankan jika Secure Boot didayakan melainkan sijil penyerang ditambah secara manual. Walau bagaimanapun, logiknya cuba meneruskan but kernel dengan normal menampal fungsi pengesahan dalam ingatan sebelum GRUB melepaskan kawalan.

Keserasiannya adalah terhad. Untuk mencari fungsi untuk diubah suai, gunakan corak bait berkod yang tidak merangkumi berbilang kernel atau versi GRUB, menjadikannya beroperasi hanya dalam konfigurasi tertentu dan terdedah kepada ranap jika offset tidak sepadan dengan versi Hadir.

Antara artifak PoC, dua rutin menonjol yang mencetak pada skrin seni ASCII dengan nama itu Bootkitty dan senarai kemungkinan pengarang; selain itu, pada permulaan ia memaparkan rentetan dan rujukan tertentu seperti "BlackCat" yang tidak berkaitan dengan kumpulan perisian tebusan ALPHV/BlackCat. Binari juga menimpa rentetan versi dan sepanduk Linux dengan teks "BoB13".

Rantai pelaksanaan dan cangkuk dalam UEFI dan GRUB

Semasa permulaan, Bootkitty menyemak status SecureBoot membaca pembolehubah UEFI dengan nama yang sama. Ia kemudian memasang cangkuk dalam protokol pengesahan UEFI — EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication dan EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState — untuk memaksa EFI_SUCCESS akibatnya, menafikan penilaian sebenar integriti imej UEFI PE.

Kemudian, muatkan dari ESP GRUB yang sah yang terletak di laluan berkod keras /EFI/ubuntu/grubx64-real.efi (mungkin salinan yang didepositkan oleh penyerang). Dengan GRUB dalam ingatan, belum berjalan, bootkit tompok dan cangkuk beberapa perkara kritikal, termasuk:

• peimage::start_image (dibenamkan dalam GRUB), untuk memintas saat stub kernel EFI (vmlinuz.efi) dimuatkan ke dalam memori. Dari sini, Bootkitty mencari dan menampal rutin yang bertanggungjawab untuk penyahmampatan kernel, kemungkinan besar zstd_decompress_dctx bergantung kepada binaan.
• shim_lock_verifier_init, sebahagian daripada shim_lock dalam GRUB, walaupun cangkuk yang digunakan tidak relevan kerana cangkuk lain menghalangnya daripada dilaksanakan, dan pengubahsuaian juga memperkenalkan bendera GRUB_VERIFY_FLAGS_SINGLE_CHUNK, yang secara teorinya mengeras pengesahan.
• grub_verifiers_open, yang diubah untuk kembali serta-merta tanpa menggunakan semakan tandatangan, sekali gus meneutralkan aliran biasa pengesahan dalam GRUB.

Cangkuk penyahmampatan kernel dan tampalan memori

Cangkuk penyahmampatan kernel memulihkan bait asal buat sementara waktu, membenarkan fungsi tulen untuk menyahmampat imej, dan kemudian menggunakan tampalan pada ingatan daripada kernel yang telah berkembang. Fasa ini penting untuk melumpuhkan kawalan dan menyediakan untuk memuatkan modul tambahan atau binari.

Secara khusus, logik yang diperhatikan menulis semula rentetan versi dengan “BoB13”, mengubah suai fungsi modul_sig_check untuk mengembalikan 0 (jadi kernel menerima modul yang tidak ditandatangani walaupun dengan Secure Boot didayakan, dengan CONFIG_MODULE_SIG_FORCE atau dengan module.sig_enforce=1), dan menggantikan pembolehubah persekitaran pertama bagi proses init oleh “LD_PRELOAD=/opt/injector.so /init”.

Idea di sebalik LD_PRELOAD adalah untuk memaksa pemuatan keutamaan a ELF dikongsi untuk menulis ganti fungsi atau memasukkan logik tambahan, teknik biasa dalam serangan userland. Kehadiran "/init" dalam nilai LD_PRELOAD sangat menarik; makna yang tepat tidak sepenuhnya jelas dan mengukuhkan tafsiran yang sedang kita hadapi a perkembangan awal.

Semasa ujian makmal, sistem memaparkan kernel sebagai tercemar selepas boot dengan Bootkitty; sebagai tambahan, dalam dmesg anda boleh melihat rentetan yang diubah suai dan jejak pembolehubah LD_PRELOAD, yang juga boleh dilihat dalam /proc/1/environ. Pada komputer dengan Secure Boot didayakan, petunjuk empirikal ialah kernel bersetuju untuk memuatkan modul tidak bertandatangan semasa runtime, yang tidak sepatutnya berlaku tanpa tampalan terlebih dahulu.

BCDropper dan BCObserver: bahagian tambahan yang berkaitan

Secara selari, modul kernel yang tidak ditandatangani digelar BCDropper, dimuat naik ke VirusTotal oleh pengirim yang sama seperti bootkit. Ia mengandungi rujukan kepada "BlackCat" dalam rentetan dan laluan penyahpepijatan, dan ciri penyembunyian fail (menapis nama dengan awalan seperti "penyuntik”, sejajar dengan LD_PRELOAD menunjuk ke /opt/injector.so).

BCDropper mengekstrak ELF terbenam yang dipanggil BCObserver dalam /opt/observer dan jalankannya melalui /bin/bash. Ia juga mengalih keluar jejaknya sendiri daripada senarai modul yang dimuatkan dan menyediakan fungsi untuk rootkit yang biasa (menyembunyikan fail, proses, port), walaupun penitis tidak mengeksploitasi kesemuanya secara langsung.

BCObserver, sebaliknya, menunggu pengurus paparan bermula. gdm3 dan kemudian cuba memuatkan /opt/rootkit_loader.ko menggunakan syscall modul_finit, memastikan modul disuntik apabila sistem telah melengkapkan but grafik.

Tidak ada kepastian mutlak bahawa kepingan ini dikaitkan dengan pengarang yang sama seperti Bootkitty, tetapi tampalan modul_sig_check mencadangkan bahawa tujuannya adalah untuk membenarkan pemuatan modul yang tidak ditandatangani, sesuai dengan apa yang dilakukan oleh BCRopper/BCObserver.

IoC dan Teknik MITRE ATT&CK yang berkaitan

berikut penunjuk penglibatan dan klasifikasi boleh membantu dalam mencari isyarat awal dalam persekitaran Linux di mana PoC mungkin telah diuji:

SHA-1	nama	Pengesanan	Huraian
35ADF3AED60440DA7B80F3C452047079E54364C1	bootkit.efi	EFI/Agen.A	Bootkitty Kit but UEFI.
BDDF2A7B3152942D3A829E63C03C7427F038B86D	penitis.ko	Linux/Rootkit.Agent.FM	BCDropper.
E8AF4ED17F293665136E17612D856FA62F96702D	pemerhati	Linux/Rootkit.Agent.FM	BCObserver.

Pemetaan MITRE ATT&CK yang paling menonjol untuk set kepingan ini dan tingkah laku yang diperhatikan, berguna untuk a Model Ancaman penting:

Taktik	ID	nama	Huraian
Pembangunan Sumber	T1587.001	Membangunkan Keupayaan: Perisian hasad	Bootkitty ialah seorang Kit but UEFI baru.
	T1587.002	Membangunkan Keupayaan: Sijil Menandatangani Kod	Sampel ditandatangani dengan disahkan ditandatangani sendiri.
Pelaksanaan	T1106	API asli	Kegunaan BCObserver modul_finit untuk memuatkan LKM.
	T1129	Modul Dikongsi	Kekuatan bootkitty LD_PRELAD dalam init.
Kegigihan	T1574.006	Aliran Pelaksanaan Rampasan: Rampasan Penghubung Dinamik	Menampal Persekitaran INIT dengan LD_PRELOAD.
	T1542.003	But Pra-OS: Bootkit	Kerahan dalam ESP.
Pengelakan Pertahanan	T1014	rootkit	BCDropper sebagai LKM untuk penyembunyian.
	T1562	Menjejaskan Pertahanan	Lumpuhkan pengesahan bagi firma dalam GRUB dan kernel.
	T1564	Sembunyikan Artifak	Sembunyikan modul anda daripada senarai modul daripada kernel.

Jejak pada sistem Linux dan cadangan mitigasi

Petunjuk forensik seperti rentetan versi kernel yang diubah telah diperhatikan dalam pemasangan Ubuntu yang terjejas. BoB13 (kelihatan dengan uname -v), pengubahsuaian pada sepanduk but (dmesg) dan kehadiran LD_PRELOAD dalam /proc/1/environKernel mungkin ditandakan sebagai tercemar, tingkah laku yang tidak berlaku tanpa bootkit.

Penyelesaian pantas apabila bootkit menggantikan GRUB adalah untuk mengembalikan fail GRUB yang sah. /EFI/ubuntu/grubx64-real.efi ke lokasi asalnya di /EFI/ubuntu/grubx64.efi supaya shim but GRUB tulen. Ingat bahawa ini hanya meliputi pentas khusus yang mana penggunaannya adalah seperti ini.

BlackLotus: kes paradigmatik dalam Windows

BlackLotus menjadi terkenal kerana dapat melaksanakannya Kit but UEFI walaupun pada Windows 11 yang ditambal sepenuhnya dengan Secure Boot didayakan. Ia dijual pada harga $5.000 ($200 setiap peningkatan) sejak Oktober 2022, dengan geofencing untuk mengelakkan sistem dari Armenia, Belarus, Kazakhstan, Moldova, Romania, Rusia dan Ukraine.

Mengeksploitasi kelemahan CVE-2022 21894- (Baton Drop), ditambal oleh Microsoft pada Januari 2022, tetapi masih boleh dieksploitasi beberapa ketika kemudian kerana binari yang terdedah dan ditandatangani masih tidak ditambahkan pada senarai Pembatalan UEFI (dbx). Pemasang memasukkan salinan pemuat but terdedah yang ditandatangani secara sah untuk mencapai kegigihan dan memintas But Secure.

Antara kebolehannya, dia mampu melumpuhkan BitLocker, Memory Integrity (HVCI) dan Microsoft Defender, gunakan a pemandu dalam kernel yang melindungi fail bootkit pada ESP dan pemuat turun HTTP mod pengguna yang berjalan dalam winlogon.exe, dengan teknik anti-VM, anti-penyahpepijat dan pengeliruan. Saiz bootkit adalah kecil (sekitar 80 KB), yang lebih disukai kerahsiaan.

Rantaian dalaman dan artifak ingin tahu telah didokumenkan, seperti rujukan kepada siri ini higurashi dalam nama komponen dan sijil yang ditandatangani sendiri, serta mesej yang tidak digunakan. Butiran ini tidak mengurangkan bahayanya, tetapi ia memberikan konteks tentangnya pembangunan.

Cara Windows Melindungi But: But Secure, But Trusted, ELAM dan Measured Boot

Di Windows, rantaian but kepercayaan bergantung pada beberapa lapisan. Boot selamat mengesahkan tandatangan perisian tegar dan pemuat but; Boot Dipercayai mengesahkan integriti kernel dan komponen but; ELAM mengutamakan memuatkan pemacu antimalware sebelum pemacu but bukan Microsoft yang lain; dan But Terukur merekodkan cincang dalam TPM untuk pengesahan jauh.

Secara lalai, komputer yang diperakui menyertakan Secure Boot didayakan dan mempercayai sijil. microsoft dan pemuat lain yang diluluskan. Walau bagaimanapun, memastikan UEFI CA pihak ketiga Microsoft didayakan memperluaskan permukaan serangan kepada amanah dalam pemuat but pelbagai pengedaran, termasuk yang mempunyai kelemahan yang diketahui. Banyak peranti kernel yang dikeraskan memerlukan melumpuhkan kepercayaan pada CA pihak ketiga untuk mengeraskan postur lalai.

Untuk membenarkan Linux dalam persekitaran yang dilindungi, pendekatan yang disyorkan ialah tambah secara eksplisit menandatangani pemuat but yang diingini ke pangkalan data UEFI atau, sebagai pilihan terakhir, melumpuhkan Secure Boot — langkah yang mengurangkan perlindungan terhadap but butWalau apa pun, perubahan ini memerlukan campur tangan manual dalam perisian tegar dan tidak boleh diautomasikan oleh perisian hasad.

Pengesahan dengan But Terukur membenarkan pelayan yang dipercayai untuk menilai sama ada titik akhir mengekalkan rantai butnya secara utuh. TPM menandatangani bukti dan, digabungkan dengan telemetri tambahan, memungkinkan untuk mengasingkan peranti yang terjejas pada rangkaian cuarentena sehingga pemulihannya.

Peraturan pengesanan dan pengawasan proaktif

Di luar instrumentasi Windows asli, komuniti telah menerbitkan Peraturan Sigma berguna untuk mengesan aktiviti yang berkaitan dengan senario ini. Ini termasuk mencipta fail perisian tegar di bawah System32 melalui proses bukan sistem, atau melumpuhkan Pengesanan Integriti Memori (HVCI) menggunakan kekunci pendaftaran (teknik MITRE ATT&CK T1562 dan T1112). Pengesanan ini dipetakan kepada berbilang SIEM/EDR/XDR.

Untuk Linux, ia adalah mudah untuk mengaitkan acara boot (journald/dmesg), perubahan kepada pembolehubah persekitaran uname -v dan PID 1, serta menyemak beban modul yang tidak ditandatangani atau operasi curiga tentang ESP. Mengintegrasikan jejak ini dengan peraturan tingkah laku dalam EDR meningkatkan kebarangkalian untuk mendedahkan percubaan ketekunan awal.

Gambaran yang lebih besar: LoJax, ESPecter, MoonBounce, MosaicRegressor dan isyarat baharu

Implan firmware UEFI pertama yang diperhatikan di alam liar ialah LoJax (2018), diikuti dengan kempen dengan MosaicRegressor dan MoonBounce, yang terkenal kerana meningkatkan tahap kecanggihan dalam rootkit UEFI. Pada tahun 2021, ESPecter dan bootkit FinSpy menunjukkan bahawa peringkat pra-OS masih menjadi sasaran menarik untuk actores maju.

Dalam bidang Linux, Bootkitty telah menjadi yang pertama prueba berfungsi seumpamanya, dengan skop terhad. Dan seawal 2025, rujukan telah muncul untuk "HibridPetya” sebagai evolusi keluarga Petya dengan keupayaan bootkit UEFI, dengan sampel dimuat naik ke VirusTotal daripada Polonia. Walaupun analisis masih awal, ia adalah peringatan bahawa kategori ancaman ini terus wujud. pengembangan.

Cadangan praktikal untuk mengurangkan risiko

Dalam persekitaran Linux, kekalkan Boot selamat aktif, menggunakan perisian tegar (UEFI) dan kemas kini kernel, dan memastikan senarai pembatalan (dbx) dikemas kini adalah tiang yang tidak boleh dirunding. Pantau modul.sig_enforce ditetapkan kepada 1 atau itu CONFIG_MODULE_SIG_FORCE didayakan jika sesuai dan elakkan memuatkan modul daripada sumber yang tidak dipercayai.

Audit partition dengan kerap ESP Ia mengimbas perubahan yang tidak dibenarkan pada laluan seperti /EFI/ubuntu/grubx64.efi dan mengesahkan bahawa tiada salinan yang mencurigakan (grubx64-real.efi). Sebarang perubahan pada aliran pengesahan GRUB mesti disiasat.

Dalam Windows, sebagai tambahan kepada Secure Boot, ia menguatkuasakan Trusted Boot, membolehkan HVCI apabila disokong oleh perkakasan, dan menerima pakai pengesahan jauh berasaskan TPM dengan dasar akses bersyarat. Meminimumkan pergantungan pada CA pihak ketiga jika tidak diperlukan dan mempercepatkan penerimaan pembatalan apabila mereka menerbitkan kegagalan dalam komponen but.

Sesetengah penyelesaian komersial menyepadukan pengimbas UEFI yang mampu menyemak perisian tegar untuk ralat. komponen berniat jahatESET mendakwa sebagai satu-satunya vendor dalam 20 hasil titik akhir teratas yang menawarkan keupayaan bersepadu ini kepada pelanggannya, pendekatan yang boleh menambah nilai dalam pertahanan perkakasan yang mendalam.

Trajektori kempen baru-baru ini menjelaskan bahawa pautan permulaan kekal sebagai objektif keutamaan. telemetri Dengan pengerasan perisian tegar/pemuat but yang betul dan semakan integriti yang sistematik, adalah mungkin untuk meningkatkan bar dengan ketara dan menjadikan kehidupan lebih sukar bagi pembangun. musuh.

Keadaan seni yang Kit but UEFI mengesahkan bahawa garis antara PoC dan operasi sebenar semakin pantas: Bootkitty menunjukkan bahawa Linux sudah menjadi tumpuan, BlackLotus menyatukan daya maju pada Windows, dan ekosistem pertahanan mesti mengutamakan kebersihan but, pengemaskinian dbx dan pemantauan IoC dan pengesahan jauh untuk mengurangkan sebarang percubaan kegigihan pra-OS sejak awal.