Firewalls with hash checking

Discussion in 'other firewalls' started by n8chavez, Jan 10, 2020.

  1. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    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?
     
  2. FanJ

    FanJ Updates Team

    Joined:
    Feb 9, 2002
    Posts:
    4,632
    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 ...
     
    Last edited: Jan 10, 2020
  3. Krusty

    Krusty Registered Member

    Joined:
    Feb 3, 2012
    Posts:
    10,193
    Location:
    Among the gum trees
    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.
     
  4. RioHN

    RioHN Registered Member

    Joined:
    Mar 14, 2017
    Posts:
    117
    Location:
    Here
    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.
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    Assuming you're deploying a top tiered integrated AV solution, I would say you are.
     
  6. Brummelchen

    Brummelchen Registered Member

    Joined:
    Jan 3, 2009
    Posts:
    5,858
    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.
     
  7. popescu

    popescu Registered Member

    Joined:
    Sep 1, 2018
    Posts:
    259
    Location:
    Canada
    That is enough, at least you can investigate if you know that hash changed.
     
  8. bellgamin

    bellgamin Registered Member

    Joined:
    Aug 1, 2002
    Posts:
    8,099
    Location:
    Hawaii
    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.
     
  9. ultim

    ultim Developer

    Joined:
    Oct 12, 2011
    Posts:
    703
    Location:
    Hungary
    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.
     
  10. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    1,999
    Location:
    Member state of European Union
    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.
     
  11. ultim

    ultim Developer

    Joined:
    Oct 12, 2011
    Posts:
    703
    Location:
    Hungary
    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.
     
  12. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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.
     
  13. ultim

    ultim Developer

    Joined:
    Oct 12, 2011
    Posts:
    703
    Location:
    Hungary
    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.
     
  14. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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.
     
  15. ultim

    ultim Developer

    Joined:
    Oct 12, 2011
    Posts:
    703
    Location:
    Hungary
    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.
     
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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?
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.