Số lượng lỗ hổng UEFI được phát hiện trong những năm gần đây và những thất bại trong việc vá chúng hoặc thu hồi các tệp nhị phân dễ bị tổn thương trong một khoảng thời gian hợp lý đã không được các tác nhân đe dọa chú ý. Do đó, bộ khởi động UEFI được biết đến công khai đầu tiên bỏ qua tính năng bảo mật nền tảng thiết yếu – Khởi động an toàn UEFI – giờ đã trở thành hiện thực. Trong bài đăng trên blog này, chúng tôi trình bày phân tích công khai đầu tiên về bộ công cụ khởi động UEFI này, bộ công cụ này có khả năng chạy trên các hệ thống Windows 11 thậm chí được cập nhật đầy đủ có bật Khởi động an toàn UEFI. Chức năng của bộ công cụ khởi động và các tính năng riêng lẻ của nó khiến chúng tôi tin rằng chúng tôi đang xử lý một bộ công cụ khởi động được gọi là Hoa sen đen, bộ khởi động UEFI được bán trên các diễn đàn hack với giá 5,000 đô la kể từ ít nhất là tháng 2022 năm XNUMX.

Bộ công cụ khởi động UEFI là mối đe dọa rất mạnh, có toàn quyền kiểm soát quá trình khởi động của hệ điều hành và do đó có khả năng vô hiệu hóa các cơ chế bảo mật khác nhau của hệ điều hành cũng như triển khai tải trọng chế độ người dùng hoặc chế độ nhân của riêng chúng trong các giai đoạn khởi động hệ điều hành ban đầu. Điều này cho phép chúng hoạt động rất lén lút và có đặc quyền cao. Cho đến nay, chỉ một số ít được phát hiện trong tự nhiên và được mô tả công khai (ví dụ: nhiều mẫu EFI độc hại chúng tôi đã phát hiện vào năm 2020 hoặc các bộ khởi động UEFI đầy đủ tính năng như phát hiện của chúng tôi vào năm ngoái – Bộ công cụ khởi động ESPecter - hoặc là Bộ khởi động FinSpy được phát hiện bởi các nhà nghiên cứu từ Kaspersky).

Bộ công cụ khởi động UEFI có thể thua về khả năng tàng hình khi so sánh với bộ cấy chương trình cơ sở – chẳng hạn như LoJax; bộ cấy chương trình cơ sở UEFI tự nhiên đầu tiên, được nhóm của chúng tôi phát hiện vào năm 2018 – vì bộ công cụ khởi động được đặt trên phân vùng đĩa FAT32 dễ truy cập. Tuy nhiên, việc chạy dưới dạng bộ tải khởi động cung cấp cho chúng các khả năng gần như giống như cấy ghép phần sụn, nhưng không phải vượt qua các biện pháp bảo vệ flash SPI đa cấp, chẳng hạn như các bit bảo vệ BWE, BLE và PRx hoặc các biện pháp bảo vệ do phần cứng cung cấp (như Intel Boot Guard ). Chắc chắn, UEFI Secure Boot cản trở các bộ khởi động UEFI, nhưng có một số lỗ hổng đã biết không đáng kể cho phép bỏ qua cơ chế bảo mật thiết yếu này. Và điều tồi tệ nhất là một số trong số chúng vẫn có thể dễ dàng bị khai thác trên các hệ thống cập nhật ngay cả tại thời điểm viết bài này – bao gồm cả hệ thống bị BlackLotus khai thác.

Cuộc điều tra của chúng tôi bắt đầu với một số lần truy cập vào thứ hóa ra là thành phần chế độ người dùng BlackLotus – trình tải xuống HTTP – trong phép đo từ xa của chúng tôi vào cuối năm 2022. Sau khi đánh giá ban đầu, các mẫu mã được tìm thấy trong các mẫu đã đưa chúng tôi đến việc phát hiện ra sáu BlackLotus trình cài đặt (cả trên VirusTotal và trong phép đo từ xa của chúng tôi). Điều này cho phép chúng tôi khám phá toàn bộ chuỗi thực thi và nhận ra rằng những gì chúng tôi đang xử lý ở đây không chỉ là phần mềm độc hại thông thường.

Sau đây là những điểm chính về BlackLotus và mốc thời gian tóm tắt chuỗi sự kiện liên quan đến nó:

• Nó có khả năng chạy trên các hệ thống Windows 11 mới nhất, được vá đầy đủ có bật Khởi động an toàn UEFI.
• Nó khai thác lỗ hổng hơn một năm tuổi (CVE-2022-21894) để bỏ qua UEFI Secure Boot và thiết lập tính bền vững cho bộ khởi động. Đây là lần đầu tiên được biết đến công khai, lạm dụng lỗ hổng này.
• Mặc dù lỗ hổng đã được khắc phục trong bản cập nhật tháng 2022 năm XNUMX của Microsoft, nhưng việc khai thác lỗ hổng vẫn có thể xảy ra do bị ảnh hưởng, ký hợp lệ nhị phân vẫn chưa được thêm vào Danh sách thu hồi UEFI. BlackLotus tận dụng lợi thế này, đưa các bản sao hợp pháp – nhưng dễ bị tổn thương – của chính họ vào hệ thống để khai thác lỗ hổng.
• Nó có khả năng vô hiệu hóa các cơ chế bảo mật của hệ điều hành như BitLocker, HVCI và Windows Defender.
• Sau khi được cài đặt, mục tiêu chính của bootkit là triển khai trình điều khiển kernel (trong số những thứ khác, bảo vệ bootkit khỏi bị xóa) và trình tải xuống HTTP chịu trách nhiệm liên lạc với C&C và có khả năng tải các tải trọng chế độ người dùng hoặc chế độ kernel bổ sung .
• BlackLotus đã được quảng cáo và bán trên các diễn đàn ngầm từ ít nhất là ngày 6 tháng XNUMX^th, 2022. Trong bài đăng trên blog này, chúng tôi đưa ra bằng chứng cho thấy bootkit là có thật và quảng cáo không chỉ đơn thuần là lừa đảo.
• Thật thú vị, một số trình cài đặt BlackLotus mà chúng tôi đã phân tích không tiến hành cài đặt bootkit nếu máy chủ bị xâm nhập sử dụng một trong các ngôn ngữ sau:
  • Rumani (Moldova), ro-MD
  • Tiếng Nga (Moldova), ru-MD
  • Tiếng Nga (Nga), ru-RU
  • Ukraina (Ukraine) , uk-UA
  • Bêlarut (Belarus), be-BY
  • Tiếng Armenia (Armenia), hy-AM
  • Tiếng Kazakh (Kazakhstan), kk-KZ

Dòng thời gian của các sự kiện riêng lẻ liên quan đến BlackLotus được hiển thị trong Hình 1.

Hình 1. Dòng thời gian của các sự kiện chính liên quan đến bộ khởi động BlackLotus UEFI

Như đã đề cập, bootkit đã được bán trên các diễn đàn ngầm kể từ ít nhất là ngày 6 tháng XNUMX^th, 2022. Tại thời điểm này, chúng tôi chưa thể xác định, từ phép đo từ xa của mình, kênh phân phối chính xác được sử dụng để triển khai bootkit cho các nạn nhân. Số lượng mẫu BlackLotus thấp mà chúng tôi có thể thu được, cả từ các nguồn công khai và từ phép đo từ xa của chúng tôi, khiến chúng tôi tin rằng vẫn chưa có nhiều tác nhân đe dọa bắt đầu sử dụng nó. Nhưng cho đến khi việc thu hồi các bộ tải khởi động dễ bị tấn công mà BlackLotus phụ thuộc vào xảy ra, chúng tôi lo ngại rằng mọi thứ sẽ thay đổi nhanh chóng nếu bộ khởi động này lọt vào tay các nhóm phần mềm tội phạm nổi tiếng, dựa trên khả năng lây lan dễ dàng của bộ khởi động và các nhóm phần mềm tội phạm. phần mềm độc hại bằng cách sử dụng botnet của họ.

Đây thực sự là BlackLotus?

