Information Security For Travelers - TrueCrypt with Honeypot

In the first iteration, I simply used TrueCrypt on my existing Windows 7 system drive.  This was great from a data protection perspective.  The machine couldn't even be booted without a password and the entire drive was encrypted.

I then took the leap to running Ubuntu Linux as my primary OS.  I used Linux Volume Manager & dm-crypt to encrypt the Ubuntu partitions on disk.  I also set up an unencrypted Windows installation to act as a honeypot.  This way my data was still protected and I had a chance at recovering the stolen hardware if the thieves used the honeypot.

Ubuntu works well on my desktop but I had issues with the laptop.  I've decided to revert back to Windows, this time incorporating the honeypot concept using TrueCrypt and the Windows boot loader.  I can still perform my Linux tasks using virtual machines.

This will be a doozy if you've never messed with the boot process before.  I found it to be a fun and exciting refresher course in the facinating world of boot strapping operating systems.

Prerequisites


  • Two Windows 7 licenses
  • Windows 7 Install media (DVD or USB)
  • Linux install / Live media (I used Ubuntu 12.04 on USB)
  • TrueCrypt 7.1a installer for Windows
  • A laptop with at least a 64GB hdd or ssd.  This drive will be erased so backup your data if you care about it.

Overview


The high-level approach is simple.  I used two separate partitions to isolate Windows installations for dual-booting.
  1. Install Windows 7 honeypot.
  2. Install Windows 7 again (to be protected via TrueCrypt).
  3. Encrypt the second partition and enable pre-boot authentication (PBA).
  4. Set up Boot Loader / Manager / Menu.
  5. Install & configure Prey on the honeypot.
  6. Protect system BIOS with a password.

The details, however, are a bit more hairy. The Windows 7 & TrueCrypt boot loader work ok for a vanilla install but we'll need a more configurable loader, which means manipulating the Windows & Truecrypt loaders.

Step 1 - Install Windows 7 Honeypot


I booted from the USB stick where I put the Windows 7 Home Premium installer and chose Custom (advanced) from the What Type of Installation Do You Want? screen.

I then created a 32GB partition, which is about the practical minimum for Windows 7, and installed the OS as normal.

I reused my OEM license key (from the sticker on my laptop) but I did NOT use the OEM system discs to do the installation.  Instead, I used an actual Microsoft Windows ISO to avoid bloatware & OEM recovery partitions.

To enable autologin to the honeypot, I used the control panel to create a standard user account with no password.  To set that account to logon automatically I launched netplwiz from the Start Menu, selected my dummy user and unchecked users must enter a username and password to use this computer.

Step 2 - Install Protected Windows 7


Once the previous install was complete, I booted from another USB stick where I had imaged the Windows 7 Ultimate installer.  Again, I chose Custom (advanced) from the What Type of Installation Do You Want? screen.

This time, I selected the remaining unused space on the drive and installed to that location.  I used a retail Windows 7 Ultimate license key because I had one available from a previous project.  You can use whichever edition you prefer.

Windows Boot Loader Configuration


Once the second installation was complete, I had a boot menu containing two items, both labeled Windows 7.  By default, the boot manager was on the 100MB NTFS System Reserved partition.

Next, I isolated the Windows 7 installations by giving them each their own boot manager.  While booted into the honeypot OS, I started a command-prompt with admin privileges and created a backup of the Windows Boot Configuration Data (BCD).

bcdedit /export c:\bcdback

I then started the Windows 7 Disk Manager and marked the partition containing volume C as Active (formerly the System Reserved partition was active).

Next I restarted, booting from a Windows 7 install USB stick, hit SHIFT-F10 to open a command prompt and set up the boot manager on the newly Active partition.  Before I started I double-checked my drive letters and partitions with diskpart.

bcdboot c:\windows /s c:
bootrec /FixBoot
bootrec /RebuildBCD

The RebuildBCD command may be unnecessary but I didn't get a chance to try without it.  Upon rebooting, the machine automatically started Windows 7 from the honeypot partition.

I then repeated the process for the other protected OS partition, starting by making it Active via the Windows 7 Disk Manager.  I then restarted, booting from the Windows 7 install USB stick, launched a command prompt, double-checked my drive letters with diskpart and finally set up the boot manager on drive c: (c: is assigned to whichever partition is Active).

bcdboot c:\windows /s c: 
bootrec /FixBoot
bootrec /RebuildBCD

Upon restart, the machine successfully booted Windows 7 from the protected partition.

