VoodooShield/Cyberlock

Yes, request is a more polite action than locking a machine down completely and unexpectedly, especially for the less tech savvy VS users.

 

Dan,

I'd be happy with a request before a complete lock down, if that's possible.

 

like this? : https://www.wilderssecurity.com/threads/voodooshield.313706/page-604#post-2661542

 

My understanding after reading all of the comments posted here over the last few days, is that the only reason SP is being introduced is to lock the computer down after a user has allowed a macro to run that was specifically created to target VS, after allowing an unknown Excel file to be opened that contains the offending macro.

Then a reboot will restore the system to a correct working situation and therefore as long as the macro isn't allowed to run again then the computer can be considered as back to normal working operation again with no need to reimage. A message would also be shown to advise the user why the system has locked and needing the reboot.

This to me seems like a wonderful idea to restore the system to normal once the computer has rebooted. SP would also protect in exactly the same way any other methods that may be written in future to target VS.

I originally thought that SP wasn't necessary because I couldn't see how I would ever run an unknown macro on my system but then it was pointed out that some users with little experience could run such a macro as of course unsuspecting people can be tricked into doing all sorts of things via clevery worded email scams etc.

So now I think that provided SP can be introduced with little user interaction being required, and would more than likely never even be needed but is still there for that one in a million chance compromise, then it seems a very worthwhile added layer to protect itself. I would add however that it would have to have absolutely no impact on the normal operation of the OS with no boot delays or start menu lockups etc. If a fully stable working model can be developed with no bugs as I'm sure Dan will eventually work out then I would be happy to see the development of this idea continue.

 

@zarzenz you discribed the situation quite well and mentioned the most important point:

 

What page is the 3.55 B3 on, I missed that one,
can I be linked, Thanks.

 

Hi
Page 602

 

https://www.wilderssecurity.com/threads/voodooshield.313706/page-602#post-2661486

Edit: Boogieman beat me to it. 11 pages ago already lol.

 

Good idea, remind me a bit like Webroot does when you set the control settings to request password or captcha validation when you want modify setting or shutdown the program.

 

Another developer mentioned it too. If for example a watchdog process can be bypassed, why adding it...
A choice can be to modify the ACE qualifier of your application, so that at least non-administrators don't have access to it (see in the quote below)
Another counter-measure could be, which was already mentioned before, to make your service non-stoppable. Even for administrators.

It can also be a good thing to make your self-protection configurable by the user (like: enable/disable self-protection)
If it will be configurable, make it disabled by default. And only after the self-protection is "mature enough", you can enable it by default for all new installations.

 

Why is it too late? You may be compromised, but do you really want to allow the malware to have free reign to do whatever it likes to your system, and more importantly, to your data, until you take remedial action (whatever that may be)? I sure wouldn't want that to happen if it can be avoided. Locking down the system has got to be the best option for limiting any further damage.

Easy for you to say, but how many home users (VS' target market according to you) backup their systems/data regularly and, if they do, how many would know how to restore their system without losing their data? Not many I would imagine. Much more likely than restoring from backup themselves, they would have to 'phone a friend' or take the computer to a repair shop.

I really don't know why you're so against Dan implementing Self Protection/Lock down in VS when AppGuard already does the same thing.

 

@mood Instead of @VoodooShield bothering with device drivers for callbacks or a lock-down mechanism, he could take a similar approach to the developer you quoted and just work with DACL protection via the function SetKernelObjectSecurity. Thanks to Platform Invokation, he can do it straight from managed code. If done right, it will prevent any non-elevated process from obtaining a handle to his processes... He could even combine the lock-down mechanism as a secondary defense to this method.

The method I mentioned above via usage of that function will be sufficient enough to block the process termination via the macro Dan was talking about, and since it prevents a handle being obtained... It means it'll have the processes protected against suspension and injection from any non-elevated processes. Microsoft Office software should not be ran with administrator privileges anyway (who does that?) so any macro's being ran will have limited rights, which means the above should be perfect as a mitigation attempt.

As long as the software can protect itself from the common attacks it is receiving then it should be fine. In this scenario, the macro is a problem, so once this is mitigated there is no "real" problem at all. Since the macro attack is not "prevalent" in the wild, some can say there is no problem even now and S-P isn't even required at the moment.

I think the method I mentioned at start of this post would be great to be implemented into the stable release and enabled by default, and the lock-down mechanism could be implemented into the stable release once it's ready but disabled by default. Just an idea.

 

a simple warning saying that you are under attack is far more understandable than locking the system.

The lock won't change that fact.

im not against the implementation, i was against the way he planned to do it. Appguard doesn't lock you out if the GUI is killed.
For example, im doing financial operations in stock market and im getting locked out without warning, and this lock cost me the loss of my transactions hence loss of money , i can assure i would hate the soft and will surely sue the dev for compensation.

 

What do you think about the DACL protection method I mentioned in my previous response? It would be quick and easy to implement and should mitigate the macro problem, assuming MS Office software is ran without elevation.

 

we gave Dan enough suggestions , now the ball is in his camp; let's move on.

 

For the longest time I have two blocks showing in the GUI. They never change up or down. Even though there has been many more. Not sure if this has been answered but I didn't see it if it was.

 

The "bypass" mWave created supported his argument for VS to implement the methods that he recommended... and yes, in this case, he is correct. But he is forgetting that VS already sufficiently protects itself in this scenario, which is why I recommended that he try to bypass VS with a macro, which would be an actual valid test. Basically, he is running a test that demonstrates the need for VS to implement the ObRegisterCallbacks routine that he recommended in our driver, when we should be testing to see if a macro can defeat VS's new lock down method.

As a backup, mWave recommended a watch dog method, which I have not been a big fan of since Fabian demonstrated to me 4-5 years ago, that the watch dog method is useless. Which is why I thought a lock down method would be infinitely more secure, as a backup. But it would be difficult to see if the lock down method is working properly, if the ObRegisterCallbacks routine and / or the protected process method from Microsoft (which Kees and I discussed yesterday in a Skype call) was already implemented. Once the lock down method is working properly, we can implement the ObRegisterCallbacks routine or the protect process method from Microsoft... and actually, we can work on these in parallel, which is what I am trying to do. Alex is not feeling well right now, but when he is feeling better, he is going to look into the ObRegisterCallbacks routine and the protected process method, and if he is comfortable with implementing them, then he is going to do so, while I finish polishing the lock down method.

Once all 2 or 3 methods are ready, we will test to see what scenarios require the triggering of the lock down method. Hopefully, we will be able to only be forced to trigger the lock down method when the ObRegisterCallbacks routine or the protected process method fails. If so, the end user will NEVER experience the lock down method.

This whole thing is a work in progress, and we only started working on it a couple of weeks ago. I do not have all of the answers yet, but when we are finished, we will have figured it out. But first thing is first... we need to refine the lock down method first.

 

Absolutely not... the the system is not compromised. Here is the log from the macro attack:

[03-24-2017 10:46:28] [ERROR] - VoodooShield has entered self-protection mode. | C:\Program Files\VoodooShield\Notify.exe | C:\Program Files\VoodooShield\VoodooShieldService.exe | True | False
[03-24-2017 10:46:29] [ERROR] - VoodooShield has entered self-protection mode. | C:\Users\Dan\Desktop\Test.exe | C:\Windows\system32\wbem\wmiprvse.exe | True | False
[03-24-2017 10:46:29] [INFO ] - This process is being killed: C:\Users\Dan\Desktop\Test.exe|C:\Windows\system32\wbem\wmiprvse.exe|True|False
[03-24-2017 10:46:29] [INFO ] - This process is being blocked: C:\Users\Dan\Desktop\Test.exe|C:\Windows\system32\wbem\wmiprvse.exe|True|False

Test.exe is the payload, which was blocked and killed (in that order... the log just logs the blocked entry later than it does the killed entry). After this, the system is locked down until the user reboots. Once the computer is rebooted, the system is clean, because there is nothing that is triggering the Test.exe payload.

So this will ultimately work extremely well for home, SMB and enterprise... especially since they will most likely never experience a lock down in the first place. And even if they do experience a lock down, they are not forced to hard reset their machines, as TH posted here: https://www.wilderssecurity.com/threads/voodooshield.313706/page-594#post-2659450

We could change the message box to a yes / no message box, but that is pointless, and would not give the user the chance to close all of their programs and save their data before rebooting their machine.

We are also forgetting that once this is fully implemented, at least in theory, a target bypass will never be created for VS, simply because whenever someone tries to create one, the system will go into lock down.

 

This is absolutely not true at all... please see: https://www.wilderssecurity.com/threads/voodooshield.313706/page-614#post-2662461

 

I agree mWave... we have a lot of different options, and I am working through it to figure out what is best for VS and for VS's users. And believe it or not, I do appreciate your input and recommendations while we work through this.

 

Do you mean like this? https://www.wilderssecurity.com/threads/voodooshield.313706/page-594#post-2659450

 

Yeah, we have a lot of options... we just need to figure out what is most secure and user-friendly. I think we are getting close.