Có một số bài viết hoặc bài viết tổng hợp thông tin về BlackLotus (tại đây, tại đây và tại đây và nhiều hơn nữa…), tất cả dựa trên thông tin được cung cấp bởi nhà phát triển bootkit trên các diễn đàn hack ngầm. Cho đến nay, không ai xác nhận hoặc bác bỏ những tuyên bố này.

Dưới đây là bản tóm tắt của chúng tôi về các tuyên bố từ các ấn phẩm có sẵn so với những gì chúng tôi đã phát hiện ra trong khi thiết kế ngược các mẫu bootkit:

• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng nó có tính năng bỏ qua Khởi động an toàn tích hợp. Việc thêm các trình điều khiển dễ bị tổn thương vào danh sách thu hồi UEFI hiện là không thể vì lỗ hổng ảnh hưởng đến hàng trăm bộ tải khởi động vẫn được sử dụng cho đến ngày nay. ✅
  • Đúng: Nó khai thác CVE-2022-21894 để phá vỡ Khởi động an toàn và đạt được sự bền bỉ trên các hệ thống hỗ trợ UEFI-Secure-Boot. Trình điều khiển dễ bị tổn thương mà nó sử dụng vẫn chưa bị thu hồi trong phiên bản mới nhất dbx, tại thời điểm viết bài.
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng bộ khởi động có tính năng bảo vệ Ring0/Kernel tích hợp chống lại việc xóa. ✅
  • Đúng: Trình điều khiển hạt nhân của nó bảo vệ các tay cầm thuộc các tệp của nó trên Phân vùng hệ thống EFI (ESP) khỏi bị đóng. Là một lớp bảo vệ bổ sung, các tay cầm này được theo dõi liên tục và Màn hình xanh chết chóc (BSOD) được kích hoạt nếu bất kỳ tay cầm nào trong số này bị đóng, như được mô tả trong Bảo vệ các tệp bootkit trên ESP khỏi bị xóa phần.
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng nó đi kèm với các tính năng chống máy ảo (chống VM), chống gỡ lỗi và mã hóa để chặn các nỗ lực phân tích phần mềm độc hại. ✅
  • Đúng: Nó chứa nhiều kỹ thuật chống máy ảo, chống gỡ lỗi và che giấu dữ liệu để làm cho việc sao chép hoặc phân tích trở nên khó khăn hơn. Tuy nhiên, chúng tôi chắc chắn không nói về bất kỳ kỹ thuật chống phân tích đột phá hoặc nâng cao nào ở đây, vì chúng có thể dễ dàng vượt qua mà không tốn nhiều công sức.
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng mục đích của nó là hoạt động như một trình tải xuống HTTP. ✅
  • Đúng: Thành phần cuối cùng của nó hoạt động như một trình tải xuống HTTP, như được mô tả trong Trình tải xuống HTTP phần
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng trình tải xuống HTTP chạy dưới tài khoản HỆ THỐNG trong một quy trình hợp pháp. ✅
  • Đúng: Trình tải xuống HTTP của nó chạy trong winlogon.exe bối cảnh quy trình.
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng nó là một bootkit nhỏ với kích thước trên đĩa chỉ 80 kB. ✅
  • Đúng: Các mẫu mà chúng tôi có thể thu được thực sự là khoảng 80 kB.
• Quảng cáo của BlackLotus trên các diễn đàn hack tuyên bố rằng nó có thể vô hiệu hóa các biện pháp bảo vệ tích hợp sẵn của Windows như HVCI, Bitlocker, Windows Defender và bỏ qua Kiểm soát tài khoản người dùng (UAC). ✅

Dựa trên những dữ kiện này, chúng tôi tin tưởng chắc chắn rằng bộ khởi động mà chúng tôi phát hiện được ngoài tự nhiên là bộ khởi động BlackLotus UEFI.

Tổng quan về cuộc tấn công

Sơ đồ đơn giản hóa của chuỗi thỏa hiệp BlackLotus được hiển thị trong Hình 2. Nó bao gồm ba phần chính:

1. Nó bắt đầu với việc thực thi một trình cài đặt (bước 1 trong Hình 2), trình cài đặt này chịu trách nhiệm triển khai các tệp của bộ công cụ khởi động vào phân vùng Hệ thống EFI, vô hiệu hóa HVCI và BitLocker, sau đó khởi động lại máy.
2. Sau lần khởi động lại đầu tiên, khai thác CVE-2022-21894 và đăng ký tiếp theo của những kẻ tấn công Khóa chủ sở hữu máy (MOK) xảy ra, để đạt được sự bền bỉ ngay cả trên các hệ thống đã bật Khởi động an toàn UEFI. Sau đó, máy được khởi động lại (các bước 2–4 trong Hình 2).
3. Trong tất cả các lần khởi động tiếp theo, bộ khởi động UEFI tự ký được thực thi và triển khai cả trình điều khiển hạt nhân và tải trọng chế độ người dùng, trình tải xuống HTTP. Cùng với nhau, các thành phần này có thể tải xuống và thực thi các thành phần trình điều khiển và chế độ người dùng bổ sung từ máy chủ C&C và bảo vệ bộ công cụ khởi động khỏi bị xóa (bước 5–9 trong Hình 2).

Hình 2. Tổng quan về thực thi đơn giản của BlackLotus

hiện vật thú vị

Mặc dù chúng tôi tin rằng đây là bộ công cụ khởi động BlackLotus UEFI, nhưng chúng tôi không tìm thấy bất kỳ tham chiếu nào đến tên này trong các mẫu mà chúng tôi đã phân tích. Thay vào đó, mã có đầy đủ các tham chiếu đến Higurashi khi họ khóc sê-ri phim hoạt hình, ví dụ như trong các tên thành phần riêng lẻ, chẳng hạn như higurashi_installer_uac_module.dll và higurashi_kernel.sysvà cả trong chứng chỉ tự ký được sử dụng để ký mã nhị phân bootkit (hiển thị trong Hình 3).

Hình 3. Chứng chỉ tự ký được sử dụng bởi BlackLotus bootkit

Ngoài ra, mã giải mã nhưng không bao giờ sử dụng các chuỗi khác nhau chứa thông báo từ tác giả BlackLotus (như trong Hình 4 – lưu ý rằng sự băm nhỏ là một nhà nghiên cứu nổi tiếng và là tác giả của nhiều công cụ phân tích phần mềm độc hại khác nhau), hay chỉ là một số trích dẫn ngẫu nhiên từ các bài hát, trò chơi hoặc sê-ri khác nhau.

Hình 4. Ví dụ về các thông báo do tác giả BlackLotus để lại trong mã

Quá trình cài đặt

Chúng tôi bắt đầu với việc phân tích các trình cài đặt BlackLotus. Bộ công cụ khởi động dường như được phân phối dưới dạng trình cài đặt có hai phiên bản – ngoại tuyến và trực tuyến. Sự khác biệt giữa hai điều này là ở cách chúng có được các tệp nhị phân Windows hợp pháp (nhưng dễ bị tổn thương), sau này được sử dụng để bỏ qua Khởi động an toàn.

• Trong các phiên bản ngoại tuyến, các tệp nhị phân của Windows được nhúng trong trình cài đặt
• Trong các phiên bản trực tuyến, các tệp nhị phân Windows được tải xuống trực tiếp từ cửa hàng biểu tượng của Microsoft. Cho đến nay, chúng tôi đã thấy các chương trình nhị phân Windows sau đây bị BlackLotus bootkit lạm dụng:
  • https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
  • https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
  • https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi

Mục tiêu của trình cài đặt rất rõ ràng – nó chịu trách nhiệm vô hiệu hóa các tính năng bảo mật của Windows như mã hóa đĩa BitLocker và HVCI, đồng thời chịu trách nhiệm triển khai nhiều tệp, bao gồm cả bộ khởi động độc hại, tới ESP. Sau khi hoàn tất, nó sẽ khởi động lại máy bị xâm nhập để cho phép các tệp bị rớt thực hiện công việc của chúng – nhằm đảm bảo bộ khởi động UEFI tự ký sẽ được thực thi âm thầm trong mỗi lần khởi động hệ thống, bất kể trạng thái bảo vệ Khởi động an toàn của UEFI.

