Removing hidden devices from Device Manager in Windows 7

You may find yourself in a situation where you have added and removed a piece of hardware from a computer, which then causes you ongoing problems. Unfortunately by default Device Manager often doesn't show these "removed" pieces of hardware, while the solution is very simple it is somewhat hidden from view.

1. Open up a command prompt as Administrator

2. Into the command prompt type,
set devmgr_show_nonpresent_devices=1

3. Then to launch the Device Manager type,
start devmgmt.msc

4. Once Device Manager is open, select the "View" menu and tick "Show Hidden Devices"

5. It is as simple as that, your hidden devices should now appear, giving you a chance to remove them and the drivers that may be causing you issues.

Cold Boot Memory Attack part 1

A couple of years back the good folks at Princeton discovered a neat way of attacking full disk encryption. RAM or random access memory is "supposed" to be volatile, meaning as soon as you reboot or power off, the contents is lost. The team at Princeton discovered this certainly isn't the case when the machine is warm rebooted and the contents can even survive a full power off cycle if the RAM temperature is lowered (perhaps with liquid nitrogen).

The technique involves either rebooting the machine with the reset button or pulling the power cable of the rig and attempting to maintain the RAM contents (one way to maintain the contents is to super-cooling the ram). A lightweight operating system is then booted, this OS will only overwrite a small portion of the memory, the remaining memory is then dumped to a file which can later be analysed off-line.

In part 1 I simply want to prove the concept of this attack and learn how it works. Then in part 2 I will attempt to combine what I have previously learnt with liquid nitrogen cooling to see if its possible to transfer the memory from one physical computer to another without losing its contents. This sort of attack might be important if the target doesn't allow selection of boot devices or if there is some other type of boot protection in place.



The Software

I have chosen to use McGrew Security's msramdmp, which in conjunction with the extremely tiny syslinux loader is a lightweight and easy to use memory dumping solution. I will not go into the details of building the bootable USB capable of performing this memory dump as McGrew Security has a great tutorial available here.

I have made a few small modifications to the McGrew Security tutorial though. Instead of using the USB stick to dump the memory contents I am going to use a Corsair Force GT SATA3 SSD. This will allow me to dump the memory contents much quicker, which is essential if you are dumping 4GB+ of memory. I found dumping to USB took in excess of 15minutes for a 2GB module, whereas the SSD took less than a minute to complete. When you are trying to dump data fro liquid nitrogen cooled memory that is slowly decaying, time is of the essence.



The Setup

Gigabyte P55-UD5 with Intel 870
Corsair Force GT SSD (for dumping the memory)
USB configured with syslinux 3.6 and msramdmp
2GB module of GSKILL PSC memory

I have chosen a single 2GB stick of PSC as the lower memory size will dump quicker. I have selected PSC because it likes cold temperatures, so when it comes time to freeze the memory I know this stick will work perfectly.

 

The Attack

First I prepare my SSD with the type 40 partition (Venix 80286) required to dump the memory (as per the image below).

I then booted into an USB based dos boot disk and tried to seed my blog name into the memory. I have repeated this a number of times but every time when I boot into Linux to analyse the dump, there is no mention of metasplo.it.

Next I tried booting into a Linux live USB and did the same echo command, but this time the output is sent to a file situated on a "ramdisk" in the hope this will help seed my blog address into RAM.

Next I warm reboot the machine by hitting the reset button, I hit F12 and selected to boot from my msramdmp USB and let the dump occur.

After around a minute the 2GB of memory is written to the type 40 partition on my SSD and then msramdmp changes the partition to type 41 (PPC PReP Boot) as per below.

Next I rebooted into the Linux live CD once again to analyse the SSD with the strings command. SUCCESS! This time the "blog.metasplo.it" string has survived the reboot and been dumped successfully from memory.

That was relatively easy and the end of part 1. You can see how this attack could be brutal in dumping encryption keys to even the most heavily encrypted hard disk.

Next I will try to transfer the memory module from one system to another while frozen with liquid nitrogen to proof of concept an attack in a more privileged environment.

Deploying Adobe Premiere Elements 10 in a network environment

Adobe Premiere is an essential tool in an educational environment, especially one with a huge recent spike in video usage like ours. I was recently lucky enough to receive a number of Adobe Premiere Elements 10 (PE10) licenses to deploy throughout my network.

I know Adobe products are always horrible to deploy, but PE10 takes something bad to a whole new level.



The Problem

Unfortunately PE10 seems to have a serious incomparability with network based profile directories, like the ones most schools would be using. The product installs without issue, but when you get to the "New Project" screen the "Save In:" field is blank. Once you click "browse" to find a path to save your project, PE10 complains of a serious error and then crashes.

The exact error message is "Sorry, a serious error has occured that requires Adobe Premiere Elements to shut down. We will attempt to save your current project."

If I login to a local account (with no network based profile, obviously) everything works perfectly.

As per this thread it seems Adobe's official position is that PE10 is designed to be used locally and running it in a network environment is unsupported. This is once again a failure by Adobe in the deployment space, it seems they just can't understand we just want to "install.exe /s" their products, what is so hard about that? I don't want to learn a whole new language to deploy a product and then have to put together dodgy fixes to get it working. OK, rant over!



The Solution

There are a few parts to this solution but the core of the fix revolves around a file called "Adobe Premiere Elements Prefs" that sits in "%appdata%\Adobe\Premiere Elements\10.0". This file contains a number of user based preferences, including the paths.

The specific line in the configuration we want to set is as below. This is the line that's populated in the "Save in:" box that is giving us all the problems.

<BE.Prefs.MRU.Document.0></BE.Prefs.MRU.Document.0>

Instead of creating this file by hand we are going to do a little bit of Adobe hacking.

1. Log into a computer with PE10 installed as a local administrator.

2. Create a local folder, ensure all users have permission to read/write. I have created a folder called c:\pe10scratch and given the "Users" group permissions to this folder.

3. Launch PE10.

4. Save your "New Project" in the c:\pe10scatch folder. (You must do this)

5. It is also a good idea to go to change the paths of all scratch disks to local disks. If network paths are used this can mean massive amounts of data moving across the network and slow performance for the user. Once in PE10 select the "Edit" menu, select "Preferences" and select "scratch disks". Set a local path for all of the available option.

6. Close PE10.

Now we need to grab the "%appdata%\Adobe\Premiere Elements\10.0\Adobe Premiere Elements Prefs" file and all of the files in the c:\pe10scratch folder (or whatever you may have called it).

At this point you may also like to grab some of the registry settings from "HKEY_CURRENT_USER\Software\Adobe". Some of the interesting ones that might save your users time are:

[HKEY_CURRENT_USER\Software\Adobe\Elements Organizer\10.0]

"Locale"=

[HKEY_CURRENT_USER\Software\Adobe\Premiere Elements\10.0]

"Language"="

"ShowDriverUpdateMsg"=

"DriverUpdateMsgCount"=

[HKEY_CURRENT_USER\Software\Adobe\Premiere Elements\10.0\WelcomeScreen]
"QuickLaunchApp"=

"LaunchCount"=

 [HKEY_CURRENT_USER\Software\Adobe\CommonFiles\Usage\Elements10]
"OptIn"=

"Date"=

These specific registry settings and possibly some others, can be deployed on login to ensure your users don't see annoying "feedback program" and "your VGA driver isn't up to date" type messages when launching the program.



User Based Settings Deployment

Now that you have your registry settings, preferences and the empty project we need to deploy them somehow.

For the registry settings and the preferences file I am using my existing kixtart based login script. A simple script as below will do the job. The following script deploys the HKCU registry changes and the preferences file if PE10 is installed on the machine.

;setup premiere elements 10
if (exist("%programfiles%\Adobe\Adobe Premiere Elements 10")) and (exist("%appdata%\premel10.tch")=0)
  SHELL "regedit /s $logonpath\registry\premel10\premel10.reg"
  SHELL '%COMSPEC% /C xcopy "$logonpath\registry\premel10\Adobe Premiere Elements Prefs" "%appdata%\Adobe\Premiere Elements\10.0\" /E /Y /C'
  Copy ("$logonpath\generic.tch") ("%appdata%\premel10.tch") /H
endif

That is one piece of the puzzle, the other is deploying the empty project we created in step 4. Unfortunately unless this project exists on the target system, the "Save In:" box will still be empty and crash when you click browse.



Deploying PE10 and the empty project

I won't cover the actual silent deployment process because Adobe has a good write up available here (yes I just did compliment Adobe for once)

I have chosen to deploy the C:\pe10scratch folder and the empty project as part of my SCCM deployment of PE10. My deployment batch file reads as follows:

vcredist_x86.exe /Q
start /wait oem.exe /UL1033 /V"SERIALNUMBER=1111-1111-1111-1111-1111-1111"
xcopy "custom\elements" "c:\pe10scratch" /E /Y /C

Extremely simply but effective. You may also choose to deploy HKLM registry settings at the same time.

Please Adobe, think about your end users before releasing a product that requires dodgy fixes to work.

Sequencing Adobe Premiere Elements 10 with App-V 4.6 SP1

I recently received a number of licenses for premiere elements 10 and due to licensing restrictions decided the best way to move forward would be to use App-V for license management.

I began the package sequencing and towards the end of the installation I recieved an error message when the "Shared Technologies" were installing.

After this installation failure, the Adobe installer kindly begins rolling back the rest of the installation, resulting in a sequencing failure.


The Resolution

This one is extremely easy but took some digging with procmon and working through logs to work it out. The installer is looking for Visual C++ 2008 SP1 x86 and as my sequencing machine didn't have it, the sequencing failed.

Specifically you need version 9.0.30729.17, without this specific version the installation won't proceed. You need to perform this installation BEFORE you start your sequencing and the package must also be installed on any App-V clients that will be accessing the application. If you miss any of these steps the application wont sequence or wont launch.

Microsoft Visual C++ 2008 SP1 x86 is available here

If you require additional information on the silent installation process itself, please check out the Adobe website http://kb2.adobe.com/cps/922/cpsid_92294.html

Blocking Windows XP user group policy by exploiting a roaming profile vulnerability

For users that roam from workstation to workstation, roaming profiles can be a life saver. All the users settings and customizations move with them and save bucket loads of configuration.

There is a huge security hole with the Windows XP roaming profile model thought, as the HKEY_CURRENT_USER hive is synchronized to the network, any customizations to the security permissions are also synchronized. It is therefore possible to totally block group policies from applying at the HKEY_CURRENT_USER level with a few easy steps.

While this doesn't affect computer level policies in the same way, they are rarely used to enforce restrictions such as blocking regedit, command prompt or the run command. Incidentally a user in a high security environment can bypass these restrictions throughout the whole network by access a single vulnerable machine.

The following steps must be performed as a local Administrator. Hold on, did you say as an Administrator? Doesn't that ruin the whole security hole arguement? In fact there are so many vulnerabilities in Windows XP that unless the patch management of the environment is good, you should be able to elevate to Administrator or SYSTEM on some computer throughout the enviroment.

Even easier is to use the "vBootkit" by Nitin and Vipin Kumar. This ingenious boot CD allows the attacker to elevate any process to system level privileges by loading a temporary rootkit into the MBT. For example we could designate the vBootkit to elevate cmd.exe to SYSTEM token after we launch it, or if command prompt is currently blocked with policy we could elevate a 3rd party task manager or launcher.

The beauty of the vBootkit is as soon as you reboot, its gone, it only loads itself into the memory space of the single boot.


Could it get any easier?

