So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting.
Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies.
For client devices who PXE boot (rare) and also are on Ethernet during boot (basically desktops and docked laptops) and also reachable by pings (so the attacker needs to be inside the network).
Some networks carry ICMP through untouched. Why you'd be using public addresses for your systems between DHCP and PXE boot is beyond me, but it's possible. However, someone would need to spray and pray because they wouldn't have visibility within the network to know about the DHCP and PXE traffic actually happening at that time.
If you're on the same LAN segment, you can probably see the DHCPDISCOVER messages that the UEFI would send as part of the PXE boot process. I would guess that you could also tell the difference between a DHCP request from UEFI vs one from Linux/Windows.
Given, without any network level DHCP guard configuration, you could likely also send your own DHCPOFFER and just tell it to PXE-boot your own image :) I suppose for some trusted-boot threat scenarios code execution at the UEFI level is a bigger issue. No idea how modern UEFI PXE-boot deals with signed images.
The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
What we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.
PXE boot enabled and attempted by default on an internet-facing network interface is certainly a... choice.
This is something that shouldn't be possible in the real world because any sysadmin should know not to do this, but guaranteed there are at least some small time operations with a couple of colo'd servers that only have single interfaces serving public traffic, and the intern who set them up didn't know what a boot order was or what "PXE" even did.
Before publishing the exploit, I imagine it would've been quite practical to flood an entire data center with malicious ICMP packages and just waiting for the next kernel patches that necessitate rebooting to come out. If you don't know that the ICMP packets flooding in aren't just weird background noise, you might ignore them when they're not causing problems.
If I send a load of ICMP at a datacenter, don't they just get dealt with at the firewall, not by individual servers? Like I can't ping a specific machine inside a datacenter, it just pings the datacenter itself
Depends on how the datacenter deals with ICMP. If you host dedicated machines on dedicated IP addresses, there's no need to deal with traffic rewriting and you can just use ICMP the normal way. If you apply NAT or weird filtering then you'll hit the firewall first of course.
For a deployed server, yes, you’d probably need to first get inside their network, then using some other exploit or social engineering, cause the server to reboot and then provoke this vulnerability and gain a persistent shell on the server.
This may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?
There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?