Bước 0 – Khởi tạo và độ cao (tiềm năng)

Khi trình cài đặt được thực thi, nó sẽ kiểm tra xem nó có đủ đặc quyền hay không (ít nhất là yêu cầu của quản trị viên) để triển khai phần còn lại của tệp vào ESP và thực hiện các hành động khác yêu cầu quy trình nâng cao – như tắt HVCI hoặc tắt BitLocker. Nếu không phải như vậy, nó sẽ cố gắng nâng cấp bằng cách thực hiện lại trình cài đặt bằng cách sử dụng phương pháp bỏ qua UAC được mô tả chi tiết tại đây: Bỏ qua UAC thông qua trợ lý Tương thích Chương trình.

Với các đặc quyền cần thiết, nó tiếp tục, kiểm tra trạng thái Khởi động an toàn UEFI bằng cách đọc giá trị của biến SecureBoot UEFI bằng chức năng Windows API có sẵn và xác định phiên bản Windows bằng cách truy cập trực tiếp vào KUSER_SHARED_DATA trường cấu trúc Phiên bản NtMajor và Phiên bản NtMinor trong trí nhớ. Nó làm như vậy để quyết định xem có cần bỏ qua UEFI Secure Boot hay không để triển khai bộ công cụ khởi động trên hệ thống của nạn nhân (vì hỗ trợ Khởi động an toàn lần đầu tiên được thêm vào trong Windows 8 và có thể không được bật trên bất kỳ máy cụ thể nào).

Trước khi tiếp tục các bước tiếp theo, nó đổi tên Windows Boot Manager hợp pháp (bootmgfw.efi) nhị phân nằm trong ESP: EFIMicrosoftBoot thư mục để winload.efi. cái này đổi tên bootmgfw.efi bản sao lưu sau đó được bộ công cụ khởi động sử dụng để khởi chạy HĐH hoặc để khôi phục chuỗi khởi động ban đầu nếu nhận được lệnh “gỡ cài đặt” từ máy chủ C&C – xem thêm trong truyền thông C&C phần.

Bước 1 – Triển khai tệp

Nếu Khởi động an toàn UEFI được bật, trình cài đặt sẽ tiến hành thả nhiều tệp vào ESP:/EFI/Microsoft/Khởi động/ và ESP:/system32/ thư mục. Mặc dù cái trước là một thư mục tiêu chuẩn được sử dụng bởi Windows, nhưng cái sau là một thư mục tùy chỉnh được tạo bởi trình cài đặt.

Bảng 1 cung cấp danh sách các tệp do trình cài đặt bỏ qua cùng với giải thích ngắn gọn về vai trò của từng tệp trong chuỗi thực thi. Chúng tôi sẽ giải thích chi tiết cách thức hoạt động của chuỗi thực thi sau; bây giờ chỉ cần lưu ý rằng một số tệp hợp pháp do Microsoft ký đã bị loại bỏ cùng với các tệp độc hại.

Bảng 1. Các tệp được triển khai bởi trình cài đặt BlackLotus trên các hệ thống có bật Khởi động an toàn UEFI

Trong trường hợp nạn nhân đang chạy phiên bản Windows không hỗ trợ UEFI Secure Boot hoặc trong trường hợp nó bị vô hiệu hóa, việc triển khai khá đơn giản. Điều duy nhất cần thiết để triển khai bộ công cụ khởi động độc hại là thay thế Trình quản lý khởi động Windows hiện có (bootmgfw.efi) nhị phân trong ESP: EFIMicrosoftBoot thư mục, với ứng dụng UEFI độc hại tự ký của kẻ tấn công. Vì Khởi động an toàn UEFI bị tắt (và do đó không có xác minh tính toàn vẹn nào được thực hiện trong quá trình khởi động), nên việc khai thác là không cần thiết và phần sụn UEFI chỉ thực thi trình quản lý khởi động độc hại mà không gây ra bất kỳ vi phạm bảo mật nào.

Bước 2 – Vô hiệu hóa tính toàn vẹn của mã được bảo vệ bởi Hypervisor (HVCI)

Để có thể chạy mã hạt nhân chưa ký tùy chỉnh sau này, trình cài đặt phải đảm bảo rằng HVCI bị vô hiệu hóa trên hệ thống. Một trong những đồng nghiệp ESET của chúng tôi đã viết một bài đăng trên blog rất nhiều thông tin về chủ đề này vào năm 2022 (Trình điều khiển nhân đã ký - Cổng vào không được bảo vệ vào lõi của Windows):

Bảo mật dựa trên ảo hóa (VBS) cung cấp một số tính năng bảo vệ với tính năng nổi bật nhất là Tính toàn vẹn mã được bảo vệ bởi Hypervisor (HVCI), cũng là một tính năng độc lập. HVCI thực thi tính toàn vẹn của mã trong nhân và chỉ cho phép thực thi mã đã ký. Nó ngăn chặn hiệu quả việc các trình điều khiển dễ bị lợi dụng để thực thi mã hạt nhân chưa được ký hoặc tải các trình điều khiển độc hại (bất kể phương pháp khai thác được sử dụng) và có vẻ như phần mềm độc hại lợi dụng các trình điều khiển dễ bị tổn thương để tải mã độc là một trong những động lực chính đằng sau việc Microsoft triển khai tính năng này.

Như thể hiện trong Hình 5, để tắt tính năng này, trình cài đặt sẽ đặt giá trị đăng ký Đã bật trong hộp kiểm Tính toàn vẹn của HypervisorEnforcedCode khoá đăng ký về không.

Hình 5. Mã dịch ngược Hex-Rays của chức năng cài đặt BlackLotus chịu trách nhiệm vô hiệu hóa HVCI

Bước 3 – Vô hiệu hóa BitLocker

Tính năng tiếp theo bị tắt bởi trình cài đặt là BitLocker Drive Encryption. Lý do cho điều này là BitLocker có thể được sử dụng kết hợp với Trusted Platform Module (TPM) để đảm bảo rằng các tệp khởi động và cấu hình khác nhau, bao gồm Khởi động an toàn, không bị giả mạo do mã hóa ổ đĩa BitLocker được định cấu hình trên hệ thống. Xem xét rằng trình cài đặt sửa đổi chuỗi khởi động Windows trên một máy bị xâm nhập, việc bật BitLocker cho các hệ thống có hỗ trợ TPM sẽ dẫn đến màn hình khôi phục BitLocker ở lần khởi động tiếp theo và thông báo cho nạn nhân biết rằng hệ thống đã bị xâm phạm.

Để tắt tính năng bảo vệ này, trình cài đặt BlackLotus:

• đi qua tất cả các tập dưới RootCIMV2SecurityMicrosoftVolumeEncryption không gian tên WMI và kiểm tra trạng thái bảo vệ của chúng bằng cách gọi Nhận trạng thái bảo vệ phương pháp của Win32_EncryptableVolume Lớp WMI
• đối với những người được bảo vệ bởi BitLocker, nó gọi Vô hiệu hóa KeyProtectors phương pháp với Vô hiệu hóa tham số được đặt thành XNUMX, nghĩa là tính năng bảo vệ sẽ bị treo cho đến khi được bật thủ công

Khi các biện pháp bảo vệ cần thiết bị vô hiệu hóa và tất cả các tệp được triển khai, trình cài đặt sẽ tự đăng ký bị xóa trong lần khởi động lại hệ thống tiếp theo và khởi động lại máy để tiến hành khai thác CVE-2022-21894.

Bỏ qua Khởi động an toàn và thiết lập sự kiên trì

Trong phần này, chúng ta xem xét kỹ hơn cách BlackLotus đạt được sự bền bỉ trên các hệ thống có bật Khởi động an toàn UEFI. Vì chuỗi thực thi mà chúng tôi sắp mô tả khá phức tạp nên trước tiên chúng tôi sẽ giải thích các nguyên tắc cơ bản và sau đó tìm hiểu sâu hơn về các chi tiết kỹ thuật.

Tóm lại, quá trình này bao gồm hai bước chính:

1. Khai thác CVE-2022-21894 để bỏ qua tính năng Khởi động an toàn và cài đặt bộ khởi động. Điều này cho phép thực thi mã tùy ý trong các giai đoạn khởi động sớm, trong đó nền tảng vẫn thuộc sở hữu của phần sụn và các chức năng Dịch vụ khởi động UEFI vẫn khả dụng. Điều này cho phép kẻ tấn công thực hiện nhiều việc mà chúng không thể thực hiện trên máy có bật UEFI Secure Boot mà không có quyền truy cập vật lý vào máy, chẳng hạn như sửa đổi các biến NVRAM chỉ dành cho dịch vụ khởi động. Và đây là thứ mà kẻ tấn công lợi dụng để thiết lập tính bền vững cho bootkit ở bước tiếp theo. Thông tin thêm về khai thác có thể được tìm thấy trong Khai thác CVE-2022-21894 phần.
2. Thiết lập sự kiên trì bằng cách viết MOK của chính nó vào MokList, Biến NVRAM chỉ dành cho dịch vụ khởi động. Bằng cách này, nó có thể sử dụng hợp pháp có chữ ký của Microsoft miếng đệm để tải tự ký của nó (được ký bởi khóa riêng thuộc về khóa được ghi vào MokList) UEFI bootkit thay vì khai thác lỗ hổng trên mỗi lần khởi động. Thêm về điều này trong Bootkit kiên trì phần.

Để phân tích chi tiết trong hai phần tiếp theo dễ dàng hơn, chúng ta sẽ thực hiện theo các bước được hiển thị trong sơ đồ thực hiện, Hình 6.

Hình 6. Bỏ qua Khởi động an toàn và thiết lập sự kiên trì bằng MOK

Khai thác CVE-2022-21894

Để vượt qua Khởi động an toàn, BlackLotus sử dụng baton drop (CVE-2022-21894): Tính năng bảo mật khởi động an toàn Bỏ qua lỗ hổng bảo mật. Mặc dù có tác động lớn đến bảo mật hệ thống, lỗ hổng này đã không nhận được nhiều sự chú ý của công chúng như nó xứng đáng. Mặc dù lỗ hổng đã được khắc phục trong bản cập nhật tháng 2022 năm XNUMX của Microsoft nhưng việc khai thác vẫn có thể xảy ra do các tệp nhị phân bị ảnh hưởng vẫn chưa được thêm vào Danh sách thu hồi UEFI. Do đó, những kẻ tấn công có thể mang các bản sao nhị phân dễ bị tổn thương của riêng chúng đến máy của nạn nhân để khai thác lỗ hổng này và bỏ qua Khởi động an toàn trên các hệ thống UEFI cập nhật.

Hơn nữa, khai thác Proof of Concept (PoC) cho lỗ hổng này đã được công bố rộng rãi kể từ tháng 2022 năm 1. Xem xét ngày đệ trình BlackLotus VirusTotal đầu tiên (xem Hình XNUMX), nhà phát triển phần mềm độc hại có thể chỉ điều chỉnh PoC có sẵn theo nhu cầu của họ mà không bất kỳ nhu cầu hiểu biết sâu sắc nào về cách khai thác này hoạt động.

Hãy bắt đầu với phần giới thiệu ngắn gọn về lỗ hổng, chủ yếu là tóm tắt các điểm chính từ bài viết được xuất bản cùng với PoC trên GitHub:

• Các ứng dụng khởi động Windows bị ảnh hưởng (chẳng hạn như bootmgr.efi, hvloader.efi, winload.efi…) cho phép xóa chính sách Khởi động an toàn được tuần tự hóa khỏi bộ nhớ – trước khi nó được ứng dụng tải – bằng cách sử dụng bộ nhớ bị cắt ngắn Tùy chọn khởi động BCD.
• Điều này cho phép kẻ tấn công sử dụng các tùy chọn BCD nguy hiểm khác như gỡ lỗi khởi động, kiểm tra, hoặc là nointegritychecks, do đó phá vỡ Khởi động an toàn.
• Có nhiều cách khác nhau để khai thác lỗ hổng này – ba trong số chúng được xuất bản trong kho lưu trữ PoC.
• Ví dụ, một trong các PoC chỉ ra cách nó có thể bị khai thác để tạo ra hvloader.efi tải một tùy ý, tự ký mcupdate_ .dll nhị phân (trong đó có thể Chính hãng or xác thựcAMD, dựa trên CPU của máy.).

Bây giờ, chúng tôi tiếp tục mô tả cách BlackLotus khai thác lỗ hổng này (các số trong danh sách bên dưới mô tả các bước tương ứng trong Hình 6):

1. Sau khi trình cài đặt khởi động lại máy, chương trình cơ sở UEFI sẽ tiếp tục tải tùy chọn khởi động đầu tiên. Đối với các hệ thống Windows, tùy chọn khởi động đầu tiên theo mặc định bootmgfw.efi nằm trong ESP:/EFI/Microsoft/Khởi động thư mục trên ESP. Lần này, thay vì hành quyết nạn nhân ban đầu bootmgfw.efi (trước đây đã được đổi tên winload.efi bởi trình cài đặt), phần sụn thực thi phần mềm dễ bị tổn thương – được triển khai bởi trình cài đặt.
2. Sau bootmgfw.efi được thực thi, nó sẽ tải các tùy chọn khởi động BCD, đã được trình cài đặt sửa đổi trước đó. Hình 7 cho thấy sự so sánh giữa BCD hợp lệ và BCD đã sửa đổi.
3. Như bạn có thể thấy trong Hình 7 (đường dẫn được gạch chân bằng màu xanh lục), Windows Boot Manager hợp pháp thường sẽ tải bộ tải HĐH Windows (WINDOWSsystem32winload.efi) làm ứng dụng khởi động mặc định. Nhưng lần này, với BCD đã sửa đổi, nó tiếp tục tải tệp dễ bị tổn thương ESP:system32bootmgr.efi, Với tránh bộ nhớ thấp Phần tử BCD được đặt thành giá trị 0x10000000 và tùy chỉnh: 22000023 Phần tử BCD trỏ đến BCD của kẻ tấn công khác được lưu trữ trong ESP: hệ thống32bcd. Giải thích về việc sử dụng các yếu tố này có thể được tìm thấy trong tài liệu đã xuất bản PoC:

Kẻ tấn công cần đảm bảo Chính sách khởi động an toàn được tuần tự hóa được phân bổ trên một địa chỉ vật lý đã biết.
[...]
Sản phẩm tránh bộ nhớ thấp phần tử có thể được sử dụng để đảm bảo tất cả các phân bổ bộ nhớ vật lý nằm trên một địa chỉ vật lý được chỉ định.
 • Kể từ Windows 10, phần tử này không được phép nếu VBS được bật, nhưng vì nó được sử dụng trong quá trình khởi chạy ứng dụng khởi động, trước khi chính sách Khởi động an toàn được tuần tự hóa được đọc từ bộ nhớ, tải Bootmgr và chỉ định đường dẫn BCD tùy chỉnh (sử dụng bcdfilepath yếu tố hay còn gọi là tùy chỉnh: 22000023) có thể được sử dụng để bỏ qua điều này.

Hình 7. Cửa hàng BCD hợp lệ (TRƯỚC) so với cửa hàng được sử dụng bởi trình cài đặt BlackLotus (SAU)

4. Trong bước tiếp theo, việc thực hiện ESP:system32bootmgr.efi tải BCD bổ sung nằm trong ESP: hệ thống32bcd. Nội dung được phân tích cú pháp của BCD bổ sung này được hiển thị trong Hình 8.

Hình 8. BCD thứ hai do trình cài đặt BlackLotus bỏ qua – được sử dụng để khai thác CVE-2022-21894

5. Do các tùy chọn được tải từ tệp BCD được hiển thị trong Hình 8, bootmgr.efi tiếp tục tải một Ứng dụng khởi động Windows dễ bị tổn thương khác được trình cài đặt triển khai – ESP:system32hvloader.efi – đó là Windows Hypervisor Loader. Quan trọng hơn, các tùy chọn BCD bổ sung được chỉ định trong cùng một tệp BCD (xem Hình 8):
   1. bộ nhớ bị cắt ngắn với giá trị được đặt thành 0x10000000
   2. nointegritychecks đặt thành Có
   3. và kiểm tra, cũng được đặt thành Có

