BIOS Security? Build a PXE Attack Server

By Tony Lee and Chris Lee

Introduction

As consultants we are often hired to evaluate the security of kiosks or computers that are designed to interface with the general public.  The most secure configurations are ones that limit user interaction to the file system, command prompts, and the Internet.  One of the best ways to limit user interaction to the hard drive is to lock down the Basic Input/Output System (BIOS) to help prevent booting to alternative Linux distros.  This includes disabling booting to USB devices, locking down the boot order, and password protecting the BIOS.  In various engagements we will run across kiosks that are fairly locked down, but still vulnerable due to a very commonly seen BIOS configuration.  This article discusses how attackers can take advantage of this BIOS setting to allow the Preboot eXecution Environment (PXE) to be an administrator’s best friend and worst enemy.

Outline

• Common attack vectors
• The environment encountered
• Modified attack vector
• Building the evil PXE server
• Bootable attack ISOs
• Virtual PXE server with ISO support
• Build instructions
• Results
• Countermeasures
• Conclusion

Common attack vectors

When assessing kiosks, one of the first things that we test for is the simplest—USB port access.  If the kiosk is in a cabinet—is the cabinet locked?  Are there USB ports on the monitor or keyboard?   Is the kiosk out in plain-sight with USB access galore?  In any case, if we have access to a port, we will check for drive recognition upon boot and also while the system is already running.

If the kiosk is properly secured, developers will have made some attempt to lock down access to the file system.  By doing so they are hoping to prevent access to intellectual property, file shares, configuration files, and access to the Windows Security Account Manager (SAM) files.  One common bypass to file system logins is to boot to a USB drive that is running a lightweight Linux Operating System (OS).  Since the kiosk environment does not have a chance to boot, it does not lockout the attacker.  As a bonus, files that are normally “locked” because they are in use by a running Windows operating system are now unlocked and accessible.

The environment encountered

Some developers take the time to lock down the kiosks.  While booted, the kiosks execute with limited (non-admin) users, they block most command prompts, hide most start menu options, and block access to the file system.  They also take it a step further by disabling USB devices during boot, locking down the boot order, and disabling modification of the BIOS.  However, one thing that we notice is that the kiosk BIOS is usually configured to boot to the network (using PXE) first.  Below is an example of various setups we have encountered.

Figure 1:  Example BIOS that prevents modification and properly disables booting to USB devices

Modified attack vector

Ideally we want access to the file system at boot, but the USB drives are sometimes disabled.  The only other option may be PXE—which all computers in these environments seem to boot to first.  Most system administrators know first-hand how useful PXE (often pronounced “pixie”) capabilities are when rolling out new images or re-imaging existing desktops.  PXE is a network enabled boot environment that leverages a server running DHCP (to provide an IP address to the client), TFTP (to load the bootstrap configuration), and some sort of file share protocol such as NFS to serve up the operating system image files.  The image below illustrates the sequence of events for a PXE boot (http://www.freebsd.org/doc/handbook/advanced-networking/pxe-nfs.png):

Figure 2:  The network flow diagram above shows the typical PXE sequence of events.

Administrators also know that building a PXE server can take time and effort.  Since we typically only have one week for these types of engagements, we needed something flexible, portable, fast, and idempotent to the victim OS.

Building the evil PXE server

Our approach to building the evil PXE server is just one of many conceivable implementations.  This solution was assembled after a few hours of research and troubleshooting.  Thus, we are certain that more graceful options are possible and we would love to get your feedback via our contact information at the end of the article.

There were several important factors which limited our options for the build.  Because we were time constrained, we wanted to find already made solutions that we could adapt and combine.  Due to resource constraints, we wanted something that was portable and could be virtualized.  We also needed to boot to an environment that would not modify the victim OS.  These constraints lead us to a couple options that yield multiple combinations:

1. Pre-built bootable attack images
2. Virtual PXE environment that can boot ISOs

Bootable attack ISOs

This section is really a matter of personal preference and could include any lightweight bootable Linux distro such as Knoppix, BackTrack, Kali, Ophcrack, and even REMnux (known for its forensic capabilities and utilities).  The key is that these images need to be bootable live images that do not rewrite the disk.  Using ISOs with built-in attack tools make the job a little easier.  Since the target in our example was running Windows 7, we are demonstrating PXE booting to an Ophcrack LiveCD with various NT hash rainbow tables.

Ophcrack LiveCDs can be obtained from the following link: http://ophcrack.sourceforge.net/download.php

Ophcrack has three main options:

• ophcrack XP LiveCD: cracks LM hashes (Windows XP and earlier)
• ophcrack Vista LiveCD: cracks NT hashes (Windows Vista and 7)
• ophcrack LiveCD: does not include any tables (if you already downloaded them)

Various free rainbow tables for Ophcrack are available at the following link:

http://ophcrack.sourceforge.net/tables.php

We started with the Vista Free table.

Virtual PXE server with ISO support

While searching for a pre-built virtual PXE server, one result kept appearing—the Ultimate Deployment Appliance (UDA) from Mike Laverick.  This can be downloaded as a VMware virtual machine from the following address:  http://www.ultimatedeployment.org/download.html

The virtual PXE server with attack ISOs should now resemble the following picture:

Figure 3:  Picture of the environment we are trying to build.

Build instructions

Step 1) Download the files mentioned above (UDA  VM and your favorite bootable live ISO – we chose Ophcrack Vista LiveCD for this example because it already had the Vista Free rainbow table in the ISO)

