UEFI firmware rootkit

Rootkit là những phần mềm độc hại cấy ghép vào những ngóc ngách sâu nhất của hệ điều hành. Mặc dù
trên giấy tờ, chúng có vẻ hấp dẫn đối với những kẻ tấn công, nhưng việc tạo ra chúng đặt ra những
thách thức kỹ thuật đáng kể và một lỗi lập trình nhỏ nhất cũng có khả năng làm hỏng máy nạn nhân
hoàn toàn. Trong dự đoán APT của chúng tôi cho năm 2022, chúng tôi lưu ý rằng bất chấp những rủi ro
này, chúng tôi mong đợi sẽ có nhiều kẻ tấn công đạt đến mức độ tinh vi cần thiết để phát triển các công
cụ như vậy. Một trong những điểm thu hút chính đối với phần mềm độc hại nằm trong các cấp độ thấp
của hệ điều hành là nó cực kỳ khó phát hiện và, trong trường hợp rootkit phần sụn, sẽ đảm bảo máy tính
vẫn ở trạng thái bị nhiễm ngay cả khi hệ điều hành được cài đặt lại hoặc người dùng thay thế hoàn toàn
ổ cứng của máy. Trong báo cáo này, chúng tôi trình bày một bộ phần mềm gốc UEFI mà chúng tôi gọi là
CosmicStrand và gán cho một tác nhân đe dọa nói tiếng Trung không xác định. Một trong những đối tác
trong ngành của chúng tôi, Qihoo360, đã xuất bản một bài đăng trên blog về một biến thể ban đầu của
họ phần mềm độc hại này vào năm 2017.

Các thiết bị bị ảnh hưởng

Mặc dù ban đầu chúng tôi không thể phát hiện ra cách thức các máy nạn nhân bị lây nhiễm, nhưng một
phân tích về phần cứng của chúng đã làm sáng tỏ các thiết bị mà CosmicStrand có thể lây nhiễm. Bộ
rootkit nằm trong hình ảnh phần sụn của bo mạch chủ Gigabyte hoặc ASUS và chúng tôi nhận thấy rằng
tất cả những hình ảnh này đều liên quan đến các thiết kế sử dụng chipset H81. Điều này cho thấy rằng
một lỗ hổng phổ biến có thể tồn tại cho phép những kẻ tấn công đưa bộ rootkit của họ vào hình ảnh của
chương trình cơ sở. Trong các hình ảnh phần sụn này, các sửa đổi đã được đưa vào trình điều khiển
CSMCORE DXE, điểm nhập của nó đã được vá để chuyển hướng đến mã được thêm trong phần .reloc.
Mã này, được thực thi trong quá trình khởi động hệ thống, kích hoạt một chuỗi thực thi dài dẫn đến việc
tải xuống và triển khai một thành phần độc hại bên trong Windows. Nhìn vào các hình ảnh phần sụn
khác nhau mà chúng tôi có thể thu được, chúng tôi đánh giá rằng các sửa đổi có thể đã được thực hiện
bằng một trình vá lỗi tự động. Nếu vậy, có nghĩa là những kẻ tấn công đã có quyền truy cập trước vào
máy tính của nạn nhân để trích xuất, sửa đổi và ghi đè chương trình cơ sở của bo mạch chủ. Điều này có
thể đạt được thông qua việc cấy ghép phần mềm độc hại tiền thân đã được triển khai trên máy tính
hoặc truy cập vật lý (tức là một kịch bản tấn công người hầu gái độc ác). Báo cáo ban đầu của Qihoo chỉ
ra rằng người mua có thể đã nhận được một bo mạch chủ đã được sửa chữa sau khi đặt hàng tại một
đại lý bán lại đồ cũ. Chúng tôi không thể xác nhận thông tin này.

Tổng quan về quá trình lây nhiễm