Và đây là nơi phép màu xảy ra. Vì chính sách Khởi động an toàn được tuần tự hóa nên được tải trong các địa chỉ vật lý ở trên 0x10000000 (bởi vì tránh bộ nhớ thấp được sử dụng trong các bước trước), chỉ định bộ nhớ bị cắt ngắn phần tử sẽ loại bỏ nó một cách hiệu quả – do đó, phá vỡ Khởi động an toàn và cho phép sử dụng các tùy chọn BCD nguy hiểm như nointegritychecks or kiểm tra. Bằng cách sử dụng các tùy chọn này, kẻ tấn công có thể thực hiện hvloader.efi thực thi mã tự ký của riêng họ. 

6. Để làm điều này, thủ thuật tương tự như được mô tả trong PoC được sử dụng: trong quá trình thực hiện, hợp pháp hvloader.efi tải và thực hiện các mcupdate_{Chính hãngIntel| AuthenticAMD}.dll nhị phân gốc từ : hệ thống32 danh mục. Đã nhận xét mã dịch ngược Hex-Rays của hàm từ hvloader.efi chịu trách nhiệm tải tệp nhị phân mcupdate*.dll này được hiển thị trong Hình 9. Lưu ý rằng hvloader.efi thường sẽ tải hợp pháp này mcupdate*.dll nhị phân từ:Windowssystem32, nhưng lần này những kẻ tấn công độc hại tự ký tên mcupdate*.dll được thực thi từ một thư mục ESP tùy chỉnh đã được trình cài đặt tạo trước đó (ESP: hệ thống32). Nó được gây ra bởi các tùy chọn BCD thiết bị và systemroot được sử dụng trong BCD từ Hình 8 chỉ định thiết bị hiện tại là khởi động – nghĩa là ESP – và cũng chỉ định SystemRoot là gốc () trên thiết bị này.

Hình 9. Dịch ngược Hex-Rays của BtLoadCập NhậtDll chức năng từ hợp pháp hvloader.efi, chịu trách nhiệm tải mcupdate_*.dll

7. Bây giờ, khi những kẻ tấn công tự ký mcupdate*.dll được tải và thực thi, nó tiếp tục thực thi thành phần cuối cùng trong chuỗi này – MokInstaller nhúng (Ứng dụng UEFI) – xem Hình 10 để biết chi tiết về cách thực hiện.

Hình 10. Mã dịch ngược Hex-Rays của mã độc tự ký mcupdate*.dll nhị phân

Bootkit kiên trì

Giờ đây, MokInstaller có thể tiến hành thiết lập tính bền vững bằng cách đăng ký MOK của kẻ tấn công vào biến NVRAM và thiết lập tệp hợp pháp do Microsoft ký. miếng đệm nhị phân làm bộ tải khởi động mặc định. Trước khi đi vào chi tiết, một chút lý thuyết về miếng đệm và MOK.

miếng đệm là bộ tải khởi động UEFI giai đoạn đầu được phát triển bởi các nhà phát triển Linux để làm cho các bản phân phối Linux khác nhau hoạt động với UEFI Secure Boot. Đó là một ứng dụng đơn giản và mục đích của nó là tải, xác minh và thực thi một ứng dụng khác – trong trường hợp hệ thống Linux, nó thường là bộ tải khởi động GRUB. Nó hoạt động theo cách mà Microsoft chỉ ký một miếng đệm, và miếng đệm lo phần còn lại – nó có thể xác minh tính toàn vẹn của bộ tải khởi động giai đoạn hai bằng cách sử dụng các khóa từ db UEFI, đồng thời nhúng danh sách các khóa hoặc mã băm “được phép” hoặc “đã thu hồi” của riêng nó để đảm bảo rằng các thành phần được cả hai – nhà phát triển nền tảng và shim (ví dụ: Canonical, RedHat, v.v.) – tin cậy – được phép thực thi. Ngoài những danh sách này, miếng đệm cũng cho phép sử dụng cơ sở dữ liệu khóa bên ngoài do người dùng quản lý, được gọi là danh sách MOK. Hình 11 minh họa độc đáo cách thức hoạt động của UEFI Secure Boot với MOK.

Cơ sở dữ liệu MOK này được lưu trữ trong biến NVRAM chỉ khởi động có tên MokList. Nếu không khai thác lỗ hổng như lỗ hổng được mô tả ở trên, cần có quyền truy cập vật lý để sửa đổi lỗ hổng đó trên hệ thống đã bật Khởi động an toàn UEFI (chỉ khả dụng trong khi khởi động, trước khi trình tải hệ điều hành gọi chức năng Dịch vụ khởi động UEFI Thoát khỏi dịch vụ khởi động). Tuy nhiên, bằng cách khai thác lỗ hổng này, kẻ tấn công có thể bỏ qua UEFI Secure Boot và thực thi mã tự ký của chính chúng trước khi gọi đến Thoát khỏi dịch vụ khởi động, để họ có thể dễ dàng đăng ký khóa riêng của mình (bằng cách sửa đổi MokList NVRAM) để làm cho miếng chêm thực thi bất kỳ ứng dụng nào – được ký bởi khóa đã đăng ký đó – mà không gây ra vi phạm bảo mật.

Hình 11. Tổng quan về quá trình khởi động MOK (hình ảnh nguồn)

8. Tiếp tục mô tả quy trình từ Hình 6 – bước 8… Ứng dụng MokInstaller UEFI tiếp tục với việc thiết lập tính bền vững cho bộ khởi động BlackLotus UEFI và che dấu vết khai thác bằng cách:
   1. Khôi phục cửa hàng BCD ban đầu của nạn nhân từ bản sao lưu được tạo bởi trình cài đặt và thay thế efi bằng shim hợp pháp do Microsoft ký, trước đó đã bị xóa xuống ESP:system32bootload.efi bởi trình cài đặt.
   2. Tạo ra một MokList Biến NVRAM chứa chứng chỉ khóa công khai tự ký của kẻ tấn công. Lưu ý rằng biến này được định dạng giống như bất kỳ biến cơ sở dữ liệu chữ ký UEFI nào khác (chẳng hạn như db hoặc dbx) và nó có thể bao gồm XNUMX hoặc nhiều danh sách loại chữ ký EFI_SIGNATURE_LIST – như được định nghĩa trong Thông số kỹ thuật UEFI.
   3. Xóa tất cả các tệp liên quan đến việc khai thác từ những kẻ tấn công ESP: hệ thống32 thư mục.
9. Cuối cùng, nó khởi động lại máy để làm cho shim đã triển khai thực thi bộ khởi động tự ký được giảm xuống EFIMicrosoftBootgrubx64.efi bởi trình cài đặt (grubx64.efi thường là bộ tải khởi động giai đoạn hai mặc định được thực thi bởi một miếng đệm trên các hệ thống x86-64).

Mã thực hiện các hành động được mô tả trong hai bước cuối cùng được hiển thị trong Hình 12.

Hình 12. Mã dịch ngược Hex-Rays – Ứng dụng MokInstaller UEFI thiết lập tính bền bỉ cho bộ khởi động BlackLotus

Bộ khởi động BlackLotus UEFI

Sau khi cấu hình tính bền bỉ, bộ công cụ khởi động BlackLotus được thực thi trên mỗi lần khởi động hệ thống. Mục tiêu của bootkit là triển khai trình điều khiển hạt nhân và thành phần chế độ người dùng cuối cùng - trình tải xuống HTTP. Trong quá trình thực thi, nó cố gắng vô hiệu hóa các tính năng bảo mật bổ sung của Windows – Bảo mật dựa trên ảo hóa (VBS) và Bộ bảo vệ Windows – để nâng cao cơ hội triển khai thành công và hoạt động lén lút. Trước khi chuyển sang chi tiết về cách thực hiện, hãy tóm tắt những điều cơ bản về trình điều khiển hạt nhân và trình tải xuống HTTP:

