Jump to content

mma64

Members
  • Posts

    57
  • Joined

  • Last visited

About mma64

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Switzerland

Recent Profile Visitors

1,122 profile views
  1. Wow, a quite fast bug correction, thanks... Yesterday, 20201216 at 17:06:18 CET the bug fix was installed on my PC. Look at the following screenshot, how this looked like. Immediately I switched to "help : installed components : COPY" or something like this. And when I reentered the firewall log view, all fields "target" were populated! Somewhat strange, but it shows me that the bug can't be in the firewall log file as such but in the firewall log view and the firewall export function. - the installed modules: Detection Engine: 22492 (20201216) Rapid Response module: 17445 (20201216) Update module: 1021 (20200218) Antivirus and antispyware scanner module: 1568.2 (20201214) Advanced heuristics module: 1203 (20201015) Archive support module: 1311 (20201125) Cleaner module: 1214 (20200921) Anti-Stealth support module: 1171 (20201106) Firewall module: 1411.3 (20201019) <--- good luck at finding out what module else had the bug, because it's not this one!... ESET SysInspector module: 1280 (20201022) Translation support module: 1833.1 (20201216) HIPS support module: 1403 (20201103) Internet protection module: 1416 (20201120) Web content filter module: 1079 (20201009) Advanced antispam module: 7864 (20201027) Database module: 1112 (20200928) Configuration module (39): 1914.2 (20201102) LiveGrid communication module: 1093 (20201216) Specialized cleaner module: 1014 (20200129) Banking & payment protection module: 1206 (20201202) Rootkit detection and cleaning module: 1029 (20200929) Network protection module: 1685.1 (20201006) Router vulnerability scanner module: 1071 (20201006) Script scanner module: 1084 (20201121) Connected Home Network module: 1040 (20200728) Cryptographic protocol support module: 1056 (20201113) Databases for advanced antispam module: 6176 (20201216) Deep behavioral inspection support module: 1109 (20201013) Advanced Machine Learning module: 1085 (20201207) Telemetry module: 1061.1 (20200706) Security Center integration module: 1026.1 (20201020)
  2. Depending on your level of knowledge this might look so, but I'm pretty sure I haven't made an error in my analysis. Ie. I have exported all firewall (and HIPS logs) since ESET V4 and this is (hopefully - I will check it...) the first time this issue has shown up. The exported log before this bug has all "target" fields populated, and the temporarily exported currrent one has all "target" fields unpopulated! ("25.11.2020 18:54:44" (see previous post) is the last record of the last exported firewall log (as ".xml") and "25.11.2020 18:59:31" (see previous post) the first not yet exported firewall log entry.) You could check this easily too: go into firewall log view, right click and then "export all...", save as ".xml" (or better, depending on your computer proficiency, as ".txt"), double-click the exported ".txt", look at the first record and at the last: "target" field empty or not?!? Which time period do you have? (I have set all values in EIS V14 to "keep the log(s) forever" of course, ie. EIS V14 : setup : advanced setup : tools : log files : automatically delete records older than ... days".) an exported ".txt" firewall log looks like this one record: Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;SHA1;User 25.11.2020 18:54:44;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;THIS-IS-TARGET-FIELD:XXX;TCP;erlaubt XXXXXXXXXXX, 12.01.2020);C:\...\XXX.exe;SHA-1 hash;USERNAME With some luck you could see both states: records with target field empty and populated. If there are populated ones, hovering them will show its content in EIS firewall log view too, of course - except there's a bug in the log view too!... This would be an interesting check, if you could do it, please, I can't because - that's really crazy! - I made this last firewall log export about three minutes (!!!) after this AV update occured!
  3. @jsb "damn it!", you were a little bit faster than I... But the following prepared post was too deep in the night written and I was too tired to post it after finishing it! I doubt this, more on this later today eventually. This would mean that the bug (thanks for confessing this, @Marcos) would be a log view problem or the like. Fact is, even exporting leaves the "target" field empty after a highly specific point in time! read on, the mentioned prepared posting at full length: here c & p directly from firewall log view working still...: 19.11.2020 15:53:38;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;XXXXXXXXXXXX:80;TCP;Allow XXXXXXXXXXXXXXXXXXXXX;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; ... today I noticed field "target" always empty, doing the very same c & p as above: 25.11.2020 18:59:31;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;NO-TARGET-FIELD-CONTENT-ANY-LONGER!!!;TCP;Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018);XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; conclusion: something very bad happened in between this time frame! But when did this happen exactly?!? even exporting the firewall log has this very same error now!... (the following one not a current one, but the FIRST non-working firewall log entry!): <RECORD> <COLUMN NAME="Time">25.11.2020 18:59:31</COLUMN> <COLUMN NAME="Event">Communication allowed by rule</COLUMN> <COLUMN NAME="Action">Allowed</COLUMN> <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="Target"></COLUMN> <--- BUG, BUG, BUG: bad, VERY VERY BAD!!! <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018)</COLUMN> <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> </RECORD> ... but I'm able to nail down the bug insertion within a 5 minutes period (without any firewall log entries in between these two)!: <RECORD> <COLUMN NAME="Time">25.11.2020 18:54:44</COLUMN> <COLUMN NAME="Event">Communication allowed by rule</COLUMN> <COLUMN NAME="Action">Allowed</COLUMN> <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="Target">XXXXXXXXXXXXX:80</COLUMN> <--- good! <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, XX.XX.2020)</COLUMN> <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN> <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXX</COLUMN> </RECORD> somewhat mysterious is the fact that within this time frame there was no EIS update whatsoever?!?: ?Time;Component;Event;User 25.11.2020 13:00:43;ESET Kernel;Detection Engine was successfully updated to version 22377 (20201125).;SYSTEM 25.11.2020 14:54:55;ESET Kernel;Detection Engine was successfully updated to version 22378 (20201125).;SYSTEM 25.11.2020 16:54:55;ESET Kernel;Detection Engine was successfully updated to version 22379 (20201125).;SYSTEM <--- look at THIS! 25.11.2020 20:54:55;ESET Kernel;Detection Engine was successfully updated to version 22380 (20201125).;SYSTEM 26.11.2020 00:54:56;ESET Kernel;Detection Engine was successfully updated to version 22381 (20201125).;SYSTEM a summer time / winter time bug (?!?). Here, at my location, we have CET time. And 16:54:55 could be, assuming such a bug / "issue", very well be 18:54:55 (= +02:00 hours). Timestamps are displayed correctly in general. But Win7 messes all times displayed up - after switching to for example winter time. Ie. correctly stored / displayed timestamps in summer time are WRONG after said switching to winter time. All of them. Eventually forever. They might be correct again during the next summer time. Now your developers have all informations they need to eliminate this catastrophic bug. As fast as possible. @MarcosMay I suggest logging the versions of all modules that are updated during an AV update too?! Because it can't be the "Firewall module: 1411.3 (20201019)" which is the current one installed on my PC...; wait a moment, it could very well be this one - because, as you know very well, there's a (huge) gap between new module versions and the arrival on a user's PC / Laptop / whatever device... here are the currently installed module versions (EIS V14.0.22): Detection Engine: 22482 (20201214) Rapid Response module: 17435 (20201214) Update module: 1021 (20200218) Antivirus and antispyware scanner module: 1568.1 (20201207) Advanced heuristics module: 1203 (20201015) Archive support module: 1311 (20201125) Cleaner module: 1214 (20200921) Anti-Stealth support module: 1168 (20200908) Firewall module: 1411.3 (20201019) ESET SysInspector module: 1280 (20201022) Translation support module: 1833 (20201202) HIPS support module: 1403 (20201103) Internet protection module: 1416 (20201120) Web content filter module: 1079 (20201009) Advanced antispam module: 7864 (20201027) Database module: 1112 (20200928) Configuration module (39): 1914.2 (20201102) LiveGrid communication module: 1087 (20201204) Specialized cleaner module: 1014 (20200129) Banking & payment protection module: 1206 (20201202) Rootkit detection and cleaning module: 1029 (20200929) Network protection module: 1685.1 (20201006) Router vulnerability scanner module: 1071 (20201006) Script scanner module: 1084 (20201121) Connected Home Network module: 1040 (20200728) Cryptographic protocol support module: 1056 (20201113) Databases for advanced antispam module: 6166 (20201214) Deep behavioral inspection support module: 1109 (20201013) Advanced Machine Learning module: 1085 (20201207) Telemetry module: 1061.1 (20200706) Security Center integration module: 1026.1 (20201020) kind regards
  4. "wow", this time a fast HIPS module update, automatic AV update has just fetched HIPS V1331.1-20181025, subdirectory '..\1543\' - and guess what: no more the totally same "get access to another application" HIPS popups appearing over and over again, if in HIPS interactive mode and "daring" to save them! (And subdirectory '..\1541\', HIPS V1332-20181008, was deleted automatically.)
  5. @MathewCXT: If you were in learning mode then check your HIPS rules please: it might be choke full with (empty, see picture #2) learning mode rules regarding "get access to another application" ones... (As explained above: you will never get out of the "get access to another application" HIPS popups loop if you "dare" to save the seemingly new HIPS rule(s)! And the corresponding program will never proceed with opening (XYplorer, Firefox) - unless you answer the popup with "remember until application quits" plus ALLOW button. Closing the program and restarting it leads to the same HIPS popup madness again...) The only HIPS mode you will notice this bug is the interactive one. @Rami: Not the case with EIS V11.2.63 to this very moment, ie. 10:53 CET. Hopefully the mentioned HIPS module reversion is far more speedy than the usual HIPS module rollout (HIPS V1332-20181008 was installed on my PC on 20181024 (!)...)
  6. @mateusb: no, the culprit is a HIPS module update, read on for the full details!... @Marcos: This new HIPS bug definitely persists every computer restart and it was for sure introduced with the newest HIPS module update, HIPS V1332-20181008, subdirectory '..\1541\', installed on my PC on 20181024! It's a horrible pain to have to live with this HIPS module version!!! (I'm using EIS V11.2.63.) And it's ridiculously easy to reproduce the bug with this program (XYplorer, an Explorer alternative), .https://www.xyplorer.com/. The reproduction procedure: 0. look very closely at picture #1 (since HIPS V1332-20181008 such HIPS popups (ie. "get access to another application") are popping up endlessly and you can save them forever, with no apparent success: they are ignored completely!!! As you can see in picture #2). 1. install a trial version of XYplorer, https://www.xyplorer.com/. With this program the bug can be shown in its full extent ridiculously easy. (That's the way I fully tested this. Optionally, to spare some time, you could try it possibly with Opera V12.x, Firefox V62(+), Vivaldi V1.x(+) - all of these generate generate now a HIPS popup with "get access to another application", since HIPS V1332-20181008 only, though all of these programs have existing HIPS rules for years. Or try it with Opera V50+ / Vivaldi V2.x (totally untested).) 2. switch HIPS into interactive mode 3. start XYplorer, a HIPS popup similar to the one in picture #1 appears, save the rule as ALLOW (look closely at #1, radio button and check boxes) 4. there might appear other HIPS popups, answer them with "remember until application quits" plus ALLOW, concentrate on the XYplorer ones only! 5. the next HIPS popup from XYplorer appears, over and over again, with the 100% identical rule that you have stored already! Store at least three of them. XYplorer never opens until you answer this specific HIPS popup with "remember until application quits" plus ALLOW button! After that XYplorer works until you close the program and restart it. 6. restart XYplorer and the very same HIPS popup madness starts over again! Store another one of these rules. Answer the next HIPS popup with "remember until application quits" plus ALLOW button, close XYplorer. 7. edit your HIPS rules and check that every of your just saved rules were saved indeed!... (See picture #2!) ESET: no offence, but I really don't know how this blatantly obvious bug could slip through your quality control unseen. Of course, nobody will notice this bug ever if not using HIPS in interactive mode (hint, hint!)... How much more proof does ESET need this time until it acknowledges this bug?!? (edit: ouch, wrong HIPS version in the enclosed picture file names, it should be HIPS V1332-20181008, subdirectory '..\1541\', not HIPS V1541.)
  7. on 20180803, after PC start with AV update, I started the firewall log viewer within ESS V10 as usual. Immediately noticing that my precious custom column width settings were destroyed... Investigating the cause of this incident I noticed that the column for the field 'target' is missing in the firewall log viewer of ESS V10. (Hovering over a firewall log entry, exporting the firewall log as ".xml" und ".txt" all include the field 'target'.) Considering the destroyed custom column width settings within the firewall log viewer the root cause must be an update within ESS V10 that was installed on 20180803.
  8. Well done, ESET. The "unknown operation" HIPS log bug has been fixed with HIPS V1322-20180613, rolled out ("to me") on 20180702, see the following screenshot: (1) PC is starting, wrong field content, (2) an AV update with (3) HIPS module update gets automatically installed at 22:36:27, (4) immediately (22:36:29) after that all HIPS log entries with correct field content (5) (6). (Remains the question why the rollout to the ESET users takes a whopping ~19 days: V1322-20180613 <-> 20180702...)
  9. Ahhh, finally the right decision. This bug is of a low severity and easy to fix. But don't forget the other highly disastrous bug that I reported... Since HIPS V1317-20180417 (and HIPS V1320-20180516) consistently reproducible after each and every AV update! Now with a ridiculously easy procedure to trigger it. It will not get any easier than this - the gold chance for ESET to catch this super bad bug! A logging HIPS rule and a not at all "special" action is all that's needed to trigger it - precise details in the PM, please read and do it! This will take only 5 - 9 minutes (*) of your super precious time!!! (*=the actual test, reading the PM post may take an additional ~10 minutes...)
  10. How can you be so sure that only the modules you mentioned were updated on 05/29/2018?!? Are the updated modules logged since V11.x? If not one is forced to continually check this manually after each and every logged AV update... Hardly I can believe that you're running with HIPS V1320-20180516 before 05/29/2018, which was installed on my PC on 05/29/2018 21:59:17 and definitely not a single second before that date (see my screenshot)!!! HIPS V1317-20180417 was installed on my PC on 05/08/2018 22:18:08 - and I'm starting my PC every day, thus you can see there is a significant amount of time passing by until a new HIPS module update reaches my PC... No update on my PC till now - but if em018_64.dll and/or em018k_64.dll (the HIPS module) were really modified on your PC then it's easy to look if this bug has been fixed: check your HIPS log after, for example, some 'cmd.exe' action...
  11. @Marcos/ESET: as the screenshot of itman shows even EIS V11.1.54 fills the HIPS log since HIPS V1320-20180516 with the very same constant text "unknown operation" as it's the case with previous versions of your software. All HIPS logs using HIPS V1320 are filled over and over with "unknown operation" forever, ie. until ESET corrects this easy to fix bug. Oh my, how much more proof does ESET need until they confirm this silly bug and fix it?!?
  12. Thanks Marcos, but I'm sorry that you're wrong. Changing "logging all blocked operations" to disabled changes nothing - as I expected it in advance. Look more closely at the attached screenshot above: 21:58:49 (hh:mm:ss), the old HIPS V1317-20180417 is still active, and guess what, field operation filled with the correct action - "get access to file"! Now look at 21:59:21 plus the creation date of subdirectory '1529' (ask your developers what this means!), this is HIPS V1320-20180516, automatically downloaded and installed on 20180529 21:59:17! Since exactly this time field operation in HIPS log is always "unknown operation" (exporting the log - the very same thing, as expected) - hand this over to your developers please, they know 100% perfectly well why this happens, why it's a crystal clear new bug and what they should do now!...
  13. yes, they do... (But read my private message please, the super bad bug I disclosed therein is now even worser - and ridiculously easy to reproduce since HIPS V1317-20180417. With your 'svchost.exe, start new app, cmd.exe' you're >50% or even >80% into my reproduction procedure, I could bet that it's triggerable even with your EIS V11.1.54!... Thank you very much.) @persian-boy: (this) "unknown operation" is no severe bug. As the screenshot clearly shows introduced with HIPS V1320-20180516. And easy to fix.
  14. regarding all ESET versions (*), mine is ESS V10.1.235: HIPS V1320-20180516, which was installed on my PC on 29th May 2018, introduced yet another bug, as can be clearly seen in the attached screenshot. (Field 'operation' filled with 'unknown operation' since then. Up to this version it contained the correct description, for example 'modify startup settings' / 'write to file' / 'delete file'...) (*= ie. all versions that make use of HIPS V1320-20180516.) (Besides: this is not the only HIPS bug, there exist two others which are far more worse than this one. One of which I already have reported, which is since HIPS V1317-20180417 even worser - more on that later. For this one I have a ridiculously easy triggering procedure now. With HIPS V1317 and HIPS V1320 it's consistently triggerable after each and every AV update!!! Before HIPS V1317 it was "limited" to an AV update with a HIPS module update...)
  15. 1. switch HIPS to interactive mode, force a HIPS popup, for example by copying a file to 'C:\Windows\System32\', the HIPS popup appears with correct xyOps action type, for example 'delete file, write to file' or 'modify registry', ALLOW (or DENY) this action, but store it as a rule. Edit this freshly stored HIPS rule, where you will see "all xyOps operations" pre-selected (see the screenshot) - that's the bug, a new one. (The 'target' is - this time (HIPS V1267-20170216 - see my previous bug report, https://forum.eset.com/topic/7475-ess-v9x-a-2nd-hips-interactive-bug-check-all-your-new-relevant-hips-rules-if-you-trusted-v9-blindly/#comment-40274!...) - OK, ie. the target user selection is honored correctly. BUT there was an "in between" HIPS V12xx, ie. between 20170201 and 20170216, where the user selected target wasn't honored, ie. the dreaded ALL targets HIPS bug reappeared once again - see my already mentioned previous bug report... Apparently this bug has been (re-)fixed already.)
×
×
  • Create New...