Step 2) Extract the UDA download and open it in your VMware product (player or workstation, etc.).  UDA version 2.0 has an easy to use first boot wizard as shown in the screenshot below—use this to configure the network settings of your PXE server.  The network settings should either match the range of your targets or you can set up an isolated network using a switch, a laptop, and your target.

Figure 4:  Example network settings we used because we set up an isolated environment with only one victim by connecting our laptop and the victim host to a standard home-use switch.

Step 3) Create a place to store the attack images.  We chose to create, format, and add a virtual disk to the UDA virtual image using the instructions below:

Create the virtual disk in VMware: With the UDA VM highlighted  Edit virtual machine settings   Add… button   Hard Disk   Create a new virtual Disk  next   Disk Size (We chose 5GB, but you can pick however much you need)  Next   Finish Log into OS (via the VMware console or SSH): User: root Password:  <whatever you set in the setup> Partition, format, and mount the disk: [root@UDA ~]# fdisk -l You will probably see your newly created disk show up as /dev/sdb [root@UDA ~]# fdisk /dev/sdb press “n” - to add a New partition press “p” – for primary partition press “1” – for partition number press “enter” – to accept the rest of the defaults w - to write the table and exit [root@UDA ~]# fdisk -l /dev/sdb [root@UDA ~]# mkfs.ext3 /dev/sdb1 [root@UDA ~]# mkdir /ISOs [root@UDA ~]# mount /dev/sdb1 /ISOs/ Prep for image upload: [root@UDA ~]# mkdir /ISOs/OphcrackNT

Step 4) Upload the bootable attack images to our new /ISOs/ directory via WinSCP, Filezilla, or other SCP program

Figure 5:  Using WinSCP to copy our Ophcrack bootable ISO to the directory we just created

Step 5) Mount the ISO via the loop option

[root@UDA ~]# mount –o loop /ISOs/<Ophcrack.iso> /ISOs/OphcrackNT/

You should now be able to verify that you can see the Ophcrack ISO contents (this includes the Vista Free rainbow table in our case):

[root@UDA ~]# ls /ISOs/OphcrackNT

Figure 6:  Screenshot that shows proper ISO mount with rainbow tables

Step 6) Create an export entry for additional Ophcrack Rainbow tables

[root@UDA ~]# vi /etc/export

Add the following line to /etc/export:

/ISOs/OphcrackNT/tables *

[root@UDA ~]# /etc/init.d/nfs restart

If you need additional rainbow tables, download them from the Ophcrack site and use WinSCP or a similar program to upload them to /ISOs/OphcrackNT/tables

Step 7) Create a symbolic link to our new ISO directory for the UDA web interface:

[root@UDA ~]# cd /var/public/smbmount/local

[root@UDA ~]# ln -s /ISOs/ ISOs

Step 8) Configure the PXE config options to include your attack image.  This is where we could not find instructions on how to configure the PXE to mount the ISO.  Even though our method worked—it is probably not the most graceful.

