CVE-2024-39707

Executive Summary

CVE-2024-39707 is a critical security vulnerability in Insyde's IHISI (Insyde H2O Interface for System Initialization) firmware interface. The flaw resides in function 0x49, which can restore factory defaults for certain UEFI variables without requiring authentication. This lack of access control (CWE-306) allows an attacker with local or physical access to the system to perform a roll-back attack, potentially downgrading critical UEFI security settings (such as Secure Boot or TPM configurations) to a less secure state. This could enable the installation of persistent bootkits or bypass of firmware-level security controls. The vulnerability affects multiple Insyde kernel versions and has been patched in the specified releases.

CVSS Breakdown & Threat Level

The CVSS score is currently 0.0 (UNKNOWN). However, based on the vulnerability characteristics, a realistic assessment would be:

• Attack Vector (AV): Local (L) – requires physical or local administrative access.
• Attack Complexity (AC): Low (L) – the IHISI function is directly callable.
• Privileges Required (PR): Low (L) – requires some form of local access, but not necessarily root.
• User Interaction (UI): None (N) – no user interaction needed.
• Scope (S): Changed (C) – the vulnerability can affect resources beyond the original authorization boundary (UEFI variables).
• Confidentiality (C): High (H) – could lead to exposure of firmware secrets.
• Integrity (I): High (H) – allows modification of critical UEFI variables.
• Availability (A): Low (L) – could cause system instability.

Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
Estimated Score: 8.2 (High)

Threat Level: High. While the EPSS score is 0.0%, the vulnerability's potential for persistent firmware compromise and roll-back attacks makes it a high-priority target for advanced persistent threats (APTs) and firmware-level attackers.

Deep Dive & Mechanics

The vulnerability exists in the Insyde IHISI (Insyde H2O Interface for System Initialization) firmware interface, specifically in function 0x49. This function is designed to restore factory defaults for certain UEFI variables. The flaw is that the function does not require any authentication or authorization before performing this operation.

Mechanism:

1. An attacker with local access (e.g., via a compromised OS or physical access) can call the IHISI function 0x49.
2. The function will reset specific UEFI variables to their factory default values.
3. This can be used to downgrade security-critical UEFI variables, such as:
   • Secure Boot state (enabled -> disabled)
   • TPM (Trusted Platform Module) configuration
   • Boot order or boot policy settings
   • Firmware update policies
4. By rolling back these settings, the attacker can bypass firmware-level security controls and install persistent malware (e.g., bootkits like LoJax or MoonBounce) that survives OS reinstallation.

Attack Scenario:

• Roll-back Attack: The attacker can downgrade Secure Boot to "Setup Mode" or disable it entirely, allowing unsigned code to be executed during boot.
• Persistence: Once Secure Boot is disabled, the attacker can install a malicious UEFI driver or bootkit that loads before the OS, providing persistent access.
• Bypass of TPM-based protections: If TPM measurements are reset, the attacker can bypass BitLocker or other TPM-based protections.

Vulnerable vs. Patched Code

The vulnerability is in the IHISI function 0x49 implementation. The vulnerable code does not check the caller's privileges before restoring factory defaults. The patched code adds an authentication check.

Vulnerable Code (Conceptual):

EFI_STATUS
IHISI_Function_0x49 (
  IN UINTN FunctionNumber,
  IN VOID *Parameters
  )
{
  // No authentication check
  return RestoreFactoryDefaults(Parameters);
}

Patched Code (Conceptual):

EFI_STATUS
IHISI_Function_0x49 (
  IN UINTN FunctionNumber,
  IN VOID *Parameters
  )
{
  EFI_STATUS Status;
  
  // Authentication check added
  Status = CheckCallerPrivileges();
  if (EFI_ERROR(Status)) {
    return EFI_ACCESS_DENIED;
  }
  
  return RestoreFactoryDefaults(Parameters);
}

The patch ensures that only authorized callers (e.g., system firmware update processes) can invoke the factory reset functionality.

Exploitation & Lab Setup

Red Team

Objective: Exploit CVE-2024-39707 to disable Secure Boot and install a persistent UEFI bootkit.

Lab Setup:

• Target machine with vulnerable Insyde firmware (e.g., kernel 5.2 < 05.29.19).
• Attacker machine with UEFI exploitation tools (e.g., UEFI Toolkit, Chipsec).
• Bootkit payload (e.g., modified version of LoJax or EfiGuard).