At this point the machine would boot from whichever of the three partitions was made active:
  • 100MB "System Reserved" with the original dual-boot BCD and boot menu
  • 31GB Windows 7 install (honeypot) w/o menu
  • 192GB Windows 7 install (protected) w/o menu
I left the protected partition Active while I proceeded with encryption.

Step 3 - Encryption


I booted the Windows 7 (protected) OS, launched the TrueCrypt client and started the system encryption wizard.  Here are the answers I gave:

  • Area to Encrypt: Encrypt the Windows system partition.
  • Number of Operating Systems: Single-Boot
  • Encryption Options: Defaults
  • Password: Follow TrueCrypt's instructions and use a longish pass phrase.
  • Collecting Random Data: follow TrueCrypt's instructions
    The software needs the movement of your mouse to generate random numbers for key generation.  It's not as goofy as it seems.
  • Wipe Mode: None
    This drive is new and has never had any sensitive information stored on it.  Wiping isn't necessary.

I passed the boot test since Partition 3 (the large protected Windows 7 install) was active and was booting independently of the honeypot install.  TrueCrypt remained ignorant of the honeypot and configured it's boot process independently as well.

Once the system encryption completed, I used the System menu to edit Settings, disabling PBA bypass with the ESC key and disabling text display during PBA.  You might want to put a convincing error message here (bootmgr missing, etc).


Step 4 - Grub4DOS Boot Loader


At this point the machine would start and boot using the TrueCrypt bootloader, enforce pre-boot authentication and successfully start the protected Windows 7 installation.  To re-enable booting the honeypot installation, I chose Grub4DOS, a third-party boot manager.

Rationale


The TrueCrypt boot loader can only chainload the Windows boot loader, which it expects to find on the Active partition.  It is not configurable.  The Windows boot loader is not suitable for our honeypot setup because of how it handles resuming from hibernation.  In a dual-boot scenario, the boot loader is on the shared System Reserved partition and somehow monitors the shutdown status of each Windows installation.  If I hibernate the protected installation and the machine is stolen, it will come out of hibernation to my protected login screen rather than to the unprotected honeypot Windows 7 desktop.

Grub2 is a modern configurable boot loader but it doesn't work well with TrueCrypt because it overwrites part of TrueCrypt's code, even when extracting the TrueCrypt boot loader from the mbr and loading it from a file instead.

Grub would work but it's multi-stage architecture is cumbersome and it would require it's own /boot partition on ext2/3.

Grub4DOS, like Grub, won't overwrite TrueCrypt's boot code when it is loaded into the MBR but it also has the added advantage of supporting NTFS for the rest of it's boot code & menu configuration.  I'm reusing my 100MB NTFS "System Reserved" partition for this task so Grub4DOS is a good fit.

Extract Sectors from Boot Disk


To handle the disk manipulation (extracting/writing boot loaders), I could either boot to a Linux Live CD and use dd and related tools or set it up from Windows using Grub4DOS Toolbox, which provides analogues to the Linux tools and automates many of the tasks so they can be performed from Windows.  One of the components, bootlace.com, can't run on a 64-bit OS so I'm used Cloud Bootlacer for that component.

The first thing I did was launch the Grub4DOS toolkit and extract the original TrueCrypt MBR and related volume headers, keys, etc.

Backup TrueCrypt MBR to file
Backup First 63 sectors (TrueCrypt MBR, volume header, keys, etc)

I then uploaded the file containing the first 63 sectors of the drive to Cloud Bootlacer, taking only the default options (i.e. none).  They returned a new file containing the first 63 sectors, but this time with the TrueCrypt MBR replaced with the Grub4DOS MBR.  Hopefully Cloud Bootlacer isn't operated by nefarious data thieves, agents of a corrupt authoritarian regime or executives from Facebook.

At this point I had the following files set aside:
  • truecrypt.mbr, containing the first sector of my drive with the TrueCrypt boot loader
  • truecrypt_orig.bin, containing the first 63 sectors of my drive, with the TrueCrypt loader, volume header, encryption keys, etc
  • bootlaced_grub4dos.bin, containing the first 63 sectors that I have yet to put on my drive, with the Grub4DOS bootloader, TrueCrypt volume header, encryption keys, etc
  • bootlaced_truecrypt.bin, which should be a duplicate copy of the file truecrypt_orig.bin.  Cloud Bootlacer generated it and I will probably throw it away. 
  • gldr, the remaining boot code for Grub4DOS, part of the grub4dos package
  • menu.lst, the stock menu configuration file that came with Grub4DOS
