Ver. 10 HIPS bugs

[itman 1,659]

This issue is troubling to say the least.

 

I will create a HIPS rule to monitor certain activity i.e. "ask" rule. It doesn't matter what I am monitoring since this issue has manifested on all the actions. Later I get a HIPS alert triggered by the "ask" rule. I then create an "allow" HIPS rule for that activity. A period of time elapses and the "allow" rule works perfectly. Then unpredictably, I receive an alert from the HIPS "ask" rule for identical process activity for which I had previously created an "allow" rule for. And yes, I did verify that the details of the alert were identical to those previously displayed when I created the "allow" rule. After allowing the activity w/o any rule creation, I can repeat the same previous activity and receive no alerts?

 

Most important to note is the above activity is random in nature making the situation all more frustrating.

 

HIPS support module: 1253 (20161025)
Script scanner module: 1008 (20161020)

Edited November 12, 2016 by itman

[itman 1,659]

Forgot to mention that I have the HIPS set to Smart mode. I am now wondering if Smart mode in ver. 9 and 10 is not compatible with user created rules? I ran into this same issue in ver. 9.

 

I will switch back to the default Automatic mode and see if that stops this behavior.

[mma64 7]

[itman] Then unpredictably, I receive an alert from the HIPS "ask" rule for identical process activity for which I had previously created an "allow" rule for. And yes, I did verify that the details of the alert were identical to those previously displayed when I created the "allow" rule.

 

@ESET: have you read this carefully?!?...

 

As bad this is for you, itman, I'm somewhat more than "happy" it's happening even in ESS V10, as I hoped (and expected *) it happening! This is the dreaded HIPS duplicates popup bug I'm writing about since a very long time, but ESET isn't listening... Here this bug in a slight variant, ie. by making a general HIPS ASK rule and then storing a very specific ALLOW rule that in rather unpredictable time intervals triggers the very same popup again as if ESS V9 / ESS V10 has forgotten this already stored rule!!! (Read here ("Phew! Finally I'm able to reproduce this bug, even with ESS V9.0.381, at will, at any time, and producing any amount of the same HIPS duplicate rules"), the really golden opportunity for ESET to catch this nasty bug. And what's ESET doing? Yeah, ESET downloaded the video and total silence thereafter, EPIC!!! At that moment I could store billions of the very same HIPS duplicate, billions!!! (The most unusal case, ever. Usually the very same duplicate pops up only once, then it takes some time until it reappears.) But storing one "new" HIPS rule lasts around 30 seconds in the meanwhile, so I stopped it after ~8 duplicates.)

 

And this seems, as itman reports here, to be completely independent of the mode HIPS is running in (ie. automatic / smart - and interactive, in my case).

 

[itman] I will create a HIPS rule to monitor certain activity i.e. "ask" rule. It doesn't matter what I am monitoring since this issue has manifested on all the actions.

 

Perhaps you could disclose one of these rules or a fake one, this way I could include it into my HIPS rules, running in interactive mode, this could shed yet another light onto the "Mysterious" HIPS Duplicates Bug?! The more activity it triggers the better... Thanks.

 

[itman] I am now wondering if Smart mode in ver. 9 and 10 is not compatible with user created rules?

 

I doubt it. It's just a nasty bug introduced with ESS V9, though even somewhat "prepared" prior to ESS V9, presumably in ESS V8, but at that time not manifesting itself in the highly visible manner as in ESS V9. (Ie. I have proof that even in ESS V8 there were HIPS duplicate popups which I have never noticed, so rare they were...)

 

@itman: it would be a good thing to store some of these HIPS duplicates popups as rules. Because I have written a program that checks the ESS V9 export settings ".xml" and spills out a list of these duplicate rules, checks HIPS rules for source and target files that no longer exist, you can specify as an optional parameter the last HIPS rule ID of ESS V8 (so one would see if there are duplicates prior to ESS V9...) and if

 

@ESET (/anyone) could say / give me a sample ESS V10 export settings ".xml" I could integrate the parsing of ESS V10 HIPS rules (if the XML format has changed - has it???)...

 

Furthermore with my ESS V9 Checker you can check your HIPS log (export it as ".txt") for yet another ESS V9 (and ESS V10 eventually too) bug: wrong log entries, ie. log entries that have, without any doubt, plain wrong descriptions, let's say source=svchost.exe, target=LogonUI.exe, description should be something like 'allow: svchost.exe (modify state of app, LogonUi.exe)', but log entry shows 'allow: svchost.exe (modify state of app, NetBeans V8.2)'. These wrong log entries happen "near" or "precisely at" a HIPS duplicates popup, but not always. Sometimes wrong log entries are written even if no HIPS duplicate happened, but that's rare. (Oh no, I've reported this bug already, see here, and what's ESET doing? Total silence, EPIC!!!)

 

This ESS V9 (/V10) Checker can be freely downloaded in the near future.

 

[itman] I will switch back to the default Automatic mode and see if that stops this behavior.

 

Nope, I bet on this. But a good idea, try it and report back!

 

(*=ESET: the HIPS duplicates popup bug will not disappear magically, as can be clearly seen by itman's finding even in ESS V10, but only by hard debug work (the HIPS duplicates bug) and by only slight code looking / debugging in the case of the wrong HIPS log entries bug!... Nobody will be able to give you an easy "1-2-3-I-only-ask-for-one-minute-of-your-precious-time-ESET!" bug triggering procedure in the case of the HIPS duplicates bug. It's really a pity that you haven't taken the really golden opportunity to catch this nasty bug, as detailled here... In the meanwhile I don't think I can replicate it - new HIPS rules stored, new HIPS duplicates stored, a lot of duplicates by "ask always" ALLOW'd - interesting detail doing it this way: there are duplicates that always trigger another duplicate or even more duplicates (record case till now: 18!), but only if I'm not storing the first one, ie. if I'm doing the "ask always" - ALLOW'd "thing"!)

 

 

[itman 1,659]

Setting the HIPS to automatic mode did not help. However, I believe I know what the issue is in at least one case.

 

I created a rule to monitor startups in %AppData% and %LocalAppData% select sub-directories in Win 10 AU. Rule works fine as evidenced by receiving an alert for cleanmgr.exe starting dism.exe in a newly created directory in %LocalAppData%\Temp. However and out of blue, I get an alert from svchost.exe trying to start backgroundTaskHost.exe that was triggered by this rule? Note that directory specified in the alert for backgroundTaskHost.exe was the correct one, c:\windows\system32.

 

I believe the problem is the HIPS is misidentifying the actual startup process when multiple child processes are being created. For example, svchost.exe starts backgroundTaskHost.exe which in turns creates and starts a child process in one of the directories coded in the HIPS rule. It might also have something to do with how the backgroundTaskHost.exe child processes is executed; perhaps the API call begin used. Far worse would be if the HIPS in the alert window is misidentifying the actual startup directory for backgroundTaskHost.exe!

 

In any case, this issue makes creating user rules for all practical purposes impossible. It also draws suspicion if the HIPS is functioning properly in any mode regardless of the user rule issue.

Edited November 13, 2016 by itman

[itman 1,659]

In reference to the immediate above posting, I believe I am getting close to finding the bug. Appears if I happen to have the directory open in File Explorer that is being protected by a HIPS rule, it will sometimes but not always trigger one of these unrelated activity HIPS alerts.

Edited November 14, 2016 by itman

[Marcos 5,074]

We have recently discovered a problem that is most likely causing this (ie. that you are prompted for an action even if a rule has already been created). It's not new to v10 and has been there for years, being unnoticed by users. It should be fixed soon by a HIPS module update.

[itman 1,659]

We have recently discovered a problem that is most likely causing this (ie. that you are prompted for an action even if a rule has already been created). It's not new to v10 and has been there for years, being unnoticed by users. It should be fixed soon by a HIPS module update.

Great news, Marcos.

 

Hopes it fixes this issue. BTW - never had an issue with ver. 8 and I had "tons" of user rules. Problem started for me in ver. 9.

[mma64 7]

@Marcos: wow, a life sign from ESET. Hopefully it's exactly the "issue" I'm talking about since months (the "Mysterious" HIPS Duplicates Bug) and not a special case of it. (And, yes, this "issue" exists probably since years, as my ESS Checker program showed me, but it was so rare that nobody could notice it, until ESS V9 was released, where it manifested itself so evidently that nobody can ignore it anymore, as witnessed and reported by SlashRose, itman and me.) And how long do I have to wait until ESET checks (and takes serious) the plain wrong HIPS log entries "issue" (ok, a bug - but call it what you/ESET want(s), the facts speak for themselves), as elaborated by me in this thread and here? And another bad news: wrong log entries exist in the firewall log too, ESS V9 - yes, I know, I know, I have reported this (minor) bug not yet. Once again the description field (rule text) is in some cases wrong, the firewall ID appears instead of the rule text... (Full details will follow in a separate thread. Hopefully ESET will check this somewhat minor bug too! This "issue" is an easy one to find and to correct.) One last wish: if export settings XML structure has changed (has it?), it would be nice if I could get access to one such file, thus I'm able to integrate it into my ESS Checker program. Thanks.

 

[itman] never had an issue with ver. 8 and I had "tons" of user rules. Problem started for me in ver. 9.

 

I too have a whole lot of user rules (>2300 and counting) and the "Mysterious" HIPS Duplicates Bug started by installing ESS V9 over ESS V8 only, ie. immediately after restarting my PC the very first duplicate popup appeared and I said, "a popup for a program that never appeared since years, what's going on here?!! OMG, do I really have to reenter all HIPS rules?!?" Of course, with tons of HIPS rules, it's impossible to remember each and every single one, but if the very same popups reappear over and over again it's not that difficult to see that something very bad is happening...

[SlashRose 25]

Well, that would be something Marcos, but believe it only when I see it, because the error has been very long and could not be so far so far! ( German: Na das wäre ja mal was Marcos, glaube es aber erst wenn ich es sehe, denn der Fehler existiert schon sehr lange und konnte bisher ja leider auch nicht Gefixt werden!)

[itman 1,659]

Believe the issue with misidentified processes is for the most part a Win 10 thing.

 

For example, you want monitor process startup in User\Temp directory. Win 10 does a lot of process startups in the Temp directory using backgroundTaskHost.exe which runs as an AppContainer process under svchost.exe. I have also seen COM+ processes doing the same.

 

The HIPS detects a process startup in the User/Temp directory but misidentifies the actual originator of the process startup. It throws an alert, but the alert shows that svchost.exe is trying to start backgroundTaskHost.exe. Whereas, the alert should be displaying that backgroundTaskHost.exe is trying to start process xxxxx.exe in the User\Temp directory.

 

I do know that COM+ processes have been the traditional "Achilles heel" of HIPS processing. Appears AppContainer run service processes in Win 10 might fall into the same category.

 

Also it appears to me that direct HIPS monitoring of process startup in the User\Temp directory in Win 10 can bork a number of Win 10 system processes.

[mma64 7]

@itman (and ESET): after the ASK rule for "all sources, targets = %LocalAppData%, %AppData% and 'C:\Windows\Temp\', write to file / delete file, log=yes' it's high time for me (and ESET, for both rules) to create itman's "monitor process startup" and look what's happening under Win7 Pro x64, ESS V9.0.408... (Thanks, itman, this gave me some more insight into the "Mysterious" HIPS Duplicates Popup Bug, and, everybody guessed it already, even more duplicates (see the screenshots)!...)

 

[Marcos] We have recently discovered a problem that is most likely causing this (ie. that you are prompted for an action even if a rule has already been created). (...) for years, being unnoticed by users. (...)

 

see screenshot #1: there are two cases of HIPS duplicates: 1. a sudden duplicate popup for the very same (or partial) HIPS rule that was stored days, months or even years ago (the first arrow in the picture). 2. a duplicate popup for the very same (or partial) HIPS rule that was a correctly triggered new one and stored just a few seconds ago (in my case now ~30 - 45 seconds ago, ie. carefully reading the popup and then storing it, whereas the storing taking ~30 seconds with ~2410 HIPS rules!) The second arrow showing such a case, perhaps with a little "twist", ie. extending the suggested storing from a single file to a whole subdirectory.

 

@Marcos/ESET: thus, of what variant of the HIPS duplicates popup bug are you talking about? I fear you're talking about (")variant(") #2, but that's the one that was "being unnoticed by users, for years" (my ESS Checker program revealed me ~4 such cases, pre ESS V9, but because of lacking high precision rule descriptions in the past it's impossible for me to say today, "this was variant  #2 / #1!" What I'm seeing is that some of them have consecutive HIPS IDs). (")Variant(") #1 on the contrary manifested itself only with the release of ESS V9. And seems to have slipped over into ESS V10, as itman states in this thread... (Though I'm not 100% sure, I'm thinking we have two distinct issues here, a somewhat smaller bug/issue (-> #2) and a highly annoying bug (-> #1). Of course you will never catch this quite unpredictable bug (#1) if you're not working with a PC and ESS V9 several days in a row, having some HIPS rules with multiple targets and the two mentioned ASK HIPS rules!!! Hint, ESET, hint: with these two ASK HIPS rules from itman and some automated randomly firing programs triggering these (ASK, but preferably not the only ones) HIPS rules at random intervals, ideally simulating longer periods of inactivity (say 0.5 - 3 hours) with no "user" activity at all too (which seems to accelerate the HIPS corruption...), it should be a piece of cake to force the dreaded HIPS  duplicates popup bug I'm talking about!!! Of course the ESET developers are more than capable to prepare such a PC doing automated random action (preferably with HIPS running in interactive mode) for sure...)

 

Screenshot #2: showing my ESS-HIPS-Old-Duplicates-Popup-Forcer program writing 10 distinct files to %LocalAppData% and then doing 10 file deletes in a row. Whereas the 10 file writes never triggered a duplicate, the 10 file deletes did two times (but not always). Perhaps the key to trigger a duplicate in the 'delete file' case is to wait until the ESS-HIPS-Old-Duplicates-Popup-Forcer program has terminated?!? Which leads to a question: why is (ESS V9 only?!?) not suspending the triggered program / process until the HIPS popup is answered?!! In previous ESS versions I had the firm impression that ESS HIPS is thoroughly suspending the triggered program / process until the popup is answered. (You can easily check out this behaviour with any 'source=xy.exe (or all), start new app, xyz.exe' HIPS rule (ie. by disabling an existing one you have), just wait answering it and see what's happening: the "start new app" target will launch, within ~120 seconds!!!)

Edited December 4, 2016 by mma64

[JWilliams 0]

Interesting - I think I ran into the same situation. After a couple of weeks on HIPS learning mode and seeing over a thousand rules created by very active use (many of which did, indeed, look like duplicates), I reverted to interactive mode and immediately started getting lots of notifications. Needless to say, I reverted to smart mode quickly.

 

Hopefully, fixing this bug will allow learning mode to serve its purpose.

[mma64 7]

@JWilliams: I'm very interested getting my hands on this set of HIPS rules, ie. to see which rules HIPS learning mode has created and whether this worked correctly or created duplicate rules already too, and even more interested if you could consider going back to interactive mode, a few hours, and storing some of the HIPS popups where you think "this must be a duplicate!" (after storing a few of them go and change the description field adding "a duplicate rule?" or something like this). (And with high probability it will be a duplicate, especially considering your "after a couple of weeks on HIPS learning mode"! After a couple of weeks on HIPS learning mode there shouldn't be any not yet registered HIPS events... (Except installation and running of new programs, starting of programs never run during the HIPS learning mode time period etc.) I could create an upload section on my website for your ESS export settings XML file (the HIPS section would be enough, that's the only one I'm interested in - *) or at least you could run my ESS Checker program over this XML file which reliably identifies all duplicate HIPS rules, ie. as soon as this program is downloadable. Which version of ESS are you using? ESS V9 or ESS V10?

 

Yet another ESET user with HIPS duplicates popups could put some more "pressure" onto ESET which seems to consider this bug as a very "isolated" / "special" issue still... (@Marcos/ESET: beware, your "starter kit" of HIPS rules is in the making! As this case shows once again it shouldn't be that difficult to run into the "Mysterious" HIPS Duplicates Bug!...)

 

(*= open this XML file with a reasonable editor, search for "rules" (including the " character!), you should see something like 'VALUE="User rule: allow ' / 'VALUE="User rule learning mode: allow ', mark everything from here up to "eraAgentProtection" (again including the " char), copy this marked section (ctrl-c, <ctrl><c>), paste it (ctrl-v) into a new file, may be ".txt", save it, PM me a download link. Or upload it. Your choice.)