VoodooShield/Cyberlock

In the free version, VS is set to deactivate after 10 minutes of idle time. User settings are not adjustable in the free version.

 

Thank you for checking into that. All of this is changing in VS 3.0 which will be ready very soon, a couple of days at the most I would think. We might be able to add a manual parent process feature, but if everything goes right, VS 3.0 will handle all of this automatically. So when we release VS 3.0, please try it and let me know what you think.

BTW, I just tested the command line you posted with VS 3.0 and it worked perfectly!

 

I just tested this with VS 3.0 and it is not fixed yet, but I will add it to the to do list right now. Thank you!

 

This is all changing is VS 3.0 as well, and hopefully it will make more sense. What information do you want me to provide, and where should I provide it? Thank you.

 

The main new feature is the KMD and getting it to work perfectly with VS, but we are working on a lot of different things. We do not have a list of planned features, because we do not know what all is going to be included in the first release of VS 3.0. But I will say this, we do have some new things we are working on that are going to be pretty cool.

 

Yeah, it looks like it is going to be working correctly . It may take a week or so after we release the first version to get everything just right, but it should be quite easy.

 

Hmmm, well, the reason we have that feature is to block payloads from exploits, so that was the best name I could come up with. Please let me know if you have a different name for that feature, I would be happy to change it if it describes the feature better. Also, keep in mind, I just was answering a question on basic functionality of that feature, and we can always expand on it even more. I did not name it based on marketing, I named it to best describe its function.

For example, if we were to call this feature "Block all files that are downloaded or spawned through web apps." then I am certain that a lot of users would uncheck this option because they do not want VS to block their downloads, and then they would be at risk for exploits. Everything is moving to HTML5, so I am hoping that the cool buzzword "exploits" will disappear with flash and java.

And actually, I do not consider VS an anti-executable. No one in their right mind would ever build and anti-executable that turns OFF when all of the web apps are closed . Obviously I am joking, but it is kind of ironic that sometimes doing something counter-intuitive turns out pretty cool. Since day one, VS has been a toggling desktop shield gadget that locks your computer while a web app is running. The goal is to safely allow as much good stuff as possible, that way average users and novices can use it. Otherwise, they are bombarded with affirmative prompts that they do not know how to answer, and obviously this is very dangerous... the biggest security hole if you ask me.

While some users like to put VS in Always ON mode to simulate an anti-executable, they are really missing out on a lot of cool stuff, and in the end, are not any more safe then what they would be if they were running in smart mode. Just think about how well VS will work on mobile devices. Here is an example. The user is playing Angry Birds, so VS is OFF and hidden. They launch their email, VS turns ON and shows the desktop shield gadget. See, it really is not an anti-executable, I promise .

Cool, if you find anything that bypasses VS, please let us know!

 

Just like Gillor said (thank you Gillor), VS auto deactivates to automatically allow system functions like windows update and backs. This can be changed in the Pro Version, if you need a license, please let me know.

 

what is kmd?

 

Kernel Mode Driver... VS 3.0 is using a mini-filter KMD.

 

https://www.wilderssecurity.com/threads/voodooshield.313706/page-312#post-2525921

 

great - thanks Dan

 

I did! Details as follows.

We set up a virtual PC with a vulnerable version of Adobe Flash Player. We went to a website set up to exploit the flash vulnerability. Using a Metasploit interpreter we could then control the hacked computer. We could turn on the webcam, do keylogging, and send the data back. We could also migrate to other processes that were already running in memory. Although we did not try it, we might also have been able to get persistence by creating a scheduled task in Windows (not quite sure about this though, comments?).

Obviously VoodooShield did not react to any of this because there were no payload and we did not execute anything, but instead used those processes already running on the machine.

So Dan, I'd really like to have your comments on this. It seems to me that VoodooShield would be best used together with some additional anti-exploit protection like those I've mentioned: EMET and Malwarebytes Anti-Exploit (and of course Flash should not be installed unless one actually have a need for it).

 

I am looking forward to V3. To answer your question, the pop up should provide more information than just CMD. Currently you can't make an informed decision as to whether to allow or block from the pop up. You are shooting in the blind.

 

I absolutely agree that it could never hurt to add additional layers of protection, and I have recommended several times that people use EMET or MBAE along side VS, just in case. It probably is not necessary, but it could never hurt.

Having said that... Flash is whitelisted so you do not want VS to break it, correct? That is, since it is trusted, you want it to do everything that it is intended to do, right? Otherwise, VS would break other programs and display unnecessary and dangerous affirmative user prompts.

Now, if you can drop a payload and execute it, THEN you have bypassed VS. This is how the various testing labs determines if a security solution is effective or not... all they care about is if an unknown payload is dropped and executed.

Also, please take a look at this: http://download.cnet.com/blog/download-blog/exploitshield-appears-to-live-up-to-its-name

"Ninety-five percent of successful exploits are Java- or PDF-based," said Bustamante in a meeting at CNET's San Francisco offices last June. "ExploitShield protects against exploit-delivered malicious payload," he said. "It's vulnerability-agnostic."

All that matters is that the payload is blocked. That is totally cool that there are other methods of ultimately blocking payloads, and I am all for people creating new cool technologies to combat the malware problem, but if VS can block 100% of the payloads spawned through web apps, using a simpler method, then I see no reason to not do so. Now, if someone can bypass VS and run a dropped payload, then we will have to fix it... we will just find another simple way to block the payload.

It is kinda funny that we are talking about this now... here is another thread that started right before we started talking about this.

https://www.wilderssecurity.com/thre...lications-from-executing-unknown-dlls.380122/

 

Sure, we can certainly do that, I think that would be helpful, thank you for the recommendation. What kind of info should we include?

VS 3.0 should auto allow all command lines from whitelisted processes... I have been trying to get that to work for a little while now, with limited success. But I think Vlad will have all of that working properly very soon.

BTW, this is actually quite similar to the above post, and exactly why stuff like this should NOT be blocked... the user simply has no idea whether to run it or not. Hopefully we can display more info if there is a block, but I just do not know what info to display.

 

Also, keep in mind, if the following study is correct, then shouldn't we block ALL payloads that are spawned through web apps? . Besides, we are supposed to close all of our applications (including security software) when we install new software anyway, correct? As I always say... there is NEVER a good reason to run new, non-whitelisted code when a web app is running.

So just because the method we use is simple, it does not mean that it does not perform as an anti-exploit, and that we cannot describe it as such. Not that I am necessary suggesting that more "complex" solutions are Rube Goldberg machines, but I am suggesting that simplicity is the ultimate sophistication . Do not get me wrong, what EMET and others do is HIGHLY impressive and cool, and to be honest, it would take me 5 years to create something like that, if I was able to create it at all.

Sections 10.0.0 and 11.0.0 are most interesting.

https://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf

 

Thank you Baldrick and Tarnak!!! It was Alan Turning!!!! I have been looking for that for MONTHS now so I can use it in our marketing!!!!

Section 10.0.0!!!!

https://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf

 

Something more than "C:\Windows\System32\cmd.exe. That pop just does not tell me anything.

 

Thanks for your replies Dan. I think your approach makes sense and perhaps the only reason I feel a bit disappointed, is all this talk about VoodooShield having never been bypassed. I now saw it happen with my own eyes, and we got through in the very first try. Since a PC can be hacked completely without the use of malware, by instead using build-in Windows components, it makes no sense for the testing labs to claim that a security program is only bypassed if a payload can be executed. I saw myself on the screen when we turned on the webcam on the hacked computer, so that's a pretty clear proof to me that we got in and were able to extract information from the hacked computer.

I still think VoodooShield is a great product, but if the attacker does not use any payload (a rare scenario I believe) it will not stop the attack. In fact, as I think you are pointing out, it is not designed to stop such an attack.