Exploitation Steps:

1. Gain local access to the target system (e.g., via a compromised OS account or physical access).
2. Identify the IHISI interface (typically via \EFI\Insyde\IHISI.efi or similar).
3. Call function 0x49 to reset UEFI variables:

   # Example using Chipsec
   chipsec_main -m common.uefi.ihisi -a 0x49
   

4. Verify that Secure Boot is disabled:

   # Check Secure Boot status
   mokutil --sb-state
   

5. Install the bootkit payload:

   # Write malicious UEFI driver to EFI partition
   dd if=bootkit.efi of=/boot/efi/EFI/BOOT/bootx64.efi
   

6. Reboot and confirm persistence.

Expected Outcome: The attacker gains persistent firmware-level access, bypassing OS-level security controls.

Blue Team

Objective: Detect and prevent exploitation of CVE-2024-39707.

Detection Steps:

1. Monitor for unusual calls to IHISI function 0x49 using UEFI runtime services monitoring.
2. Enable Secure Boot and TPM attestation to detect roll-back attacks.
3. Use firmware integrity monitoring tools (e.g., CHIPSEC, FWTS) to detect unauthorized UEFI variable changes.
4. Monitor for unexpected changes to Secure Boot state or boot order.

Prevention:

• Apply the firmware patch immediately.
• Enable Secure Boot with custom keys to prevent unauthorized firmware modifications.
• Use TPM-based remote attestation to verify firmware integrity.
• Restrict physical access to systems.

Indicators of Compromise (IOCs)

• UEFI Variable Changes: Unexpected changes to SecureBoot, SetupMode, BootOrder, or TPM variables.
• Firmware Logs: Entries showing IHISI function 0x49 being called without a corresponding authentication event.
• Bootkit Artifacts: Presence of unsigned UEFI drivers in the EFI System Partition (ESP).
• System Behavior: Secure Boot being disabled without user interaction, or boot order changing unexpectedly.
• Network IOCs: Outbound connections from firmware-level code (e.g., C2 traffic from a bootkit).

Detection Engineering

YARA Rule

rule CVE_2024_39707_IHISI_Function_0x49 {
   meta:
      description = "Detects calls to Insyde IHISI function 0x49 for factory reset"
      author = "Valters IT"
      date = "2025-04-10"
      reference = "CVE-2024-39707"
   strings:
      $s1 = "IHISI" ascii wide nocase
      $s2 = "0x49" ascii wide nocase
      $s3 = "RestoreFactoryDefaults" ascii wide nocase
   condition:
      all of them
}

Sigma Rule

title: CVE-2024-39707 - Insyde IHISI Function 0x49 Factory Reset
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects calls to Insyde IHISI function 0x49 which can reset UEFI variables without authentication
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-39707
logsource:
    product: windows
    service: system
    definition: 'Requires UEFI runtime services logging'
detection:
    selection:
        EventID: 1
        Image|endswith: '\IHISI.efi'
        CommandLine|contains: '0x49'
    condition: selection
falsepositives:
    - Legitimate firmware update processes
level: high

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-39707 - Insyde IHISI Function 0x49 Factory Reset Attempt"; content:"|49 00 00 00|"; offset:0; depth:4; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Apply the firmware patch provided by Insyde for the affected kernel versions:
   • Kernel 5.2: Update to version 05.29.19 or later.
   • Kernel 5.3: Update to version 05.38.19 or later.
   • Kernel 5.4: Update to version 05.46.19 or later.
   • Kernel 5.5: Update to version 05.54.19 or later.
   • Kernel 5.6: Update to version 05.61.19 or later.
2. Verify that Secure Boot is enabled and properly configured.
3. Enable TPM-based remote attestation to detect firmware tampering.

Long-term Mitigations:

• Implement firmware integrity monitoring using tools like CHIPSEC or FWTS.
• Restrict physical access to systems.
• Use UEFI Secure Boot with custom keys to prevent unauthorized firmware modifications.
• Regularly audit UEFI variable changes.

Workarounds (if patching is not possible):

• Disable the IHISI interface if not required (consult vendor documentation).
• Implement additional access controls at the OS level to prevent local users from calling UEFI runtime services.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert