Is Applocker really that good??

Discussion in 'other software & services' started by exus69, Jun 23, 2012.

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

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    Is Applocker really that good when most of the 3rd party exploits are contained within the programs already whitelisted in the program files?? For eg. Acrobat Reader, Browser Exploits, Office macros....

    Please explain
     
  2. JRViejo

    JRViejo Global Moderator

    Joined:
    Jul 9, 2008
    Posts:
    20,912
    Location:
    U.S.A.
    Moved Thread to this Forum for More Exposure.
     
  3. guest

    guest Guest

  4. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    So that means in the real world Applocker will save the computer from random installations from USB/CD ROM or random stuff downloaded from the internet (assuming standard user).

    However it wont help in case of Acrobat Reader or browser exploits coz they are whitelisted in other words if there is any hostile compiled executable code inside a regular pdf file then it WILL execute coz program files (where Acrobat resides) is whitelisted (path rule), is that correct?? So to mitigate them we've EMET, Sandboxie, HIPS, updated patches, image of the system...Am I understanding this correctly??
     
    Last edited: Jun 24, 2012
  5. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    For you first question:
    Yes, it will block. Additionally, you can block autorun using GPEDIT(there is a lot of talk here in the forum - search for).

    Second question:
    In the way you are describing, no, it will NOT execute. Let me try to explain (and sorry for the bad english):
    1) Lets say you are browsing and got hit by a drive by. The drive by will be save to ANOTHER place, not Program Files(remember you need ADM privileges to save here?), so when the malware try to execute (saved lets say, in TEMP), it will be blocked. The parent app have rights to execute, the child no.

    As we always say here, nothing grant 100% security by itself. There is another ways (discussed here in the forums too) to bypass Applocker. The thing is: What is the probability of you encounter something like this in the wild? Most probably it will be used in a targeted attack and not to do botnets and display ads to the user... For this you just need social engineering.
     
  6. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    s23, thanks alot for the explanation and your English is not bad at all :)

    One more question. I like the path rule way of configuring Applocker. Is there any compelling
    reason why I should opt for the Publisher rule way of configuring Applocker?? In what way
    Publisher rule method is better than Path rule method?? (Hash rules
    are out of question due to constant changes in the rules after updates)

    What say??
     
    Last edited: Jun 25, 2012
  7. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    Normally I configure a mix of Path and Publisher rules.. just to make things easy for me.

    I start with the default rules and remove the "All digitally signed Windows Installer files" from Windows Installer Rules. After I do a scan with AccessChk to check the exclusion I need configure for the Windows Folder rules (There is some folders there where a standard user can write). A common rule I create using Publisher is for Adobe Flash. It creates a random dll, so more easy configure with Publisher Rules.

    How you are configuring your machine with built-in security, I suggest you configure this in GPEDIT too:

    Computer Configuration>Windows Settings>Security Settings>Local Policies> Security Options:


    User Account Control: Only elevate executable files that are signed and validated = ENABLED.

    User Account Control: Detect application installations and prompt for elevation = DISABLED.

    Take Care!
     
  8. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    >99% of malware of exploits in the wild will attempt to download some other file (an executable) to give you a persistent infection. This file will be saved somewhere in User space, from which execution should be denied with Applocker. This will stop you from getting a persistent infection, but won't stop the malware script from running (i.e. it could log keys or snoop your files).

    Publisher rules are better because the digital certificate is checked, which for well known publishers is exceedingly rare to have an issue with (i.e. stolen private key, or "collision" attack).
     
  9. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    For that purpose I am using Mr.Brians method where he has already denied access to "everyone" group in certain parts of Windows folders. However, the problem is even Administrators are part of the everyone group hence I got a group policy block message when I copy a portable executable to say C:\Windows\Temp and try to execute it from there. Of course its not causing any hindrance to the Admin account but the Admin must have access to all parts of the system isnt it?? Is there a way to remove Administrators from "everyone" group?? Google did not help in this case...

    Can you please tell me how you did that?? Adobe flash is one of the very common attack vectors.

    That is a nice suggestion. Made a note of it :)


    But wont the Script rules in Applocker help in the above case??
     
  10. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    I not use it like this. I have a .txt file with my list of exclusion folders, but currently I'm not finding it... so I will show you a post from Mr. Brian with a list. I just add them to the exclusion and that's it. A more specific rule take precedence.

    https://www.wilderssecurity.com/showpost.php?p=1658968&postcount=30

    If I remember right, I used "FlashUtil32_11_2_202_235_ActiveX.dll" to create the Publisher rule, inside:
    C:\Windows\System32\Macromed\Flash

    PS: Not sure if flash still with this behaviour.. long time I not configure my OS like this... how I use Windows just to play games, currently I'm using just the default rules (without that one I mentioned in the first post) with Sandboxie free.

    Hope this helps.
    Take care!
     
  11. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    Hi s23,

    If you notice that post is made on April 14th, 2010. After that he has come out with an updated exclusions list on May 16th, 2010. Here is the link https://www.wilderssecurity.com/showpost.php?p=1679077&postcount=7

    I've configured my Applocker according to the link above. However, am facing the following issue while running as Admin.
    I've not disabled that path. How can I face this issue since am running as Admin I should be able to run any dll on the system isnt it??
     

    Attached Files:

    Last edited: Jun 27, 2012
  12. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    I just realized a grave mistake. I was giving explicit deny permissions instead of exceptions!! The images should make things clear.
    That has solved my above quoted problem.
     

    Attached Files:

    Last edited: Jun 27, 2012
  13. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    Nice. Congrats.
    I think your setup is completed.
    If you want, you run AccessChk to make sure all the folders are in the exclusion list. Depending of your software selection, can be another ones look for. I remember some time ago that Returnil created folders inside Windows with write permissions for Standard user (Corrected after).
     
  14. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    IIRC the script rules in Applocker are for particular, obscure scripting programs in Windows, eg powershell. It doesn't control the more common scripting approaches such as flash or java.
     
  15. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    That path is already covered in my path rule so I think there's no point in giving the publisher rule for that particular dll, is that correct?

    So to protect from flash and java script attacks we have NoScript, EMET, Sandboxie, LUA, HIPS...Is that enough or something more is required?? I know it's NEVER enough but when you combine all of that with the users "common sense" and "presence of mind" then it should definitely be enough :) what say ??
     
    Last edited: Jun 28, 2012
  16. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    Well, yes, if you throw the kitchen sink at it that would fix it :) Let's talk about each of those:

    Sandboxie: This will cover you no worries, but not necessarily against key loggers. Some will say "key loggers are covered because sbie blocks internet". We want to allow internet to many scripting programs, I would combine sbie with a properly configured outbound firewall (eg MS Excel should not be connecting to www.hereisavirus.ru).

    NoScript: I don't like this because it hoses my internet experience. I just use Chrome which is safe from browser scripts due to low privilege/isolated tabs.

    EMET: This protects against certain vulnerabilities that exist due to sloppy coding. At the moment I trust the Chrome team and wouldn't bother using EMET on this... everything else that faces the net and can run scripts will benefit from EMET. Don't need to bother if using sbie, except for things running outside the sandbox.

    LUA: The default for Windows now anyway. Plenty of damage can be done here still including logging of keys + internet access.

    HIPS: Policy HIPS, sure. Old-school HIPS with AppLocker? Wouldn't bother.

    Summary: I like Chrome, EMET, and firewall in conjunction with an anti-executable such as AppLocker. Add an on-demand/periodic signature based scan and you're good to go.
     
  17. exus69

    exus69 Registered Member

    Joined:
    Mar 15, 2009
    Posts:
    160
    It's very important in this case to have something like Applocker running
    because a keylogger running in user space can grab it!!
    With Applocker, the keylogger will be defeated in its very first move
    of "executing"...Sorry I mean second move...first move being able
    to write to a user allowed path/registry...

    Reply to the above.

    Source : http://hackademix.net/2010/08/01/al_9x-was-right-my-router-is-safe/


    But if EMET is running fine under SBIE then whats the harm in having the added protection without hogging memory??

    It's very important in this case to have something like Applocker running
    because a keylogger running in user space can grab it!!
    With Applocker, the keylogger will be defeated in its very first move
    of "executing"...Sorry I mean second move...first move being able
    to write to a user allowed path/registry...
     
  18. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    It's superfluous to use Applocker and Sandboxie together. I would just pick whichever one you like better. Similarly I would not use EMET on Sandboxed programs (it's ok for programs outside the sandbox). You get zero benefit in exchange for slightly more resource usage, more time needed to set up your system, and greater risk of conflicts.
     
  19. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    How would you get 'zero benefit' from using EMET with Sandboxie? By that logic no one needs to use DEP, ASLR, SEHOP if they can run a program in Sandboxie.
     
  20. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    That's correct.
     
  21. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Well that's silly.
     
  22. Wait, what? Is this because Sandboxie already applies some forms of memory protection to programs running under it? I thought Sandboxie was just... a sandbox?
     
  23. adrenaline7

    adrenaline7 Registered Member

    Joined:
    Apr 27, 2011
    Posts:
    128
    Sandboxie virtualizes and separates your applications like you would normally expect a sandbox to do, but I believe the paid version also allows you to run applications with the LOWEST rights it can possible run at in addition to the virtual sandbox. So its harder for apps to elevate and get the privileges necessary for most exploits to even work and even if they do you can delete the sandbox. So its like two layers of protection.

    I am not 100% sure on this but this is my understanding. I am a huge EMET fan, and I use it on my system, but I kinda agree with Melf that I don't think its particularly necessary to use EMET along with Sandboxie.
     
  24. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    The paid version just allows for automatic sandboxing and like... one other thing I can't remember.

    Sandboxie doesn't do anything in regards to memory protection like DEP or ASLR.
     
  25. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    It isn't a matter of getting zero benefit, IMO. It's more that the purpose of Sandboxie's concept is to keep what belongs in the sandbox, in the sandbox. So, if we take this as Sandboxie's principle, then Sandboxie will protect the user, even if some program (say, the web browser) gets exploited.

    From that perspective, is it really necessary to open a hole in Sandboxie to allow IPC with EMET? And, when talking about EMET, we're talking about everything else.

    Not only it wouldn't be necessary to open the hole, as EMET's protection would be futile inside the sandbox, and simply because the sandbox is already meant to stop whatever malicious action may happen inside the sandbox.

    When I say stop, of course I mean if properly configured to only allow specific processes to run inside the sandbox. Then, we're only left with memory malware (as in, malware not landing in the disk itself ;)), and this is outside of Sandboxie's protection scope. But, only to an extent actually. If the user uses different sandboxes or cleans the sandbox before doing important stuff, as he/she should, then what's the problem?

    Opening holes in a sandbox, for the sake of convenience or adding "extra" security, breaks the very same principle behind the sandbox.

    If people are not willing to sacrifice convenience, then they shouldn't be using Sandboxie in the first place. :D
     
Thread Status:
Not open for further replies.