What are the top security concerns when setting up a PXE (Preboot Execution Environment) booting environment, ordered by severity of a possible exploitation?

Things that I thought of are (in no particular order):

  • Rogue DHCP takeover
  • Man-in-the-Middle attacks on the NBP load over TFTP

The question is meant to look at the general protocol and its possible weak points and is not restricted to a certain setup concerning equipment or attacker.

If anyone wants to help me bring this question in a more suited format, you are welcome.

  • Could you precise who is expected to legitimately access/manage which components of your setup, and what you expect adversaries to be capable of? – Steve Dodier-Lazaro Aug 8 '14 at 4:30
  • @SteveDL I added a paragraph in the question to answer your question (hopefully). – RikuXan Aug 8 '14 at 7:26
  • TFTP does not need a man in the middle it is trivial as in no authentication thus the first T in TFTP. – zedman9991 Aug 8 '14 at 13:16
  • @zedman9991 But wouldn't I still have to be "in the middle" to block the real TFTP's answer to prevent a race condition and secure my answer to be the client's accepted one? Also in most situation by sniffing the client's traffic to see when he requests the NBP I'm usually in the middle as far as I know. Maybe I'm not completely understanding what you mean. – RikuXan Aug 9 '14 at 1:21
  • Sorry to not be clearer my point was the attacker does not need to hijack your TFTP session he can just initiate one himself at will. – zedman9991 Aug 11 '14 at 12:57

In a PXE environment, as a pentester, I have 2 major classes of attack I can choose from.

1: I can capture a full machine image. Do your systems automatically connect to the domain controller after setting up the machine? If so, this image probably has domain controller credentials on it, that I can capture and use elsewhere.

2: I can manipulate images on a restored machine. After capturing, I can make an image that has, say, the corporate image with AV disabled and malware pre-installed, then MITM someone's system for a persistent foothold in the company. Since PXE isn't encrypted or authenticated in any way, this is trivial to do with physical access, a few seconds of privacy, and something like a pwn plug or a raspberry pi.

| improve this answer | |
  • Thank you for the answer, very cool to see someone bring real-world experience into this. Your first point is one I hadn't really thought about yet, the possibility of the supplied images containing critical data. – RikuXan Aug 13 '14 at 6:12
  • I do have one question about point 2 though: I generally assumed MITM attacks on PXE are possible due to it being unencrypted. However, I just realized that on a switched network I don't know how one would block the broadcasts being sent to exchange them with malicious ones. So are PXE/any broadcast protocol MITM attacks always linked to race conditions? Or is there another way to ensure that the malicious answer gets preferred? – RikuXan Aug 13 '14 at 6:18
  • @Ryan you blame PXE for an altered image in a PXE restore process when it is the restore application and no PXE the one that has to check the image's integrity. PXE is a part of the provisioning equation, we have to be very cautious and see if we talk about the "security of the provisioning equation" or the "security of PXE"; they are different things. – Pat Aug 13 '14 at 9:23
  • 1st off: If I can get physical access in the environment, I can plug something between the computer and the switch that can manipulate traffic. Therefore, that device would just need to capture and not re-propigate broadcasts. No race condition necessary. – Ryan Gooler Aug 13 '14 at 22:00
  • @Pat I'm not blaming PXE at all for this. I'm just saying that since this environment exists, that is a place I can inject myself. These sort of attacks are usually possible with other network-based provisioning systems, as long as I can adequately spoof enough of a corporate system to allow me to download the image. – Ryan Gooler Aug 13 '14 at 22:04

The top security concern is that the only protection of traditional PXE booting is physical security. There is no encryption or authentication anywhere in the process from power-on to OS start.

The basic PXE process:

  1. Computer makes a DHCP request
  2. DHCP server responds with address and PXE parameters
  3. Computer downloads boot image using TFTP over UDP

The obvious attacks are a rogue DHCP server responding with bad data (and thus hijacking the boot process) and a rogue TFTP server blindly injecting forged packets (hijacking or corrupting the boot image).