1. After elevating yourself to an Administrator or SYSTEM prompt (perhaps via the Kumar's vBootKit), launch a regedit session.

2.  After I navigate to my "HKEY_CURRENT_USER\Software\Policies" key, you can see a number of policies that are set to apply to my account. These have likely been added via domain group policy.

3. If we right click the Policies key and select permissions, we find the SYSTEM has full control over this key.

5. The SYSTEM account is used to deliver group policies directly to this "HKEY_CURRENT_USER\Software\Policies" registry key. By setting the SYSTEM account to Deny permissions. as per the image below, we effectively block the system from being able to apply its group policies to my account.

Computer policies will still continue to function, but you can use the same technique on the "HKEY_LOCAL_MACHINE\Software\Policies" hive to block computer policies. The difference is HKLM changes won't follow you from computer to computer like HKCU policies will in a roaming profile environment.

6. The next step is to delete all the existing policies (unless there is any you want to keep of course). We can now potentially unblock Internet Explorer restrictions, allow the command prompt and perhaps even stop a login script from running.

7. Now if you run a gpupdate you will find the policies don't reapply, your HKCU policy free! The next time you log off these policy permission changes will be synchronized to the network and you will be exempt from HKCU policies on every machine login.

You can see how devastating this could potentially be. A systems administrator doesn't patch an edge workstations as early as early as he or she should, an employee elevates themselves to local administrator and applies these group policy blocks, the changes synchronize to the network. All of a sudden that same employee has allot more flexibility to launch attacks from more privileged workstations (that are running roaming profiles) in other parts of the network.

Possible ways of mitigating the attack

I think the easiest way to mitigate the attack is auditing. Regular checking, or scripted checking of NTUSER.DAT hives on the network share the roaming profiles reside.

I have played around with scripting to mount the hive as read-only (with reg load), check the Policies key for SYSTEM permissions irregularities with subinacl, report on any unusual findings and then un-mount the hive.

Using subinacl and the below string we can audit the current status of the SYSTEM account that is used to apply the group policy to the user "HKEY_CURRENT_USER\Software\Policies" key.

subinacl /verbose=1 /keyreg "HKEY_CURRENT_USER\Software\Policies" /display=dacl

You could very simply do this with a batch or kixtart script and have it run on a weekly or monthly basis and e-mail the dodgy findings directly to you.

Deploying custom Microsoft Word 2007 registry settings at logon

As a systems administrator in a reception to 12 school (K to 12 for any non-aussie's reading) I get allot of requests for settings delivery, much more than I ever experienced in the corporate world. These settings range from printers, network drives to office templates, application configuration and anything else you can think of.

Recently I was asked to deliver some Microsoft Word 2007 settings for our younger students, the requests from staff were that the "picture in front of text", "hide formatting" and "search everywhere in clipart" options were automatically deployed. For students as young as 5 logging onto the computer and opening Word can be a challenge, let alone going into options and manually configuring these options.

All of these settings are buried deep in Office 2007's registry entries but with some trial and error and the ever trusty procmon from sysinternals, it is easy to work out.


Setting clipart to search web collections

This one is fairly easy, the key in question is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Clip Organizer\Search\Last Query\Extra]

The easiest way to get the setting you want is to open Word, tick the appropriate boxes and then export the above key with regedit.

Applying the setting is as simple as importing it into the users HKCU store as part of your login script, below is an example of a kixtart script.

if ($isUserReception)
   SHELL "regedit /s $logonpath\registry\word2007pictureinfront_hideformat.reg"
   SHELL "regedit /s $logonpath\registry\word2007clipartcollections.reg"
endif


Keeping picture in front of text and hiding formatting

Changing these two settings are slightly more difficult but can be extracted in exactly the same way. Both of these settings are controlled by a large value named:
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data\Settings]

This REG_BINARY value is unconfigured by default and is only set when the user specifies some non-default settings in Word, such as the "keep picture in front of text" and "hide formatting" from the options menu.

1. Before we try to capture the settings it is best to start wish a fresh [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data\Settings] value, you can do this by deleting the value in regedit.


2. Next open Word 2007 and set your options. For me those options are "keep picture in front of text" and "hide formatting" but you can set as many settings as you want. You may need to do this multiple times for multiple settings "packages" as its not possible to export individual settings as most are contained within this single value.

3. Close Word, this is when the settings are written to the registry.


4. You can now export the key and deploy it with a logon script. Remember this is a HKCU key, so it must be deployed in a user based script.


Hopefully these couple easy processes will help you deploy more advanced settings for your users.