8

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.

RikuXan
  • 193
  • 1
  • 1
  • 7
  • 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 08 '14 at 04:30
  • @SteveDL I added a paragraph in the question to answer your question (hopefully). – RikuXan Aug 08 '14 at 07: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 08 '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 09 '14 at 01: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

4 Answers4

11

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.

Ryan Gooler
  • 759
  • 4
  • 9
  • 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 06: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 06: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 09: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
  • @Ryan please read again the title of the question; this thread is about "PXE security". It seems to me your concepts about security boundaries are not clear; also your imaginative situations where you have "physical" access to the patch cord linking the PC and the switch makes me think you are just improvising answers here. – Pat Aug 14 '14 at 07:43
9

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.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 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 08 '14 at 07: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 08 '14 at 08: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 06:11
  • @Mark sorry but you are wrong; there's not an "active" way to look for DHCP rogues; DHCP rogue detections just "listen" for offers coming from not authorized DHCP servers. a PXE DHCP server listening for rogues can immediately stop its service and trigger an alarm when one a no authorized DHCP offer is detected. – Pat Aug 13 '14 at 08:12
  • @RikuXan please understand PXE is not really a "protocol" it is an "environment" then its security depends on 1) the security inherited from the underlying protocols 2) by how smart we implement the PXE environment. Well implemented PXE environments are very secure. – Pat Aug 13 '14 at 08:14
  • @Pat I think that just depends on your definition of a protocol. PXE from my understanding is defined by the interaction of DHCP and TFTP elements and by the specification published by Intel there are some weak points like the lack of encryption in the NBP transfer. I do unterstand that it is not necessarily a protocol in the sense of e.g. HTTP, but think that the word still works for PXE as well. – RikuXan Aug 13 '14 at 08:18
  • @RikuXan 1) PXE is an assembly of protocols; it is not a protocol. 2) why do you need to encrypt an NBP transfer?? do you need to check NBP integrity? then you can use the old Intel's "Boot Integrity Services" specification which is supported by PXE v2.1 or you can use "Secure boot" in today's UEFI world. If you want secure PXE you get secure PXE. – Pat Aug 13 '14 at 08:32
  • @Pat 1) Okay, after looking at the specification again, I agree that the word environment is better suited for PXE (I do not think however that seeing it as a protocol as well is completely false since it can be seen as "a system of digital rules for data exchange within or between computers", the wikipedia definition for a communications protocol). 2) As far as I can tell, BIS support is optional and if you look at Ryan Gooler's answer even when turned on there is potential for maliciousness without encryption. – RikuXan Aug 13 '14 at 08:42
  • @RikuXan 1) PXE does not have its own boundaries that's why it is not good considering as a "protocol". 2) is BIS optional? of course; a password in a windows account is also optional. 3) Ryan Gooler answer is "highly imaginative"; he talks about a manipulated image in a PXE restored machine; well that's not PXE's fault at all. I think we struggle here to see where PXE begins and where it ends. I encourage you guys to read about PXE before talking about its security. – Pat Aug 13 '14 at 08:54
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/16397/discussion-between-rikuxan-and-pat). – RikuXan Aug 13 '14 at 08:55
4

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.
Ohnana
  • 4,737
  • 2
  • 23
  • 39
  • 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
1

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

http://www-01.ibm.com/support/docview.wss?uid=swg21247020

EDIT:

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.

Pat
  • 111
  • 2
  • 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