Trước khi đi sâu vào các thành phần khác nhau tạo nên bộ rootkit này, chúng tôi muốn cung cấp một cái
nhìn cấp cao về những gì nó cố gắng đạt được. Mục tiêu của chuỗi thực thi này là triển khai bộ cấy cấp
nhân vào hệ thống Windows mỗi khi nó khởi động, bắt đầu từ một thành phần UEFI bị nhiễm.

Các tác giả phần mềm độc hại UEFI phải đối mặt với một thách thức kỹ thuật duy nhất: bộ cấy của họ bắt
đầu chạy quá sớm trong quá trình khởi động đến nỗi hệ điều hành (trong trường hợp này là Windows)
thậm chí còn chưa được tải trong bộ nhớ - và tại thời điểm đó, ngữ cảnh thực thi UEFI sẽ có chấm dứt.
Tìm cách truyền mã độc qua các giai đoạn khởi động khác nhau là nhiệm vụ chính mà rootkit hoàn
thành.

Quy trình làm việc bao gồm việc thiết lập các hook [1] liên tiếp, cho phép mã độc hại tồn tại cho đến khi
hệ điều hành khởi động. Các bước liên quan là:

Phần sụn bị nhiễm ban đầu khởi động toàn bộ chuỗi. Phần mềm độc hại thiết lập một hook độc hại
trong trình quản lý khởi động, cho phép nó sửa đổi bộ tải nhân của Windows trước khi nó được thực thi.

Bằng cách giả mạo bộ tải hệ điều hành, những kẻ tấn công có thể thiết lập một hook khác trong một
chức năng của nhân Windows. Khi chức năng đó sau đó được gọi trong quy trình khởi động bình thường
của HĐH, phần mềm độc hại sẽ kiểm soát luồng thực thi lần cuối.

Nó triển khai một mã shellcode trong bộ nhớ và liên hệ với máy chủ C2 để truy xuất tải trọng độc hại
thực tế để chạy trên máy của nạn nhân.

Sơ đồ tổng quan :
Sau khi thiết lập được những gì mà bộ cấy phần mềm độc hại cố gắng thực hiện, giờ đây chúng ta có thể
xem xét chi tiết hơn về cách thực hiện của từng bước trong số các bước này.

Toàn bộ chuỗi thực thi bắt đầu bằng trình điều khiển EFI. Nó dường như là một phiên bản vá lỗi của một
phiên bản hợp pháp có tên CSMCORE (nhằm tạo điều kiện khởi động máy ở chế độ kế thừa thông qua
MBR), nơi những kẻ tấn công đã sửa đổi con trỏ thành chức năng dịch vụ khởi động HandleProtocol.
Mỗi khi hàm này được gọi, việc thực thi được chuyển hướng đến mã do kẻ tấn công cung cấp để cố gắng
xác định thành phần nào đã gọi nó (nó đang tìm kiếm một thành phần cụ thể để lây nhiễm - efi). Bằng
cách kiểm tra các đối số của hàm cũng như các byte nằm ở địa chỉ trả về, CosmicStrand có thể xác định
chính xác “lệnh gọi” mà nó đang tìm kiếm.
Điểm cụ thể này trong quá trình thực thi đã được chọn vì ở giai đoạn này, trình quản lý khởi động đã
được tải trong bộ nhớ, nhưng vẫn chưa chạy. CosmicStrand nắm bắt cơ hội này để vá một số byte trong
Archpx64TransferTo64BitApplicationAsm của nó

Chức năng đó sau đó được gọi trong quá trình khởi động hệ điều hành bình thường, cũng tại thời điểm
chiến lược: lúc đó bộ nạp hệ điều hành Windows cũng có trong bộ nhớ và có thể được sửa đổi lần lượt.

Khi nó chạy, Archpx64TransferTo64BitApplicationAsm định vị một chức năng từ bộ tải hệ điều hành
(OslArchTransferToKernel) bằng cách tìm kiếm một mẫu byte cụ thể. Sau đó, CosmicStrand thêm một
hook vào cuối nó.