UEFI secure boot can be used to prevent hijacking, but a rogue DHCP or TFTP server can still prevent booting by ensuring the computer receives a corrupted boot image.

| improve this answer | |
  • Thank you for your answer, to translate your answer into possible attack vectors it would mean MitM-Attacks due to lack of encryption (sniffing is kind of irrelevant since PXE usually doesn't transmit critical data, but only binaries) and illegal access to the booting system due to the lack of authentication, am I seeing this correctly? – RikuXan Aug 8 '14 at 7:34
  • @RikuXan, I've expanded my answer. Everything takes place over UDP, so "MitM" attacks are simply a matter of ensuring the attacker's packets arrive before the honest packets. – Mark Aug 8 '14 at 8:21
  • This answer is not correct. a rogue DHCP can be detected in a manner of seconds, PXE authentication can be granted by DHCP MAC address and architecture; alarm of duplicated MAC addresses can also be easily triggered. PXE security can be easily improved just taking care of it. Today WDS/MDT/SSCM are mostly PXE based and are widely used in a corporate environment – Pat Aug 12 '14 at 15:03
  • Unless you're actively scanning for a rogue server, the first you'll know about it is when a DHCPDISCOVER receives two DHCPOFFER packets in response. Sure, at that point you can go hunting for it, but the PXE software already has the bad response. – Mark Aug 12 '14 at 17:53
  • @Pat I realize there are many security precautions in different PXE implementations like WDS or even gPXE/iPXE, but my question actually aims for weaknesses in the protocol rather than in specific implementations. I'm trying to get an overview on possible security problems and looking at every single implementation would only over-complicate this. – RikuXan Aug 13 '14 at 6:11

There are some specific vulnerabilities associated with PXE boot images.

  1. Unauthenticated Images. If someone gets onto your network, it's trivial to boot a PXE image from VirtualBox or VMWare. Which means that you now have a rogue host on your network, loaded with all your proprietary software.
  2. Local Administrator exploits. (Windows only) Since this someone has physical access to the image, they can pull password hashes off of the disk image and crack them or pass them. If you have a fleet of PXE-configured images with shared credentials, you've just handed a ton of hosts over to an attacker. At the least, they have a pivot point into the rest of the network.
  3. Unattend.xml. (Windows Only) This file is an answer file that provides information Windows Deployment needs for domain joining and other setup tasks. This file can contain product keys and passwords to an account with at least domain-join privileges! And if you're really silly, that account is a domain admin.
| improve this answer | |
  • Note that this only applies to Windows systems (and I'm not sure it even applies to all of them). If you were to set up a rogue host on my network, you'd find yourself running a rather generic Linux system. Access to the interesting parts of the network filesystem requires a valid user (not admin) account. – Mark Feb 16 '16 at 20:01

The implementation of PXE in a corporate environment may raise concerns about security. This document shows why these concerns are mostly unfounded.



I'd like add that PXE is only a part of the provisioning equation then talking about the "security of the provisioning equation" and talking about the "PXE security" are different things.

PXE is not a "protocol"; it is an environment made of several protocols; PXE does not have its own boundaries that's why we must be really cautious when trying to assess PXE security.

| improve this answer | |
  • 2
    I'm sorry, but I'm getting a 410 Gone error message for the page you posted, is the link broken or is this some kind of hidden paywall? – RikuXan Aug 12 '14 at 14:58
  • no hidden paywall; just a missing character when pasting the link; please check it now. – Pat Aug 12 '14 at 15:07
  • 1
    Thanks, it worked. Just to recapitulate and link the article with my question, the three risks mentioned are: 1. Unauthorized PXE servers allowing clients to boot unauthorized/unmanaged images; 2. Forging packets of any kind to corrupt the boot process/manipulate the images; 3. Unauthorized PXE clients booting from the system due to a lack of authorization mechanics – RikuXan Aug 12 '14 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.