Recent Posts

Pages: [1] 2 3 ... 10
1
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by oldschool on Today at 08:30:19 pm »
I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
I have numerous entries for chrome.exe, firefox.exe, conhost.exe, winword.exe ... and so on. I'm guessing some of these are due to executable version updates. IIRC Dan said that there is no performance issue here.
In the whitelist tab, you can scroll over to the right and you will see the parent process, hash, and other info.  Most likely there are duplicates because a different parent process called that whitelisted process.  This was a feature that I implemented in VS 4.0, which is the main reason we initially had a lot of unwanted blocks, until I could work out all of the bugs.

A lot of people think of VS as just another application whitelisting utility... and that aspect of VS would be absolutely true if all VS did was whitelist based on hash, and possibly path or file size.  One of the many things that sets VS apart from other application whitelisting utilities is that it has many, many attribute checks on the whitelist... and one of the most important and easy to explain is the parent process check.

For example, cmd or powershell has the ability to be good or bad... and it all depends on the context of the item.  And this is pretty much true with any process / executable, especially ones that are abused and vulnerable.  So the reason you have several different items listed in the whitelist for the same process is because VS is simply whitelisting the context of each user action, so that it can later perform parent process path comparison when the item is later launched.  As an example, you might want to manually launch cmd.exe, but you certainly do not want Chrome to launch it without your permission ;).

Simply classifying individual files as good or bad, and adding the "good" ones to the whitelist, makes little sense to me, especially when (at least in theory), every file is vulnerable.  VS considers the entire context of the user action to determine whether to allow the item or not.

VS 3.0 was quite robust, but VS 4.0 is even more secure, and this is one of the reasons why.  So when someone says "Product X already has a whitelisting feature, so you do not need VS", they are simply unaware of VS's advanced features.  It is partially my fault because I do not publish our entire playbook.  This is particularity true when Product X's whitelisting feature is largely cloud based (I could write another book on this).

I hope this makes sense... if not, please let me know, I could write a book on this subject and some of the other advanced features that I have developed and integrated into VS the last several years.


This makes sense to me - and I will never be confused for a geek, thus my handle 'oldschool" (heck, I only got a smartphone 2 months ago!). As to your other post, I have 447 items in my whitelist which I reset about a month ago. I have very few 3rd party apps. I'm using Windows version 1803.
2
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 06:06:35 pm »
Feature request: editable whitelist entries. The command line entries are editable, and that is great, and I would like the same with the whitelist entries.
Why?
Because after running VS for a couple days, I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
Thank you for the suggestion... I can play around with this and see how it goes.  My initial concern is that everything (process name, path, hash, etc.) has to match absolutely perfectly with the whitelist in order for an item to be allowed.  So it is probably best just to have VS automatically whitelist the items, but we can play around with it and see ;).

As far as dismhost is concerned... I probably just need to update the dismhost auto allow feature in VS.  They must have made some changes or something.  What version of Windows are you running? (I am assuming the latest 10).  Can you think of anything you can tell me that will automatically trigger this block, so I can reproduce the error?  Thank you!
Thanks, Dan.
I am on Windows 10 pro x64 1809, which the latest, but not necessarily the greatest.
If you want to see the block right away, probably it will happen if you manually initiate "Start maintenance" from Control panel/System and Security/Security and Maintenance.
Cool, thank you, I will check it out right now.  If I am unable to reproduce the issue, I might ping you back and ask you a couple more questions.
3
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 06:05:25 pm »
@VoodooShield

Researcher Bypasses Windows UAC by Spoofing Trusted Directory!

https://www.securityweek.com/researcher-bypasses-windows-uac-spoofing-trusted-directory

Glad we have VS!  8)
Interesting, thank you for the info TH!  Yeah, UAC was never designed to be a security mechanism.  I remember when I first heard about UAC that was going to be released with Vista... I was super excited because I was tired of my clients computers being infected.  UAC has made a lot of progress over the years, but I was completely disappointed in the escalation of privileges design (and that it was not intended to be a security mechanism), rather than a robust security tech.  Then again, if this were the case, we never would have created VS and we never would have met ;).
4
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 05:51:32 pm »
I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
I have numerous entries for chrome.exe, firefox.exe, conhost.exe, winword.exe ... and so on. I'm guessing some of these are due to executable version updates. IIRC Dan said that there is no performance issue here.

Correct. This is my experience with the whitelist as well -> VS with Windows Defender = no performance issues for me. In fact, last night I copied a 4GB file and it took seconds. This on a 9 year old i3 machine!
Very cool... just out of curiosity, how many whitelisted items do you guys have?  What is the record? ;).  I bet it is under 5,000... which should be perfectly fine.
5
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 05:49:50 pm »
BTW, let me look at the code... I might be able to see if we can remove even more old whitelist entries from the whitelist from when the parent was updated and has a different hash, during the whitelist cleanup on startup.  I hope I am saying that correctly and that it makes sense... if not, just let me know!
6
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 05:47:45 pm »
I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
I have numerous entries for chrome.exe, firefox.exe, conhost.exe, winword.exe ... and so on. I'm guessing some of these are due to executable version updates. IIRC Dan said that there is no performance issue here.
In the whitelist tab, you can scroll over to the right and you will see the parent process, hash, and other info.  Most likely there are duplicates because a different parent process called that whitelisted process.  This was a feature that I implemented in VS 4.0, which is the main reason we initially had a lot of unwanted blocks, until I could work out all of the bugs.

