VoodooShield/Cyberlock

Setting aside the emotional part of that blog post, I must say that the technical part is pretty interesting. At least I've learned something new.
I tried that exploit on VS 3.0 and both powershell processes were blocked. So at least this type of bypass is not more an issue for VS. However everything that was built by people can be bypassed/hacked/cracked, so I would not calling it "Full Disclosure" it's most like a bug/hole that he found.

And I have to add, that even if you were not been heard, appreciated or paid it is still a good idea to stay a human being and respect the work of other people. (it's about the emotional part of the post)

 

It happens on Email field rather than on Password field, right?

 

Both.

Windows Firewall Control (vendor = BiniSoft) for example, has problems with some input fields because of quirks in Microsoft's NET Framework; the problem is very pronounced on lower end systems.

However, in the case of VS it seems not caused by NET Framework nor any system resource limitation(s)...

 

The person who wrote that obviously has a big beef with something...sounds to like a nobody looking to be somebody but without the ability to do something to be that somebody...best ignored IMHO.

 

I still was unable to reproduce it bot on VS 2.x and 3.0. Tried also on VM. But I removed some input validation checks on the fields, so I hope it will fix the issue for you in the next release

 

Actually he seems to know what he is talking about.
I was able to verify his MBAE disarm about half-a-year ago with a different PoC (CVE-2013-3163) and his EMET bypass also seems to be reasonable when looking at earlier published EMET research.

 

He does know what he is talking about. The whole affair is unfortunate. However, I stand by my original position = saying a security soft can be bypassed and actually producing a verifiable bypass is completely different.

Had he simply produced a PoC - or whatever - that actually bypassed VS - then it would have shut everyone up...

 

He actually did. If you watch the videos on that blog he posted videos.

 

He does. But frankly, I have given up on the subject. Best can be summed up with "You can bring a horse to water, but you can't make him drink."

 

Instead of engaging in acrimonious debate, it would have been best if PoC was produced earlier. However, it is a moot point since it applies only to v 2 AppCertdll. We are now on VS 3 so it is time to move on...

 

NP

 

@VladimirM

CONFIRMED and REPRODUCIBLE.

Does v. 3 support wild-cards for command lines ?

Let me explain why it is needed...

Sandboxie, for example, uses cmd.exe to delete the sandbox. Everytime Sandboxie "creates" a sandbox, it assigns a random name to that sandbox. Therefore, the sandbox file path is not static.

Using SBIE, for best security, each time I close a sandboxed application, the sandbox is to be deleted. Since SBIE uses cmd.exe - a protected, vulnerable process - VS will alert every time SBIE attempts to delete the sandbox using the Command Line Interface.

White-listing the command line does not solve the issue since the file path changes every time a new sandbox is created -> since the sandbox "name" is randomly generated.

This creates a "quirk" for VS.

I have included a screen shot of the Command Lines pane that indirectly shows that VS white-lists the command line for each new instance that SBIE invokes cmd.exe to detele the sandbox. White-listing the command line in each instance of sandbox deletion is pointless because of the file path change; VS will alert when SBIE attempts to delete any subsequent sandbox.

A direct, practical way to enable the user to white-list command lines in such a case is wild-card support.

NOTE: The second excepted command line below is the one I created in VS using a wild-card symbol (*) in place of the sandbox random name, but unfortunately it does not work.

I hope my explanation is clear... lots of repetition of the same point, but I think you will know what I am saying.

 

@VladimirM , @VoodooShield

It's debatable, but I think regedit.exe should remain a protected, vulnerable process... especially for those that wish to lock users out when using VS' password protection.

The setting is still there is vulnerable processes, but it was disabled a few months ago; VS no longer blocks regedit.exe when it is ticked in the Black Listed processes list.

Just food for thought...

 

@VladimirM

There are duplicate entries for numerous files in the Whitelist Editor pane. This is an old VS issue.

In some instances VS does not calculate the SHA-256 and\or include it in the Whitelist. This is an old VS issue.

I haven't looked into it any further, but the duplicate entries are also backed up to the VS Cloud.

Not anything critical. Merely annoyances...

 

I second this suggestion. I have the same issue with Dashlane when my browser opens.

In my case the line is:


Second suggestion: please make the VS windows resizeable. I can't copy and paste the entire line and can't take a screen clipping of it!

 

Resizable VS GUI is absolutely needed !!!

Better command line white-listing within VS on an as-needed basis is absolutely needed !!!

 

Still waiting for implementation

https://www.wilderssecurity.com/threads/voodooshield.313706/page-265#post-2476580

https://www.wilderssecurity.com/threads/voodooshield.313706/page-266#post-2477354

According to Dan, it will be implemented at some point.

What I do now is to reset whitelist if there are a lot of duplicate entries.

 

Using V3 now (installed over from previous version), running fine here.

 

Oh no! The latest 2 fixed that I've done before the release were disabling Custom Folders button and fixing that Sandboxie issue. And according to screenshot is seems like I posted one of the previous builds. Today I will release the new version (the right one), that will also have some fixes of the reported bugs.

No, but it's not supported in the way as it expected, I mean *-any characters, ?-single character. But it is a great idea and I think it should be implemented (it is pretty easy one). But if it will be implemented, then it is up to user to edit the entries to the proper wildcard.

 

Thanks for the updates!
I added those tasks to the task list for the future releases. I'll review them with Dan to assign the priorities.

 

VoodooShield 3.01 Beta Release
Accidentally the 3.00 version didn't contain some last minute fixes. They were added to this one. As well some of the bugs that were reported also fixed in this version
You can download it from https://voodooshield.com/Download/beta3/InstallVoodooShield.exe
It's recommended to turn off or uninstall any old versions of VoodooShield prior to installing the new version.
Due to auto-update bug, version 3.00 could not be autoupdated to higher version! So it is recommended to update manually to version 3.01. The next releases will be updated automatically

System requirements:

• Windows Vista sp1 and above (XP wasn't tested!)
• .NET 2.0/3.5 and above

What's new in VoodooShield 3.01 Beta:

• Fixes that were missed in 3.00 - Sandboxie fix, disable Custom Folders
• nircmd.exe fix
• chrome update bug fix
• probably registration fields fix (I'm not sure, because never was able to reproduce it)
• Autoupdate version fix

There are still some features missing in the first beta, but they will be implemented in future versions.
I will be available for the next 2-3 days for your questions or comments regarding 3.01 Beta functionality/issues/bugs and will be happy to get some feedback.

Have a good day,
Vladimir

 

@VladimirM

beta 3.01

Character input field = FIXED.

Sandboxie command lines = NOT FIXED; white-listed command lines for each sandbox file path still occurring.

Duplicate White List editor entries = NOT FIXED; VS takes standard Snapshot, then prompts user to perform Advanced Snapshot. VS Advanced Snapshot does not detect or over-write entries from standard Snapshot... this results in some duplicates in White List editor.

Hee, hee... all minor scruff, but OCD users will go beserk...

 

Cheers, Vladimir

Will get that installed shortly and look to give it a run.

Regards, Baldrick

 

Thanks Vlad,
VS 2.86 uninstalled and 3.01 beta installed, reset the whitelist - I also get the duplicated whitelist entries what hjlbx has already reported.
Can confirm custom folders is now disabled. Although I did initially notice what Dzp5t reported - that when I opened whitelist, it enabled custom folders again and further when in custom folders, I pressed the 'enable custom folders' button, it opened my browser and took me to my account page at VS.

2 services as usual......
VS.exe using around 15mb memory and VSservice.exe using around 17mb memory.

Thanks
Gordon