Bring Your Own Vulnerability Drivers (BYOVD) đang xuất hiện ngày càng nhiều hơn trong danh sách các lỗ hổng được phát hiện trên hệ điều hành Windows. Bỏ qua những rào cản vững chắc mà Microsoft đã cố gắng xây dựng để phòng thủ hệ thống mới, kẻ tấn công đang lợi dụng những drivers cũ với nhiều bề mặt để khai thác nhiều cơ hội xâm nhập hệ thống hơn.
BYODV đã trở thành vấn đề nhận được nhiều sự quan tâm và được mang tới AVAR 2024 như một đề tài thảo luận trong việc phòng chống malware trên Windows. Điều đó cho thấy sự an toàn của driver nói chung và vấn đề BYOVD nói riêng cần được đánh giá nghiêm túc như mọi malware hay phương pháp tấn công khác, cần được nghiên cứu kỹ càng, không chỉ với các đội kiểm thử mà còn cả với đội phát triển sản phẩm, cũng như các đơn vị đảm bảo an toàn thông tin cho hệ thống.
Bối cảnh
Các phương pháp bảo vệ drivers của Windows
Ban đầu, các drivers của Windows có thể được load dễ dàng thông qua các công cụ khác nhau (chính thức và không chính thức). Những mục tiêu ban đầu nhắm tới khả năng này chỉ đơn thuần nhằm “vô hiệu hóa một số rào cản”, điển hình là các Anti-cheat engine của các trò chơi. Tuy nhiên, nhận ra sự tự do ấy, nhiều kẻ tấn công đã lợi dụng để dễ dàng xâm nhập vào lõi hệ điều hành và vô hiệu hóa các hệ thống quan trọng (ví dụ: AV, EDR,...). Nhận ra mức độ nghiêm trọng của vấn đề này, Windows đã dần áp dụng các quy tắc kiểm tra để đảm bảo một driver là an toàn trước khi được nạp vào kernel.
Bắt đầu từ Windows 8, các driver muốn được load vào hệ thống bắt buộc phải được ký số bởi một bên thứ 3 và Windows. Việc sở hữu một chữ ký với chi phí đắt đỏ đã phần nào cản bước kẻ tấn công nghiệp dư, tuy nhiên vẫn không thể làm khó những đội có quy mô bài bản. Một số kẻ tấn công còn núp bóng những sản phẩm AV với drivers đã được ký để xâm nhập hệ thống, khiến cho việc xác thực qua ký số trở nên không đủ.
Windows tiếp tục yêu cầu các driver muốn được nạp vào hệ thống phải trải qua Hardware Lab Kit (HLK) compatibility tests và kết quả bài test này phải được đính kèm với driver khi nộp lên Hardware Developer Portal để được ký. Đồng thời, để vào được Hardware Developer Portal, đơn vị phát triển driver bắt buộc phải tham gia vào Hardware Developer Program, một chương trình đặc biệt của Microsoft nhằm kiểm soát các driver do các bên thứ ba phát triển. Đây là một quy trình rất phức tạp và cần nhiều giấy tờ, văn bản pháp lý xác thực. Bằng cách này, con đường tự do phát triển một malicious driver mới để nạp vào hệ thống coi như đã khép lại.
Cùng với đó, Microsoft cũng phát triển Windows Defender và Windows Security Center làm lá chắn riêng cho mình thay vì phụ thuộc vào các AV và EDR khác. Windows Defender sẽ chỉ được tắt khi AV/EDR sử dụng ELAM driver để nạp driver và đăng ký hiện diện với Windows Security Center. Một lần nữa, để có được các công cụ cần thiết để viết ELAM driver, đơn vị phát triển AV/EDR bắt buộc phải tham gia vào Microsoft Virus Initiative (MVI), một tổ chức liên minh chống malware do Microsoft đứng đầu. Đồng thời, sản phẩm AV/EDR phải liên tục vượt qua các bài kiểm tra định kỳ do MVI đề ra, cũng như các bài test khác do các bên thứ 3 cung cấp để đạt đủ và duy trì điều kiện thành viên của MVI. Điều này giúp cho các sản phẩm AV/EDR hoạt động ổn định với hệ sinh thái Windows, đồng thời cũng chặn đứng phần lớn cơ hội lợi dụng AV/EDR để tấn công vào lõi hệ thống.
Tuy nhiên, các quy tắc này lại không áp dụng cho các driver cũ và hệ điều hành cũ. Tức là, những driver cũ nếu đã từng được nạp và chấp nhận bởi kernel cũ, thì sẽ vẫn tiếp tục được nạp và chấp nhận. Những lỗ hổng đã và đang tồn tại ở driver cũ, vẫn sẽ tồn tại. Đây là cơ hội tấn công rất lớn mà các đội tấn công đã nhìn ra và khai thác.
Những cuộc tấn công mới nhất năm 2024
Tháng 1/2024 – Kasseika
Vào tháng 1 năm 2024, nhóm Kasseika ransomware lợi dụng driver viragt64.sys, vốn là thành phần hợp lệ của phần mềm VirIT antivirus. Họ đổi tên driver này thành Martini.sys, sau đó khởi tạo một dịch vụ để tải driver vào ứng dụng độc hại. Khi driver đã được tải, ransomware sẽ chạy một script dò tìm tiến trình (process) liên quan đến công cụ bảo mật hoặc tiện ích hệ thống — nếu tiến trình nào trong danh sách này đang chạy, ransomware gửi mã điều khiển tới driver để tắt các tiến trình đó, từ đó làm suy yếu khả năng phòng vệ trước khi mã độc mã hóa dữ liệu.
Tháng 3/2024 – Akira
Tháng 3 năm 2024, ransomware Akira cũng sử dụng driver zamguard64.sys (thuộc phần mềm chống malware Zemana) — driver này đã được ký hợp lệ, nên khó bị chặn bởi hệ thống nếu không có biện pháp bảo vệ đặc biệt. Akira sử dụng công cụ PowerTool để khai thác driver này nhằm tắt các công cụ EDR ở cấp độ kernel (hệ điều hành cấp thấp hơn, sâu hơn). Việc tắt EDR ở cấp thấp như vậy cho phép ransomware hoạt động mà ít bị phát hiện hoặc bị can thiệp.
Tháng 7/2024 – Qilin
Trong tháng 7 năm 2024, nhóm Qilin ransomware dùng một phần mềm malware mới tên Killer Ultra, có chức năng rất rộng, trong đó có khả năng tắt các công cụ bảo mật thông qua BYOVD. Họ lợi dụng lỗ hổng CVE-2024-1853 trong driver của Zemana Anti-Keylogger để cho phép tắt tiến trình — tức là, nếu driver bị khai thác, mã độc có thể ra lệnh cho hệ thống đóng các tiến trình bảo mật mà bình thường người dùng hoặc hệ thống bảo mật không cho phép. Khi Killer Ultra thực thi, nó sẽ giải nén driver dễ bị tổn thương vào hệ thống, khởi tạo dịch vụ mới để load driver, sau đó dò quét các tiến trình bảo mật trong danh sách cố định để tắt chúng.
Tháng 7/2024 – BlackByte
Cũng vào tháng 7 năm 2024, nhóm BlackByte phát triển chuỗi tấn công BYOVD để giúp việc mã hóa dữ liệu (host encryption) thuận lợi hơn. Họ sử dụng bốn driver có lỗ hổng: RtCore64.sys (từ phần mềm overclocking của MSI), DBUtil_2_3.sys (thuộc tiện ích cập nhật firmware của Dell), zamguard64.sys (như trên, từ Zemana Anti-Malware), và gdrv.sys (thuộc công cụ của GIGABYTE dành cho bo mạch chủ). Các driver này bị đổi tên ngẫu nhiên, rồi được thả vào hệ thống bởi mã độc; sau đó mã độc dùng các driver này để vô hiệu hóa các tiến trình bảo mật, giúp quá trình mã hóa dữ liệu diễn ra mà không bị chặn mạnh.
Tháng 8/2024 – RansomHub
Tháng 8 năm 2024, nhóm RansomHub dùng một malware gọi là EDRKillShifter để tắt các công cụ bảo mật trước khi mã hóa dữ liệu. EDRKillShifter hoạt động như loader: giải mã một phần tài nguyên nhúng trong mã độc, sau đó giải nén và chạy payload để khai thác driver hợp pháp có lỗ hổng. Driver này nếu được tải thành công sẽ giúp nâng quyền và tắt các tiến trình bảo mật đang chạy. RansomHub cũng tạo một dịch vụ driver mới, load driver đó, và liên tục quét hệ thống để tìm tiến trình bảo mật theo danh sách có sẵn để tắt, thậm chí thực hiện sau khi khởi động lại máy.
Đứng trước vấn đề này, bên cạnh việc ra thông báo và yêu cầu các đơn vị vá các lỗ hổng trong driver của mình, Windows cũng cho ra driver blocklist - danh sách các driver bị chặn hoạt động, nhằm cố gắng bao phủ các bề mặt tấn công cũ. Driver blocklist được giới thiệu trong Windows 10, version 1809 và mặc định trên Windows 11, hoặc các máy tính có bật Hypervisor-protected Code Integrity (HVCI), hoặc có chạy S-mode. Rõ ràng, đây là một phương pháp có tính “vét cạn”, và do đó vẫn có thể có những mối nguy hiểm tiềm ẩn trong những driver nằm ngoài blocklist.
Đồng thời, driver blocklist này, cùng các quy tắc khác cho driver, vẫn không áp dụng cho Windows 7 trở về trước. Hiện tại, các drivers vẫn có thể được nạp tự do trên các hệ điều hành này. Do đó các nguy cơ đối với các hệ điều hành cũ vẫn rất cao. Dẫu cho Microsoft đã tuyên bố dừng hỗ trợ các hệ điều hành cũ, nhưng một đại đa số người dùng vẫn còn đang sử dụng các phiên bản nhiều nguy cơ này (đặc biệt là ở Việt Nam, số lượng người dùng Windows 7 vẫn rất đáng kể). Do đó, nguy cơ người dùng bị tấn công BYOD vẫn rất lớn.
Các Payload tấn công
Lưu ý, đây là các payload dược khai thác trên các driver cũ, tức là không được bảo vệ bởi các quy trình, điều kiện mà Microsoft đã đề ra.
Các mô tả dưới đây chỉ nhằm phục vụ nghiên cứu và kiểm thử, phòng thủ hệ thống. Tác giả không chịu trách nhiệm với mọi hành vi sử dụng các tri thức này để thực hiện hoạt động tấn công phá hoại.
_EPROCESS
Đây là payload được ghi nhận phổ biến nhất trong các lỗ hổng BYOVD. Cốt lõi của việc khai thác payload này là tìm tới cấu trúc _EPROCESS. Đây là cấu trúc lưu trữ thông tin của một tiến trình, bao gồm cả tiến trình thường và tiến trình hệ thống. _EPROCESS bao gồm các vùng ghi PID, Process Environment Block (PEB), Thread Environment Block (TEB), thông tin tài nguyên (mutex, file…) và đặc biệt là thông tin về quyền của tiến trình, được lưu trong Access Token. Kẻ tấn công sẽ tìm tới một vùng nhớ trỏ tới Primary Access Token của _EPROCESS, sau đó lấy sao chép nó và thay thế vào malicious driver/system process.
Một phương pháp lợi dụng payload này là tính RVA tới PsInitialSystemProcess trỏ tới System process (0x04), sau đó dùng malicious driver chạy NtQuerySystemInformation và tìm tới _EPROCESS, cuối cùng là tính toán offset tới Primary Access Token trong _EPROCESS và copy lại vào malicious driver.
Các trình loader đã được phê chuẩn bởi Microsoft
Lợi dụng vấn đề một số legacy driver vẫn được chấp nhận và nạp bởi một số trình nạp driver, kẻ tấn công sẽ lợi dụng các trình nạp driver này để nạp vào các mã độc dưới dạng shellcode hoặc malicious driver.
Một open-source driver loader đã lợi dụng Lenovo Mapper để nạp vào một anti-cheat driver nhằm vô hiệu hóa hệ thống TPM-based license check của Valorant thông qua kỹ thuật ghi đè vùng nhớ tùy ý (arbitrary memory write).
Hệ thống anti-cheat driver này đã được Windows đưa vào blocklist vào 2024.
Các driver không được cấu hình quyền hạn
Một trong những lỗ hổng thường thấy khác của driver đó là quyền hạn của driver được mở không giới hạn trên toàn bộ máy. Lợi dụng điều này, kẻ tấn công có thể dựa vào driver đã được nạp vào hệ thống để thực thi mã độc dưới quyền SYSTEM, ghi mã độc vào các vùng nhớ quan trọng của hệ thống, hoặc phá hủy dữ liệu.
RawDisk là một driver nằm trong phần mềm của EldoS Corporation, có nhiệm vụ tương tác với file và ổ đĩa để cập nhật, chỉnh sửa thông tin. RawDisk được cấu hình để có quyền đọc ghi trên cả các phân vùng MBR, dẫn tới nguy cơ tấn công gây mất toàn bộ dữ liệu và hỏng hệ thống.
RawDisk đã được liệt kê vào danh sách của MITRE AT&ACK.
Các lớp vulnerabilities phổ biến
Đọc/ghi đè tùy ý trên MSR (Arbitrary MSR read/write vulnerabilities)
MSR là các thanh ghi được CPU sử dụng cho nhiều mục đích khác nhau. Bằng cách gọi tới MSR thông qua số của MSR hoặc tên cụ thể, hệ điều hành có thể điều khiển nhiều thành phần của hệ thống: caching, điều khiển tốc độ quạt… và đặc biệt là chuyển lời gọi từ user mode xuống kernel mode.
Khi chuyển giao này xảy ra (thường là ở tầng user mode thấp nhất, ví dụ: ntdll.dll), một system call tương ứng với lời gọi được yêu cầu được đặt vào thanh rax, sau đó instruction int 0x2e sẽ được thực hiện. Thanh RIP sẽ được cập nhật tới địa chỉ của system call handler tại kernel, và RSP sẽ trỏ đến một stack ở kernel để gọi hàm tiến hành thực thi syscall. Ở Windows x64, thông thường sẽ là KiSystemCall64.
Vậy làm thế nào để hệ thống biết được địa chỉ của KiSystemCall64 ở đâu để gọi? Nó nằm ở một thanh MSR đặc biệt phục vụ cho việc chuyển lời gọi từ user mode sang kernel mode; ở Windows x64, nó là MSR 0xC0000082.
Biết được số của MSR này, kẻ tấn công hoàn toàn có thể lợi dụng khả năng ghi đè tùy ý lên thanh MSR để thay địa chỉ của KiSystemCall64 bằng một địa chỉ khác trỏ tới một hàm muốn thực thi, từ đó chạy đoạn mã độc mong muốn.
Một ví dụ cho kiểu tấn công này là WinRing0 - một driver được dùng trong nhiều phần mềm phục vụ đào tiền mã hóa. WinRing0 có mục đích điều khiển (và vô hiệu hóa) một số tính năng hệ thống như caching, quạt gió… để dồn tài nguyên cho miner. Lỗ hổng trên WinRing0 đã được phát hiện vào năm 2020.
Đọc/ghi đè tùy ý trên kernel physical memory
Bất cứ driver nào cho phép đọc ghi vùng nhớ tùy ý đều có thể là đối tượng cho kiểu tấn công này. Kẻ tấn công sẽ lợi dụng các hàm đọc/ghi vùng nhớ tùy ý để tìm đến và lấy/thay đổi Access Token hoặc các cấu trúc tại kernel mode, nhằm nâng quyền (privilege escalation) cho một process tại user mode hoặc kernel mode.
Các hàm sau, nếu được sử dụng trong một driver có cho phép giao tiếp thông qua IOCTL, đều khiến cho driver có khả năng bị tấn công bằng phương thức này.
Access to Physical Memory
MmMapIOSpace()
ZwMapViewOfSection()
PCI Config Space Access
HalSetBusDataByOffset()
HalGetBusDataByOffset()
Memory Copying Operations
memcpy()
memmove()
Sử dụng driver không được cấu hình quyền hạn
Tận dụng payload driver không được cấu hình quyền hạn đã nêu trên, kẻ tấn công có thể thực thi các hành động dưới quyền system và gây hại tới hệ thống.
Một trong những nguyên nhân của vấn đề này có thể kể tới việc sử dụng các template/ skeleton driver mà không audit cẩn thận. Việc nghiên cứu và phát triển driver (đặc biệt là driver trên Windows) được đánh giá là khó, do vậy việc tái sử dụng các đoạn code open-source hoặc code mẫu trong các giáo trình là điều dễ thấy. Tuy nhiên, các đoạn code này chỉ mang tính minh họa, và để chứng minh hoạt động của chúng (và dễ hơn cho người đọc thực thi các đoạn code), quyền hạn của/với driver thường được mở không giới hạn, tạo điều kiện truy cập các tài nguyên, và cũng tạo điều kiện cho các tấn công.
Một trong những cách phân quyền tương tác với driver đó là sử dụng Security Descriptor Definition Language (SDDL) trong file INF cài đặt driver hoặc IoCreateDeviceSecure. Chuỗi này chỉ định nhóm/đối tượng và các quyền được tương tác với driver. Thông thường, quyền này sẽ được giới hạn; ví dụ, chuỗi D:P(A;;GA;;;SY)(A;;GR;;;WD) chỉ định SYSTEM được quyền truy cập mọi thứ của driver, và mọi user khác chỉ được quyền read. Nhưng trong nhiều hướng dẫn và skeleton, chuỗi này không được thiết lập (mặc định global), hoặc chuỗi mặc định D:(A;;FA;;;WD) (full quyền cho tất cả) được sử dụng, dẫn tới nguy cơ bị khai thác.
Trong các bài blog tới, chúng ta sẽ đi tìm hiểu sâu hơn về cách triển khai một số kỹ thuật khai thác trên, cũng như một số cách phòng chống cụ thể.