Archives for March 2011

XenDesktop USB Filtering the easy way!

In XenDesktop 5.0 you can configure HDX policies to block or allow certain types of USB devices. For example, you could block flash drives but allow USB printers or webcams. Unfortunately, Citrix doesn’t give you an easy to to discover class IDs, vendor IDs, or other identifiers that can be used in their policies. Citrix has a good article here on USB filtering in XenDesktop 5.0.

Instead of digging through the registry to discover this critical USB data, I found a great tool that makes it a snap. Nirsoft has a free USB viewer you can download here.

To create the appropriate rules I did the following process:

1. In Citrix Desktop Studio open the Users HDX policy and navigate to USB DevicesClient USB device redirection. Edit the policy and change the value to Allowed.

2. Using the Citrix receiver connect to a virtual desktop, then from the menu bar click on the USB button.

3. In my case I have a flash drive connected to my physical computer, so I selected that from the drop down menu. I then heard the Windows USB disconnect/connect sounds and saw my flash drive ready to use in the VM.

4. Download the USB viewer tool and run it inside the VM. In the list of USB devices, locate your connected device and double click on it. Here’s what comes up for my USB stick:

5. Take note of the USB class ID and USB subClass IDs, as you will need these for the HDX rules.

6. Back in Citrix Desktop Studio open the Users HDX policy and navigate to USB DevicesClient USB device redirection rules. Edit the policy and create a new rule, for example:

7. Accept the rule, then log out of your virtual desktop then log back in. If you try and connect your thumb drive now, nothing happens. Unfortunately XD5 doesn’t provide the user any feedback why you can’t connect the device. It would be most useful if a warning popped up saying that device was administratively prohibited, so the user didn’t call the help desk wondering why it wasn’t working.

You can use the same basic procedure to build up allow or deny device lists as required. Some devices can be tricky, such as multi-function USB printers/scanners/fax machines. So a single composite device might need a few allow entries to make it properly function. But using USB device view, you can pretty easily figure out what you need to do.

Immediately Activate Office 2010 and Win7 in a VDI Environment

Lately I’ve been working on a XenDesktop 5.0 Proof of Concept with Windows 7, and I wanted to make sure Windows 7 and Office 2010 were activated immediately when a VDI VM booted up. Normally after some period of time Windows 7 and Office 2010 will activate themselves, but this can take several minutes or longer. So I wanted a solution that would activate office 2010 and Windows 7 shortly after boot time, so I didn’t have to worry about any activation messages.

In my scenario I’m using a KMS server with DNS SRV records, so Windows and Office can automatically find the KMS server on the network. Windows 7 has a nifty new task scheduler, so I thought I’d see if I could make a boot time task that activated Windows 7 and Office 2010. Sure enough, it was pretty easy and works like a charm.

Here’s how to create the scheduled task:

1. Launch the Task Scheduler and find a good place to put your new task. I chose MicrosoftWindowsWindows Activation Technologies.

2. Create a new task and configure the General properties as shown below:

3. Configure the trigger settings as shown below:

4. Configure the actions as shown below (Note that I configured cscript as the ‘program’ and put the rest of the command line as the arguments):

5. I cleared all of the condition settings, as they were not relevant for this task.
6. Finally, I configured the following settings. These settings are not critical, so you can tweak them as needed.

At this point you now have a configured task the runs once right after a computer boots to activate Windows 7 and Office 2010, on both 32-bit and 64-bit platforms. I wouldn’t run this on a physical computer, as activation is automatic and only is required every 180 days. But in a VDI environment where the VM’s state is reset after every reboot, I like making sure it’s immediately activated.

To validate that Office 2010 is activated you can run:

32-Bit: cscript “c:\Program Files\Microsoft Office\Office14\ospp.vbs” /dstatus
64-Bit: cscript “c:\Program Files (x86)\Microsoft Office\Office14\ospp.vbs” /dstatus

