- Malware thường kiểm tra sự hiện diện của phần cứng như quạt CPU để tránh chạy trong môi trường ảo
- Có thể kiểm tra thông tin quạt CPU qua lớp WMI Win32_Fan, và dữ liệu này được lưu trong SMBIOS
- Để chèn dữ liệu SMBIOS tùy chỉnh trong Xen, cần có bản vá và cấu hình riêng, đồng thời phải cấu hình cả bảng Cooling Device (Type 27) và Temperature Probe (Type 28)
- Trên QEMU/KVM, có thể áp dụng SMBIOS tùy chỉnh một cách đơn giản bằng tùy chọn -smbios mà không cần bản vá riêng
- Nhờ đó, có thể làm cho máy ảo trông như có quạt CPU, từ đó thử vượt qua cơ chế phát hiện của malware
Vì sao phải làm việc này?
- Một số malware kiểm tra sự hiện diện của phần cứng cụ thể (ví dụ: quạt CPU) để xác định liệu chúng có đang chạy trong môi trường ảo hay không
- Chúng kiểm tra phần cứng qua các lớp WMI như Win32_Fan; nếu thiếu các thông tin này, chúng sẽ kết luận đó là máy ảo và tránh thực thi
- Mục đích là để ngăn các nhà phân tích phân tích malware
- Có nhiều lớp WMI khác nhau như Win32_CacheMemory, Win32_VoltageProbe, nhưng bài viết này tập trung vào quạt CPU
Máy tính nhận biết có quạt CPU như thế nào?
- Máy tính đọc thông tin SMBIOS để nhận biết sự hiện diện của thiết bị làm mát (quạt CPU)
- Instance Win32_Fan được cung cấp bởi cimwin32.dll, và DLL này đọc thông tin quạt từ mục type 27 của SMBIOS
- Có thể dùng cách như hooking DLL, nhưng thao tác trực tiếp với SMBIOS là cách tiếp cận tốt hơn
SMBIOS Type 27
- SMBIOS type 27 có nghĩa là "Cooling Device"
- Có thể dùng tiện ích dmidecode để kiểm tra trực tiếp dữ liệu Cooling Device trong SMBIOS
- Ví dụ:
- Type: Chip Fan
- Status: OK
- Description: CPU Fan
- Nominal Speed: 5600 rpm, v.v.
Cách cấu hình dữ liệu SMBIOS tùy chỉnh trong Xen
- Trong Xen, có thể dùng tùy chọn smbios_firmware trong file cấu hình domain để chỉ định trực tiếp dữ liệu SMBIOS ở dạng nhị phân
- Tạo file smbios.bin và chèn dữ liệu Cooling Device (type 27) vào đó
- Kích thước cấu trúc SMBIOS (ví dụ: 24 byte) phải được thêm ở phía trước dưới dạng số nguyên little-endian 32-bit
Vấn đề: giới hạn ghi đè cấu trúc
- Xen chỉ cho phép ghi đè các cấu trúc số 0, 1, 2, 3, 11, 22, 39
- Type 27 mặc định không được cho phép, nên cần vá mã nguồn
- Trên diễn đàn nhà phát triển Xen cũng từng có bản vá liên quan được đề xuất, nhưng chưa được chấp nhận chính thức (cần áp dụng bản vá và tự build)
Cần cả Type 28
- Cooling Device (type 27) có liên kết với Temperature Probe (type 28)
- Nếu SMBIOS không có mục type 28, lớp Win32_Fan sẽ không hiển thị bình thường
- Cần lấy dữ liệu type 28 từ hệ thống host và thêm vào smbios.bin để được nhận diện chính xác
Cấu trúc smbios.bin hoàn chỉnh
- Bao gồm cả dữ liệu Type 27 và Type 28
- Chèn thông tin kích thước (little-endian) trước mỗi cấu trúc
- Ví dụ: dạng 18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ...
Áp dụng và kiểm tra trong Xen
- Sau khi khởi động máy ảo Windows bằng lệnh tạo domain, kiểm tra trong WMI xem lớp Win32_Fan có được nhận diện bình thường hay không
- Nếu hiện Description: Cooling Device, Status: OK thì việc nhận diện quạt CPU đã thành công
Cấu hình dữ liệu SMBIOS trong QEMU/KVM
- Trên QEMU/KVM, có thể dễ dàng cấu hình SMBIOS tùy chỉnh bằng tùy chọn -smbios file=đường_dẫn
- Dùng dữ liệu raw mà không cần thông tin kích thước cấu trúc
- Có thể dùng nguyên dữ liệu SMBIOS của host cũng không sao
Tài liệu tham khảo
- Tài liệu file cấu hình domain của Xen, ghi chú thiết lập của mcnewton, kho lưu trữ bản vá Xen bị từ chối, System Management BIOS Reference, bản vá QEMU Anti Detection, v.v.
1 bình luận
Ý kiến Hacker News
Một cách chống mã độc mới là mua PC tản nhiệt thụ động; cũng có nhắc tới mẹo đặt bàn phím tiếng Nga để chặn kiểu malware lừa đảo, có thể xem liên kết liên quan
Tôi thực sự đang dùng PC Linux tản nhiệt thụ động Streacom FC8 Evo cùng bàn phím tiếng Nga, nhưng khi xem bằng lệnh dmidecode thì thông tin thiết bị làm mát vẫn còn đó và thiết bị làm mát vẫn được phát hiện, dữ liệu cảm biến cũng cho thấy thông tin nhiệt độ
Có ý kiến cho rằng dù dùng PC tản nhiệt thụ động thì trên bo mạch chủ thường vẫn còn các đầu cắm quạt, nên kể cả không cắm thật thì cũng chẳng khác biệt lớn
Có người nói đừng dùng những cách nói như “smol pp”, chỉ ra rằng trong ngôn ngữ đó có yếu tố chế giễu cơ thể
Ở thành phố tôi có một người dùng biển số tùy chỉnh “SML PP”, tôi không biết tại sao lại như vậy
Có ý kiến rằng khi dùng cách nói “ngôn ngữ của chúng ta”, thì bản thân việc một người trong phần bình luận blog nói tới “chúng ta” đã là khá mơ hồ
Có ý kiến cho rằng nếu làm cho hệ điều hành trông như máy ảo thì sẽ tăng bảo mật và hữu ích cho nhà nghiên cứu; nếu muốn cách tiếp cận không ảo hóa thì phải được cấp quyền rõ ràng, và như vậy malware có thể sẽ tránh nhắm cả người dùng phổ thông chỉ để né phân tích của nhà nghiên cứu, rốt cuộc ai cũng được lợi trừ tác giả malware
Có ý kiến rằng thay vì làm hệ điều hành thông thường trông giống VM, thì nên làm cho máy ảo hoàn toàn không biết rằng nó đang bị ảo hóa; hệ thống lpars của IBM được cho là hoạt động theo kiểu đó
Có nhắc rằng nếu làm vậy thì các công ty phần mềm chống gian lận cũng sẽ bị thiệt; tôi muốn biết rõ phần mềm của mình đang chạy ở đâu, nhưng cũng có nhiều người chơi multiplayer ghét kẻ gian lận còn hơn cả cheat, nên trên thực tế không dễ thay đổi
Có người nói trong thế giới phát triển di động thì kiểu khuôn khổ này thực ra đã trở thành hiện thực
Tôi chưa từng thấy mô tả SMBIOS trên bo mạch chủ tiêu dùng nào thực sự khớp với phần cứng thật; malware kiểm tra SMBIOS kiểu này có thể thất bại trên 50% phần cứng thật, nhưng nếu nó chặn chắc 100% VM hoặc debugger thì từ góc nhìn malware vẫn rất đáng làm dù có thất bại; tuy vậy có lẽ đo thời gian sẽ đáng tin hơn cách này
Có phản hồi rằng hiện tượng mô tả SMBIOS không khớp phần cứng thật đặc biệt nghiêm trọng ở các hộp máy giá rẻ từ Trung Quốc; những giá trị bỏ trống như “to be filled in by OEM” rất hay xuất hiện ngay trong image BIOS đang chạy khi mã hóa, chỉ riêng các giá trị đó thôi cũng đã đủ buồn cười rồi
Malware cũng đầy lỗi; giống như trước đây từng có trường hợp lỗi trong mã mạng khiến virus lây lan với tốc độ chỉ bằng một nửa so với dự định, nên dù malware không lây được lên mọi thiết bị thì nó vẫn có thể gây thiệt hại khổng lồ
Gần đây tôi tò mò Linux nhận diện quạt bằng cách nào, có dùng ACPI hay EFI không, vì hầu hết thiết bị của tôi đều nhận đúng quạt/cảm biến
Có người hỏi liệu kiểu kiểm tra SMBIOS này có thật sự được malware ngoài đời dùng hay chỉ xuất hiện trong mẫu do nhà nghiên cứu tạo ra
Có ý kiến rằng những trò malware dùng API để làm việc phân tích khó hơn có thể trông dễ thương, nhưng phần lớn các lời gọi API như vậy rất dễ bị phát hiện bằng phân tích tĩnh, và nếu binary không bị làm rối thì còn phản tác dụng; chia sẻ kinh nghiệm rằng các chương trình có mục đích thực sự thường được phát hành với chữ ký từ CA đáng tin cậy nên trong phân tích bảo mật những hành vi kiểu đó rất dễ bị đánh dấu khả nghi; hồi còn junior tôi cũng từng bắt kiểu dùng API này bằng mẫu regex, và nó khá hiệu quả trong việc bắt các mẫu mã độc cơ bản phát tán diện rộng
Gần đây malware cũng ký file khá thường xuyên; kỳ vọng rằng các băng nhóm malware sẽ không ký binary nữa là sai, chứng chỉ ký mã bị đánh cắp là chuyện phổ biến, và cũng có nhắc tới việc Microsoft ngại thu hồi chứng chỉ vì sợ làm hỏng phần mềm của khách hàng hiện có; malware cũng hay lợi dụng driver dễ tổn thương để chui vào kernel, nên thực tế là một binary nhỏ đáng ngờ gọi WMI thì dễ bị để ý hơn, còn tiện ích ép xung đầy lỗ hổng làm cùng truy vấn đó lại chẳng ai nghi ngờ; trên thực tế cách này không hẳn để né phát hiện mà để payload malware không kích hoạt trên PC của nhà phân tích, nếu bị phát hiện thì payload giai đoạn hai sẽ không được tải xuống và hành vi C&C có thể tạo ra tấn công thật cũng bị hoãn lại
Có đề xuất rằng từ góc nhìn bảo mật, có lẽ nên chạy mọi phần mềm trong VM
Có ý kiến rằng antivirus chỉ dựa vào phân tích tĩnh để đoán malware hay không cũng khá mơ hồ; nếu vậy thì chi bằng dùng hẳn cơ chế whitelist, chỉ cho phép phần mềm đáng tin và coi tất cả phần còn lại là malware, kết quả cũng chẳng khác gì
Thực tế là các công ty như CrowdStrike có thể được ký chính thức cho phần mềm cẩu thả chạy ở mức kernel và gọi đủ loại system call mà chẳng ai bận tâm; bất kể có phải VM hay không, vấn đề là cứ đưa code và bản phát hành chưa được kiểm chứng vào production rồi khi thế giới thực sự hỏng hóc, chuyến bay bị chậm hay hạ tầng trọng yếu gặp sự cố thì cũng không chịu trách nhiệm tương xứng; thậm chí có phê phán rằng các công ty hợp pháp đôi khi còn gây thiệt hại lớn hơn hacker hay tác nhân cấp quốc gia, và vụ xz util cũng được xem là tai nạn bảo mật lớn ngang tầm SolarWinds hay ClownStrike
Tôi từng thấy một người bạn trong ngành infosec dành phần lớn thời gian để làm honeypot malware giống hệt phần cứng thật; thật đáng kinh ngạc khi họ thiết lập cực kỳ tinh vi đủ loại thiết bị, từ bộ điều nhiệt chạy Windows XP cho tới bộ điều khiển PLC của Siemens và desktop ngân hàng
Điều này làm tôi nhớ tới việc khi thiết lập Hackintosh thì SMBIOS phù hợp là bắt buộc; rất nhiều API PC tương đối ít phổ biến đã được đưa vào trong vài thập kỷ qua, và chúng thường được dùng để kiểm tra phần mềm ảo hóa hay malware phản ánh các chi tiết này tốt đến mức nào; nếu muốn tiến thêm một bước thì còn cần cả mô phỏng cảm biến nhiệt độ thay đổi động theo tải CPU thực tế
Theo Mitre ATT&CK T1497.001 (VM Detection), kiểm tra SMBIOS là một vector đã được biết đến; tôi cũng thử nghiệm và thấy có thể cấu hình nguồn điện thành ‘HotReplaceable=Yes’, ‘Status=OK’ để nó hiện như một máy chủ bare-metal trị giá 5.000 USD; lệnh đã dùng là
pip install dmigenrồidmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1