COMMAND
PXE-2.0 protocol
SYSTEMS AFFECTED
PXE-2.0 protocol
PROBLEM
Ollie Whitehouse found following. This is really to plant a seed
in the minds of many on different attack vectors (i.e. it's theory
based). After seeing the posting on BugTraq about the ISC DHCP
client it got me thinking (leading on from something we have been
working on in the lab). Allot of the Intel NICs these days
support PXE-2.0 (2.1) for remote OS loading/booting (RedHat
supports this for remote installs). This got me thinking on the
possibility of three things.
1) Compromise a machine on boot (i.e. either install a compromised
version of the OS from a different builds server or boot a
different image - i.e. taking Man-in-the-middle to a new
degree).
2) Boots an image that updates firmware of the machine, boot
order, boot room (re-flashing an Intel NIC for something else?)
3) The third is what we had been working on in the LAB, CISCO PIX
520 firewalls have three Network cards which (if you install a
graphics card in your PIX520) you will see goes though a
standard Phoenix bios then attempt to boot of all three network
cards via PXE-2.0. Typically in the way you would configure a
PIX, it would boot outside, DMZ, inside NICS in that order. So
if you can ever get a PIX to crash (it will automatically
reboot) and your compromised host on the DMZ can deliver the
DHCP answers to the DHCP requests for PXE enabled NIC and then
deliver the image via TFTP (the entry to the TFTP server is
gained from a DHCP scope property). So you would be able to
configure (in theory) a PIX with a new remotely loaded version
of an image.
The practice? Well from what has been seen a majority of PXE-2.0
enabled network cards are set to boot local rather than network
so it does wipe out the above attack vectors (but hey it only
takes one).
SOLUTION
Set boot local.