Chapter 3: Windows Infrastructure

Understanding how Microsoft Windows functions, and Vista in particular, is key to understanding how to secure it. Most Windows administrators don't really understand how Windows "works." They've been taught about Windows from a system administrator's operational point of view, but not given enough information about how it operates under the hood. This chapter explains key Windows infrastructure processes and concepts so that the mechanics of how it all works together can be applied to security. This chapter will loosely flow along the lines of how a Windows PC boots and runs.

Note 

Do not rely upon this chapter as the complete, detailed reference of the complexities of Windows Vista. Microsoft Windows is sufficiently complex that to cover any single concept completely would be beyond the intended scope of this book. This chapter is intended as a high-level guide. Readers who are truly interested in the internals of Windows will find a good resource in Microsoft Windows Internals, Fourth Edition by Mark E. Russinovich and David A. Solomon.

Boot Sequence

When the computer first turns on, hardware self-checks (called Power-on-Self Test or POST) are performed to ensure the hardware is functioning without error. Firmware located on flash memory, PROM, or EEPROM chips will contain either PC/AT legacy BIOS or newer Extended Firmware Interface (EFI) code.

EFI is an open standard invented by Intel (http://www.intel.com/technology/efi), but widely expected to replace the PC/AT BIOS code used in personal computers for nearly three decades, within the next few years. EFI requires new firmware, new drivers, and EFI-aware boot applications and operating systems.

The first release of 32-bit Windows Vista supports PC/AT BIOS firmware only, but has the "hooks" for the eventual EFI implementation. Microsoft plans to fully implement EFI in future 64-bit versions of Windows when the other vendor pieces are matured and widely available. There are currently no plans to support EFI in 32-bit versions of Windows. In the near future all computers should be 64-bit, so this should not be burdensome for long.

The boot sequence will be either EFI-based or legacy PC/AT BIOS-based, but not both. An operating system installed using EFI can only be accessed by booting with EFI, and vice versa. The firmware code is executed, along with any other ROM-or EFI-enabled hardware devices and interfaces cards (SCSI controller, video, and so on). See Figure 3-1 for a summary of the boot process, excluding any effects of BitLocker Volume Encryption.

Figure 3-1: Windows Vista boot sequence summary

In the legacy scenario, the BIOS uses Interrupt 13h to find the computer's hard drive and then uses the disk system Master Boot Record (MBR) to locate the partition table. The partition table is used to locate the Windows bootstrap code on the disk containing the system partition. Vista's pre-boot code locates the Windows Boot Manager (Bootmgr), a hidden file in the root directory of the system partition. The Bootmgr file is the first piece of Windows to load. Everything before that is generic for any operating system.

In an EFI-enabled system, the EFI firmware loads EFI drivers and code, and locates the EFI system partition (ESP) using the new GUID partition table (GPT). The GPT replaces the legacy MBR and each disk is identified with a GUID, which allows EFI-enabled systems to support far more disks and more partitions per disk than the BIOS could.

Note 

EFI systems require a minimum of two storage partitions, including the EFI System Partition, which is hidden from the OS.

In EFI-enabled systems, the Vista boot code locates the EFI Boot Manager (Bootmgr.efi) located under the hidden \Boot directory located off the root directory of the system partition (or in non-volatile random access memory (NVRAM) in the EFI firmware). This is intentionally made to be transparent, and most users will not be able to tell whether the NVRAM or the hidden \Boot directory is used.

Regardless of the two methods used, the Boot Manager then loads code supporting memory management, TPM, file systems, and PCI configurations, among other early loading components. Next, the Boot Configuration Data store file (called BCD located under the hidden \Boot folder) is called. The BCD replaces the legacy Boot.ini file. The Boot.ini file will be present only on dual-booting systems needing legacy OS support.

The BCD store's contents can be viewed and configured using the Bcdedit.exe utility. For administrators and security troubleshooters, it is important that managed systems be differentiated between EFI and legacy BIOS booting. When booting with diagnostic software, boot methods using the BIOS cannot access the BCD store located on the ESP, and vice versa.

In the \Boot folder there will be one or more Bcd.log (or Bcd.log X, where X is a sequential number) files. If boot logging is enabled, the Bootstat.dat file is updated with boot event messages. The Boot Manager then locates the Windows Vista boot volume and calls the Vista Boot Loader (Winload.exe located in \%Windir%\System32). Winload.exe replaces NTLDR (which will only be present on dual-boot legacy systems). The Boot Loader then loads the Vista OS kernel (Ntoskrnl.exe), which handles the rest of the Vista OS load.

Along the way, every step of the boot process is checked for authentication and integrity. The boot files' digital signatures are stored in a file called Nt5.cat, which is stored in \%Windir%\System32\Catroot\{GUID}. The {GUID} number can change as the OS is updated, but is named {750E6C3-38EE-11D1-85E5-00C04FC295EE} in the first Vista version released to the public.

Winload.exe is responsible for checking the integrity of boot drivers and the kernel is responsible for drivers loaded afterward.

Boot Viruses No Longer a Threat

Another big side effect of EFI-booting is that existing DOS-boot sector viruses are no longer a threat. Contrary to popular belief, 20-year old DOS boot sector viruses could easily disable all BIOS-reliant operating systems, including Windows XP Pro, Windows Server 2003, Linux, BSD, and OS X computers.

Once the OS is loaded, Windows XP Pro and Windows Server 2003 are in control and can't be infected or spread boot malware, but if a BIOS-enabled computer system is started with media containing a boot-enabled boot virus, MBR-infector, or partition table infector, it could still modify and "infect" the system. Incredible, but true. In most cases, the DOS-boot sector virus would just corrupt the system's boot sequence causing startup problems and crashes. Still, a single errant boot could keep the system down until the damage was repaired.

EFI-enabled systems do not have traditional boot sectors or partition tables to infect. Although bootable malware hasn't been much of threat in the last decade, EFI finally puts the nail in the coffin of old DOS boot viruses. New EFI boot viruses are possible, but would generally require booting from media created by an infected system.

BitLocker Volume Encryption

A common feared threat scenario is an attacker with physical access to a computer storing confidential information, say for example, with a stolen laptop. Boeing, the U.S. Veterans Administration (twice), the FBI (at least 317 times), the University of California, Allina Hospitals and Clinics, Fidelity, Chevron, Kaiser Permanente, the YMCA, QUALCOMM, and thousands of other organizations have all had laptops stolen, misplaced, or otherwise lost. In fact, the organization that knows where all the computer assets they have bought and paid for is rare, if it exists at all. The estimated cost of a stolen computer is $182 per customer record stored on it, according to one means of calculation by the Ponemon Institute (http://www.ponemon.org). You can probably easily imagine what would happen if a computer containing your organization's most sensitive secrets were purloined.

Once in the hands of the thief, logon security will not let the attacker into the operating system and any data protected by NTFS security without a valid logon name and password. However, the attacker can easily boot around the operating system and bypass the NTFS security restrictions. This is why one of the enduring truths about computer security is that if a bad guy has physical access to your computer, it ain't your computer any longer.

Knowledgeable attackers commonly use NTFS-aware versions of Linux or utilities such as Ntfsdos (http://www.sysinternals.com/Utilities/NtfsDos.html) to access otherwise protected NTFS volumes. Windows PE, which can fit on a USB drive or on a boot CD-ROM, can also be used to boot around the hosted Windows boot code.

By booting with these operating systems or utilities, it is possible to view files stored on NTFS-protected volumes without a password. Attackers can view and copy confidential data, and access the computer's local Security Accounts Manager (SAM) database to steal password hashes.

While confidential data can be protected with optional Encrypting File System (EFS), most Windows users don't take advantage of it; and even if they do, it is easy to put something in a folder where EFS is not used. Furthermore, EFS is only as secure as the password of the user who used EFS to protect the files. As that password is typically stored in some hashed form (either in the local SAM or as a cached credential) on the system itself, the attacker can usually circumvent EFS with not too much trouble. Finally, even if one assumes away the implementation issues with EFS, prior to Vista it was impossible to protect many types of files and folders (system Pagefile, system files, and so on) with EFS. Enter Microsoft BitLocker Drive Encryption.

BitLocker allows Vista (or later) volumes to be encrypted to prevent boot around attacks. By default, BitLocker can encrypt the boot volume (the volume where Windows system files and data are normally stored), but additional volumes can also be encrypted. BitLocker can protect the disk volume until the user supplies a PIN or supplies a key stored on a USB flash memory drive.

Note 

Although it sounds confusing at first, the system partition is the drive volume where the boot code is located, and the boot volume is where the Windows system files are stored. BitLocker protects the latter by default.

The cryptographic key that is involved with the data encryption/decryption is called the Full Volume Encryption Key (FVEK). It is encrypted by another BitLocker encryption/decryption key called the Volume Master Key (VMK) and stored on the local volume. There is a different VMK for each encrypted volume. This parent-child arrangement allows stronger encryption to be implemented with fast performance. BitLocker further encrypts the VMK and stores it, in encrypted form, on the local volume as well. The encryption/decryption key that is used to protect the VMK can be stored on the local hard drive, protected by an external key (provided by the user or located on a USB drive), or stored on a specialized cryptographic microcontroller chip.

Note 

Contrary to frequently published documentation, BitLocker does not encrypt the entire boot volume. Key parts of the boot volume, necessary for BitLocker's operations (e.g. boot sector, volume metadata, encrypted FVEK, encrypted VMK, etc.), plus any sectors marked as bad, are not encrypted.

BitLocker, in its recommended state, can encrypt the VMK with another key (called the Storage Root Key) stored on a cryptographic chip called the Trusted Platform Module (or TPM). TPM is an open standard created by the Trusted Computing Group (http://www.trustedcomputinggroup.org) and widely endorsed by hardware and software vendors including Microsoft and several Linux distributors. The TPM chip (see http://www.en.wikipedia.org/wiki/Trusted_Platform_Module for more generic details) can be used for nearly any cryptographic process, and not just BitLocker. But it is Vista and BitLocker that will bring TPM to the masses.

BitLocker requires Vista (only Enterprise or Ultimate editions support Bit-Locker), an enabled TPM chip (version 1.2 or later), a TPM-enabled mother-board, a TPM-enabled BIOS, and two NTFS-formatted drive partitions. Most popular computer vendors are currently shipping the majority of their systems TPM-ready. The two drive partitions must exist before installing Vista or can be created afterward using a non-destructive disk partitioning utility. Microsoft provides one called the BitLocker Drive Preparation Tool (http://www.support.microsoft.com/kb/930063). Microsoft recommends a 1.5GB system partition for BitLocker to reside upon. BitLocker protects the boot volume, not the system partition (the partition the computer boots on). Thus, any files or information on the system partition can be read by an offline attack.

However, the data protected by BitLocker on the boot volume will be encrypted until the correct decryption key to unlock the VMK (which unlocks the FVEK) is supplied. The decryption key can be stored on the local hard drive (not providing too much additional protection), or on the TPM chip. Additionally, the administrator can require that a 4-to 20-character PIN or key stored on a USB drive be presented in order for BitLocker to decrypt the boot volume. BitLocker uses 128-bit Advanced Encryption Standard (AES) ciphers by default, although administrators can choose stronger keys.

Note 

Users should not save confidential files to the system partition because BitLocker protects files on the boot volume only.

If the hardware requirements are already in place, TPM must be enabled first, followed by BitLocker. BitLocker requires the same boot process each time the system boots. BitLocker provides the volume encryption while the TPM chip stores the decryption key and verifies the integrity of the boot up process. TPM compares the integrity of the BIOS (if present), optional ROMs, boot sector, boot loader, and Boot Manager against previously stored values. If any of them have been modified, BitLocker halts the boot process and prompts the user for a recovery method. BitLocker requires the same boot process each time the system boots, and thus a hard drive moved between two systems, or between a BIOS-and an EFI-enabled system, will not be easily accessible without a successful recovery method.

Note 

Many customers may want to consider disabling BitLocker's integrity checking of BIOS and ROM, if it is not already disabled. Firmware updates to any of these would cause BitLocker to prevent booting without requesting a recovery method. Even new USB drives present at boot could cause a boot failure.

If BitLocker refuses to boot, the user can supply a previously defined recovery password (48-characters) or 128-bit recovery key. The recovery password can be printed when BitLocker is enabled, saved onto a network folder or other drive location, or stored on a USB flash memory drive. Active Directory has been extended so that BitLocker recovery passwords (and keys) can be archived into Active Directory for recovery purposes. Longhorn server and new Active Directory forests will have the necessary schema attributes and will not require the customer to extend the schema separately.

Don't confuse the keys that have to be provided by the end user when using BitLocker. There can be two manually provided keys: the Boot-up key to unseal protected volume(s) during normal operation and the Recovery key. The Boot-up key can be:

• Optional: Can be configured to not be required

• PIN (provided by user)

• Startup Key (stored on a USB drive)

• Protected by the TPM chip

• The Recovery key, used if the BitLocker boot sequence fails for any reason can be:

• Recovery key (provided physically)

• Recovery password (manually inputted)

• Both, you can use either one separately

Enabling TPM and BitLocker

Once you decide to turn on BitLocker Drive Encryption, the summarized steps are:

1. Decide on BitLocker Boot-up key mode

2. Choose and prepare for Recovery method

3. Enable TPM hardware in BIOS, if used

4. Initialize TPM in Vista, if used

5. Enable BitLocker

6. Validate BitLocker Configuration and Installation

Assuming you have and want to use TPM, the TPM chip must first be initialized (or when you attempt to initialize BitLocker for the first time, it will prompt you to enable the TPM functionality before proceeding anyway). The TPM chip functionality can be accessed using the new TPM Microsoft Management Console, Tpm.msc (see Figure 3-2).

Figure 3-2: New Trusted Platform Module (TPM) console

Choosing to initialize the TPM chip will result in the dialog box presented in Figure 3-3, and requires a reboot. During the startup, a text-based screen from the BIOS will inform you that the TPM is about to be modified and will ask the user to either ignore or to allow the modification. This screen may show up twice.

Figure 3-3: Initializing the Trusted Platform Module (TPM) chip

Next, as Figure 3-4 shows, you are asked to create a TPM management password. You can manually create one or allow TPM to create one. As this password is meant to be stored on a flash memory drive or printed anyway, we recommend letting the wizard create it for you. It will create a very long, random password.

Figure 3-4: Creating a Trusted Platform Module (TPM) password

You can print the password or save to another location including a USB flash memory drive (see Figure 3-5). We strongly recommend saving or printing the password, which should then be stored in a secure place. You will need it later if you have to recover this system's data.

Figure 3-5: Saving the TPM password to media

Only after the TPM management password has been saved will TPM finish initializing (see Figure 3-6). Finally, you'll be greeted with a TPM initialization completed message.

Figure 3-6: TPM initialization in process

There are several options for customizing TPM and BitLocker's behavior. To access, use group policy or local computer policy (Gpedit.msc) and choose the following leaf container (see Figure 3-7) , Computer Settings\Administrative Settings\BitLocker Drive Encryption.

Figure 3-7: TPM and BitLocker group policy settings

By modifying the "Configure TPM platform validation profile" setting you can modify the validation that the TPM does each time the computer is started. Note that some of these options can cause severe problems. For instance, if you enable the option to validate the BIOS, you will be unable to flash a new BIOS on the system without first turning off BitLocker and the TPM. This obviously increases security, but at the expense of a significant amount of usability.

Next, access the BitLocker Drive Encryption applet under Control Panel (see Figure 3-8).

Figure 3-8: Enabling BitLocker using the BitLocker Drive Encryption applet

Figure 3-9 shows the various BitLocker startup options. They include providing no additional key during startup, manually supplying the 48-character PIN, or supplying a 128-bit key from a USB flash memory drive. We highly recommend using BitLocker with at least one additional authentication factor, assuming your users will put up with it. It definitely increases your security. Figure 3-10 shows the USB key option being selected.

Figure 3-9: BitLocker startup options

Figure 3-10: Saving BitLocker key to USB

Next, the user is prompted for how to store the recovery key in case Bit-Locker prevents booting. Figure 3-11 shows the various options. The recovery key is used only if BitLocker fails to boot using the normal key for some reason. This could happen because the hardware in the computer changed, or because of some failure condition. The recovery key is also needed to boot into the recovery console. We recommend making an electronic copy of the recovery key on a USB flash memory drive and also printing it for redundancy. You can never really have too many backups of these things. You should store both items in a secure location. If you are truly paranoid, you can make as many copies as you wish, and store them in several locations. Just be sure to keep track of where they are. You can store several recovery keys on a single USB flash memory drive. The computer will sort out which one belongs to which computer when it needs them.

Figure 3-11: Saving a BitLocker recovery key

As Figure 3-12 shows, Windows Vista encourages one last final check of recovery and encryption keys before BitLocker encrypts the boot volume. This check is heavily recommended and should not be bypassed. It simply involves booting using the newly created BitLocker settings, including any additional authentication factors you elected to use. If you do bypass this check and your system does not recognize your USB token at boot time, you will need to enter the recovery password (40 digits) to restart the system. As soon as the system boots successfully, the actual encryption of the volume will start.

Figure 3-12: Enabling BitLocker system check

Upon reboot and logon, you will see a balloon message similar to Figure 3-13.

Figure 3-13: Initial BitLocker encryption in process

During the encryption process you may notice that the volume you are encrypting is shown as full and with a red bar in Windows Explorer. This is by design. Windows will automatically use as much of that volume as it can during the encryption process to speed up the operation. Eventually, the boot volume will be fully encrypted and protected (see Figure 3-14).

Figure 3-14: Confirming BitLocker encryption status in disk management

BitLocker Drive Encryption provides solid boot volume encryption with several startup and recovery methods. When used with a TPM chip, it is a very secure technology. Several analysts have suggested that stolen computer assets with Vista-enabled BitLocker do not have to be reported as compromised as often mandated by public privacy disclosure laws.

Note 

If there is no external keying material, and only TPM is used, thieves can boot your OS and can then attack it through any external-facing port, service, or application (as covered in Chapter 2).