ESS V9.x - A 2nd HIPS Interactive Bug (-> check all your new relevant HIPS rules, if you trusted V9 blindly)

[mma64 7]

- this is an easy one to reproduce, within 5 minutes (see the screenshots for proof) (ESS V9.up-to-V9.0.349.0, for sure in Win7 Pro 64-Bit):

0. enable HIPS interactive mode

1. run a 'cmd.exe' ("DOS"-box, in german "Eingabeaufforderung")

2. (You can do this with any program, but it has to be one without an existing HIPS rule for 'write to file, Rescache'!) type 'fc /b this.txt that.txt<ENTER>', store the two HIPS popups regarding 'svchost.exe' and 'conhost.exe' (I think these two popups will appear).

3. press UP arrow, to fetch previous command line, ie. the 'fc /b this that', and <ENTER>

4. repeat 3. (20 - 48 times) until a new HIPS popup appears, 'fc.exe, write to file, Rescache' -> screenshot  #1

5. carefully look at screenshot #2 (radio button, 2 checkboxes, select 'C:\Windows\Rescache\*' in ListBox)

6. everything ok (screenshot #3)? Then click ALLOW button. New HIPS rule is stored.

7. check the newly created HIPS rule in the HIPS rule "storage space", ie. where all HIPS rules are -> screenshot #4, your selection disappeared!!!

 

This may or may not be the case for all HIPS rule ListBox selection cases, be it "write to file", "delete file", "modify registry" etc pp.

 

Plus, not bugs, but significant time consuming usability annoyances:

- be it HIPS popup, be it firewall popup, the checkbox "log this incident" must be visible in the popup!!! (In case of the firewall popup it's a regression, ie. in previous versions it was there, not in ESS V9!)

- be it HIPS popup, be it firewall popup, the description field must be visible.

- HIPS popup: as in the firewall popup the full file path has to be visible.

 

It's incredible how much user time is wasted without these three usability musts!!!

 

Thanks.

 

[mma64 7]

- "push" - come on, ESET, nearly three months are gone and you aren't able to reproduce this crystal clear, highly annoying bug, existing even in ESS V9.0.375?!!

 

- this new way it will take you a miniscule minute of your precious time to proof me right:

 

1. enable HIPS interactive mode. And rename the ".txt" to ".bat" (".bat" not uploadable).
2. run a 'cmd.exe' ("DOS"-box, in german "Eingabeaufforderung")

3. execute the attached harmless batch file by typing "it-is-SO-easy.bat" and pressing <ENTER> (ok, using MS$$$ Explorer and double clicking this file should be enough too?! is enough!, carefully following the ridiculously easy steps in screenshot #1. (Press "ALLOW" (radio button "ask every time") for 'svchost.exe' and 'conhost.exe', if they should pop up.)

4. check the created new HIPS rule in "setup : advanced setup: antivirus: HIPS: rules edit" and admire the wrongly chosen ALL targets register ('tab'). Bug proven!!!

 

- this bug exists in HIPS fileOps (verified), regOps (verified) and peOps (not verified, but I'm pretty sure...).

 

- contents of the ".bat":

rem ESS V9 HIPS bug proof - DO IT!!! Within less than a minute you will see this annoying bug proofed... 05.05.2016 mma64
rem works on Win7 Pro, 64-bit, eventually you have to take another file than 'license.rtf'
rem in *this* case you should answer the HIPS popup with 'store permanently, DENY, C:\Windows\System32\* (from the ListBox)',
rem in real world HIPS popups you would answer with something more like 'store permanently, ALLOW, x:\..\..\* (from the ListBox)'...
rem
rem *************************************************************************************************************************
rem *** if you have no 'C:\Windows\System32\license.rtf' - make a copy of any (small(er)) file, rename it to 'license.rtf',
rem *** delete the 'rem ' in the next line and add 'rem ' in the line below the next line, save this file and run it...
rem *************************************************************************************************************************
rem copy license.rtf C:\Windows\System32\license-(should-not-be-written).rtf
copy C:\Windows\System32\license.rtf C:\Windows\System32\license-(should-not-be-written).rtf

 

 

- and don't forget the usability annoyances please, see my first posting! Not only I am wasting incredible amounts of time because of these usability omissions but all ESET users using ESS V9...

 

(06.05.2016 19:50: simplified running the ".bat" file)

 

thanks

 

it-is-SO-easy.bat.txt

Edited May 6, 2016 by mma64

[toxinon12345 32]

The wildcard is invalid for a filesystem path; it should be *.*

[mma64 7]

@toxinon12345: sorry, regarding valid file system paths in ESS HIPS I have to contradict you, ie. in the HIPS popup you have a SelectionListBox and the only thing you can do is selecting one of the suggested items, see the screenshot.

 

I'm seeing 4 downloads of the ".bat.txt". Has anybody tried this out yet?

[toxinon12345 32]

Is that what I tried to say: The wildcard is invalid for a filesystem path. The listbox must show a *.* pattern, else will default to the whole filesystem

For registry paths is OK.

Edited May 6, 2016 by toxinon12345

[itman 1,659]

Big tip!

 

For a directory other than the base directory e.g. C:\Windows for this example, you can use \ \ as follows: 

 

C:\Windows\System32\ \

C:\Windows\SysWOW64\ \

etc.

 

For any rule where you wish to monitor write activity for that directory only and not any associated sub-directories.

 

Eset last year changed the Endpoint HIPS to allow for base directory coding but did not include the same in the retail version. Ditto for file wildcard capability e.g. *.exe, etc. that exists in the Endpoint version but not the retail version.

 

Wouldn't it be wonderful if Eset updated and expanded its documentation in the HIPS area

Edited May 6, 2016 by itman

[Marcos 5,074]

We've made some changes to the HIPS module which should fix this issue. If somebody would like to test before HIPS 1226 is put on pre-release servers, let me know and we can compile it for you.

To itman: please clarify what you mean by "base directory coding" as it's not clear to me nor to our developers.

[toxinon12345 32]

@itman, just curious where you found that syntax of double backslash, (\\), maybe DOS or some WinApi.

Also, it dont work for root volume directory, for example C:\\ dont work !

[itman 1,659]

We've made some changes to the HIPS module which should fix this issue. If somebody would like to test before HIPS 1226 is put on pre-release servers, let me know and we can compile it for you.

To itman: please clarify what you mean by "base directory coding" as it's not clear to me nor to our developers.

For example, C:\Windows.

 

I have tried all combinations; C:\Windows, C:\Windows\, and C:\Windows\ \ in a rule to monitor write activity to only C:\Windows directory and not any sub-directories. None work and I get alerts for write activity to any subordinate subdirectories. However as I previously mentioned, coding a rule for C:\Windows\System32\ \ only alerts for write activity in the System32 directory and not any associated sub-directories i.e. C:\Windows\System32\Tasks, C:\Windows\System32\en-US, etc..

 

The same applies as Toxinon12345 noted; coding C:\ \ doesn't restrict alerts only to the C:\ root directory but includes all subordinate directories. 

 

-EDIT-

 

The way the HIPS should work is if for example, C:\Windows or C:\Windows\ is coded, it means that specific directory and files within exclusively. If C:\Windows\* or C:\Windows\*.* is coded, it means the Windows directory and all subordinate directories and files within.

 

Whatever coding Eset decides to use, make sure we users are informed of it so we can modify any existing rules in use.

Edited May 9, 2016 by itman

[itman 1,659]

@itman, just curious where you found that syntax of double backslash, (\\), maybe DOS or some WinApi.

Also, it dont work for root volume directory, for example C:\\ dont work !

"Trial and error" technique.

 

See my above reply to Marcos.

[toxinon12345 32]

The same applies as Toxinon12345 noted; coding C:\ \ doesn't restrict alerts only to the C:\ root directory but includes all subordinate directories.

To avoid ambiguities, I set the double backslash because I dont want recursivity (I want only the First nested level to trigger).

But that '\\' dont work for the root dir in the volume.

On the other hand, I triggered a rule when c:\windows\explorer.exe was trying to delete the file in the c:\windows directory; just using the c:\windows\\ notation. So is working as expected, exception is the root volume.

[itman 1,659]

On the other hand, I triggered a rule when c:\windows\explorer.exe was trying to delete the file in the c:\windows directory; just using the c:\windows\\ notation. So is working as expected, exception is the root volume.

 

Yes, indeed. That does work. The problem is that when you code, C:\Windows\\, that rule also applies to all C:\Windows\\ sub-directories; not just C:\Windows directory which was the issue I was trying to explain. So if you desire to only monitor write and delete file activity in the C:\Windows directory exclusively, you presently cannot do so. However using "\\" for any subdirectory of C:\Windows does work. It appears to me the problem manifests itself for any directory immediately subordinate to the root directory e.g. C:\Windows or C:\Program Files or C:\Users, etc..

 

And you are correct about the C:\ root directory. No HIPS rule coding appears to work for specifying the directory exclusively. For example, if you wanted to monitor write activity or program startups from the root directory only.

 

-EDIT-

 

Maybe a specific example will get the point across. I want to monitor only file write and delete activity in the following directories. I do not want to monitor same activity for any additional directories that might be located with a specified directory.

 

C:\Windows - coding C:\Windows\\ doesn't work. What happens is the HIPS rule is activated for any additional directories and their subdirectories within C:\Windows. In other words, it is the same as if I coded C:\Windows\*.*

 

C:\Windows\System32 - coding C:\Windows\System32\\ works correctly.

 

C:\Windows\System32\Drivers - coding C:\Windows\System32\Drivers\\ works correctly.

 

etc..

 

Hopes this helps.

Edited May 9, 2016 by itman

[toxinon12345 32]

What I understood is that folders are just some type of Null-zero-byte files. So, only the First level would be affected.

Speaking about registry access, keys and values are treated by different functions

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724875(v=vs.85).aspx

Edit: another one undocumented: leaving the list for source apps in blank, and then switch between ["Specific applications" | "All applications"] makes a difference for triggering, related to overriding.

Edited May 9, 2016 by toxinon12345

[itman 1,659]

Relating to HIPS rules pertaining to the registry, most work as expected with a small "glitch" that I will explain below.

 

I have HIPS rules where I want to monitor registry write activity when a new service is created or an existing service value keys are modified. Additionally, I want to monitor any registry write activity for any changes that occur in value keys associated with the ServiceDDL key for any service. 

 

I do not want to be alerted for any other write activity for any subordinate service registry keys other than given above. The following HIPS coding accomplishes this:  

 

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\*\\
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\*\\
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\*\\
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\*\Parameters\ServiceDLL
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\*\Parameters\ServiceDLL
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\*\Parameters\ServiceDLL

 

The glitch I mentioned previously is the HIPS will not alert when a new service key is created e.g.HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\newservice. However, the HIPS will alert when a subordinate regular or value key for newservice is created e.g. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\newservice\parameter. This is not an issue because creation of a new primary key in itself does nothing since it is just a placeholder in the registry. It is the value keys associated with the primary key that the OS will use for processing instructions.

 

I also find it interesting that the coding notation of "\*\\" works for registry HIPS rules to define a specific path in the registry with no path transversal. However, similar coding is not permitted for file/directory paths since the use of an "*" is not allowed e.g. C:\Windows\*\\ to specify that directory exclusively with no path transversal.

Edited May 10, 2016 by itman

[Marcos 5,074]

First of all, try installing the latest version of the HIPS module 1226. Download HIPS module files from here and here and save them to a disk. In safe mode, replace the original files in the ESET install folder.

If I understood correctly, it should address the issue reported in the initial post. Currently we're now working on rules for extensions and then we'll try to enhance rules so that it's possible to limit their applicability to a specific folder instead of all subfolders as well.

[itman 1,659]

I should add that coding for example C:\Windows\\ works in the "targeted applications" HIPS tab - go figure? If you code a HIPS rule for example to monitor program start activity with a targeted application of C:\Windows\\ specified, you will only receive alerts for application startups in that directory exclusively.

 

This leads me to believe that the HIPS is treating directories/folders as files in the "targeted files" HIPS tab if an application root directory is coded in that section. Weird indeed ................. 

Edited May 10, 2016 by itman

[toxinon12345 32]

Good! Is now working with HIPS 1226

[itman 1,659]

@Marcos - A suggestion on the HIPS directory issue.

A few Endpoint solutions use special characters to indicate whether path transversal shall occur. For example, McAfee's Endpoint solution uses the ampersand character i.e. "&" to indicate no path transversal is to be done. In addition, it uses the asterisk character i.e. "*" like Eset to indicate path transversal is to be performed. Both characters are used in file and registry rule coding.

I like this approach since it removes any ambiguity and error risk of using the existing double slash mark coding.

[Marcos 5,074]

To Itman: we would like to focus now on things that worked for you in v8 but don't work with v9 as there should be virtually no difference in how HIPS behave. Since multiple issues have been reported here in the forum even within same topics, our engineers would like you to:

1, make a list of these issues

2, provide us with your rules (we'll keep them confidential and will be used only for our internal testing)

3, provide step-by-step instructions how to reproduce them (a demonstration video would be helpful).

 

Once we get this sorted, we'll focus on new features that were not supported in v8 either.

[chrcoluk 2]

Can I use this new hips module on v8?

 

and yeah itman has great rules, I try to find posts where he posts a few so I can copy but he wont release the whole set :/

Edited May 13, 2016 by chrcoluk