myITforum.com : Motivation to physically secure your systems

I was recently helping another admin figure out how he could deploy operating system updates to a bunch of laptops which never connect to the network and which the users were not local administrators. We came up with an interesting method which exploits what I consider to be a security loophole in Windows 2000 and XP. After I thought about our findings a bit, I realized that this could be a huge vulnerability for many organizations and thought I should share it so that you can be informed. (I contacted Microsoft prior to writing this article, but this scenario was deemed to not be a security issue since it involves the user having physical access to the system.)

We all know that we should consider the following items when securing our computer systems:

Set alternate boot devices (cd-rom, usb flash, floppy, ...) to disabled in the BIOS so that the system only boots from the hard drive.
Physically secure the computer case by using a locking device of some sort which prevents access to the case internals.
Rename default local accounts (Administrator and Guest) and possibly do something with local groups as well.
Setup some sort of alert system to notify an admin when a computer case has been opened.
Password protect the BIOS.

Well, if we haven't properly considered the above list and the user has the ability to boot using a tool such as BartPE, WinPE or the Sysinternals recovery tools, the user can make an alteration to the operating system startup scripts and subsequently gain higher system access from within Windows than desired.

Here is a scenario to consider:

I am a standard user on the local system with either a local or domain user account.
I am able to boot my computer from cd-rom or USB flash drive using a tool such as BartPE, WinPE, etc. (Booting from an alternate source allows me to bypass most security settings of the operating system on the hard drive.)
I can copy an executable or script to the Windows file system on the hard drive.
I can modify the C:\Winnt/Windows\System32\GroupPolicy\Machine\Scripts\script.ini file so that it runs a command of my choice. IE: Make it run the script or executable I copied over in step 3. (The script.ini file is where Group Policy stores the list of items to be run during system startup. This file is in plain text and easily editable.)
I reboot the system and my script runs at startup under the context of the System account using elevated privileges.

Such a script might give my account local administrative privileges by adding my account to the local administrators group.

Being able to edit the script.ini file is neat for those of us who want an easy way to automate some system tasks, but I consider it to be a big hole. I would like to see Microsoft consider encrypting the contents of the script.ini file as such a measure would help to prevent this scenario from happening.

I hope this little bit of information provides inspiration to those out there who have not yet secured against the use of alternate boot devices.

BTW: There are a few variations to the above scenario which can accomplish the same results, but I'll leave them out for now.

Please feel free to send me an email with any comments on this article ( dethomson@hotmail.com ).

See my other articles or blog


		myITforum.com ©2010 \| Legal \| Privacy