A lot of people think of VS as just another application whitelisting utility... and that aspect of VS would be absolutely true if all VS did was whitelist based on hash, and possibly path or file size.  One of the many things that sets VS apart from other application whitelisting utilities is that it has many, many attribute checks on the whitelist... and one of the most important and easy to explain is the parent process check.

For example, cmd or powershell has the ability to be good or bad... and it all depends on the context of the item.  And this is pretty much true with any process / executable, especially ones that are abused and vulnerable.  So the reason you have several different items listed in the whitelist for the same process is because VS is simply whitelisting the context of each user action, so that it can later perform parent process path comparison when the item is later launched.  As an example, you might want to manually launch cmd.exe, but you certainly do not want Chrome to launch it without your permission ;).

Simply classifying individual files as good or bad, and adding the "good" ones to the whitelist, makes little sense to me, especially when (at least in theory), every file is vulnerable.  VS considers the entire context of the user action to determine whether to allow the item or not.

VS 3.0 was quite robust, but VS 4.0 is even more secure, and this is one of the reasons why.  So when someone says "Product X already has a whitelisting feature, so you do not need VS", they are simply unaware of VS's advanced features.  It is partially my fault because I do not publish our entire playbook.  This is particularity true when Product X's whitelisting feature is largely cloud based (I could write another book on this).

I hope this makes sense... if not, please let me know, I could write a book on this subject and some of the other advanced features that I have developed and integrated into VS the last several years.
7
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by Shmu26 on Today at 05:19:55 pm »
Feature request: editable whitelist entries. The command line entries are editable, and that is great, and I would like the same with the whitelist entries.
Why?
Because after running VS for a couple days, I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
Thank you for the suggestion... I can play around with this and see how it goes.  My initial concern is that everything (process name, path, hash, etc.) has to match absolutely perfectly with the whitelist in order for an item to be allowed.  So it is probably best just to have VS automatically whitelist the items, but we can play around with it and see ;).

As far as dismhost is concerned... I probably just need to update the dismhost auto allow feature in VS.  They must have made some changes or something.  What version of Windows are you running? (I am assuming the latest 10).  Can you think of anything you can tell me that will automatically trigger this block, so I can reproduce the error?  Thank you!
Thanks, Dan.
I am on Windows 10 pro x64 1809, which the latest, but not necessarily the greatest.
If you want to see the block right away, probably it will happen if you manually initiate "Start maintenance" from Control panel/System and Security/Security and Maintenance.
8
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 05:10:15 pm »
Thank you TH and Andi... yeah, all modes except Disabled will return to what they were before reboot.  Disabled will return to whatever previous mode was selected.  Before I made the change, Training mode would act the way Disabled mode currently does.  But now, Training mode returns to Training mode after reboot.

We could do the same for Disabled mode, but as Andi was saying, from a security perspective, it is probably best for VS to not ever start in Disabled mode.

Basically, as Andi said "VS remembers every setting after reboot except "Disable/Install" mode!".  Is this the way it VS is acting for you as well TH?

Sorry, I was confused... but I think we are good to go now.

Yes and I was just reporting and I have no issue if it wants to go back to Smart Mode! The only reason I mentioned it is when I update my NVIDIA Drivers on my new Alienware 17R5 it uninstalls the older version and does a reboot and starts to install even before the system fully starts but I haven't had any issues so far.
I see... it makes perfect sense now.  What I might be able to do is if the previous mode was Disabled, we can put VS on training instead of the actual previous mode before the reboot.  This would be a super simple change... actually, there are only a few very simple lines of code that controls what mode VS will start in on a reboot... so it is super easy to change or fix it.  We just have to test on a few different computers to make sure it is working properly.
9
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 05:07:21 pm »
Feature request: editable whitelist entries. The command line entries are editable, and that is great, and I would like the same with the whitelist entries.
Why?
Because after running VS for a couple days, I already have 4 user-allowed entries for dismhost. If I could wildcard the random part of the path, then one entry would do the job.
Thank you for the suggestion... I can play around with this and see how it goes.  My initial concern is that everything (process name, path, hash, etc.) has to match absolutely perfectly with the whitelist in order for an item to be allowed.  So it is probably best just to have VS automatically whitelist the items, but we can play around with it and see ;).

As far as dismhost is concerned... I probably just need to update the dismhost auto allow feature in VS.  They must have made some changes or something.  What version of Windows are you running? (I am assuming the latest 10).  Can you think of anything you can tell me that will automatically trigger this block, so I can reproduce the error?  Thank you!
10
VoodooShield / Re: VoodooShield v4 STABLE Thread
« Last post by VoodooShield on Today at 04:57:34 pm »
Dan - Just installed 4.66 and it started in disabled mode. Did not notice until the reminder popped up. It is normally run in Smart Mode. I think this has happened before.

Yesterday running 4.65 I had a reminder to start VS but I do not remember stopping it.

David
Hey David... thank you for letting me know.  As a test to see if the issue is going to come back later, you might try to reinstall VS 4.66 over the top of 4.66.  If that acts up, then we certainly have a bug somewhere ;).  Thank you!
Pages: [1] 2 3 ... 10