Ramiel
uefi diskless persistence technique + OVMF secureboot bypass
Install / Use
/learn @3intermute/RamielREADME
#
.%%( (
/%%%%%% *#
,%%%%%%%% (
%%%%%%%%%%%% ,(
*%%%%%%%%%%%%%%, (
#&%%%%%%%%%%%%%%%&@@ /
#%%%%%%%%%%&@ %%%% %%%%%%@, &
%%%%%%@.*%%%%%%%%%%%%% (%%%%%%%%%%%%%@ *
*%%%%%%%%%%%%%%%%%%%%%%% &&%%%%%%%%%%%%%%%%%%%&*/
/@@@@%%%%%%%%%%%%%%%%& %&%%%%%%%%%%%%%%%%%%&,
,#@@@@@@@&%%%%%%%%%&.%&%%%%%%&%%%%%%%%% (
@@@@@@@@@@@@%%%& %%%%%%%%%%%%%%%,
#@@@@@@@@@@&@% %%%%%%%%%%%%&/
(@@@@@@&@@@ %%%%%%%%%%,
*@@@@@@@@ %%%%%%%//
&@@@@ %%%%%/
/@@*%%*
@
RAMIEL POC WRITEUP
0xwillow, jan 2023
uefi diskless persistence technique + OVMF secureboot bypass
https://cpl0.zip https://github.com/3intermute/ramiel
featured on black mass vol 2 !!: https://twitter.com/vxunderground/status/1704194528662409444
<========================================================================================> abstract:
the majority of UEFI bootkits persist within the EFI system partition.
disk persistence is not ideal as it is easily detectable and cannot survive OS
re-installations and disk wipes. furthermore, for almost all platforms, secureboot is
configured to check the signatures of images stored on disk before they are loaded.
more recently, a new technique [6] of persisting in the option rom of PCI cards was
discovered. the technique allowed bootkits to survive OS re-installations and disk
wipes. in the past, edk2 configured secureboot to allow unsigned option ROMs to
execute [8], but this has since been patched for most platforms.
PCI option rom persistence is not without limitations:
1. PCI option rom is often small, usually within the range of ~32 - ~128 KB,
providing little room for complex malware.
2. PCI option rom can be trivially dumped as it is mapped into memory.
ramiel attempts to mitigate these flaws. leveraging motherboard NVRAM, it can utilize
~256 KB of persistent storage on certain systems, which is greater than what current
option rom bootkits can utilize.
it is also difficult to detect ramiel since it prevents option roms from being
mapped into memory, and as vault7 [7] states:
"there is no way to enumerate NVRAM variables from the OS... you have to know the
exact GUID and name of the variable to even determine that it exists."
additionally, due to a misconfiguration in OVMF, ramiel is able to bypass secureboot
for certain hypervisors.
<========================================================================================> implementation details:
- overview:
| 0.1 overview |
the order in which sections are presented is the order in which ramiel performs operations.
-
infection: 1.1 ramiel writes a malicious driver to NVRAM 1.2 ramiel writes chainloader to PCI option rom
-
subsequent boots: 2.3 ramiel patches secureboot check in LoadImage to chainload unsigned malicious driver 2.4 ramiel prevents oprom from being mapped into memory by linux kernel 2.5 chainloader loads the malicious driver from NVRAM
misc: 2.1 OVMF misconfiguration allows for unsigned PCI option roms to execute with secureboot enabled 2.2 overview of PCI device driver model 2.6 source debugging OVMF with gdb
initial infection: ┌───────────────────┐ ┌────────────────┐ ┌►OEM firmware update tool──►│NIC PCI option ROM │ │dropper ├─┘ │ ├──────┐ │ │ │chainloader driver │ │ │ ├─┐ │ │ │ └────────────────┘ └►SetVariable()──────┐ └───────────────────┘ │ │ │ │ ┌───────────────────┐ │ └──────►│NVRAM │ │ │ │ │ │maliciious driver │ │ │(chunks) ├───┐ │ └───────────────────┘ │ │ │ │ │ │ next reboot: DXE dispatcher loads unsigned chainloader driver │ │ (ignores secureboot violation due to misconfiguration)│ │ │ │ │ │ │ │ ┌────────────────────┼──┘ │ │ │ │ ▼ │ ┌────────────────┐ │ │chainloader │ │ │ │ │ │ │ │ └─────────┬──────┘ │ │ │ ▼ │ chainloader: patch secureboot check in CoreLoadImage │ chainloader: zero XROMBAR │ │ │ │ │ │ │ │ ▼ │ chainloader: load malicious driver chunks from NVRAM │ │ ┌────────────────────┘ ▼ ┌────────────────┐ │malicious driver│ │ │ │ │ └────────────────┘
| 0.2 bare metal |
ramiel has not been tested on bare metal although theoretically it should work with secureboot disabled.
- infection:
| 1.1 NVRAM |
on the version of OVMF tested, QueryVariableInfo returned: max variable storage: 262044 B, 262 KB remaining variable storage: 224808 B, 224 KB max variable size: 33732 B, 33 KB
in order to utilize all of 262 KB of NVRAM, the malicious driver must be broken into 33 KB chunks stored in separate NVRAM variables. since the size of the malicious driver is unknown to the chainloader, ramiel creates a variable called "guids" storing the guids of all chunk variables. the guid of the "guids" variable is fixed at compile time.
example NVRAM layout: guid of guids (89547266-0460-43b3-9dfc-e4d627e6629) is known by the chainloader
┌──guids───89547266-0460-43b3-9dfc-e4d627e6629────┐
┌───────┤0eb06226-a02e-49be-bd56-866b328b44a3 │
│ │ │
│ ┌────┤c62104c3-0b2a-4c5a-9b1d-17780ebeaf9f │
│ │ │ │
│ │ ┌──┤b0d0f31d-88e0-4cbf-a589-ccc35e4569ab │
│ │ │ └─────────────────────────────────────────────────┘
│ │ │
│ │ │
│ │ │
│ │ │ ┌──0eb06226-a02e-49be-bd56-866b328b44a3──┐
└──┼─┼─►│<max var size chunk 1 of driver> │
│ │ └────────────────────────────────────────┘
│ │
│ │
│ │ ┌──c62104c3-0b2a-4c5a-9b1d-17780ebeaf9f──┐
└─┼─►│<max var size chunk 2 of driver> │
│ └────────────────────────────────────────┘
│
│
│ ┌──b0d0f31d-88e0-4cbf-a589-ccc35e4569ab──┐
└─►│<max var size chunk 3 of driver> │
└────────────────────────────────────────┘
runtime.c e