On your host OS (not VM):

Use 7zip or similar program to extract the kernel and initrd files from the Ophcrack image:

Kernel is:  ophcrack-vista-livecd-3.4.0.iso\boot\bzImage

Initrd is:  ophcrack-vista-livecd-3.4.0.iso\boot\rootfs.gz

Use browser to navigate to the IP you chose in the setup:

User: admin

Password:  <whatever you set in the setup>

Setup the Operating System:

Click the OS tab   Name it something descriptive   Choose Manual Configuration for the Operating System    click Next

Figure 7:  Screenshot of creating the OS to connect offer up

On the next screen, you will select the kernel and initrd file you extracted to your host OS then click Finish.

Figure 8:  Manual deployment configuration

Setup the PXE boot Menu (create a template):

    Click on the Templates tab   Click the New button   Fill out the information as shown below:

    Template name:  OphcrackNT

    Description:  Ophcrack with NT Rainbow Tables

    Operation System:  Manual Configuration

    Flavor:  OphNT

    Click Next  then finish

Figure 9:  Creating the template

Figure 10:  Confirming the template options

You are now ready to boot to your PXE attack server.

Results

On-site, we usually setup a separate network using a home-use switch to prevent us from disturbing any other hosts on the client network that happen to reboot while we are connected.

Figure 11:  Environment that we created

Since you would recognize some of the kiosks we have tested in the past, we will show you pictures from our test environment below:

Once networked, boot the victim and allow it to obtain an IP address from our PXE server:

Figure 12:  Picture showing the three critical components—Attacker, victim, and switch

Select our Ophcrack image in the PXE boot menu:

Figure 13:  Picture showing the PXE boot menu

Log in by hitting enter and you will see a message stating that the rainbow tables were not found.  No problem, we shared them via NFS.

Figure 14:  Booted into the OS, but no tables were found

Spawn command shell - top left icon on the screen

su -   (password is root)

mkdir /tables

mount -o nolock -t nfs 192.168.100:/ISOs/OphcrackNT/tables /tables

Double click "Ophcrack" icon

Load the victim’s SAM:

Load button -> Encrypted SAM

/media/sda1/windows/system32/config -> Choose button

Load our mounted rainbow tables:

Tables button

Select table ("Vista free" in our case) -> Install button -> /tables/vista_free -> Choose button -> Ok button

Start the Crack:

Click the Crack Button

Now, you will see the tables being loaded into RAM and with a little luck the password will be cracked.

Figure 15:  The picture above shows the tables being loaded mounted, the hashes loaded, and the password cracked.

Note that even if you are not able to crack the password, you still have hashes.  You could use a tool such as Metasploit’s psexec module to pass the hash and obtain access to the host.

Countermeasures

We have illustrated a proof of concept attack that will work against an environment that has a locked down BIOS, but still boots to PXE first.  What can organizations do to prevent this attack?  It will most likely come down to a layered defense which may include some or all of the following:

• Disable PXE boot if not required
• Port security on the switches to prevent unknown hosts from connecting
• Protect network port access to kiosks
• Protect the power to kiosks
• Full disk encryption on the kiosks – we would not have been able to decrypt the drive to see the SAM or any other sensitive files

Conclusion

We have shown you what is possible when an environment has the BIOS locked down, but is still set to boot to PXE first.  Using our proof of concept, you can quickly build this PXE attack server and test your vulnerability to this attack vector.  As mentioned before, this was the result of a few hours of research and troubleshooting.  We are open to any feedback on how to make this work more fluently (particularly the section which pertains to having PXE boot the ISO) or another solution if you have one that is more graceful.  Thanks for reading and happy hacking!

Email:  Tony.Lee -at- FireEye.com Linked-in:  http://www.linkedin.com/in/tonyleevt

Email:  Chris.Lee -at- Foundstone.com Linked-in:  www.linkedin.com/in/chrislee804

This article and others like it will be featured in the upcoming Hakin9 magazine released at the end of July:  http://hakin9.org/bios-security-learn-how-to-protect-your-system-and-become-a-proffessional-security-expert/

Special Thanks to

Bill Hau

David Pany

Dan Dumond

Dennis Hanzlik

Glen Edwards

Ian Ahl

Rudolph Araujo