I placed the gldr, menu.lst and truecrypt.mbr (one might choose to rename this one for obscurity) files in the root of the 100MB NTFS "System Reserved" partition.

Write Modified Sectors to Boot Disk


Finally, I did the scary thing.  From the Grub4DOS Toolbox, I wrote the bootlaced_grub4dos.bin file to the first 63 sectors of my drive.


Alarmingly, it threw an error, "Error writing to target!  80".  There were no messages in the log and no indications on the 'net, so I gave up Windows and booted from an Ubuntu USB stick.  No damage was done by the failure, so I confirmed that my SSD was indeed /dev/sda and then I used dd to write the grub4dos bootloader to the MBR:

$ sudo dd if=/tmp/g4d.bin of=/dev/sda bs=512 count=63





 
63+0 records in
63+0 records out
32256 bytes (32 kB) copied, 0.00359019 s, 9.0 MB/s

Configure Grub4DOS


After writing the new MBR, I rebooted and was presented with the default Grub4DOS menu, as defined in menu.lst.  The default menu was able to find and boot the honeypot OS but not the protected OS.








I replaced the contents of menu.lst with the following:






# load the first entry after a few seconds
default 0
timeout 10
# set graphics mode (1366x768) and menu colors
color light-grey/black black/light-grey dark-gray/black white/black
color border=0x222222
graphicsmode -1 1366 768 32
# hide the System Reserved & TrueCrypt Partitions, activate the honeypot partition
# and chainload the boot manager on hd0,1
title Windows 7
hide (hd0,0)
hide (hd0,2)
unhide (hd0,1)
rootnoverify (hd0,1)
makeactive
chainloader /bootmgr
# hide the System Reserved and honeypot partitions, activate the truecrypt partition
# and chainload the truecrypt bootloader previously stashed on hd0,0
title TrueCrypt
hide (hd0,0)
hide (hd0,1)
unhide (hd0,2)
rootnoverify (hd0,2)
makeactive
chainloader (hd0,0)/truecrypt.mbr

It would be a good idea to obscure any references to TrueCrypt (though if true plausible deniability is your goal you'll probably have to go much further than this).

I saved the file, restarted and verified that I could now select and boot either the honeypot or the TrueCrypt protected operating systems.

Step 5 - Prey


I downloaded and installed the latest Prey from the Prey Project.  Unlike most users who selectively enable Prey when the laptop has been stolen, I want Prey to activate whenever someone reaches into the honeypot.  To make things simple, I've configured Prey to run standalone and send me a usage report every 20 minutes by email.

Documentation for Prey is sparse.  Most users have PreyProject accounts and use the control panel to manage and configure the service.  I'm going old school for now.  To configure Prey, launch:

C:\Prey\platform\windows\prey-config.exe

A GUI will appear.

Choose the first option to configure standalone vs control panel mode


Standalone & SMTP Settings

  • Check URL: Despite the on-screen text, a value must be set.  I chose the URL of a non-existent page on this blog that will always return an HTTP 404 error.
  • SMTP Settings: I chose the credentials for a gmail account which I consider to be somewhat "throwaway".  The password is weakly protected on the hard drive.  This alone may be enough to convince me to switch to control panel mode in the future.

In this configuration, Prey stores the password to my SMTP server as a simple base64-encoded entry in a config file. One should not use this password for anything important.  

To further protect Prey's configuration, I edited the permissions of c:\prey:
  • removed inheritance
  • removed permissions for Authenticated Users
  • removed permissions for Users

This left SYSTEM and Administrators with full access.

A few minutes later I received my first report.

It included a screenshot, a failed capture from my web cam, my IP address, latitude/longitude, uptime and Windows username.

Step 6 - Protecting System BIOS


Should the laptop be stolen, I want to encourage the thief to use the machine as-is, so that they can be tracked via Prey.

With physical control of the machine, we can't prevent a determined thief from reinstalling the operating system to bypass our security controls but we can make it harder.

My last step was to disable booting from USB devices and to password protect the settings.  These are among the few options that HP permits the end-user to modify in the Insyde BIOS.

Remaining Issues


  • The TrueCrypt Boot Loader screen options are not respected
    • "do not display any text" cannot be enabled
    • "allow pre-boot authentication to be bypassed with ESC" cannot be disabled allowing USB boot (facilitating a wipe & reinstall by a clever thief)
  • Prey reports contain "turn on your webcam" error rather than webcam captures

No comments:

Post a Comment