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

Comodo FW v5 picked it up and auto sandboxed it.

 

I have tested this using both conventional disk based and memory based DLL injection. EIS/EAM behavior blocker will stop attempted memory injection attempt from unknown and unsigned source process.

 

This is correct. If the system's DLLs are whitelisted, then the Anti-exe program doesn't care what rundll32.exe does, as long as the DLL it calls is whitelisted.

Some years ago, an exploit was used in MSWord to call a malicious DLL which was renamed with the file extension bkx. If the Anti-exe program reads the code, then the file extension doesn't matter:



(The Anti-exe used here was Faronics AE2.)

It doesn't matter how the DLL attempts to intrude onto disk, it should be blocked. Below, I simulate a browser i-frame exploit to load a non-whitelisted DLL:



The writing to disk of unauthorized executables should be the easiest exploit to prevent.

Note that the above examples assume an exploit has gotten past my perimeter and attempts to run. At the perimeter, there are these entry points:

• firewall (eg: Conficker.A exploit via port 445)

• browser (plug-ins, etc. exploit)

• email links/attachments (trick to click exploit)

• USB (executables permitted to run from external media)

For Wilders personnel, is it likely something can intrude beyond these entry points?

----
rich

 

Remus! AE is unique in that it read the executable code and not the file extension. No other anti-executable has this capability. Also they don,t stop dll loading, however they do stop dll injection and copy/ create dll files etch.

 

Hi,

Could something be wrong with your test? Is your DLL an Executable File (contains executable code)? SRP will prevent unauthorized DLL loading.

Six years ago (time flies!) I had a Wilders Member test with SRP my MSWord hmmapi exploit which attempts to load an unauthorized version of the hmmapi.dll:

"Error in loading hmmapi.bkx. This program is blocked by a Group Policy."​

----
rich

 

@VoodooShield ：Thank you very much for your reply. But I still have some problems on this:

1. Would the only way to hijack a whitelisted application be executing another process to do the hijack? Would it be possible to do the hijacking like this: I open a malicious PDF file, then an exploit in Adobe Reader is then used to load an unknown dll?
2. If it is really essential to launch a process to do the hijacking, then why many anti-exe programs still prefer to monitor rundll32? I mean, if there are some malwares that can hijack rundll32.exe to execute malicious dlls even when an anti-exe program is installed, I guess they could do the same thing to the other whitelisted executable files, right?

 

I have read several places that whitelisting dll's has a severe impact on system performance. Isn't it more efficient and secure to whitelist the rundll32 command lines, and block all of the non-whitelisted ones? If not, we should consider adding whitelisting of dll's to VS 3.0, now that we have that capability. Thank you!

 

Yes, Yes. It really flies. BTW I still remember that I also probably tested it against HIPS but i don't have the sample any more.

 

Not sure what you mean here... specifically "AE is unique in that it read the executable code and not the file extension." I would be curious if you have a minute to elaborate.

 

Hi, @Infected . Thank you very much for your test.
Could you introduce some details in your test?
Particularly, which file is sandboxed by Comodo? The exe or the dll, or both of them?
Have you already changed to rating of the exe file to "Trusted", while keeping the dll file as "Unrecognized"?

 

Hi, @Peter2150 . Thank you for your reply.
Regarding your question, the dll actually needs to execute something. It at least needs to find out the current time. The time with some other contents will be returned to the exe file as a string.

 

1. I am not sure how to answer the first part, but I will do my best. We can assume that the whitelisted application is safe and does not contain malicious code, so it does not matter if it is theoretically hijacked or not, right? As far as a malicious PDF goes... The whole goal of an exploit is to run the payload, and to do this, it needs to have an executable payload or rundll32 command line to call the dll. I am assuming that all of the security products have these protections.
2. This is because rundll32 is the "partially whitelisted" executable that calls the dll, so we have to restrict what it does. Rundll32 needs to be whitelisted for certain functions (especially a lot of windows functions), otherwise there would be way too many blocks. But it needs to be restricted... this is a favorite tool of malware writers.

 

Hi, @Rmus .
Thank you for your introduction on Faronics AE2.

Yes, because it actually needs to execute something, like finding out the current time.
Would you be interested in the test files?
I can send them to you if you want, so that you could do some tests with Faronics and SRP at your convenience.

 

Hi, @VoodooShield . I am sorry but I still cannot understand. As long as rundll32 could be utilized by malware writers, why the other whitelisted applications would not be utilized by them to execute unknown dlls?

 

Hi,

I have read the same thing. I have not experienced any impact on my system performance with Faronics AE2. In an earlier post, Pete mentions this problem with a later version of AE. I tested up through v.3 and didn't experience that problem.

My only experience is this: years ago when I was looking for anti-exe types of products for home users, one was Process Guard (PG). There was a PG forum here at that time (now archived). One of the many complaints was dealing with rundll32: how to set up rules for it. Because of that, I opted for AE2 which automatically created a whitelist of every executable file on the system. There is nothing more for the user to do. That type of program appealed to me more. So, rundll32 can run, as long as the DLL is whitelisted.

Whether or not this method would work for your program, I do not know!

regards,

- rich

 

It's cool, I think you are overthinking it . A whitelisted app can either load a dll on startup, or it can use rundll32 with a command line to call a dll. If it loads the dll on startup, it does not need to utilize rundll32. However, if it has to make an outside call to rundll32 through a command line, then the command line is blocked, until the command line is whitelisted.

 

I received your test files and your DLL is an executable, because I cannot copy it from your folder to disk. Nor can I run your EXE.





I don't have SRP, but based on what I see above, there is no way that DLL is going to load on a system with SRP or any other similar protection.

----
rich

 

Yeah, I guess what they do is that any whitelisted program can call rundll32, which is pretty much what VS does, but it has taken a little while to get it right .

We can play around with dll monitoring and see it if impacts system performance or not. VS also automatically whitelists the command lines when it is OFF, and we have most of the commonly used command lines hardwired in, so the way we handle it now works pretty well for us.

 

I recall you tested against your (rather large!) collection of different security products -- one was GesSwall, I think.

----
rich

 

@VoodooShield , thank you for your reply.

So would it be possible for a whitelisted application to be utilized to load a malicious dll on startup?

@Rmus , thank you for your tests.
I notice that my exe and dll are all blocked with the reason "Copy".
But in #29, the malicious dll in your example is blocked with the reason "Open".
Could you introduce the difference between them?

Furthermore, could you add my exe file (calldll.exe) into the whitelist of Faronics AE2, and then test whether Faronics could block the dll or not in such case?
I mean, certainly we can block the exe file from running, but could we only block the dll file when the exe file is whitelisted?

 

Welcome . Sorry, I was referring to application startup (not windows startup). I do not see how that would be possible since we can assume it does not contain any malicious code, being that it is a whitelisted application . For example, if you have a whitelisted app that all it does is display a message box that says "Hello World", then that is all it will ever be able to do. It is not coded to do anything else.

 

Well I've tested it using SRP and also Malware Defender and neither would block dll loading. You can even rename dll to exe and it would still work and wouldn't be blocked by either. Try whitelisting exe with Faronics AE but not dll (if that's possible) and try to run it.

 

I tested SecureAPlus against this. After trusting the Exe file, it still blocked the .dll file.

https://www.dropbox.com/s/w9itoi8a7gm11q4/SecureAPlus.PNG?dl=0

 

Thank you for your tests.
But...why SecureAPlus on my virtual machine does not show such a block window?
Furthermore, as you can see, the string returned by the DLL are still correctly displayed in the console. So I think this means SAP fails in blocking the dll file, right?