Could UEFI/BIOS exploits/rootkits be a potential source of compromise?

Support
1

Could UEFI/BIOS exploits/rootkits be a potential source of compromise?

Is there an API that is capable of briding the firmware(BIOS/UEFI) with an OS,

or a Hypervisor?

Is there a list of firmware exploit kits that allow for this type of API?

Is it possible to PXE boot a bootkit/rootkit, or an RTOS remotely?

Could this be done using something like IntelME?

Which network protocol/service would be used in this case?

Would this networking protocol be wired or wireless?

2

Unspecific to Kicksecure.

Can be resolved as per:

It is. Related wiki pages:

Probably. See:

Search term:
efivars

You can also copy and paste that question into search engines and AI search tools.

I don’t see why not.

That doesn’t really matter if wired or wireless. Exploits can be chained, called the exploit chain. There will not be an answer such as:

  • “use only wired and you’re safe”; or
  • “use only wireless and you’re save”

Wiki page Open Source Hardware has many facinating links such as about hypothetical CPU backdoors.

3

Can you recommend a reasonably priced open source hardware for creating a

persistent Kicksecure/Whonix USB? Would a Pi work?

Anything reasonably priced and user friendly?

Do you personally have a recommended list of devices that you use and

allow for a smooth workflow.

4

EFI partition is stored on the SPI chips, or is disk partition?

5

The EFI system partition is a partition on the disk, it is not a firmware component. It’s usually the first partition on a disk, usually uses the FAT32 filesystem, and usually has a directory named EFI in it.

1 Like
6

how can this be an interface to the UEFI/BIOS code? Or is this not correct.

How would the EFI disk partition, if written to RAM, allow for an interface between

the OS and the UEFI/BIOS API. Is there some sort of shell that can be

accessed between the EFI partition and the SPI chips.

7

I have no further comment on top what is documented in the wiki page that I liked to.

This is out of scope for support on this forum.

User documentation, actionable steps what users can do are documented in the wiki as far as we could document it. There is also a lot information about past attacks, potential attacks and tons of links you can follow to learn more.

Discussion on specific attacks on EFI are out of scope. There’s a a plethora of information on the internet. Search terms such as:

  • attacks on EFI

  • breaking firmware

There are many websites and video presentations dealing with this topic.

There is so much information, if you wish to study this, they can keep you busy for years.

8

Ok well are there specific links for this? Are these presentations at conferences and talks?

9

Did you try Google, YouTube, Perplexity?

10

2 posts were split to a new topic: InRelease is not valid yet (invalid for another 4h 25min 51s)

11

Yes, it is theoretically possible to PXE boot a bootkit/rootkit or an RTOS remotely, but it requires control over the network infrastructure or exploitation of vulnerabilities in the PXE boot process.

Conditions for PXE Attack:

  • The attacker must have control over the network infrastructure (e.g., DHCP or TFTP servers).
  • The target system must be configured to PXE boot from the network (e.g., in a corporate or lab environment).
  • Security measures like Secure Boot or UEFI firmware passwords may need to be bypassed or disabled.

If your main concern with PXE is something along the lines of data centers in the scenario of installing Kicksecure on VPS, well then that something outside your control or the operating system you install.

12

If your talking about PXE on personal computer like a laptop or desktop. Well, then here are some mitigation suggestions you can do within your control.

    1. Disable PXE boot in BIOS:

In the BIOS look for PXE boot related settings and Disable them.
- Boot Sequence: uncheck integrated NIC as a boot option
- System Configuration/Integrated NIC: Make sure to only select the “Enabled option” Not the Enabled wPXE option
- Disable anything related to “Network boot” or “Boot from LAN” might be in POST section options.

    1. Block PXE-Related Port (Port 69) on Network Firewall:

Block port 69 Trivial File Transfer Protocol (TFTP) via on your WiFi networks Firewall. This means blocking incoming/outgoing of port 69 on UDP/TCP it mainly uses UDP but to be safe or for simplicity do both.

Blocking port 69 alone does not affect DHCP, but it does prevent the subsequent TFTP transfer. There may be alternative ports or protocols that could be used for PXE booting, potentially bypassing the block on port 69. Traditionally PXE booting via TFTP is done via port 69 UDP. Blocking it on the operating systems firewall is useless, this needs to be done at the network level (Network Firewall). This is because PXE boot is intialized before the OS is even loaded.

Do not block port 67 and 68 cause these are utilized for DHCP and it will cause you experience issues obtaining an IP address from a DHCP server which translates to not being able to connect to the internet.

    1. Use Open-Source Firmware (Coreboot/Libreboot):

Opt for a computer that you can install a Coreboot or Libreboot on. PXE boot functionality is not included by default in either Coreboot or Libreboot. It has to specifically be selected when compiled with compatible configuration payloads.

Combining all three suggestions (Ideally number 3 is best mitigation) would be the best measures. However not everyone may be able to do this so combining method 2 and 3 would be good mitigation option given if you cant flash an open source firmware as such that strips PXE capability out of the firmware.

1 Like
14

Do you mean install it on Raspberry Pi and use the Pi as form of external media as if it was a flash drive to boot into Kicksecure from?
I’m sensing this this related to DMA (Direct Memory Access) concerns?

Most standard 2.0 USB devices, such as flash drives, typically do not use DMA. However, high speed USB devices, such as flash drives like USB 3.0 and later controllers often do include DMA features for high-speed data transfer.

The USB host controller, part of the system chipset, may use DMA to manage data transfers. This means even if the USB device itself doesn’t use DMA, the controller might, introducing a potential attack vector. In the case that the USB port is USB 3.0 rated but the USB device is USB 2.0 rated.

IOMMU (Input-Output Memory Management Unit) to isolate device memory access, mitigating DMA attack risks is already enabled in Kicksecure by default.

Raspberry Pi’s do have DMA (Direct Memory Access) BTW just to let you know but you might be able to disable some functionality in the config file but I have never looked into it before.

17

A post was merged into an existing topic: InRelease is not valid yet (invalid for another 4h 25min 51s)

18

6 posts were split to a new topic: VBoxManage error: Code NS_ERROR_INVALID_ARG (0x80070057)