HIPS fails to block all instances of an application from running [Solved]

The HIPS block rule is not blocking all instances of an application from running.

For example, if you install the new MS Edge browser and set */msedge.exe to be blocked from launching via a HIPS rule it seems to block all attempts of the process to create child processes using the same executable, but fails to block the parent process from running, thus allowing the blocked executable to run.

I.e. It appears that HIPS fails to block applications from running if they instantly and repeatedly try again.

Kind regards,

Reece

Maybe a bit off-topic…

Add a HIPS application custom rule for “C:\Windows\System32\notepad.exe” (my famous example) and set under “ACCESS RIGHTS” all and each “Action” to “Block”.
Now run notepad, open or create a new text file, do some editing in the text file and then save the text file and discover that the HIPS block rule DOES NOT WORK AT ALL. Notepad can do everything it wants.
Why? Because it’s a Microsoft executable and Comodo applies whitelisting to all Microsoft executables and thus dictating hidden allow rules for all Microsoft executables to the user.
The user is not in charge anymore of controlling their own system. No, Comodo CIS is taken over their system and controls it for you.

Try the above with a non-Microsoft executable and discover that the HIPS application custom rule with all and each “Action” set to “Block” does work as it should.

Another instance where hidden whitelisting is applied is here: https://forums.comodo.com/resolvedoutdated-issues-cis/hips-allows-notepad-in-unrecognized-state-t126003.0.html

Comodo, let power-users or advanced-users control their own system and add a feature for them to stop or disable this hidden whitelisting CIS wide!!!

In case of your MS Edge it is no different story. It’s a Microsoft executable so it is allowed to do everything at all times. You don’t have control over it, how nice!

set */msedge.exe to be blocked from launching
first you use *\msedge.exe, second the access rights only applies to what that application can do, not what other applications can do to it. If you block msedge from running other msedge it works, but it does not mean windows explorer or other applications can not execute msedge. For that you need to edit the other application rule to block msedge for run an executable access right i.e. explorer.exe > run an executable block.
Add a HIPS application custom rule for "C:\Windows\System32\notepad.exe" (my famous example) and set under "ACCESS RIGHTS" all and each "Action" to "Block". Now run notepad, open or create a new text file, do some editing in the text file and then save the text file and discover that the HIPS block rule DOES NOT WORK AT ALL. Notepad can do everything it wants. Why? Because it's a Microsoft executable and Comodo applies whitelisting to all Microsoft executables and thus dictating hidden allow rules for all Microsoft executables to the user. The user is not in charge anymore of controlling their own system. No, Comodo CIS is taken over their system and controls it for you.
That's not how the whitelisting works, to block notepad from writing to a text file, the file path must be included under protected files/folders. Otherwise of course it will be allowed, as HIPS is not instructed to monitor the particular file path that you used to save the text file. e.g. if you set everything to block and try to save to the desktop it will be blocked, but if you try to save to the downloads folder, then it won't be blocked because the downloads folder is not protected. Also if you open the HIPS event logs you will see entries of blocked events coming from notepad.

I did use */, just miss-typed here.

Yup you are right, was tired ha ha.

Should note for anyone reading this, if you also would like to block an .exe or any other type of file from running, you can add it to your Blocked Files.

!ot! I haven’t been using HIPS. I go through firewall tasks > Block Application. It’s great that HIPS is there as an option, but HIPS seems like a lot of work to me. How to respond to all those alerts! I’ve been using cruelsister’s setup built around proactive mode and HIPS off, containment on.

HIPS is there for safe applications that are exploited. Something auto-containment may not be able to prevent, especially if it is a fileless attack.

Actually, if you run HIPS in safe mode, you will hardly get any popups these days. You should give it a try :wink:

Check out the cruelsister channel on youtube. There’s a video on fileless malware and she has it set up to block fileless attacks with HIPS turned off. Very fine how she knows her way around the settings. It’s a safe and simplified setup for Comodo.

Regarding trying HIPS: I actually tried it when I first installed CIS and I was discouraged not just by the number of alerts, but by the fact that I was out of my element and had no idea how to respond to most of them. Even a safe app that’s not exploited can exhibit what the firewall considers unusual or suspicious behavior and alerts can and do fly. I would love to see a video tutorial helping users understand how they should respond to HIPS alerts. When I found out about a “safe” setup for novice everyday users I was intrigued. Since then I’ve been using the cruelcomodo setup.

Yeah I’ve seen the video.

