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:
- Pre-built bootable attack images
- 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:
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
|
Special Thanks to
Bill Hau
David Pany
Dan Dumond
Dennis Hanzlik
Glen Edwards
Ian Ahl
Rudolph Araujo