OslArchTransferToKernel được gọi ngay trước khi việc thực thi được chuyển từ bộ tải Windows sang hạt
nhân Windows, điều này làm cho nó trở thành một điểm nối truyền thống cho các rootkit thuộc loại đó.

Trước khi hạt nhân Windows có cơ hội chạy, CosmicStrand đã thiết lập một hook khác trong mã
ZwCreateSection Mã độc được sao chép [2] vào hình ảnh của ntoskrnl.exe trong bộ nhớ và các byte đầu
tiên của ZwCreateSection được ghi đè để chuyển hướng đến nó. Chúng tôi lưu ý rằng những kẻ tấn công
đã cẩn thận đặt mã độc bên trong không gian chùng của phần .text của ntoskrnl.exe, điều này làm cho
việc chuyển hướng này ít dễ thấy hơn rất nhiều trong mắt các sản phẩm bảo mật có thể xảy ra.Tại thời
điểm này, CosmicStrand dường như cũng cố gắng vô hiệu hóa PatchGuard, một cơ chế bảo mật được
giới thiệu để ngăn chặn các sửa đổi trong cấu trúc chính của nhân Windows trong bộ nhớ. Để làm như
vậy, nó định vị hàm KiFilterFiberContext của ntoskrnl.exe [3] và sửa đổi nó để nó trả về mà không cần
thực hiện bất kỳ công việc nào. Điều đáng chú ý là việc bản địa hóa chức năng này, cũng đạt được bằng
cách tìm kiếm các mẫu mã cứng, rất đầy đủ và thậm chí còn chứa các mẫu tương ứng với bản phát hành
Redstone 1 từ tháng 8 năm 2016.

Nhân Windows sau đó khởi động và kết thúc việc gọi hàm ZwCreateSection được nối trong khi đang
chạy bình thường. Khi điều đó xảy ra, CosmicStrand giành lại quyền kiểm soát việc thực thi và khôi phục
mã gốc trước khi chạy thêm mã độc.

Mục đích chính của ZwCreateSection hook là thu thập địa chỉ của các hàm API do hạt nhân cung cấp và
tạo một loại bảng nhập cho thành phần tiếp theo. Sử dụng các chức năng đã phân giải, nó cũng cấp phát
một bộ đệm trong không gian địa chỉ của hạt nhân nơi nó ánh xạ một mã shellcode, trước khi gọi nó.

Mã vỏ hạt nhân

Tất cả các bước được mô tả cho đến nay chỉ phục vụ mục đích truyền thực thi mã từ UEFI xuống nhân
Windows. Shellcode này là thành phần thực sự độc hại đầu tiên của chuỗi cho đến nay. Nó thiết lập một
quy trình thông báo luồng được gọi mỗi khi một luồng mới được tạo. CosmicStrand đợi cho đến khi một
trong winlogon.exe xuất hiện, rồi thực hiện một lệnh gọi lại trong ngữ cảnh đặc quyền cao này. Tại đó,
CosmicStrand sẽ ngủ trong 10 phút và kiểm tra khả năng kết nối internet của máy bị nhiễm.
CosmicStrand không dựa vào các hàm API cấp cao để tạo lưu lượng mạng mà thay vào đó tương tác trực
tiếp với Giao diện thiết bị truyền tải: nó tạo IRP cần thiết (gói yêu cầu I / O) và chuyển chúng đến ngăn
xếp mạng bằng cách gửi IOCTL đến Đối tượng thiết bị TCP hoặc UDP. Yêu cầu DNS được thực hiện theo
cách này, sử dụng máy chủ DNS của Google (8.8.8 [.] 8) hoặc máy chủ tùy chỉnh (222.222.67 [.] 208).
CosmicStrand truy xuất tải trọng cuối cùng của nó bằng cách gửi gói UDP hoặc TCP được chế tạo cụ thể
(tốt nhất là) đến máy chủ C2 của nó, update.bokts [.] Com. Câu trả lời dự kiến sẽ trả về trong một hoặc
một số gói chứa các phần 528 byte theo cấu trúc sau: