Subscribe via Email

Subscribe via RSS


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Windows Services – Fix unquoted path vulnerabilities using PowerShell

At work as part of some security certification we are running Nessus scans on all our systems and it came up with the following vulnerability – link. Read that link, it’s good info.

Basically if one of your Windows Service entries point to (say) “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\SMSvcHost.exe” without the double quotes then one could potentially create a malicious file called Windows.exe at “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows” and Windows will execute that file instead of parsing the full path and treating it as part of a folder name. That’s because Windows uses space as a delimiter between a command and its switches & arguments and so it could treat the entry as “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows.exe” with arguments “Communication Foundation\SMSvcHost.exe“.

The solution for this is to find all such entries that contain a space, and if the path is not in double quotes then make it so. You have to do this in the registry, so you could either do it manually or make a script and do it en masse. I went the latter route so here’s something I created.

I am being lazy and not really offering input etc as I just expect a list of servers to be scanned in a file called “ServerNames.txt”. I have the above saved to a .ps1 file and I simply run it as .\Registry.ps1. Feel free to adapt to your needs.

What it does is that it connects to the server specified (provided they are online), tries to open the “services” key under HKLM (assuming it has access), and then enumerates all the subkeys that contain the service names and checks if the path has a space. It only matches against paths containing a .exe so it could miss out some stuff. Once it finds a match it extracts the bit up to the .exe, splits it along any spaces, and if there are more than one results (which means the path did have spaces) it encloses it in double quotes and replaces the original entry.

The code is smart enough to know it must correctly double quote something like "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe /V:4.6" as "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe" /V:4.6 and not "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe /V:4.6".

By default it only displays results. An optional parameter -FixIt will also make the changes.

Example output:

Hope it helps!

Windows – View hidden network interface IP address

Was troubleshooting something in VMware, I ended up copying the actual files of a VM from one datastore to another and re-adding it to a host (because the original host was stuck entering into maintenance mode and I needed this VM to sort that out blah blah … doesn’t matter!). Problem is when I did the re-adding and vCenter asked me if I copied or moved the VM, I said I copied. This resulted in all the network interfaces getting new MAC addresses (among other changes) and suddenly my VM was without any of the previously configured static IPs!


The old interfaces are still there just that they are hidden.

I used PowerShell/ WMI to list all the network interfaces on the server (this shows the hidden ones too).

In the Network Connections GUI all I can see are the last two adapters, so everything else is hidden. If I just wanted to delete them I would have followed the instructions in this post. (When following the instructions in that post be sure to enter set devmgr_show_nonpresent_devices=1 on a line of its own).

The ones starting with “vmxnet3” are what’s of interest for me so let’s focus on that. 

The reason I focused on SettingID is because if you check under HKLM\SYSTEM\ControlSet001\services\Tcpip\Parameters\Interfaces you’ll find entries with these GUIDs.

With a bit of PowerShell you can enumerate these keys and the IP address assigned to it:

My PowerShell skills are getting worse by the day due to disuse so the above is not probably the most elegant way of doing this. :)

Anyways, by comparing the two outputs I was able to identify the missing IP as either or The latter was of a different network so it looked like an older hidden adapter. I set the former, and as expected the network started working. Yay!


Solving “Btsync:// Protocol Not Available” errors (or how to register a new protocol in Windows)

I have BitTorrent Sync. It was installed a long time ago and automatically updated over the years. I guess the initial installs never registered the Btsync protocol because today I emailed myself a link to a shared folder on my phone and when I clicked the link on the computer nothing happened. I was using Chrome so I tried it under Internet Explorer and Firefox. The former gave the error above, the latter said the address wasn’t understood and explained that it doesn’t know what program to use for the btsync protocol. Good, at least these were clearer on what the issue was. (Moreover Firefox even showed the full address in the address-bar – btsync:// – kudos to it!)

I haven’t added a new protocol/ extension to Windows for a long while, and while I could modify the protocols/ extensions for existing entries under “Default Programs” in the Windows control panel (I am using Windows 8.1 Update 1 by the way) there was no option to add a new protocol. Never mind, it’s possible via the registry. See this link on more details, the upshot of it is that you can create registry keys under HKEY_CLASSES_ROOT to register new protocols or file extensions. Below is what I created for Btsync, copy paste this into a text file with the extension .reg, change the program paths if your installation is in a different folder (quite possible if you have the 64-bit version for instance), then double click the file and say OK to importing it. 

That’s it! Now BitTorrent launches as expected. Hope this helps someone …

Tip: Overriding a GPO setting via Registry

At work our Desktops team has put a policy in place that enables Outlook cached mode for every one. Which becomes a pain in the a$$ when you have to disable and enable cached mode for some users as part of fixing issues (OST file corruptions, no incoming emails, etc).

Thankfully this is a setting you can temporarily override via the registry. Just got to modify a key under HKCU.

But … if you open the registry as the affected user and try modifying the key, you can’t because of lack of permission. Expected, right? What’s the point of a policy if users can modify the registry directly to override it. Admin users can modify the key, but if you open the registry as an admin then HKCU points to the admin and not the user.

Here’s how you workaround though: open the registry by doing a “run as” as the admin. Then go to HKEY_USERS. One of the entries there will be for the user logged in. (There shouldn’t be many entries, but if there are then you can find the one you want in one of two ways: (1) Use psgetsid from the Sysnternals tools to find the SID of the logged in user. That’s the entry you want. Or (2) go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. You will find entries there with the same names as under HKEY_USERS. Check the ProfileImagePath key in each – the one with the path to the logged in user is the key you want).

Once you find the key of the logged in user under HKEY_USERS that’s it. Everything under here is the HKCU of the logged in user so any changes you make here reflect HKCU. Go ahead and change whatever you want – the change will succeed because you are now using an admin account to make changes to the logged in user’s HKCU. Hah!

Hope this helps someone.

Recreating Windows profiles; Internet Explorer passwords

I had to recreate a user’s Windows profile the other day and made the novice mistake of removing the profile from his computer by just deleting the folder from c:\Users. Not a good idea coz that leaves all the registry stuff behind. The correct way to remove his profile would have been to go via the System properties, User Profiles, and then delete the profile. If it complains about the folder not being removed, then remove the folder.

What happened in my case since the registry stuff was still leftover is that Windows wouldn’t create a new profile folder because it thought the profile folder had an error. It kept logging the user in with a temporary profile and complained so: “You have been logged on with Temporary profile”.

Worse, I always thought HKEY_USERS was where all the registry stuff was stored so that’s where I kept looking to try and delete the registry bits manually. Finally I realized it’s under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList – doh! HKEY_USERS only has the registry hives for actively loaded profiles – not necessarily the one logged in interactively, but also user accounts running in the background or that have recently run (via “run as” etc).

So I went to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, found the profile (which now had a .bak suffixed to it), deleted it (because I want him to start afresh), and that got things working again.

After recreating the profile the user told me he wanted his Internet Explorer saved passwords. These are stored under HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 but I hadn’t saved his HKCU hive before deleting the profile. Not a problem – I had a backup of the profile folder, so I:

  1. Copied the NTUSER.DAT file from there to my computer (NTUSER.DAT is basically the HKCU hive for his account),
  2. Loaded it into my registry as a temporary hive,
  3. Exported ...\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 from this temporary location to a .reg file,
  4. Opened this file in notepad and renamed the root to HKEY_CURRENT_USER.

I then sent the .reg file to the user and once he opened it the passwords were imported into his registry.

Here’s the command I ran from an elevated command prompt to load the ntuser.dat file to a temporary location HKLM\TempHive:

Using the above temporary location, I had to rename HKLM\TempHive to HKEY_CURRENT_USER once I exported the key and opened in notepad.

How to get a list of COM objects from the registry

Today I was looking for the COM ProgID for Excel on my machine and my previous approach of using WMI didn’t work.

That’s not correct as I can create a new COM object by referring to Excel.Application.

Since ProgIDs are found in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Classes I figured that would be a good place to get an exhaustive list from. Under this key there are three types of subkeys:

  1. Subkeys for each file extension registered with the system, each of which has a (Default) entry with the ProgID and also a subkey with the ProgID. Not all these ProgIDs seem to be valid though (based on my testing), so it’s best to go by the other set of subkeys detailed below.
  2. Subkeys for each ProgID – usually of both ProgID formats <Program>.<Component>.<Version> and <Program>.<Component> – again, not all valid, but a good test of validity (based on my testing) being whether they contain a subkey called CLSID.
  3. Subkeys such as “Unknown”, “Undecided”, etc and also some that look like ProgIDs but are not in the correct format (for instance: they don’t contain the <Component>.<Version> bit, or contain spaces and underscores (not allowed)

So a sensible way to filter out ProgIDs seems to be to check for subkeys of the format <Program>.<Component>.<Version> (the <Version> being optional) and to further filter out those which have a CLSID subkey.

Thus we have the following:

And to search for a specific application, one can do: