VoodooShield/Cyberlock

Cool, thank you Gordon!

 

Yeah, these are all protected since they are in the windows folder!!! It is hard to explain what I did... but just start Internet Explorer and go to File / Open, then click Browse, then change the "filter" from "Web Documents" to "All Files", then try to open one of these... VS will block it . Thank you!

 

Very cool, thank you for letting us know!

 

I thought I was going to be able to catch up on all of the posts, but I am going to have to stop on page 476 for now, but I hope to catch up on the rest this weekend. Thank you guys, have a great weekend!

 

Well, Dan

All I can say that v3.33 is running very nicely here both on a Windows 10 64bit & 32bit system...nothing to report so far in terms of freezing or the like.

Regards, Baldrick

 

Hi Dan, well good news, no freeze and no DISMHOST messages with v3.33

Thanks and have a great week-end!

 

Great to hear, thank you guys!

BTW, if VS does happen to freeze, please right click on the VS tray icon to see if the right click menu appears... there is a chance that the flashing of the desktop shield gadget is making it so VS is not actually freezing, but it is unresponsive when the user left or right clicks on it (I hope that makes sense).

Also, if VS does happen to freeze, please disable VoodooAi in Settings / Advanced for a few days and see how it does. Thank you!

 

Working very well here also and will test the Disable/Install mode and let you know!

Daniel

 

Hi Dan

I'm running 3.33b and still getting dismhost.exe blocks. Is it because i'm on the 'fast ring' and each version update is using a different version of dismhost?

I'm happy to workaround this issue, as I appreciate you can't be expected to support the previews as well as releases.

Thanks
Mark

 

Disable/Install mode works as it should! Not a peep from VS installing new software.

Daniel

 

Hi Mark, nice to meet you! Yeah, it must be a brand new version of dismhost... if you can send me the hash of the new file (or just post it on here), I will add it for the next version. You should be able to copy the hash from the User Log by highlighting the item and pressing control + C. Thankfully, dismhost seems to only be updated around twice a year, and there are usually 2 versions, a 32bit and a 64 bit, so we will probably need to add 2 hashes. Thank you!

 

This is an odd one I haven't seen before opening one of my notepad text files?

 

Hi Dan

I've sent you a PM with the hashes.

I'm not sure if dismhost.exe will only change a couple of times a year as i've already had two different versions in the last week for the two insider preview builds.

Thanks
Mark

 

Well exactly this happened here. Desktop shield not responsive. Went to the VS tray icon and managed to view the VS menu but the menu just open and does not close and I cannot select any item there. I will kill VS from task manager and disable VooodooAi to see how it goes. I will send logs...

 

This is exactly what happens to me!

Sometimes, I get freezes when VoodooAi is calculating the score for an exe and it takes ages (a minute of more) to return a result. If it doesn't manage to get a result I have to kill Voodooshield.

 

Thank you, I added them. Yeah, I am not sure how often they update dismhost for insider preview builds, but for normal releases it does not seem to be that often.

 

Cool... I am thinking there is something funny going on with the flashing, so I removed the flashing completely temporarily to see if that is what is going on. I actually like it without the flash, and just the progress bar! If you guys prefer it this way as well, we will just keep it this way. Anyway, here is the version without the GUI flashing. Please try it and let me know how it does, thank you!

https://voodooshield.com/Download/beta3/InstallVoodooShieldNoFlash.exe

 

Hmmm... that would be a different issue if it is on the User Prompt, showing "Calculating VoodooAi". I have never had that happen to me, but there are several ways I can make it do that to test. There should be a Block button when VS as calculating the VoodooAi... does it work to kill that user prompt? I can also change the button to Cancel (or whatever). Thank you for letting me know!

 

Yes, there is a Block button and it yes it does close the prompt. But it would be useful to have a Cancel button or even a Allow (at my own risk!) button when I know I can trust the file.

 

OK, thanks! Installed... I will see how it goes

 

okay, but it would be nice to give the poor user a second chance. The way you have things set up, as soon as the user mistakenly allowing an exe file, or some unexpected software conflict takes place, it is gameover in one second. The malware has the keys to the most powerful tools of destruction.
other anti-exe programs give you a second chance, by preventing suspicious execution of vulnerable windows processes. You don't have to block all executions, i

Dan, I would humbly encourage you at some future point to add some extra loving care to the protection of vulnerable windows processes, so it won't be game over if the user makes one unwise click...

 