Um in theory it should be possible even with both sandbox and script analysis turned on to allow fileless malware to run via an exploited executable.

Via direct disk access or just via the exploited excitable itself it may also be possible to then save a file to disk. HIPS can prevent this type of attack.

With that said, most malware will be via a file you download I guess anyway, so to be fair, that type of configuration is possibly going to block most malware you would typically get.

Basically hardly any application should require access to anything protected by HIPS and cause a HIPS popup on default HIPS settings. So the answer really is for me to just deny each popup (I hardly ever get them). The only time this really changes is if the executable is not known to Comodo that caused it. In such cases I would recommend submitting it on the forum and waiting for it to be whitelisted.

HIPS on Safe Mode will never alert for any Application signed by a vendor rated as trusted by Vendor List, or trusted by Cloud Lookup, unless you have enabled “Create rules for safe applications” setting which will automatically erase existing HIPS rules, including some default HIPS rules and this may lead to alerts, due to a known Bug.

UPDATE:

It seems both HIPS ‘Blocked Files’ and ‘Auto-Containment’ set to block, is not able to prevent an executable from running. It seems to block one instance of it, but not the other.

Adobe Creative Cloud seems to be launching server.js which then launches node.exe.

Even with node.exe listed in ‘Blocked Files’ and given an Auto-Containment rule to block it, it launches anyway.

It shows up in the ‘Containment Events’ log as blocking it multiple times.

Is node.exe running from the same path you made the blocks from or is it running from a different path? Is node.exe running as SYSTEM or being launched by a SYSTEM level process? Also try only using one form of block, either use the block auto-containment rule or just use the blocked files, does node still run then?

  • node.exe always uses the same file path.

  • node.exe is always ran as my user account

  • Using either or both ‘Block Files’ or ‘Auto-Containment’ Block Rule results in a process creation for node.exe. Both blocking methods show in the logs.

Something just out of interest:
When both Block File and Auto-Containment Block are both used, it seems to be the ‘Block File’ option that blocks the file as per the logs.

Using No ‘Block Files’ or ‘Auto-Containment’ Block Rule, results in 2 node.exe processes.

  • CCXProcess.exe → [Runs ‘main.js’] → node.exe
  • CCLibrary.exe → [Run ‘server.js’] → node.exe

Using either ‘Block Files’ or ‘Auto-Containment’ Block Rules or both results in just 1 node.exe process.

  • CCXProcess.exe → [Runs ‘main.js’] → node.exe

What is also interesting, is when trying to add node.exe to Blocked Files using the ‘Running Processes’ option, it doesn’t list the processes by the process names as per Windows Task Manager i.e. node.exe. It lists them as per the script they were launched from i.e. either main.js or server.js. Therefore adding the process via this method (instead of manually finding the file path) adds the script to the blocked files rule instead of node.exe.

I have attached a screenshot to illustrate what I mean.

I can of course block main.js and server.js too and it will finally result in node.exe not launching.

However this is besides the point, as there is clearly a way that an executable is able to be run even if added to the CIS block rules.

There is obviously something different / very particular about the Adobe Creative Cloud launching process. I just tried this in HIPS Block or Auto-Containment with 2 applications to start with (Google Earth and Glary Utilities)

Both were blocked completely with the HIPS Block showing no message, unless I tried to run the executable from the Run command, when the Windows popup warning that I had no rights to run the application showed. Auto-Containment popped up the standard CIS Blocked message each time, no matter how many times

Edit: Also with all Office 365 applications, which with HIPS Block, gives the Windows ‘no permissions’ message (as Explorer is blocked)

Certainly is. Which is great, as there has been a seemingly unknown bypass discovered because of it. :slight_smile:

P.s. Shane, there you go. XD

Looks like you added node to heuristic command line analysis which is why you can’t see node listed in process list. I wouldn’t be surprised if using blocked files on a heuristic application is causing this incomplete blockage.

SOLVED:

Ok, when I said…

- node.exe always uses the same file path

I was wrong.

There are two different node.exe files in similar looking directories. One is in ‘\Program Files\Common Files\Adobe’ the other is in '\Program Files\Adobe'

I just didn’t add both.

Oops!

It is now blocking it. :smiley:

Thank you all for looking into it though!!!

You just saved me a card charge to try that out - thanks ;D

Oh dang! Really glad I just spotted it then!

I was actually recording a video to demo it whilst also making a recording using Process Monitor.

I then cross referenced the HIPS Log with the process and was like… oh… ha ha.