[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66402D01.8090200@gmail.com>
Date: Sat, 11 May 2024 21:44:17 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Microsoft Device Firmware Configuration Interface
(DFCI) in Linux efivars directory
Corey Lopez wrote:
> I have dual boot Windows 11 Home Edition and Debian based setup on my laptop.
>
> Distributor ID: Kali
> Description: Kali GNU/Linux Rolling
> Release: 2024.1
> Codename: kali-rolling
>
> After realizing a security breach on my Kali system I discovered /etc/network/interface
> had the immutable attribute set while trying to restrict access using chmod. I decided to
> investigate other files on my system with the immutable attribute set by running this
> command as root:
>
> # find / -type f -exec lsattr {} + 2>/dev/null > immutable-list-find.txt
>
> This led me the directory /sys/firmware/efi/efivars/ where I discovered efi variables
> pertaining Microsoft's Device Firmware Configuration Interface (DFCI).
Were the EFI variables marked immutable or did you make a list of every
file on the system and notice them on that list?
> Microsoft's
> DFCI enables zero touch remote configuration of UEFI BIOS giving the ability to
> manage BIOS settings and hardware. The DFCI allows for remote disabling or enabling
> of cameras, microphones, radios, boot external media, bootstrapping an OS, cpu
> virtualization, and I/O virtualization. According to Microsoft's github page, the zero
> touch certificate is shared by all DFCI-enabled systems and does not need to be injected
> at manufacturing.
>
> Microsoft advertises DFCI as a defense mechanism against rootkits, however it seems that it
> is being used as a UEFI bootkit. According to Microsoft DFCI is not available for Windows 10
> or 11 Home Edition. My Acer Aspire 3 15 has Windows 11 Home Edition, and was purchased
> as a consumer product versus a commercial. This means that not only is there a capability that
> DFCI can be implemented on a consumer product, but through a Linux based operating system.
>
I will admit that this seems strange, but it appears that your laptop
has firmware support for DFCI even though, by Microsoft's claims, it
should not be eligible for that feature.
> I will provide the ASCII output of each file that I found on my Kali Linux system from the
> /sys/firmware/efi/efivars/ directory. I will not provide the entire hexdump output to save space.
> However, I will provide more if requested after my initial posting.
>
> [... snip ASCII columns from hex dump; reformatted below ...]
For a first step, I note that those EFI variables appear to contain XML,
and have (using ` sed -e '/^|/{: L;/|$/N;s/|\n|//;t L}' | sed -e
'/|$/{N;N;s/\(.\{16\}\)|\n\*\n|/\1\1/}' -e 's/^|\.\.\.\.//' -e
's/\.|\n/\n/' -e 's/\.|$//' | awk '/^<\?xml/ { print | "xml_pp";
close("xml_pp"); next } 1' `) converted that back to readable ASCII,
with the XML nicely pretty-printed; attached in full, some possibly
interesting details inline below:
> File Name: DfciPermissionCurrent-3a9777ea-0d9f-4b65-9ef3-7caa7c41994b
>
> ASCII Output:
>
> <?xml version="1.0" encoding="utf-8"?>
> <CurrentPermissionsPacket Default="1" Delegated="128">
> <Date>2024-01-30T13:51:08</Date>
> [...]
> <LSV>0</LSV>
> </CurrentPermissionsPacket>
The "Date" field is potentially interesting if you had the laptop at
that time, but if the laptop is newer than that date, it and the other
dates are likely manufacturing-related timestamps.
> File Name: DfciSettingsCurrent-d41c8c24-3f5e-4ef4-8fdd-073e1866cd01
>
> ASCII Output:
>
> <?xml version="1.0" encoding="utf-8"?>
> <CurrentSettingsPacket>
> <Date>2024-01-30T13:51:34</Date>
>
The dates are close together; did you have that laptop prior to January
30th, 2024?
> <Settings>
> [...]
> <SettingCurrent>
> <Id>Device.Password.Password</Id>
> <Value>No System Password</Value>
> </SettingCurrent>
>
I could not pass up this apparent detail that it seems Microsoft may be
putting passwords in plaintext again, unless that field merely reports a
status.
> <SettingCurrent>
> <Id>Dfci.RecoveryUrl.String</Id>
> <Value/>
> </SettingCurrent>
>
This and several following fields all have no value whatsoever, while
others seem to me to have neutral values; this looks like DFCI is
present but unconfigured.
> [...]
> </Settings>
> <LSV>0</LSV>
> </CurrentSettingsPacket>
>
> File Name: UEFISettingsCurrent-d41c8c24-3f5e-4ef4-8fdd-073e1866cd01
>
> ASCII Output:
>
> <?xml version="1.0" encoding="utf-8"?>
> <CurrentSettingsPacket>
> <Date>2024-01-30T13:51:34</Date>
> <Settings>
> [... snip apparent duplicate settings ...]
> </Settings>
> <LSV>0</LSV>
> </CurrentSettingsPacket
The date here matches the date on the DfciSettingsCurrent variable.
> I did discover loop devices on my system that I could not remove with the
> losetup command. I had to manually remove them with the rm -f command from
> the /dev/disks directory.
Using rm does not remove the devices at all: they are still present in
the kernel, and you only removed the nodes from the filesystem.
> Also, I ran the lsof command, which helped me discover
> the type of file systems that were being used. This prompted me to use apt purge
> to remove Gnome Virtual File System from my laptop.
>
> # lsof /dev/loop*
>
> I received this in response:
>
> can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
> can't stat() fuse.portal file system /run/user/1000/doc
>
Others have explained this weirdness; it is actually normal
functionality, except possibly for loop devices having been in use.
Just to make sure, you did run lsof *before* using rm, right?
> This should be enough to give others places to look to determine if they have been
> infected, however I will be more than happy to provide more if needed.
>
See if the mystery loop devices come back after a reboot, and if so, use
losetup to determine what files they are attached to; that information
is needed to distinguish between normal operation and a possible
persistent compromise. Also, I vaguely remember that attempting to
detach a loop device that is not attached can also report an error.
They may not actually be in use after all.
-- Jacob
View attachment "dfcidump.txt" of type "text/plain" (7657 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