I realize that I have 3 or so pages of posts to catch up on, and hopefully I can do that by tomorrow, but I wanted to address this asap. I think there is some confusion, and if we talk through this, we can figure it out. Hopefully users such as CS can give their opinion as well, and in the end, everything will be perfectly safe and as user-friendly as possible. I think in the end, you will find that this new method is a lot more secure than the old method, but if not, we can add options for the old method as well, and give the user the ability to specify vulnerable processes.

BTW, I completely forgot that at least for now, the old vulnerable processes are blocked while VS is on (for example powershell, cscript, wscript, etc)… and if you try to run one while VS is on, it will be blocked and the mini prompt will say “VoodooShield Blocked a Blacklisted Item”. I just have not removed this code yet until I was comfortable that the new method was working well, and that it did not block too many safe processes (it turns out that it blocks very, very few safe processes).

It would probably be best to use a specific example, so let’s take powershell, since it will work for all of our scenarios… here is the path:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Unless I am forgetting something, we can probably break down processes into 3 different groups:

1. Non-Whitelisted Processes: Let’s say for example you have a non-whitelisted app that needs to spawn powershell for some reason. Since it is not whitelisted, it will never get the chance to spawn powershell until it is whitelisted. So the way I see it, we can basically ignore this, and just assume that there is no reason to block powershell that is spawned from a non-whitelisted app, since it will never happen.

2. Whitelisted Processes: Let’s say for example you have a whitelisted app that needs to spawn powershell for some reason. I personally think that a whitelisted app should not be restricted in anyway, because bad things can happen. Yeah, I know, VS has a local sandbox feature, but that is beside the point. To me, if a whitelisted process needs to spawn powershell, it should be able to do so whenever it needs to, and should never be restricted in doing so.

3. Processes spawned by web apps: This is where it gets interesting. A lot of exploits run shellcode that spawn powershell as a child process of a web app… this is extremely common. The problem is… many security products auto allow everything in the windows folder, and as a result have to “patch” this issue by adding a vulnerable process feature. The new method that VS uses fixes this in an even more secure and user-friendly way because it blocks ALL child processes of web apps in the Windows folder (except for 2-3 files that are necessary and happen to be difficult to exploit). So 3 months from now, when all of the malware authors start exploiting a new windows process, it does not have to be added to the vulnerable process list… it is simply going to be blocked because it is a child process of a web app (that is in the windows folder). As I mentioned… there are a few others that are outside of the windows folder, like java, flash, Silverlight, etc, but those are easy to hardwire in.

You said that “other anti-exe programs give you a second chance”… I am not sure what second chance you are referring to… can you please give me a detailed example? Also, try the following test with VS and with the other anti-exe products… open Internet Explorer and go to File / Open, then past in our command line from above and run it (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)... I think you will see what I mean .

I could be completely missing something, or could be completely wrong about something, which is why it is great that we are talking about this (and why I have not removed the old vulnerable processes safety net yet). If it turns out that it is completely safe, which I think it is, we should be able to remove the blacklisted items permanently, and believe it or not PROBABLY EVEN THE COMAND LINES!!! Although, I am getting a little ahead of myself there .

Please let me know what you guys think, and if there is a way to bypass the new method!

 

VS 3.33Beta

When i close and reopen VS it detects and whitelists a program i uninstalled. The program location does not exist either. The program is Launchy. TY

 

Hi Dan, thanks for very detailed explanation!
I personally am not super worried about those fileless browser exploits, because:
1) they are pretty rare if you are using chrome or another secure browser, and you keep your software updated
2) it is easy to get some extra anti-exploit protection from any number of free or paid security softs

I am more concerned about some iffy app that I, or another user, allowed to install, on the impulse of the moment. If it turns out to be malware, and it has now installed itself, then a set of rules that protects vulnerable windows processes from doing suspicious things will still save my system, in many cases. These rules don't have to stop all instances of cmd.exe or cscript etc, because, as you rightly point out, that will bother the user too much. Instead, you can set parameters to catch certain operations that smell fishy. There are even ready-made parameter lists of this sort.

true, such a list would have to be updated from time to time, but an outdated list is still much better than no list.

In order to save the user from needless prompts, you could hardcode a whitelist for certain common apps that need to run vulnerable windows processes. An example of such an app is the dropbox desktop app. If you enable Kaspersky Trusted Applications Mode, dropbox often will not function properly, unless you dig deep into the TAM settings to make a set of exceptions for it. And if you run SecureAPlus, then you will get a barrage of prompts when dropbox runs an update. But a smart dev could just whitelist the dropbox app and other common apps.

I am just sharing my ideas, because I like VS.

 

I like the simplicity of not having to maintain a vulnerable processes list, as I am currently doing in NVT ERP and AppGuard.