Our IT Security lead asked me today how many people had installed "DropBox" (a file sharing/syncing app). So I pulled up my Add/Remove programs report, plugged in "%Drop%Box%" as a search term, and promptly was given "No results". "GREAT!" I thought, "another potential data leakage source not being exploited!" But then I got to thinking (which I do now and again...). So I went to www.dropbox.com and installed the app, then checked the Add/Remove Programs applet in Control Panel and saw Dropbox listed there. Then I reran Software Inventory to update the Add/Remove Programs inventory on my machine. I was rather surprised to discover that Dropbox did not show up in my inventory, even after purging the local .bak files. On some deeper digging I checked the registry and found that the Uninstall info for this app actually lives under the HKEY_CURRENT_USER key (or HKEY_USERS to be more precise, at HKEY_USERS\S-1-5-21-....\Software\Microsoft\Windows\CurrentVersion\Uninstall\Dropbox). I also found a module for our Cisco desktop conferencing application, and Google Chrome living in this little less-frequented-corner of the registry, both of which also do not show up in the AeX_OS_Add_Remove_Programs dataclass! Running a seach of Inv_AeX_SW_Audit_Software turned up quite a few instances of dropbox.exe with a ProductName of Dropbox, and all of them living happily in C:\Documents and Settings\<userid>\Application Data!
So now what? Well in the short term I tell my IT Security Lead that in fact we do have quite a few installs of this app in our environment. In the long-term, I wonder why Symantec doesn't inventory this section of the registry which seems to be targeted more and more by sneaky applications trying to by-pass restricted user rights, and add to my task list developing a little script to augment the built-in Add/Remove Programs inventory by also parsing the user-specific uninstall keys for each user and insert those into the existing AeX OS Add Remove Programs.nsi file prior to posting it back to the NS. If and when I get around to writing that, I'll be sure to post it back here to Connect to help out the rest of you.
There actually nothing "sneaky" about the Add/Remove Program (ARP) entry going into the HKCU hive.
Any installation which uses MSI technology can be installed either "Per machine" or "Per User". A default behaviour can be determined by setting the ALLUSERS property to 0 for per-user or 1 for per-machine installs.
A per-user install has the following basic characteristics:
1. The shortcut(s) goes into the installing user's start menu rather than the "All Users" start menu, so is only available to that specific user on that PC.
2. Any installed DLL files are registered in HKCU/Software/Classes instead of HKLM/Software/Classes (these two hives are merged to give HKCR, with HKCU given priority over HKLM where there is a conflict)
3. The ARP entry is registered in HKU/<user SID>
A per-machine install has the following basic characteristics:
1. Shortcuts are put in the All Users profile
2. DLLs are registered in HKLM/Software/Classes
3. The ARP entry is registered in HKLM
Per-Machine installs always need Admin rights to install, Per-User installs may also require admin rights to install if restricted areas need access to install files, but otherwise it is possible to deploy some stuff to areas where users have full rights.
Since MSI technology was released back in 2000, this behaviour has been well known and had remained essentially unchanged for at least a decade. However, if the audit or inventory tool runs as a system process, it has no access to the user's registry hive (unless it can scan HKU) and if user profiles are redirected to a server share then again the content in their profiles may not even be present on the box for the inventory to detect.
So the only way to avoid having this problem is to block all users from installing software themselves, or to make sure that your inventory process includes scans of the user profile which may involve something running from a login script, or a process that is kicked off by a RUN statement in the user part of the registry.
Any updates on this one?
Thanks for posting this! It's really good to know in case I run into something like it. Please do post your update if/when you create it. Thanks again.
Glad you are highlighting this issue, software is increasingly being written to be installed without admin rights into a user’s profile (Chrome, Firefox, Spotify etc), then there is portable versions of software that is completely self contained, anything that can help with identifying with these installs, would be a useful addition. We use Application Metering to block the aforementioned software.