• Trình điều khiển hạt nhân chịu trách nhiệm cho
  • Triển khai thành phần tiếp theo của chuỗi – trình tải xuống HTTP.
  • Giữ bộ nạp còn sống trong trường hợp chấm dứt.
  • Bảo vệ các tệp bootkit khỏi bị xóa khỏi ESP.
  • Thực thi tải trọng hạt nhân bổ sung, nếu được hướng dẫn bởi trình tải xuống HTTP.
  • Gỡ cài đặt bootkit, nếu trình tải xuống HTTP hướng dẫn như vậy.
• Trình tải xuống HTTP chịu trách nhiệm:
  • Giao tiếp với C&C của nó.
  • Thực thi các lệnh nhận được từ C&C.
  • Tải xuống và thực thi tải trọng nhận được từ C&C (hỗ trợ cả tải trọng hạt nhân và tải trọng chế độ người dùng).

Quy trình thực thi đầy đủ (đơn giản hóa), từ trình cài đặt đến trình tải xuống HTTP, được hiển thị trong Hình 13. Chúng tôi mô tả các bước riêng lẻ này chi tiết hơn trong phần tiếp theo.

Hình 13. Sơ đồ hiển thị quá trình thực thi bộ khởi động BlackLotus UEFI

Quy trình thực thi BlackLotus

Các bước thực hiện như sau (các bước này được hiển thị trong Hình 13):

1. Bước đầu tiên, chương trình cơ sở UEFI thực thi tùy chọn khởi động Windows mặc định, đây là tệp thường được lưu trữ trong EFIMicrosoftBootbootmgfw.efi. Như chúng tôi đã mô tả trước đó (Phần kiên trì Bootkit, 8 .a), tệp nhị phân MokInstaller đã thay thế tệp này bằng tệp được ký hợp lệ miếng đệm.
2. Khi miếng đệm được thực thi, nó đọc MokList biến NVRAM và sử dụng chứng chỉ được lưu trữ trước đó bởi những kẻ tấn công để xác minh bộ tải khởi động giai đoạn hai – bộ khởi động BlackLotus UEFI tự ký nằm trong EFIMicrosoftBootgrubx64.efi.
3. Khi được xác minh, miếng đệm thực thi bootkit.
4. Bootkit bắt đầu với việc tạo Boot-only Chính sách VbsVô hiệu hóa biến NVRAM. Như mô tả tại đây, biến này được đánh giá bởi trình tải HĐH Windows trong khi khởi động và nếu được xác định, các tính năng VBS cốt lõi, chẳng hạn như HVCI và Credential Guard sẽ không được khởi tạo.
5. Trong các bước sau (5. a–e), bộ công cụ khởi động tiếp tục với một mẫu chung được sử dụng bởi bộ công cụ khởi động UEFI. Nó chặn việc thực thi các thành phần có trong luồng khởi động điển hình của Windows, chẳng hạn như Trình quản lý khởi động Windows, trình tải HĐH Windows và nhân HĐH Windows, đồng thời kết nối một số chức năng của chúng trong bộ nhớ. Như một phần thưởng, nó cũng cố gắng vô hiệu hóa Windows Defender bằng cách vá một số trình điều khiển của nó. Tất cả điều này để đạt được khả năng thực thi tải trọng của nó trong giai đoạn đầu của quá trình khởi động hệ điều hành và để tránh bị phát hiện. Các chức năng sau được nối hoặc vá:
   1. Ứng dụng ImgArchStartBoot in bootmgfw.efi or bootmgr.efi:
      Chức năng này thường được kết nối bởi bootkits để nắm bắt thời điểm khi trình tải hệ điều hành Windows (winload.efi) được tải vào bộ nhớ nhưng vẫn chưa được thực thi – đây là thời điểm thích hợp để thực hiện nhiều bản vá trong bộ nhớ hơn.
   2. BlImgAllocateImageBuffer in winload.efi:
      Được sử dụng để phân bổ bộ đệm bộ nhớ bổ sung cho trình điều khiển hạt nhân độc hại.
   3. OslArchChuyển tớiKernel in winload.efi:
      Được kết nối để nắm bắt thời điểm khi nhân hệ điều hành và một số trình điều khiển hệ thống đã được tải vào bộ nhớ, nhưng vẫn chưa được thực thi – đây là thời điểm hoàn hảo để thực hiện nhiều bản vá trong bộ nhớ hơn. Các trình điều khiển được đề cập dưới đây được vá trong hook này. Mã từ hook này chịu trách nhiệm tìm các trình điều khiển thích hợp trong bộ nhớ được hiển thị trong Hình 14.
   4. WdBoot.sys và WdFilter.sys:
      BlackLotus vá điểm vào của WdBoot.sys và WdFilter.sys – trình điều khiển ELAM của Bộ bảo vệ Windows và trình điều khiển bộ lọc hệ thống tệp của Bộ bảo vệ Windows, tương ứng – sẽ quay lại ngay lập tức.
   5. đĩa.sys:
      Bootkit móc điểm vào của đĩa.sys trình điều khiển để thực thi trình điều khiển nhân BlackLotus trong giai đoạn đầu của quá trình khởi tạo hệ thống.

Hình 14. Mã dịch ngược Hex-Rays của OslArchChuyển tớiKernel hook – vá trình điều khiển Windows Defender và tìm kiếm đĩa.sys điểm vào

6. Tiếp theo, khi nhân hệ điều hành thực thi lệnh đĩa.sys điểm vào của trình điều khiển, hook đã cài đặt sẽ nhảy đến điểm vào trình điều khiển nhân độc hại. Mã độc lần lượt khôi phục lại bản gốc đĩa.sys để cho phép hệ thống hoạt động bình thường và đợi cho đến khi winlogon.exe quá trình bắt đầu.
7. Khi trình điều khiển độc hại phát hiện ra rằng winlogon.exe đã bắt đầu, nó đưa và thực thi thành phần chế độ người dùng cuối cùng – trình tải xuống HTTP – vào đó.

trình điều khiển hạt nhân

Trình điều khiển kernel chịu trách nhiệm cho bốn nhiệm vụ chính:

• Đưa trình tải xuống HTTP vào winlogon.exe và tiêm lại nó trong trường hợp chuỗi kết thúc.
• Bảo vệ các tệp bootkit được triển khai trên ESP khỏi bị xóa.
• Vô hiệu hóa quy trình Windows Defender ở chế độ người dùng MsMpEngine.exe.
• Giao tiếp với trình tải xuống HTTP và nếu cần, thực hiện bất kỳ lệnh nào.

Hãy xem xét từng cái một.

Tính bền bỉ của trình tải xuống HTTP

Trình điều khiển hạt nhân chịu trách nhiệm triển khai trình tải xuống HTTP. Khi trình điều khiển khởi động, nó đợi cho đến khi quá trình có tên winlogon.exe bắt đầu, trước khi thực hiện bất kỳ hành động nào khác. Khi quá trình đã bắt đầu, trình điều khiển sẽ giải mã tệp nhị phân của trình tải xuống HTTP, đưa nó vào winlogon.exekhông gian địa chỉ của nó và thực thi nó trong một luồng mới. Sau đó, trình điều khiển tiếp tục kiểm tra định kỳ xem luồng có còn chạy hay không và lặp lại quá trình tiêm nếu cần. Trình tải xuống HTTP sẽ không được triển khai nếu trình điều khiển phát hiện trình gỡ lỗi kernel.

Bảo vệ các tệp bootkit trên ESP khỏi bị xóa

Để bảo vệ các tệp của bootkit nằm trên ESP, trình điều khiển hạt nhân sử dụng một thủ thuật đơn giản. Nó mở tất cả các tệp mà nó muốn bảo vệ, sao chép và lưu các phần điều khiển của chúng, đồng thời sử dụng Thuộc tính ObSetHandle hàm kernel chỉ định Bảo vệTừĐóng cờ bên trong Xử lýCờ (ĐỐI TƯỢNG_HANDLE_FLAG_INFORMATION) thành 1 – do đó bảo vệ các tay cầm không bị đóng bởi bất kỳ quy trình nào khác. Điều này sẽ cản trở mọi nỗ lực xóa hoặc sửa đổi các tệp được bảo vệ. Các tệp sau được bảo vệ:

• ESP:EFIMicrosoftBootwinload.efi
• ESP:EFIMicrosoftBootbootmgfw.efi
• ESP:EFIMicrosoftBootgrubx64.efi

Nếu người dùng cố gắng xóa các tập tin được bảo vệ này, điều gì đó giống như trong Hình 15 sẽ xảy ra.

Hình 15. Nỗ lực xóa các tập tin được bảo vệ bởi trình điều khiển BlackLotus

Là một lớp bảo vệ khác, trong trường hợp người dùng hoặc phần mềm bảo mật có thể bỏ đặt cờ bảo vệ và đóng các tay cầm, trình điều khiển nhân liên tục giám sát chúng và gây ra BSOD bằng cách gọi trình điều khiển. KeBugCheck(INVALID_KERNEL_HANDLE) hoạt động nếu bất kỳ tay cầm nào không tồn tại nữa.

Vô hiệu hóa quy trình Windows Defender chính

Trình điều khiển hạt nhân cũng cố gắng vô hiệu hóa quy trình Windows Defender chính – MsMpEng.exe. Nó làm như vậy bằng cách loại bỏ tất cả các đặc quyền mã thông báo của quy trình bằng cách đặt SE_PRIVILEGE_REMOVED thuộc tính cho mỗi người trong số họ. Do đó, quy trình Defender sẽ không thể thực hiện công việc của nó - chẳng hạn như quét tệp - đúng cách. Tuy nhiên, vì chức năng này được triển khai kém nên nó có thể trở nên vô hiệu bằng cách khởi động lại MsMpEng.exe quá trình.

Giao tiếp với trình tải xuống HTTP

Trình điều khiển hạt nhân có khả năng giao tiếp với trình tải xuống HTTP bằng cách sử dụng Sự kiện và Phần có tên. Tên của các đối tượng được đặt tên được sử dụng được tạo dựa trên địa chỉ MAC của bộ điều hợp mạng (ethernet) của nạn nhân. Nếu một giá trị của một octet thấp hơn 16, thì 16 sẽ được thêm vào nó. Định dạng của tên đối tượng được tạo có thể khác nhau trong các mẫu khác nhau. Ví dụ: trong một trong các mẫu chúng tôi đã phân tích, đối với địa chỉ MAC 00-1c-0b-cd-ef-34, các tên được tạo sẽ là:

• BaseNamedObjects101c1b: cho phần được đặt tên (chỉ ba octet đầu tiên của MAC được sử dụng)
• Đối tượng được đặt tên cơ sởZ01c1b: cho sự kiện được đặt tên – giống như cho Phần, nhưng chữ số đầu tiên của địa chỉ MAC được thay thế bằng Z

Trong trường hợp trình tải xuống HTTP muốn chuyển một số lệnh tới trình điều khiển hạt nhân, nó chỉ cần tạo một phần được đặt tên, viết lệnh có dữ liệu liên quan bên trong và đợi lệnh được trình điều khiển xử lý bằng cách tạo một sự kiện được đặt tên và đợi cho đến khi trình điều khiển xử lý lệnh. trình điều khiển kích hoạt (hoặc tín hiệu) nó.

Trình điều khiển hỗ trợ các lệnh tự giải thích sau:

• Cài đặt trình điều khiển hạt nhân
• Gỡ cài đặt BlackLotus

Người đọc cẩn thận có thể nhận thấy điểm yếu của BlackLotus ở đây – mặc dù bộ công cụ khởi động bảo vệ các thành phần của nó khỏi bị gỡ bỏ, nhưng trình điều khiển nhân có thể bị lừa để gỡ cài đặt hoàn toàn bộ công cụ khởi động bằng cách tạo các đối tượng có tên nêu trên và gửi lệnh gỡ cài đặt tới nó.

Trình tải xuống HTTP

Thành phần cuối cùng chịu trách nhiệm liên lạc với máy chủ C&C và thực thi bất kỳ lệnh C&C nào nhận được từ máy chủ đó. Tất cả các tải trọng mà chúng tôi có thể khám phá đều chứa ba lệnh. Các lệnh này rất đơn giản và như tên phần gợi ý, chủ yếu là tải xuống và thực thi các tải trọng bổ sung bằng các kỹ thuật khác nhau.

truyền thông C&C

Để giao tiếp với C&C của nó, trình tải HTTP sử dụng giao thức HTTPS. Tất cả thông tin cần thiết cho giao tiếp được nhúng trực tiếp vào tệp nhị phân của trình tải xuống – bao gồm các miền C&C và đường dẫn tài nguyên HTTP được sử dụng. Khoảng thời gian mặc định để liên lạc với máy chủ C&C được đặt thành một phút, nhưng có thể thay đổi dựa trên dữ liệu từ C&C. Mỗi phiên giao tiếp với một C&C bắt đầu bằng việc gửi một thông báo HTTP POST báo hiệu tới nó. Trong các mẫu chúng tôi đã phân tích, các đường dẫn tài nguyên HTTP sau đây có thể được chỉ định trong tiêu đề HTTP POST:

• /mạng/API/hpb_gate[.]php
• /API/hpb_gate[.]php
• /cổng[.]php
• /hpb_gate[.]php

Dữ liệu tin nhắn báo hiệu được thêm vào trước một đăng ký vào= chuỗi, chứa thông tin cơ bản về máy bị xâm nhập – bao gồm mã định danh máy tùy chỉnh (được gọi là HWID), trạng thái Khởi động an toàn UEFI, nhiều thông tin phần cứng khác nhau và một giá trị có vẻ là số bản dựng BlackLotus. HWID được tạo từ địa chỉ MAC của máy (ethernet) và số sê-ri ổ đĩa hệ thống. Định dạng của tin nhắn trước khi mã hóa như trong Hình 16

Hình 16. Định dạng của tin nhắn báo hiệu

Trước khi gửi thư đến C&C, trước tiên, dữ liệu được mã hóa bằng khóa RSA được nhúng, sau đó mã hóa base64 an toàn cho URL. Trong quá trình phân tích, chúng tôi đã tìm thấy hai khóa RSA khác nhau đang được sử dụng trong các mẫu. Một ví dụ về yêu cầu báo hiệu HTTP như vậy được hiển thị trong Hình 17.

Hình 17. Ví dụ về thông báo HTTP POST báo hiệu (được tạo bởi một mẫu từ VirusTotal – mẫu có IP cục bộ thay vì địa chỉ C&C thực)

Dữ liệu nhận được từ C&C dưới dạng phản hồi cho thông báo đèn hiệu phải bắt đầu bằng giá trị ma thuật hai byte HP; mặt khác, phản hồi không được xử lý thêm. Nếu giá trị ma thuật là chính xác, dữ liệu theo sau giá trị ma thuật được giải mã bằng AES 256 bit ở chế độ CBC với chuỗi HWID nêu trên được sử dụng làm khóa.

Sau khi giải mã, thông báo tương tự như đèn hiệu, chuỗi có định dạng JSON và chỉ định mã định danh lệnh (được gọi là Kiểu) và các tham số bổ sung khác nhau như:

• Khoảng thời gian giao tiếp C&C
• Phương pháp thực hiện sử dụng
• tên tệp tải trọng
• Loại tải trọng dựa trên phần mở rộng tệp (.sys, Exe., hoặc là DLL. được hỗ trợ)
• Mã thông báo xác thực được cho là được sử dụng để yêu cầu tải xuống dữ liệu tải trọng
• Khóa AES được sử dụng để giải mã dữ liệu tải trọng

Tất cả các lệnh được hỗ trợ và mô tả của chúng được liệt kê trong Bảng 2.

Bảng 2. Lệnh C&C

Trong các lệnh này, C&C có thể chỉ định liệu tải trọng trước tiên sẽ được thả vào đĩa trước khi thực hiện nó hay được thực thi trực tiếp trong bộ nhớ. Trong các trường hợp liên quan đến việc thả tệp vào đĩa, ProgramData thư mục trên ổ đĩa hệ điều hành được sử dụng làm thư mục đích và tên tệp cũng như phần mở rộng được chỉ định bởi máy chủ C&C. Trong trường hợp thực thi các tập tin trực tiếp trong bộ nhớ, svchost.exe được sử dụng như một mục tiêu tiêm. Khi C&C gửi một lệnh yêu cầu sự hợp tác của trình điều khiển nhân, hoặc một người vận hành muốn thực thi mã ở chế độ nhân, cơ chế được mô tả trong Giao tiếp với trình tải xuống HTTP phần được sử dụng.

