Are the User directories a security concern?

Discussion in 'other security issues & news' started by wat0114, Mar 6, 2013.

Thread Status:
Not open for further replies.
  1. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,985
    Location:
    Canada
    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.
     
  2. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  3. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,985
    Location:
    Canada
    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.
     
  4. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  5. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,985
    Location:
    Canada
    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 :)
     
  6. mechBgon

    mechBgon Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    68
    Location:
    USA
    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! :p

    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.
     
  7. new2security

    new2security Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    492
    AFAIK, "regular" Chrome now installs in Program Files directory.
     
  8. mechBgon

    mechBgon Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    68
    Location:
    USA
    Thanks for the update, that's good news :thumb:
     
  9. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    1,985
    Location:
    Canada
    I agree, mechBgon. BTW, good to see you at Wilders :thumb: :)

    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.
     
  10. SirDrexl

    SirDrexl Registered Member

    Joined:
    Apr 14, 2012
    Posts:
    545
    Location:
    USA
    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.
     
  11. mechBgon

    mechBgon Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    68
    Location:
    USA
    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).
     
  12. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,718
    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"
     
  13. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    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.
     
Loading...
Thread Status:
Not open for further replies.