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?
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:
Wiki page Open Source Hardware has many facinating links such as about hypothetical CPU backdoors.
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.
EFI partition is stored on the SPI chips, or is disk partition?
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.
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.
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.
Ok well are there specific links for this? Are these presentations at conferences and talks?
Did you try Google, YouTube, Perplexity?
2 posts were split to a new topic: InRelease is not valid yet (invalid for another 4h 25min 51s)
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:
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.
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.
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.
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.
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.
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.
A post was merged into an existing topic: InRelease is not valid yet (invalid for another 4h 25min 51s)
6 posts were split to a new topic: VBoxManage error: Code NS_ERROR_INVALID_ARG (0x80070057)
Yeah but blocking TFTP ports might not be enough???
I read that it that PXE also relies on DHCP Discover tags specifically option 60 (Vendor Class Identifier) and once it sees option 60 the PXE server answers with a DHCP Offer that contains option 43 (vendor-specific info), option 66 (Boot server name), and option 67 (Boot file name) e.g. pxelinux.0, ipxe.efi, etc.
On L2 managed switches you could drop DHCP packets that contain PXEClient string in option 60.
Alternatively couldn’t you possibly could block all option 66 (Boot Server Host Name) and (Bootfile Name) option 67 DHCP requests.
Correct if I’m wrong but I think iptables on OpenWrt could drop DHCP packets containing options 66 and 67 and block all incoming and outgoing TFTP port 69?
I have never used the -m u32 option
But is it possible to make iptables actually match any option DHCP option 66 or 67?
Would either of these two iptables ideas work or are the byte offset too far into the packets?
iptables -A INPUT -p udp --sport 67 --dport 68 \
-m u32 --u32 "0x10:0x1c@0x2a:0x04" \
-j DROP
iptables -A INPUT -p udp --sport 67 --dport 68 \
-m u32 --u32 "0x10:0x1c@0x2e:0x04" \
-j DROP
If that’s the case then on most networks the match will never fire, so PXE offers still sail through…
Documentation states that a DHCP packet starts with a 236-byte header, but options sections begins at byte offset 240???
iptables -I OUTPUT -p udp --sport 67 --dport 68 \
-m u32 --u32 "240 = 0x42 || 240 = 0x43" \
-j DROP