Could anti-exe programs prevent applications from executing unknown dlls?

Discussion in 'other anti-malware software' started by Online_Sword, Sep 26, 2015.

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

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    As far as I know, dlls also contain executable codes. So I am curious about whether anti-exe programs could prevent applications from executing the codes in unknown dlls.
    It seems that nearly all anti-exe programs would monitor rundll32.exe, which means that they could stop rundll32.exe from loading unknown dlls.
    But what would happen if an application rather than rundll32.exe (like the browser) is hijacked (if possible) to execute unknown dlls? Could anti-exe programs prevent this?

    To see this, I write a very simple dll in C# which only could return a string, and a simple exe (in C# as well) to execute the dll and display the string on command-line console.
    Here I test AppGuard (trial), Bouncer (demo), Exe Radar Pro (beta), SecureAPlus (prenium).
    In particular:
    • AppGuard is set in the Lock Down mode; I add the exe file into system space, while leave the dll file in the user space;
    • Bouncer is set in the Lethal mode; I add the exe file into whitelist, while add the dll file into the blacklist;
    • Exe Radar Pro is set in the Lock Down mode; I add the exe file into whitelist;
    • SecureAPlus is set in the Lock Down mode; I set the trust level of the exe file to "Trusted Application", while the dll file is set to "Not Trusted";
    In any of these tests listed above, the exe file could display the string correctly.
    Does this mean that anti-exe programs cannot prevent applications from executing unknown dlls?
     
  2. Arcanez

    Arcanez Registered Member

    Joined:
    Oct 5, 2011
    Posts:
    396
    Location:
    Event Horizon
    you should do another test with faronics anti-executtable. It has DLL protection built into it. If enabled it costs a bit more performance, however I'm curious about your results
     
  3. Brummelchen

    Brummelchen Registered Member

    Joined:
    Jan 3, 2009
    Posts:
    1,736
    i do not recommend such control. if only few libs were loaded, but modern programs use more libs, in most cases standard libs (qt, dotnet aso). to avoid injections tools like MBAE are first choice. HTH

    PS i remember "Malware Defender" HIPS, any external action with a lib call has its own function. but it was to complicated to determine all by mind so MD has a learning mode for trusted apps. thats the intention about - trusted apps are ok, if you dont trust, forget it, uninstall. any other behavior i would call port of "paranoia".
     
  4. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,088
    When I'm using SRP I have control over dll loading enabled also. Sometimes SRP blocks non-whitelisted dlls but I don't know which function it is covering.

    Malware Defender mentioned before had dll loading allowed by default, probably to prevent many popups and large rules database.
     
  5. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    @Arcanez
    Hi. Thank you for your suggestion. I might test it later.

    @Brummelchen
    Hi. I do not want to take a fine granular control over all dlls, since in fact I am not paranoia.:p I only hope to know whether it is possible to prevent exe files inside the system space from loading un-whitelisted dlls in the user space. I guess such a limitation would not interrupt the applications seriously (I should say I am not sure about that:D).

    @Minimalist
    Hi. Just now I have tested SRP (Software Restriction Policy). Particularly,
    • In the dialog "Enforcement", I change the option "Applying software restriction policies to the following" from "All software files except lib files (such as DLLs)"(Default) to "All software files"
    • In the dialog "Designated File Types", I add "DLL" into the list.
    • The exe files is set to "Unrestricted", while the dll file is set to "Disallowed".
    Result: :(The exe file still can display the string correctly.
    I guess this means SRP might unable to prevent dll loading as well.
     
  6. Infected

    Infected Registered Member

    Joined:
    Feb 9, 2015
    Posts:
    665
    Can you show the screen shots of it being bypassed? Might try smart object blocker.
     
  7. flatfly

    flatfly Registered Member

    Joined:
    Aug 25, 2010
    Posts:
    66
    Yes, i believe Smart Object Blocker should be able to block it.
     
  8. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,640
    Location:
    Toronto, Canada
    @Online_Sword I am also curious about the type of testing that you are doing. This is very interesting.

    Just to confirm, the executable itself when run (without the DLL) does not contain or display the test string? So the test string is only contained within the DLL? And it is that specific executable that is calling that specific DLL (and not some other built-in Windows executable)?

    Would you be willing to share this test executable and DLL? I am interested and curious about this testing scenario as well. I am wondering if certain things like hash-based might work better and so on.
     
  9. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    Hi, @Infected . Hi, @flatfly . In the past, I have not ever tried SOB.
    Just now, I install it on my virtual machine.
    At first, I hope to know whether it is installed properly.
    So I write a rule into the Process.DB file in the "Smart Object Blocker\Block" folder as follows:
    And then save it.

    The problem is...I can still launch ABC.exe...I don't know what happened...

    @WildByDesign
    Hi.
    Yes. In fact, the executable file will corrupt when it fails to load the dll.:p This is just a small test so I have not written any code to handle the exception...So it simply corrupts.:D
    At first I plan to upload it to share it, but wilderssecurity says that "The uploaded file does not have an allowed extension."
     
    Last edited: Sep 26, 2015
  10. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,640
    Location:
    Toronto, Canada
    @Online_Sword You would have to upload to an external file hosting site. The best thing would be to add the executable and DLL to an archive file such as .zip or .7z, good idea to password protect the archive as well to prevent file hosting sites from taking it down thinking that it could be a virus. Then share the link here if possible. If that is not allowed, you might have to just share link as PM to whoever asks you. Thank you.
     
  11. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    Thank you. I have sent you a PM.:)
     
  12. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    Anyone who is interested in the test files, please send me a PM.;)
     
  13. ifacedown

    ifacedown Registered Member

    Joined:
    Oct 12, 2013
    Posts:
    120
    Location:
    Philippines
    What about Voodooshield?
     
  14. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    @Infected @flatfly: Hi, just now I finally make SOB work.:D
    I mean, now I successfully block some exe files from running.

    :(Sadly, it seems that SOB cannot block the dll, either.
    The name of my dll is "HelloDll.dll".
    I put the following rule in DLL.DB:
    But the exe can still display the string returned by the dll correctly.

    @Infected , I think you can reproduce it with SOB and the test files I sent to you...

    @ifacedown: I have not tested VS yet, and I would do this later.:)
     
  15. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,055
    Location:
    The Netherlands
    Yes, I remember that some HIPS added this feature but for me it was too intrusive, I don't see the need for it. You should worry more about dll-injection, a technique used by most advanced malware.
     
  16. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,640
    Location:
    Toronto, Canada
    @Online_Sword Thank you, I appreciate that. I am doing some preliminary testing right now with your test files. And I think that it's a good method to test and see since malware could easily utilize something similar. This will help all of us, using different anti-exec/app whitelisting programs, to test our rule sets and make rule changes accordingly.

    My preliminary testing so far has been with regard to Bouncer at the moment. Some key points that I've noticed so far:
    • Enabling Parent Checking feature made quick work of blocking this.
    • Under regular Bouncer [BLACKLIST] section you could also add *mscoree.dll to achieve similar blockage, blocking .NET execution.
    • The separate drivers for MemProtect and CommandLineScanner provided more granular control to block this.
    In this regard, it's good to see that Bouncer, in particular, has added Parent Checking to the current Beta which adds more granular control overall. But also, it would be good to see if the developer can add the CommandLineScanner driver's functionality into the main Bouncer driver for even more granular control.

    I would like to do some testing with SOB later as well but likely wont get time until Monday. If I get time sooner, I will post results. I'm certain that SOB will block it as well but will need some specific rules.
     
  17. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    @WildByDesign : Thank you very much for your tests.:thumb:

    Does this mean that, if the DLL files are written in C or C++ rather than C#, then we only have to use the Parent Checking feature to block them? (Sorry I know little about MemProtect and CommandLineScanner...)
     
    Last edited: Sep 26, 2015
  18. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,088
    I've tested it using SRP and Malware Defender.
    I could not block it by SRP no matter how I set it up.
    With Malware Defender I also didn't get notification about your dll. But I got notification about loading this libraries:

    upload_2015-9-26_19-38-48.png
    Maybe some function is used that MD is not monitoring? Or might it be the problem that .NET is used?
     
  19. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,088
    One more thing. I'm not a programmer but it looks like that dll is not loaded normal way. If you rename your dll file to HelloDll.exe you still get the message. Is this normal?
     
  20. VoodooShield

    VoodooShield Developer

    Joined:
    Dec 9, 2011
    Posts:
    4,876
    Location:
    United States
    Sorry to chime it here, but a user asked me to give my 2 cents. I know your query is hypothetical (and interesting) ;), and it is fun to think about.

    Really what it comes down to is this. Something has to call a dll for it to execute. If a whitelisted executable calls a dll then you WANT IT TO BE ALLOWED (in general), otherwise it can cause serious issues with other software, as Rasheed187 suggested.

    However, if the executable is not whitelisted but still perform a dll injection, that is a totally different story... Assuming other built in protections to the security app does not block it first.

    Here is some interesting reading: http://stackoverflow.com/questions/124549/what-exactly-are-dll-files-and-how-do-they-work
     
    Last edited: Sep 26, 2015
  21. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    @Minimalist : Thank you for your test.
    Yes, this is also what I found.:)
    I am not sure about that. I should say that I know little about the mechanism of C#...
    It seems that using C# to write the test files is not a good idea -- this makes our problem more complicated.
    Maybe I will rewrite them in C or C++ later.
    Em...I do not think it is normal.
    Just now, I tried to remove the extension of the dll file, and to give it a random extension. But in such cases, CallDll.exe corrupts.
    It seems that only the original extension (dll) and the "exe" extension work. I don't know why...
     
  22. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    Thank you for your reply.:)
    My problem is that, would it be possible or not that a whitelisted executable file is hijacked to execute an unknown DLL (in the user space) that any whitelisted executable actually DO NOT depend on?
     
  23. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,640
    Location:
    Toronto, Canada
    I can't say for certain because I am not a programmer and have no knowledge of programming languages. But what this simple test reminded me of is, for example, have a whitelisted browser such as Chrome or Firefox, and for example add the Flash Player .DLL files to the blacklist during times of Flash exploits active in the wild. That is what came to my mind. But oddly, in those scenarios, the Flash .DLLs were blocked without any problem.

    MemProtect and CommandLineScanner are just other projects of kernel-mode drivers made by the same developer as Bouncer. Similar purpose of a single-purpose, small yet efficient kernel driver.
     
  24. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,047
    Location:
    Saudi Arabia/ Pakistan
    Hi, malicious dll loading is not intercepted by classical HIPS. The reason is obvious. It will give literally hundreds of pop up alerts that is practically not feasible to deal with by any user. ( Malware Defender and older version of Comodo Defence Plus had this function but it was disbled by default atleast in Comodo).

    Online Armor added some interception for this but I am not sure how effective was this. Comodo people promised to fix this issue with some better alternative but they could never do it.

    Recently I read some where that some HIPS( ESET HIPS? ..not sure) have solved this issue by allowing any executable to allow to load ONLY white listed dlls( by using a a builtin white list of dlls for any white listed exe) but I am not sure how robust this solution is.

    In the past, I have done some testing with this as well.
    https://www.wilderssecurity.com/threads/dll-exploit-lnk-exploit-mitigation-by-hips.284188/
     
  25. VoodooShield

    VoodooShield Developer

    Joined:
    Dec 9, 2011
    Posts:
    4,876
    Location:
    United States
    Not that I can think of... First of all, the process that is doing the hijacking has to be whitelisted before it can even execute. Then if it can execute, it is limited to code and functions of the executable that it could somehow hijack... so why would it do this? I mean, if it can execute, then it would be a lot more efficient to simply run its own malicious code. This is why whitelisting is so powerful... It is kind of like the old saying "what comes first, the chicken or the egg?".

    BTW, I have seen some pretty malicious dll's in the past that did a lot of damage, that were spawned through a rundll32 command, so that is a concern. But I imagine that all of the products in your tests protect against this type of an attack.
     
Loading...
Thread Status:
Not open for further replies.