Thủ thuật chống phân tích

Để làm cho việc phát hiện và phân tích phần mềm độc hại này trở nên khó khăn hơn, tác giả của nó đã cố gắng hạn chế khả năng hiển thị của các tạo phẩm tệp tiêu chuẩn, chẳng hạn như chuỗi văn bản, nội dung nhập hoặc dữ liệu nhúng không được mã hóa khác ở mức tối thiểu. Dưới đây là tóm tắt các kỹ thuật được sử dụng.

• Mã hóa chuỗi và dữ liệu
  • Tất cả các chuỗi được sử dụng trong các mẫu được mã hóa bằng một mật mã đơn giản.
  • Tất cả các tệp nhúng được mã hóa bằng AES 256-bit ở chế độ CBC.
  • Các khóa mã hóa cho các tệp riêng lẻ có thể khác nhau giữa các mẫu.
  • Ngoài mã hóa AES, một số tệp cũng được nén bằng LZMS.
• Độ phân giải API chỉ trong thời gian chạy
  • Trong tất cả các mẫu (nếu có), API Windows luôn được giải quyết độc quyền trong thời gian chạy và hàm băm thay vì tên hàm được sử dụng để tìm địa chỉ hàm API mong muốn trong bộ nhớ.
  • Trong một số trường hợp, trực tiếp tòa nhà cao tầng lời gọi lệnh được sử dụng để gọi chức năng hệ thống mong muốn.
• Truyền thông mạng
  • Giao tiếp bằng HTTPS.
  • Tất cả các thư do trình tải xuống HTTP gửi đến C&C đều được mã hóa bằng khóa công khai RSA được nhúng.
  • Tất cả các tin nhắn được gửi từ C&C đến trình tải xuống HTTP đều được mã hóa bằng khóa lấy từ môi trường máy của nạn nhân hoặc sử dụng khóa AES do C&C cung cấp.
• Các thủ thuật chống gỡ lỗi và chống VM – nếu được sử dụng, thường được đặt ngay ở đầu điểm vào. Chỉ các thủ thuật phát hiện trình gỡ lỗi hoặc hộp cát thông thường mới được sử dụng.

Giảm thiểu và khắc phục

• Tất nhiên, trước hết, việc giữ cho hệ thống của bạn và sản phẩm bảo mật của nó luôn cập nhật là điều bắt buộc – để tăng khả năng ngăn chặn mối đe dọa ngay từ đầu, trước khi nó có thể đạt được sự bền bỉ trước hệ điều hành.
• Sau đó, bước quan trọng cần được thực hiện để ngăn việc sử dụng các tệp nhị phân UEFI dễ bị tổn thương đã biết để bỏ qua Khởi động an toàn UEFI là thu hồi chúng trong cơ sở dữ liệu thu hồi UEFI (dbx) – trên hệ thống Windows, dbx các bản cập nhật phải được phân phối bằng Windows Updates.
• Vấn đề là việc thu hồi các tệp nhị phân Windows UEFI được sử dụng rộng rãi có thể dẫn đến việc làm cho hàng nghìn hệ thống lỗi thời, hình ảnh khôi phục hoặc bản sao lưu không thể khởi động được – và do đó, việc thu hồi thường mất quá nhiều thời gian.
• Lưu ý rằng việc thu hồi các ứng dụng Windows mà BlackLotus sử dụng sẽ ngăn cản việc cài đặt bộ công cụ khởi động, nhưng vì trình cài đặt sẽ thay thế bộ nạp khởi động của nạn nhân bằng bộ nạp khởi động bị thu hồi nên nó có thể khiến hệ thống không thể khởi động được. Để khôi phục trong trường hợp này, cài đặt lại hệ điều hành hoặc chỉ khôi phục ESP sẽ giải quyết được sự cố.
• Nếu việc thu hồi xảy ra sau khi thiết lập tính bền vững của BlackLotus, bộ công cụ khởi động sẽ vẫn hoạt động, vì nó sử dụng một miếng chêm hợp pháp với khóa MOK tùy chỉnh để duy trì tính bền bỉ. Trong trường hợp này, giải pháp giảm thiểu an toàn nhất là cài đặt lại Windows và xóa khóa MOK đã đăng ký của kẻ tấn công bằng cách sử dụng mokutil tiện ích (cần có sự hiện diện vật lý để thực hiện thao tác này do tương tác cần thiết của người dùng với Trình quản lý MOK trong quá trình khởi động).

Takeaways

Nhiều lỗ hổng nghiêm trọng ảnh hưởng đến bảo mật của hệ thống UEFI đã được phát hiện trong vài năm gần đây. Thật không may, do sự phức tạp của toàn bộ hệ sinh thái UEFI và các vấn đề liên quan đến chuỗi cung ứng, nhiều lỗ hổng trong số này đã khiến nhiều hệ thống dễ bị tổn thương ngay cả một thời gian dài sau khi các lỗ hổng đã được khắc phục – hoặc ít nhất là sau khi chúng tôi được thông báo rằng chúng đã được khắc phục. Để có hình ảnh rõ hơn, đây là một số ví dụ về lỗi vá lỗi hoặc thu hồi cho phép bỏ qua Khởi động an toàn UEFI chỉ từ năm ngoái:

• Đầu tiên tất nhiên là CVE-2022-21894 – lỗ hổng bị BlackLotus khai thác. Một năm kể từ khi lỗ hổng được khắc phục, các tệp nhị phân UEFI dễ bị tấn công vẫn chưa bị thu hồi, cho phép các mối đe dọa như BlackLotus hoạt động lén lút trên các hệ thống có bật UEFI Secure Boot, do đó mang lại cho nạn nhân cảm giác an toàn sai lầm.
• Đầu năm 2022, chúng tôi đã tiết lộ một số lỗ hổng UEFI cho phép, ngoài những thứ khác, vô hiệu hóa Khởi động an toàn UEFI. Nhiều thiết bị bị ảnh hưởng không được OEM hỗ trợ nữa nên không được khắc phục (mặc dù các thiết bị này không quá cũ – khoảng 3-5 năm tại thời điểm lỗ hổng được tiết lộ). Đọc thêm trong blogpost của chúng tôi: Khi “an toàn” hoàn toàn không an toàn: Các lỗ hổng UEFI có tác động lớn được phát hiện trong máy tính xách tay tiêu dùng của Lenovo
• Cuối năm 2022, chúng tôi đã phát hiện ra một một số lỗ hổng UEFI khác, việc khai thác cũng sẽ cho phép kẻ tấn công vô hiệu hóa UEFI Secure Boot rất dễ dàng. Như đã chỉ ra bởi các nhà nghiên cứu đồng nghiệp từ nhị phân, một số thiết bị được liệt kê trong cố vấn vẫn chưa được vá hoặc không được vá chính xác, thậm chí vài tháng sau lời khuyên – khiến thiết bị dễ bị tổn thương. Không cần phải nói, tương tự như trường hợp trước, một số thiết bị sẽ dễ bị tổn thương mãi mãi vì chúng đã đến ngày Kết thúc hỗ trợ.

Chỉ còn là vấn đề thời gian trước khi ai đó lợi dụng những lỗi này và tạo bộ công cụ khởi động UEFI có khả năng hoạt động trên các hệ thống có bật Khởi động an toàn UEFI. Như chúng tôi đã đề xuất năm ngoái trong bản trình bày RSA, tất cả những điều này làm cho việc chuyển sang ESP trở nên khả thi hơn đối với những kẻ tấn công và là một hướng đi khả thi đối với các mối đe dọa UEFI – sự tồn tại của BlackLotus đã xác nhận điều này.

IoC

Các tập tin

Giấy chứng nhận

mạng

Kỹ thuật MITER ATT & CK

Bảng này được tạo bằng cách sử dụng phiên bản 12 của khuôn khổ MITER ATT & CK.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. Truy cập Tại đây.
• nguồn: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/