Are the User directories a security concern?

Because of this recent thread and others similar to it, as well as through my own experience, I pose this question to those of you who utilize an anti-executable approach or similar in your security setup.

Some very common installers and programs such as Flash and Firefox liberally place files in user directories (%APPDATA% path variable), in many cases the files being temporary in name and/or location as well, which is why I've had to use wildcards in several of the rules, otherwise management of them would be an ongoing nightmare.

Some examples given that I have created AppLocker rules for:

-C:\USERS\user_name\APPDATA\LOCAL\ROBLOX\VERSIONS\VERSION*\ROBLOXSTUDIO.EXE (Roblox player)

-C:\USERS\*\APPDATA\ROAMING\ADOBE\FLASH PLAYER\NATIVECACHE\*\*\ADOBECP*.DLL (Adobe Flash)

-C:\USERS\*\APPDATA\LOCAL\TEMP\*.TMP\APPASSOCREG.DLL (Firefox)

-C:\USERS\*\APPDATA\LOCAL\TEMP\*.TMP\CITYHASH.DLL (Firefox)

-C:\USERS\*\APPDATA\ROAMING\MOZILLA\FIREFOX\PROFILES\*.DEFAULT*\EXTENSIONS\SUPPORT@LASTPASS.COM\PLATFORM\WINNT_X86-MSVC\COMPONENTS\LPXPCOM.DLL (LastPass plugin)

As you can see, the .DLL files are the worst! It is for this reason I feel the way some of these programs utilize these directories makes it challenging to prevent the unauthorized launching of executable file types. The article from the thread I linked to is a good example of this.

BTW, I realize the most secure approach is to authorize based on Hash or Publisher rules, but many of these files are not digitally signed, so that rules out the use of Publisher rules. Hash rules can be used but they are a major PITA to manage because the hash changes every time the file is updated, requiring the Hash rule to be manually updated.

Anyway, I'm wondering how others who use anti-execs and HIPS handle files located in these directories? Are they a concern for you? Just looking for some ideas.

 

I don't have any rules allowing in such paths, simply because I'm not using (currently) any application that places such file types in user space. But, when I had, I would allow them by hash value.

Yes, it's a PITA, but it pays off. I would never trust in a Publisher rule in a day and age where malware authors are using digital signatures (stolen or otherwise) to bypass security measures.

The only side down to something like AppLocker (something we both use) is that we have to fetch the files manually (from within it). It could have have a Refresh option. I wonder why it hasn't? I mean to manually refresh the hash values, not automatically.

 

Yes, a refresh option would be huge time saver. Unfortunately, I just don't have the patience anymore to manually update them anymore

One thing I'm noticing so far with XP Pro, is that these programs don't seem to utilize (abuse) these directories the same way they do on Win 7. I might have more on that later, but so far I've been able to outright deny execution of executable in the %APPDATA% profile with no issues yet.

 

One option would be to use PowerShell. It does have some built-in commands to deal with AppLocker. I just never bothered with it, though.

Some links:

-https://blogs.msdn.com/b/powershell/archive/2009/06/02/getting-started-with-applocker-management-using-powershell.aspx?Redirected=true

-http://technet.microsoft.com/en-us/library/ee460962.aspx

-http://technet.microsoft.com/en-us/library/ee791828.aspx

There may be some overlap, but I had them in my favorites.

 

That looks pretty nifty, thanks! The one problem I could foresee are those infuriating temp directories that seem to take on a different name on a random basis, like the Adobe ones. Anyway, I think I'll probably just take my chances and just stick with the Path rules, since I'm getting too lazy to spend much time on administration tasks

 

I apply Software Restriction Policy to all files including .DLLs on about 10 Win7 Pro and Win8 Pro systems, plus Windows Home Server 2011, and have no conflicts on my systems, with one exception: at work, I made a Hash Rule to permit a specific .DLL file used by QuickBooks 2011. Nothing terrible was happening when SRP blocked the .DLL, but it kept creating a Windows error message daily that confused our elderly bookkeeper. I fix, I fix!

If software is being installed into the user's directory, that just needs to stop. One known offender is Google Chrome, but you can get the "corporate" .MSI-based installer and get it installed into the Program Files directory.

I haven't dabbled with AppLocker, partly because SRP is supported by all the Pro/Business versions of desktop Windows since XP Pro, whereas Applocker is only supported on Win7 Ultimate/Enterprise and Win8 Enterprise.

 

AFAIK, "regular" Chrome now installs in Program Files directory.

 

Thanks for the update, that's good news

 

I agree, mechBgon. BTW, good to see you at Wilders

Actually something I've just discovered is that all those %APPDATA% DLL rules I have for Firefox may not be needed any more! I remember getting AppLocker event viewer alerts for those files soon after I installed Firefox v19, but in checking the logs this morning after running the browser for a while, I don't see any of those files in there, so those rules with Temp directories may just be only "temporary" after all. I've backed up the AppLocker config and deleted those rules, and will monitor. Hopefully I don't need them any more.

 

I wonder if that's to avoid UAC prompts. When Chrome used to install itself in the Users path, it could update itself silently and automatically with no approval needed. Now, I get a prompt and have to approve it before it will update.

 

Fraudware and scareware began installing to the user's directory for that reason as an adaptation to the post-WinXP landscape, where people were (at worst) Protected Admins by default, and possibly even Standard Users. Unless they're using Parental Controls, SRP or AppLocker, installing to the user's profile will work, at least once the installer manages to get to the user's privilege level (i.e. not caged by sandboxing/Protected Mode).

 

With all the AppLocker design issues and possible bypass flaws that have been discussed on this forum, I decided that I don't want to bother myself with too much AppLocker maintenance. Instead, I wanted a rule-set that's simple to import-export and update if the need arises.

Thanks to MrBrian and his posts, that was made easier than I initially expected. I set it up so that it's somewhat similar in fashion to using default-deny SRP with Path rules (covering the potential loopholes by checking with AccessEnum). That way, I can easily run programs as Admin whenever I want to...

In addition, I have a few other custom rules such as blocking PowerShell (since I don't use it and there were issues brought up by moonblood)
and Countermeasure against "Spoofed filenames in Windows using the RLO (Right-to-Left Override) Unicode Character"

 

Yup... and I dig your sig: SRP fan boy. Awesome measure indeed. Though I haven't eliminated "all" loopholes, I run one that's a great balance of security & convenience for me, making some concessions. I like to call it a user friendly default deny policy.

And also a safe admin account, that is practically like a pseudo-LUA. Between SRP, LUA, GP/LP, folder permissions, etc... I used to lock everything down like fort knox. But then found it just too restrictive, unnecessarily so considering my usage. So I trimmed it back to strike a balance of convenience & security. It can be a tight rope walk sometimes.