To validate Windows 7 is activated you can run:

cscript c:\windows\system32\slmgr.vbs /dli

P.S. Microsoft: Would it really be too much to ask that the Windows and Office teams collaborate on the command line switches for activation? Clearly there was no coordination as the switches are totally different between the products.

Building a Sandy Bridge ESX Server

A few months ago I posted the parts list for sub-$1000 ESX server. At that time Intel had not released their Sandy Bridge CPUs or chipset. Now that manufacturers are shipping chipsets without the SATA bugs, I thought I’d post an updated list of components for a screaming home ESX server. You can buy everything you need except the CPU cooler from TigerDirect.

The same criteria apply to this server as my previous post: compact form factor (HTPC case), quiet, power efficient, and dual 1Gb NICs. The CPU has a built-in GPU, so no separate graphics card is required. If you already have external shared storage (like a QNAP), then you don’t need an internal HD and could use the 8Gb tiny flash drive listed below to install ESXi on. The NICs on the motherboard are not supported by ESXi, which is why you need the SuperMicro card.

Intel also ships a lower power i5-2400 CPU (65w max vs 95w max), but it runs at a lower clock speed. Depending on your requirements, this may be a better option if your electricity bill is a concern. The WD hard drive is a screamer, but is a bit noisey. So if the noise will disturb you, going with their green line would be a much quieter option, but is slower.

Antec MicroATX Minuet 350 case  $116
Asus P8H67-M Pro $130
Intel Core i5-2400 $200
Patriot 8GB DDR3 PC3-12800 2x $85
SuperMicro Dual GiGE NIC AOC-SG-I2 $86
Scythe Big Shuriken CPU Cooler $35

Total: $737 + Shipping

Optional parts:
Asus DVD Burner $20
LaCie 8Gb ultra-small USB flash drive $25
Western Digital 1TB 6Gbps Caviar Black SATA HD $85
Intel Core i5-2400S Low-power CPU $200

Update 1: Got all of the parts and the server works great. I would advise that you install the memory before you put on the CPU cooler, or you will find yourself taking the CPU cooler off. Also, if you don’t get the memory I specified above, make sure the memory you get is low profile and doesn’t have any heatsinks sticking up above the DIMM PCB. I really like the new ASUS EFI BIOS..very graphical, easy to use, and slick. I also decided to get a tiny 4GB USB memory stick from Best Buy for $15, located here.
Update 2: I did some power measurements, and idiling the server uses 47 watts, which is more than 20 watts less than my previous ESX server. The integrated graphics card and more power efficient CPU sure make a difference!
Update 3: vSphere 5.0 recognizes the onboard RealTek NIC. So if you are satisfied with a single NIC you can skip the SuperMicro card in my parts list. If you want the very latest motherboard the Asus P8Z68-M Pro works extremely well, and its onboard NIC is also recognized. The Z68 chipset has the advantage of overclocking the CPU while letting you use GPU equipped CPUs, so you don’t need an add-in PCIe video card like you do with the H67 chipset.

Hashes to Ashes – Root your domain in seconds

Protecting privileged passwords is always extremely important, and you may think just because you use a very long password that is highly complex that it may take a hacker days, weeks, or even years to break into your system. Or you may also think that giving regular users local admin rights on their workstations or laptops, while not ideal, really isn’t THAT bad. After all, the user’s elevated rights would not extend beyond their local computer, right? Or how about giving low-level help desk staff administrator rights on certain servers or computers in the domain? Fairly low risk, right?

Think again, as these scenarios may not seem overly dangerous to your average administrator or IT manager, but to a person with a couple of free tools, they could potentially 0wn your entire Windows forest in just a few short seconds…without having to decrypt long complex passwords, download large rainbow tables, or use large computing resources.

