WARNING: Contains early research and conjecture…
OTHER WARNING: Probably no new major CVE, just an analysis of real world usage of existing ones and potential MFS misconfiguration with OEM signing keys. (E.G. the finding of AMT tech on a consumer Intel NUC + PCH debugging enabled)
About the name…
Look… Lots of Stargate SG1 was playing while I slept, waking up to realize why the Intel ME layout was like it was(two copies of the Boot partition sharing pages making it impossible for it to be for reasons of resiliency). Because it includes an Intel AMT/ME/CSME host and“guest” as well as a UEFI host/guest division, and it’s an evil force that takes advantage of its host, can hide in plain sight…. Also SymBIOSis makes ma laugh, and it has similarities to other ACPI dark-wake attacks…
Also when you’re looking at maestro, vermanus loader, arben, hotham, snowball, sigma you have to be a little punchy too. (Not saying every word of that is kit specific). It’s also highly likely that I’m observing an in-the-wild usage of this CVE: https://www.zdnet.com/article/intel-csme-bug-is-worse-than-previously-thought/ trying to detangle undocumented components vs malicious ones.
ME runs old Intel ME 11 with ish_bup CVE(this chipset lacks ROM rollback prevention) from one ME partition. (CSE Main containing bup, kernel, syslib, icc, dal_ivm, tcb, sigma)
ME runs hybrid CSME 11/12 with custom AMT OEM key + Boot Guard and rbe as well as essential features such as power management, snowball, and the Java VM
The MFS data partition is shared amongst both personalities, easily done as the Main is lightweight
These two personalities are stored in two Boot tables that share pages:
Intel ME makes use of SR-IOV to share the Intel Gigabit Ethernet hardware
The UEFI Hosting Environment
rbe decompresses 8MB SPI flash into 16.8MB runtime area
UEFI Boots AMI Text BIOS(NB)
Loads early DXEs causing the dual driver issue later
Contains custom PK/KEK/db/dbx
Delta compression also explains the dual NVRAM areas which are largely or wholey duplicate(loaded at base address 0x800078 and 0x830078)
Intel VT-d is leveraged to control hardware during the OS runtime phase
The UEFI Guest Environment
Runs Intel Visual BIOS payload as a secure boot UEFI Capsule under AMI BIOS(SB)
Update / Restore Code copies out only the“Intel Visual BIOS” EFI App - maintaining persistence, as any UEFI Protocols would maintain backward compatibility
Causes reloading of core UEFI modules(double driver problem)
By now it is too late to access the root UEFI
By the time the Gig Ethernet adapter is brought up in UEFI Shell it is ID 0x6 - making it a highly virtualized device, likely to facilitate loopback AMT / iSCSI / PXE(it also seems to like to use the MAC address 888888888788 for these purposes:
The Gig Ethernet adapter comes up under the“Managed Network Profile” and is immediately attempting to reach back over IPv4/IPv6 to a IPSec host via IKE(port 500)
Restore / Update Persistence
By using RomLegacyLayout DXE and a Faked JDEC part(parseIntelImage: SPI flash with unknown JEDEC ID 207018 found in VSCC table, decoding to STMicro as a manufacturer part ID 0x701B), a firmware update capsule can be“applied” and then delta compressed against the working payload, with blacklist DXEs removed. A new runtime capsule is generated and stored
A capsule is just a verified, UEFI executable, so the payload and the loadable code areas are separate and parseable
The capsule then drops permissions to be able to write to real SPI
Explains the usage of NVRAM to store the version of the UEFI payload and lack of variation on some components across updates
About the name…
Play at home with the capture…
Apriori:
Current Working Hypothesis
The Core, ish_bup, The AMT and a CSME kit
The UEFI Hosting Environment
The UEFI Guest Environment
Restore / Update Persistence