Is HIPS rule processing case-sensitive in Windows file-names?

[carmik 0]

Not sure if this is a bug or not (I think it is though).

Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains:

elevate "C:\Program Files\internet explorer\iexplore.exe"

 

This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie:

elevate "C:\Program Files\internet Explorer\iexplore.exe"

It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well.

Can someone from ESET check if this is an issue indeed, and, if so, provide a fix?

[itman 1,748]

I created a .cmd script containing the following:

wscript.exe "C:\Program Files\internet Explorer\iexplore.exe"

I then created an Eset HIPS rule to block any process startup from cmd.exe. The result was:

Time;Application;Operation;Target;Action;Rule;Additional information
9/17/2021 11:00:59 AM;C:\Windows\System32\cmd.exe;Start new application;C:\WINDOWS\System32\Conhost.exe;Blocked;User rule: block child process startup from cmd.exe;

It appears you are using this utility: https://code.kliu.org/misc/elevate/ ; i.e. elevate, to bypass UAC and elevate to admin privileges. In any case, that should have no bearing on blocking the conhost.exe startup from cmd.exe.

 

[carmik 0]

elevate "C:\Program Files\internet explorer\iexplore.exe"

itman the issue is that the allow rule for the action above does not match the same command when "internet explorer" above is written as "internet Explorer".

[itman 1,748]

24 minutes ago, carmik said:

elevate "C:\Program Files\internet explorer\iexplore.exe"

itman the issue is that the allow rule for the action above does not match the same command when "internet explorer" above is written as "internet Explorer".

It doesn't matter since Eset blocks the conhost.exe startup from cmd.exe. As such, the script would never proceed to the point where the elevate process executes.

Are you stating that this elevate process you're using spawns wscript.exe to run iexplore.exe?

Note the way to run iexplore.exe as you are doing is to create a .vbs script containing the following code:

Quote

Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Run("iexplore")
Set objShell = Nothing

https://stackoverflow.com/questions/1340355/launch-programs-whose-path-contains-spaces

Edited September 17, 2021 by itman

[carmik 0]

Ok, back at work.

The scenario is this: we have a Checkpoint VPN software that does not run well under Windows 10. In order to be able to actually utilize it successfully, a user has to start internet explorer as an admin.

This is problematic as you can understand, since this opens a full can of worms. So we've been instructed to follow this approach: install powertoys and create two scripts. One that launches internet explorer named script.cmd:

elevate "C:\Program Files\internet explorer\iexplore.exe"

And one that resides on the user desktop, named vpn.cmd:

runas /user:local_admin_user /savecred "cmd /c c:\path\to\script.cmd"

So the user runs vpn.cmd, which in turn starts cmd to execute script.cmd. Hope this makes sense now.

The bug (if it is one) is that admin block rules in the eset HIPS policy seem to be case-sensitive, regarding the name of the application used!

[itman 1,748]

15 hours ago, carmik said:

The bug (if it is one) is that admin block rules in the eset HIPS policy seem to be case-sensitive, regarding the name of the application used!

Eset HIPS rules are not case sensitive. See below HIPS log entry of "C:\Program Files\internet explorer\iexplore.exe" startup being blocked from cmd.exe:

Time;Application;Operation;Target;Action;Rule;Additional information
9/20/2021 4:09:23 PM;C:\Windows\System32\cmd.exe;Start new application;C:\Program Files\internet Explorer\iexplore.exe;Blocked;User rule: block child process startup from cmd.exe;

Your problem is related to this. It appears this elevate process you are using is indeed case sensitive.

 Also note that this elevate process not only changes IE permissions but appears to also start it. Existing Eset anti-ransomware rules will not monitor any process startup activity from elevate.exe. HIPS rules are not global in nature. For example; they will monitor IE startup from cmd.exe. They will monitor elevate,exe startup from cmd.exe. If elevate.exe is allowed to start by cmd.exe, anything that elevate.exe starts will be allowed to run. A separate HIPS rule needs to be created to monitor elevate.exe process startup.

Edited September 20, 2021 by itman

[carmik 0]

I see, thank you for your detailed analysis!