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

IDK, I thought it showed the .dll blocked? But maybe not. Just going by what the popup said. I'm not experienced with this.

 

Em...I do not think so.
Let's see it. Suppose I have a whitelisted application called "A.exe", it loads a dll called "B.dll" to do something on startup. In particular, B.dll has a function with name DoSomething.
Then, maybe, a malware writer could write a malicious dll with the same name and providing the same interface (DoSomething). But the body of the function DoSomething in this dll certainly contains some malicious activities.
Then the malware writer might be able utilize an exploit of "A.exe" to load the bogus dll ("B.dll") and execute the function DoSomething...Wouldn't this be possible?

 

AE2 has "Copy" protection. When I extract a file from RAR to disk, I am "Copying" it to disk. In a home situation, this prevents kids from downloading games, etc, without parents permission. It also prevents malware from getting onto disk.

I disabled Copy Protection and extracted your files to a folder. Now, if I attempt to execute CallDLL.exe, the file is blocked from running ("Open"):



I disabled AE to see what would happen when I attempted to execute your CallDLL.exe: an error message displayed:




----
rich

 

Since I cannot run your EXE file, I attempted to access your DLL from a command prompt, and it failed.



----
rich

 

Hi Pete,

Yes, I'm on WinXP.

I don't understand your comment. What do you mean "would run?"

----
rich

 

Have you tried the Mac voice commander?!!

Yes, that is a shame.

 

It won't run on Windows XP. It needs Net framework 4 installed to run. It does run on Windows 7 x86 though.

 

If this dll is being loaded on startup of the whitelisted, then it should NOT be blocked. But if it is calling the dll through rundll32, then it should be blocked. It really is that simple.

For example, VS loads 3 or so dll's on startup, as do all of the other security products (I would assume). If you run some of these at the same time, they do not block each other's dll's, correct?

It all comes down to this... if an application is whitelisted, it should not be restricted in any way. I know some security products do this, but it can cause serious problems when whitelisted apps cannot load the dlls they need, and it increases the number of dangerous affirmative user prompts.

I know there is a lot of greyware out there now, but ultimately either an application contains malicious code or not. This is somewhat subjective because something that may be malware to me, may not be malware to someone else (to a certain extent). But by whitelisting an application, you are trusting it... trusting it that it does not contain malicious code. And if it is trusted, then it should not be restricted in any way. "Do or do not. There is no try" .

Now, if an application can be exploited to spawn an unknown process... then that is a different story, but that is why everyone should use whitelisting of some kind .

How is the .dll being called? Can someone send me the test file to support@voodooshield.com?

 

If the DoSomething function contains malicious code, then A.exe never should have been whitelisted in the first place . What comes first, the chicken or the egg?

If you send me your sample, I can take a look at it.

 

+1
Thanks

 

Sorry, but I think you might misunderstand my opinion.
In my scenario, in the original version of B.dll, DoSomething contains NO malicious code. But a malware writer might create a FAKE B.dll, which contains the same interface (function head) as the original one, but contains malicious codes (function body).
Then, the malware writer might utilize an exploit to hijack A.exe to execute the fake B.dll, rather than the original one.
In such case, I am afraid that the malicious codes will be executed. But A.exe is still innocent. So we cannot say that A should be blacklisted.
And I think one approach to avoid this is to build a DLL whitelist based on the path, the vendor, and the Hash code.

Gmail does not allow me to send any executable files, so instead, I will PM you a download link.

 

Hi, @UnrealPc .
I am unable to PM you...I don't know why...
Maybe you can try to PM me?

 

Sure, thank you too Pete! These scenarios are fun to think and talk about... you never know, we might find a bypass this way .

 

PM doesn't work for me too. I tried since this morning to send you a pm but this function is still unavailable for me.
I'm a new member here, maybe i must reach a certain number of posts for sending pm.
I have no idea

 

As best as I can determine, no anti-exec is going to prevent you against memory based dll injection; especially if it is shell based. This is the dll injection method most of the current malware is using. There are memory based dll injection techniques that can even hid the memory based injected dll in the target process.

Ref: https://disman.tl/2015/01/30/an-improved-reflective-dll-injection-technique.html
http://blog.ioactive.com/2012/06/inside-flame-you-say-shell32-i-say.html

 

Assuming that B.dll could be replaced... the malware writer would not even have to "hijack" A.exe with an exploit... if A.exe calls a certain function in a dll, then all they would have to do would be to run A.exe. The problem is, how do you replace B.dll without running whitelisted code?

I do agree that whitelisting dll's based on name, path and hash (the way VS already whitelists exe's) would technically be more secure, and now that VS 3.0 is using the mini-filter driver, we have that option. The question is... does implementing such a mechanism actually increase security, and does it outweigh the cost of a potential system performance hit. Besides, it can also cause problems whenever dll's are updated by legitimate software... they would need to be whitelisted again since the hash does not match. And since most computer users have no idea whether to allow the new dll or not, it is better to not prompt them. VS's goal is to safely and automatically allow as much good stuff as possible, that way we do not overburden the user with dangerous user prompts. And since VS toggles to OFF when it is not running a web app, this kind of stuff is auto allowed.

On the other hand, to a certain extent, I do see your point about a dll or possibly an exe being dropped or replaced... I mean, you can never be too safe, correct . So if that is the case, isn't it best to NOT whitelist the entire C Drive (and other drives)... but rather to only whitelist items that are absolutely critical to run the necessary apps? You know, like maybe have a tiny, customized whitelist that only contains 100-150 items, so that it has the absolute smallest attack surface possible? Rather than whitelisting the entire computer (30,000 + items or so) and having a massive attack surface?

I tried your sample, and yeah, you are loading the dll on app startup. So yeah, CallDll.exe should be initially blocked, but once it is whitelisted, then it should automatically allow HelloDll.dll.

 

Thank you for the links! I have tried many dll injection techniques and shellcode samples on VS, but I have never been able to bypass it, and I am assuming that a lot of people have tried as well . However, if we do find something that will bypass it, we will definitely be implementing dll protection with the new mini filter driver. We have talked about doing this any way... we just need to figure out if it really is an issue first.

BTW, if you find something that can bypass VS, please let me know!!! I would be really curious what finally got us . And of course we will be sure to fix it.

 

@Online_Sword: Here is some source code that you can experiment with in Visual Studio: https://github.com/stephenfewer/ReflectiveDLLInjection

And here are a bunch of them... https://github.com/search?utf8=✓&q=DLL Injection

 

Interesting... So can you tell if there is a performance hit when the dll monitoring (or whatever it is called in Faronics) is enabled?

 

Wow, that is crazy! I just realized something... I am guessing that if we implement dll protection into VS using our snapshot / toggling stuff, that there would maybe only be around 300 or so dll's on the whitelist, and hopefully it would not impact system performance. We have not tried it yet, but I guess we will find out soon enough .