So please, let's forget that talk about VoodooShield having never been bypassed. I feel a bit mislead by that and I have now seen proof of the contrary.

In fairness, it is my impression that almost all the malware attacks I read about on a regular basis, use some sort of payload. And that would indeed be stopped by VoodooShield.

Thanks for the links by the way, I'll start reading!

 

I have spoken with NSSLabs on the phone several times, and have asked them several times what their criteria was for a bypass. They told me several times that ultimately it all comes down to whether the payload was allowed to execute or not. Based on their criteria (not mine), you did not bypass VS. VS does not block functions of whitelisted apps. If it did, then the computer would not run so well. Either a file contains malicious code or it does not. If it contains malicious code, it should be blocked. If it does not contain malicious code, it should be allowed.

A lot of people ask me why they are still getting email spam and tracking cookies after installing VS too . VS is not designed to block spam or tracking cookies either... but that does not mean that it was bypassed. If you can bypass VS by allowing something that it was designed to block, THEN you have something. Until then, you have not bypassed VS.

Have you tried your test with other security products? Have you found any that will block built in flash functions (maybe EMET will, whos knows)? Please let me know, I would be very, very curious to see a demonstration video! Thank you for your help!

 

I fully understand that VoodooShield is not designed to block this kind of attack. The fact still is, that the computer got hacked despite having VoodooShield running. I think most people will see that as a “bypass”.

So according to NSSLabs you can actually hack a computer WITHOUT having bypassed the installed security software. That's kinda funny. And clearly a problematic definition.

We did actually continue with a test of EMET and it blocked the flash exploit without any issues.

Other than that, I think a classical HIPS could also stop the attack, but it might require some tweaking and not be a user friendly approach.
Personally, I would just uninstall Flash Player. ;-)

 

EMET only offers protection till the moment that an attacker has developed bypass techniques for it. If someone knows what he is doing then EMET is not really a big issue.

 

I am actually on an onsite project right now, so I will reply in detail a little later (I am on my phone). But I just thought of something and I wanted to bring it to your attention. Your testing methodology is invalid and does not hold water. In order to test with metasploit, you had to whitelist it, because VS blocked it, correct? So VS stopped the attack, but it did so much earlier than you realized because you are not familiar enough with testing methodologies to perform a valid test. So in essence, we could create an executable payload that performs the EXACT same functions that metasploit performed in your test, and VS would block it, the same way that it blocked metasploit . The thing is, child processes of white listed processes should automatically be allowed, unless the parent process is a web app (in general). Otherwise, the user is bombarded with dangerous affirmative user prompts and desensitized, so then usually clicks allow by default.

So considering that your testing methodology is tragically flawed, you are probably in no position to criticize NSSLabs. They know how to perform a valid test, much better than you or I ever will.

During development, there were a lot of things that bypassed VS, always due to bugs in the code (which is absolutely normal), but I fixed them before it was ever released. And there was 1 guy named Adam that found a few bugs that resulted in bypasses as well. Then the only other time VS was bypassed was about 2 years ago when a client of mine was infected because of an error in the code. .. It was an easy fix. So there have been 3 or occasions where VS was bypassed, but it was ALWAYS a result of a bug in the code, NOT a design issue.

No one has EVER bypassed VS because of a design flaw though, with the exception of Fabian like 3-4 years ago when VS was a working prototype, on version 1.0. Not that VS cannot be bypassed, it probably can be, and I am curious to see what finally bypassed VS. It is not like our marketing campaign includes something like "100% protection, guaranteed." I think if we did that, then you would have the right to correct me. But saying that many people have tried to bypass VS, and no one has been able to is 100% true, ever since VS was stable and I started making that claim. That is why we had the VoodooShield challenge a year ago or so.

It is not cool to post on wilders that you bypassed VS, when your testing procedures are flawed... That is how rumors get started.

Please make a video of EMIT blocking your "attack"... I would love to see it. Mainly because I have never seen what an EMET block looks like . Thank you for trying to bypass VS, I really do appreciate it!