How? Very simple really…it’s called passing the hash. This is not a new attack, and if you are a security professional then I’d sincerely hope you are aware of this attack vector because it’s been around for a long time. But there are a couple of freely available tools that allow the attack to be accomplished in just a few seconds, even on the most modern Microsoft operating systems like Windows Server 2008 R2 SP1 and Windows 7 SP1.

To demonstrate this attack, I have two computers. The first is a Windows Server 2008 R2 SP1 domain controller (fully patched), called N001DC01. The second server is called N001Lync01, and is also Windows Server 2008 R2 SP1 (fully patched) and running Microsoft Lync Server 2010. Both have additional security lockdowns applied to them, including many of those required by the Federal Government.

In a typical corporate environment you would have a limited number of domain administrators, and then many delegated administrators with fewer rights. For this example, the sysadmin account is the domain admin, and on N001Lync01 there is a local administrator account called LocalAdmin. The domain admins would likely use their account to logon to most servers and clients in the environment to do their daily job such as fixing system problems, installing patches, etc. All accounts have long, strong passwords, that are 20 characters or longer. The domain name is contoso.net.

To completely 0wn the domain and elevate my rights from local administrator on one server to being a domain admin, I’ll follow this quick, pain free, process:

1. I’ll logon to N001Lync01 as the local administrator, localadmin. I’ll do a whoami to verify I’m who I say I am.

2. Next, I’ll try to map to the C drive on a domain controller, just to prove that I don’t have permissions since I’m a local administrator only on N001Lync01.
3. Since I have local admin rights on N001Lync01, I’ll dump the hashes stored in memory and see if there’s anything useful. By George, yes, I do believe we have a winner. I can see that the password hash for the domain administrator account, contososysadmin, is present and was captured.

4. Now that we have the domain admin hash (after just a few seconds of work), let’s now use the hash to impersonate sysadmin and root the domain.
5. Ok, after that little trick a new command prompt opens up and once again check to see who I am. Ok, it looks like I’m still just the localadmin, but maybe I have covert super powers waiting to be used?
6. So let’s see if I can access the domain controller, shall we? Yes sir, the command prompt has the hash of sysadmin injected, so when I do a directory listing of my domain controller it now returns the results I’m expecting.
7. Directory listings are a bit boring, how about we try and launch Active Directory Users and Computers and create a new user account? Bingo, success! Now we could also remotely launch a hash dumper on the domain controller and extract the password hashes for pretty much every account account in AD.

To recap, I was a lowly delegated administrator and only had local admin rights on a single server in the domain. But because more privileged accounts logged onto the system, I could dump those hashes and escalate my privileges to a full blow domain admin. At this point I could create back doors, add new accounts, impersonate other user accounts, or download practically anything off the network. Total time to 0wn could be less than 30 seconds.

A few lessons can be learned to help mitigate this attack vector:

1. Do not give regular users local administrator rights on their domain joined computer. It’s pretty trivial for them to escalate their rights to full domain admin, given the right circumstances.  


2. Limit lower level help desk staff to non-administrator roles on servers and clients. Don’t think giving them admin rights on everything but domain controllers is safe or low-risk. They can be a domain admin in just a few seconds.

3. Only use your domain admin credentials to logon to domain controllers. Use another delegated administrator account to access member servers or client computers. This at least makes escalation a little bit harder. Remember, don’t use privileged credentials on less trusted computers.

4. Limit service account rights to least privilege, and NOT domain admin. If the service account, say for auditing software, accesses every computer in the domain then any local admin on any computer can impersonate anyone else.

5. Always have anti-virus software on your computer that may recognize the tools that I used in this demo and block them. Or, you could implement some type of white list/black list of applications on clients, but this has its limits.

6. Use Authentication Mechanism Assurance, a new feature in Windows Server 2008 R2. Marcus Murray has a great blog on how to implement this in the real world.

If you want to try this out for yourself, in a test environment, you can download runhash x86 here, runhash x64 here, lslsass x86 here and lslsass x64 here. Remember, these tools could get you fired or worse if you use them in an unauthorized manner.