Windows Firewall Control (WFC) by BiniSoft.org

Hi Alexandrud, Does WFC use HTTPS or FTP to download new versions ? And check the SHA2 when download completes ? It seems safer that way. I was exploited once while I had that WFC Update rule turned on. Once I re-imaged the machine and turned the rule off before I connected the ethernet cable, I wasn't exploited again. Not saying that that is the definite entry point of the attack, it may be co-incidental. But hey, it doesn't hurt if it does those things, and check the code. Sorry for not being able to beta test v6 in time, I just noticed that you released it.

 

With the missing libraries, it wont be able to prepare the data so it can't send it either.

WFC uses https to download the new installer which is now digitally signed. The update dialog will request administrative privileges and in the UAC prompt that you receive you can see that it is digitally signed. I don't understand how you were exploited in the past with WFC rule turned on before you connected the ethernet cable. WFC never downloads anything unless the user approves it manually.

 

Hi Alexandrud, I meant that I was exploited while I had the WFC Update rule enabled. Then, I re-imaged the hard drive to recover from the attack, and then turned off the WFC Update rule and then re-connected the ethernet cable. I never do configurations while I am online. After the rule is disabled, I was not exploited again.

 

What was the exploit ? How were you exploited ? What happened ? Why you had to restore a Windows image ? How is this related to WFC ?

When you have the WFC updater rule enabled, it only checks an online XML file from binisoft.org website. It doesn't download any file, it doesn't install anything. It doesn't do anything to your computer. I don't get it, I don't understand why you think that you were exploited because of WFC.

 

Hello,

I do not want to disturb, but need to ask a question.

My WFC Version is 5.4.1.0
To install WFC 6.0.2.0 now, I have to deinstall 5.4.1.0.

Does anybody know, how to back up my rules and settings to use them in 6.0.2.0?

Thanks

 

No worries. I said it is not the definite point of entry - meaning the exploit may not have came through that port. But it is just co-incidental that after the rule was deactivated, he didn't attack again. Usually they try to attack again to see if the same vulnerability can still be used. Or maybe they did try again and the exploit failed.

The fastest way to recover, for me, is to restore from disk image. Thus I don't need to check the event logs, check this, check that, find which app has a newer version, check the exploit databases, etc.

But if the attacker has analysed your code, they would know many things; like what the xml file name is that your code is expecting. I don't do much programming nowadays, but may be this is the kind of thing to look for : http://www.informit.com/articles/article.aspx?p=430402&seqNum=3

 

To export user settings, in the Options tab you have a button named Export user settings to a file.
In the uninstall dialog, choose the third option so that the firewall rules will be left as they are when WFC is uninstalled.
After you install version 6.0.2.0, in the same Options tab use the button Import user settings from file. The program will restart itself to reload all settings. If not, restart it manually.

 

Thanks @alexandrud !

I want to say thank you for the new user guide, too!
https://www.binisoft.org/pdf/guides/Malwarebytes-WFC-User-Guide.pdf

 

I must disagree with you on this. The WFC updater needs an outbound rule for port 443. It is not an inbound rule, there is no port open, there can't be any attack from outside world just because you have this rule enabled. Even if the "attacker" has analyzed WFC code, this doesn't change anything. WFC is not a vector of any attack. The only ways to have your security compromised in relation with WFC are:
- You use a cracked version of WFC. In this case, it is user's fault because he chose to use a cracked version instead of an official build.
- A hacker gets access to binisoft.org website and uploads a custom build of the software. Too much work for nothing in return.
- The user executes with administrative privileges a malware that will disable entirely Windows Firewall, no matter what if you have WFC installed or not. This would be probably 99,99% the real problem.

If you really have real proof that you were a victim of an exploit/attack/hitman/whatever because you have used WFC, please post here the evidences. Things like "something bad happened one day, it must have been WFC fault", is just non-sense.

 

I have decided not to import my user settings for the time being so as not to influence the new program.

 

Hi Alexandrud, thanks for the detailed explanation. I get my copy of WFC from your website, latest version. It's free, so there is no need to use cracks. That PC is a clean install, with the following free programs downloaded on their respective websites : NoVirusThanks's OSArmor, and VoodooShield. I am doing security testing, so I only load security programs. I keep one image of the hardened PC with no external programs, and one image, hardened, plus the security programs I am testing.

How often does WFC checks for new updates? After every reboot of a PC? After every account sign in?

 

This is what I always do when installing WFC fresh. The rules panel can become "messy" because of updates and the like so it is nice to get things a bit more organized.

 

When Automatic check for updates is checked, on each wfc.exe startup, after 1 minute. When checking manually, each time the user presses the button.

 

(updated) Sorry to hear the app has or will be sold out for corporate profit; its 2 MB footprint & pocketbook footprint is what made it shine above the rest. I am curious will it stay at the rate you offered it $5 or $10 for a lifetime license, and if it will remain available as a separate install from malwarebytes like adwcleaner. In that case not a big deal but still... if it goes the way of corporate whoredom and bulkware, a sizable chunk of the user base will go elsewhere. Performance wise, Malwarebytes works best off... then run once and a while to detect malware. (I haven't had any detection's in over a year due to safe browsing habits, so whats the use) I never leave it running due to its heavy footprint & telemetry (which goes on even after disabling it), and potential attack surface, but was happy to see after recent updates, they actually disable the svchost service when you exit the program. Now I don't uninstall mwb after each time I use it.

Also the new feature

Awesome feature. Does this mean it will actually block individual svchost processes or does this only provide a name?

 

[updated]

I just realized why I was unable to get WFC updates, because it uses only insecure TLS parameters. I have hardened my schannel curve & ciphers to only use known secure ciphers, that means no CBC, and no Nist curves... the latter is vulnerable to rigid, ladder, twist, complete, ind attacks, (see the table at the bottom of the link) and certain software providers are still behind the curve and have not updated their servers to use the latest algorithms, like adobe creative cloud & WFC for example. If you did not harden your ciphers and curves, it is not out of the question that you had a MITM who hijacked your handshake with WFC update servers, which then injected malware through the connection. Can't know without more detail but given it only uses insecure algorithms, then its possible.



I use only curve25519 with:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Which are the only secure combination in windows at the time of this post. And thus receive a handshake failure when negotiating with WFC servers. SSL Labs have informed me they will be updating their best practices after the latest vulnerabilities. Anyone serious about security will have included the use of aforementioned curves and suites. This must be done on WFC's servers. TLS 1.3 support would mitigate most of these issues, but there are new attacks that can even compromise TLS 1.3 until servers have been patched. As noted by a Chromium dev here, disabling these ciphers on your client doesn't protect you from this latest tls 1.3 attack. If the server supports the ciphers using a vulnerable library (the ciphers themselves are not vulnerable, it is certain implementations) then an attacker can use the vulnerability to exploit otherwise secure ciphers as well. This is why it is of utmost importance, especially for security software providers, to keep their servers up-to-date with the latest ssl libraries, and highest quality cipher and curve specs available.

 

It is necessary to significantly increase the length of this field, because the translation does not fit.
I know that when you select a sound file, it is played once, so a sound file check button would be useful.

 

Windows Firewall can block or allow svchost.exe connections generated by specified Windows service since Windows Vista. This has nothing to do with WFC. WFC is now able to tell which service was blocked based on the Process ID.

You can also manually check for a new version if you visit the website.

Noted.

 

Thank you @alexandrud. I am a little confused. You mentioned previously that windows 10 was unable to distinguish between individual svchost based rules; with wfc blocking one blocked all svchost processes, this has changed? Just to clarify, now you are saying I can use WFC to block individual svchost services effectively without blocking every svchost.exe service at the same time?

 

This was always possible and has nothing to do with WFC. If you check the default firewall rules from Windows 10, a lot of them are defined for specific Windows services. See on the previous page what I meant.

 

Users understand that WFC cannot do what Windows Firewall cannot do.
But if the situation with services svchost is incomprehensible to two users, then it is also incomprehensible to most users, just the majority of users are ashamed to state or ask about it.
Explain, please, once again, in detail and specifically, so that the lamer can understand how it is with blocking individual services svchost.

 

So it was always possible but not in WFC until recently. When cryptographic services was detected and I blocked it, it blocked Cryptographic Services (svchost.exe) C:\windows\system32\svchost.exe; and also added the "cryptographic services" under the services list, which I assume means WFC finally has fine grain control over svchosts now;

Yet you're saying windows update is the only one that does not work with a ruleset?
[update, confirmed, I can block certain aspects of windows update without interfering with other services]

I see its working effectively for most services, without blocking all svchost services at one time. Last I checked comodo can't even do this.

However I believe one connection was made from scvhost.exe that was not listed with a given, "service name". If there is a block rule for svchost.exe with no service name given, will individual allow rules overrule the single block rule?

 

A firewall scheduler would be great to reduce attack surface area immensely. One could create a rule for example to allow wuauserv every second tuesday only. Or allow ssh incoming at a timed interval, which could also be timed on the host machine. Also an option to automatically set 'high' filtering upon idle would be great in high security and attack prone environments; if you aren't online, you aren't able to get hacked and makes it extremely difficult for an adversary to determine your online status and habits. Also, when user is sleeping, PC is completely remote attack surface free. If necessary, it could shut down adapters as well, could prevent arp attacks (though I doubt arp hijacking is possible in high filtering mode) and hardware level vulnerabilities such as the latest AMD Ryzen network based chipset attacks.

 

I am getting svchost.exe with an ID that relates only to svchost.exe, no service listed; I'm assuming "always" blocking this will result in all my other allow/block rules for svchost as being null and void; can you confirm @alexandrud


In which case, with no other alternative, an WFC exclusive 'always ignore' rule would be great.

 

[updated] Confirmed, blocking svchost.exe's constant WFC popups nullifies all svchost service block/allow rules making them pointless and useless; the best solution to this would be for WFC to implement a ignore option (or check box) under "block this program", for each block type ex, 5 minutes, etc), this is effective for any svchost Process ID that does not have an effective service name that can be blocked by windows firewall, and one will not be constantly harassed, nor forced to ignore everything under the svchost umbrella. If this new service process ID blocking feature in WFC is still in its infancy, maybe it will provide more fine control over process ID's with future updates.

Thanks aldist, I do not want to ignore all svchost queries, just specific process IDs.