Are there any firewalls that are bound by hash checking that would prevent an application from simply taking the location and name of another and thus getting their permissions? If that even something to be concerned about, or am I just being needlessly paranoid?
Wasn't that about the issue why Steve Gibson released his first LeakTest back in 2001 ? Name and path are not enough. There was a reason why file-integrity-checker NISFileCheck was made back at those years (no, it is not available anymore, but I do have it). Anyways, things have so much changed ...
VoodooShield isn't a firewall but now that WhiteListCloud is incorporated it creates block rules in Windows Firewall for files it determines are unsafe by default. It does check the hash among other factors, and that allows you to check the hash on VT or elsewhere before you allow it. You can even choose files to blacklist manually.
It should probably be an optional feature.. Optional because non-tech folk may find it frustrating to be prompted again and again for the same applications every time they update. A firewall doing static hash checking on an exe, while certainly not a bad thing for marginal gains, has limited use I think. If malware is in a position to both run and then replace another file in order to gain network/internet access, it could just as easily replace or modify a dll it knows the legitimate application will load. The firewall would need to check the validity of every file the executable loaded (including browser addons) and also monitor in memory to prevent code injection etc. If your system is badly compromised you can't trust a software firewall to help at all unless it's external to the compromised machine. I would sooner rely on other security software and OS security features to protect the integrity of applications and prevent malicious software running in the first place. Potential entry points like browsers should be untrusted and sandboxed to prevent them making system changes should they become compromised.. And if you want to go one step further use an external firewall to monitor/control traffic from your system.
local hash checks are pointless, they only show up that exe file has changed but not why and if the file is still valid (approved update, eg firefox). so you need external approval and that makes a local hash check useless.
Or else run an app with full-on anti-exe capabilities such as VoodooShield, SecureAPlus, & EXE Radar Plus. And/or use a file integrity checker such as AdInf.
IMHO this is not practical to do on a real system. The problem starts when you realize that the an application is not only made up of its executable, but also of all external libraries (let's say .dll files) that it uses. Any of these libraries can also get replaced, so at a minimum, a firewall that you are looking for would have to scan all of these files. These can account to hundreds of megabytes in total for each application, resulting in serious performance losses due to constant disk activity and memory thrashing. You might be able to offset this with extensive caching, but this would only work after a "warmup" period after each system boot. Then there are also scripts, dynamically compiled code, and code injection to also take care of. But such a protective measure would also be kind of useless. If you assume that malware can replace installed applications on your computer, then it more or less implies that the malware has already gained administrative privileges. Meaning it can already do anything it wants on your system, including but not limited to doing damage to files, disabling anti-malware and firewall etc. If you want to prevent a malware from taking over the identity of an application, the solution should be sought in access controls and not in firewall technology. This includes installing applications that you want to protect to protected locations (folders that require administrator rights). For further protection, untrusted software should run under virtualization, and their identity and source should be verified before even running them.
AV does that, but usually only when file is written to disk. There is not point to check hash when there are not handles to file. There is small improvement in security when file is checked when there is handle to only read or execute file, but comes at performance cost. You are right when it comes to executables inside directories as Program Files. They are protected by OS permissions related to files. On the other hand many programs install themselves inside AppData.
Very unfortunately, true. Sometimes these applications let you choose between installing for all user or only the current user, in such a case the former should be chosen for security. And when there isn't such a choice, 1) the user could manually adjust the permission on the program's directory inside AppData, and 2) the developer should be contacted to let him know of the problem. There is also the Windows Store. One of the problems it actually addresses very well is security. It installs applications to a user-specific directory that is properly secured, AND runs the applications in secure containers. The downside is of course the associated Microsoft account and that it is hard to use offline, but if that's okay for you (and your app is available in the Store at all), then I can recommend it, for the obvious security reasons.
Actually, most firewalls with HIPS have always offered this feature. As soon as some .exe file has been changed it alerts you about it. So let's say malware tries to bypass the firewall with this simple trick, it won't work. But you're right, there are plenty of other ways to bypass the firewall.
Are you sure they do it for the whole dependency chain? I think they only do it for the executable itself, which makes the performance acceptable of course, but doesn't provide a real security advantage as it is easy to bypass.
No correct, I believe they only check the .exe file, so if you have already made a rule, then they know if the .exe file has been changed or not. So if you didn't update some app yourself, you already know there is something fishy going on. BTW, I never use auto-update, I always update manually.
So then what I wrote still stands. My reason for claiming earlier that it is not practical to do hash verification is because you *have* to scan all dependencies, otherwise the whole protection mechanism is useless. If the AV only scans the executable, the only thing malware has to do to circumvent the protection is to replace a DLL file in the program's directory instead of the main EXE. This and similar protection mechanisms are why I generally do not support HIPS and various security software. I've seen way too often they implement flashy protections that only look good on the surface, but once you dig deep enough you realize they provide no real benefits. The security software market is way too overcrowded with lots of quackery and companies hoping to make easy money, but only few of them provide real protection. They still all survive because it is too easy to provide users with a fake sense of security, all you have to do is show some shield icons, red and green colors, maybe ask about a few irrelevant events happening on your system. And if the computer gets infected, you can always blame it on the user.
I have also never heard of malware being able to do any damage by simply replacing or modifying some .EXE file. I don't even know how it would work, I guess in theory you could replace a legit browser like firefox.exe, with a modified one with trojan capabilities?
