Error when applying differential update

[Samoréen 8]

My TEMP/TMP environment variables now point to C: . Let's see if this changes anything...

[Samoréen 8]

Hi,

After moving the TEMP folders and the Windows pagination file back to C :  and after a quiet period (away from my desk for a while), the problem re-appeared today. After the update failure, a first attempt to update manually also failed, as usual. And as usual again, the second manual attempt succeeded. Nothing changed. the pagination file  after

So it's neither a hardware problem with the SSD where my temporary files were previously stored (this disk is no longer involved in the update process) nor a problem with the location of the TEMP folders. Back to start...

[itman 1,659]

I guess we have comeback "full circle" to those certificate errors in regards to the Eset pico updates.

Whereas external man-in-the-middle attacks exist, they are overall rare in success due to a number of factors. That leaves local device like activity as the best possibility. The most common type of local device MITM interception is done is through a hidden localhost proxy. Your best way to detect this activity is to use a network monitor and look for connections to/from 127.0.0.x address. Note that Eset also performs like activity via ekrn.exe, so exclude it from consideration. Additionally, something might have set up a non-localhost proxy on your device so validate no proxy connections exist on any of the network adapters you are  using.

Edited July 30, 2018 by itman

[Samoréen 8]

Hi Itman,

No proxy used in this system, no suspect activity to ro from 127.0.0.x. I used various tools in order to detect transparent proxies : no proxy detected.

Quote

That leaves local device like activity as the best possibility. The most common type of local device MITM interception is done is through a hidden localhost proxy.

So, a malware undetected by ESET NOD32 and that would only affect ESET updates from time to time and not any other network activity for any other software ?

IPV6 is enabled on my system. Could this be a problem ?

[Samoréen 8]

By the way, ESET NOD32 still didn't auto-update to version 11.2.49.0 (I'm in France) ? Any possible relationship ?

[itman 1,659]

@Peter Randziak, can someone at Eset checkout how the pico update downloads are signed? Such as the certificate chaining path to the root CA store issued certificate.

One other possibility here is @Samoréen is missing the required intermediate and root certificates in his Win root CA store that pico updates certificate uses.

Edited July 31, 2018 by itman

[Samoréen 8]

Itman, are you telling me that not all updates are "pico" updates ?

This could explain why not all updates fail. 

I'll see if I can find some document listing the required certificates for Eset Nod32.

 

[itman 1,659]

50 minutes ago, Samoréen said:

Itman, are you telling me that not all updates are "pico" updates ?

Eset performs four types of updates on a regular basis:

1. Signature definition updates.

2. Program module updates.

3. Pico updates

4. LiveGrid updates

The first two types are logged in the Eset event log.

Pico updates are differential updates to program modules as shown in the Eset log screen shots you posted. They will only appear in the Eset Event log when a problem is encountered. Pico updates were introduced in ver. 11 as a way to rapidly apply changes to the Eset program modules without having to download a full module update.

[itman 1,659]

I don't think we have tried this one yet. Really don't think it will help but worth a shot anyway.

Clear your update cache as illustrated in this Eset KB article: https://support.eset.com/kb3189/?locale=en_US&viewlocale=en_US

[itman 1,659]

3 hours ago, Samoréen said:

I'll see if I can find some document listing the required certificates for Eset Nod32.

That's an effort in futility in regards to this problem.

What is happening is Eset has code signed the pico update download. Within the associated certificate is a hash value for the download file. What Eset is doing calculating the actual hash value for the file downloaded on your device and comparing it to hash value given in certificate associated with the download file. If they don't match, it will then create the log certificate error entry you are seeing. 

All it takes is as little as a one bit change; e.g. from 0 to 1, in the download file to change its hash value. Besides man-in-the -middle activity, files can become corrupted in the transmission process due to technical issues. Likewise, it could be caused by HDD/SDD problems when the file is physically created on your device.  I would think if these were the problems, it would manifest in some way on other file downloading activity you are performing. But, who knows? 

Edited July 31, 2018 by itman

[Samoréen 8]

3 hours ago, itman said:

I don't think we have tried this one yet. Really don't think it will help but worth a shot anyway.

Clear your update cache as illustrated in this Eset KB article: https://support.eset.com/kb3189/?locale=en_US&viewlocale=en_US

The Clear Update Cache option is grayed out.

New bunch of failures tonight...

[Samoréen 8]

I finally could upgrade to version 11.2.49.0.

[Samoréen 8]

2 hours ago, itman said:

What is happening is Eset has code signed the pico update download. Within the associated certificate is a hash value for the download file. What Eset is doing calculating the actual hash value for the file downloaded on your device and comparing it to hash value given in certificate associated with the download file. If they don't match, it will then create the log certificate error entry you are seeing. 

All it takes is as little as a one bit change; e.g. from 0 to 1, in the download file to change its hash value. Besides man-in-the -middle activity, files can become corrupted in the transmission process due to technical issues. Likewise, it could be caused by HDD/SDD problems when the file is physically created on your device.  I would think if these were the problems, it would manifest in some way on other file downloading activity you are performing. But, who knows? 

I'm aware of this. I'm a former developer/system engineer and I coded such things in the past. I can admit file corruption during transfer from the ESET servers to my system but corruption affecting only ESET files (and apparently only pico updates) is very unlikely. I don't have any problem with other updates and downloads and many of them are sensitive to file corruption. For example, I'm using a lot of Microsoft .Net applications and all units are checked again corruption before being installed/updated. Never had a single problem. All my disks have been checked multiple times and no problem has been reported. I also run memory tests : no problem reported either. Maybe my system configuration has something that ESET NOD32 doesn't like but I think it's now useless to consider any system failure on my side.

[itman 1,659]

1 hour ago, Samoréen said:

The Clear Update Cache option is grayed out.

It should not be. It should be blue in color.

One more thing to try. Set Proxy mode to "Do not use proxy server" per the below screen shot. I assume your system is not configure to use a proxy server.

[Samoréen 8]

8 hours ago, itman said:

It should not be. It should be blue in color.

One more thing to try. Set Proxy mode to "Do not use proxy server" per the below screen shot. I assume your system is not configure to use a proxy server. 

The Clear Update Cache option is OK this morning. The proxy mode was already set to "Do not use proxy server".

[itman 1,659]

5 hours ago, Samoréen said:

The Clear Update Cache option is OK this morning.

If this doesn't solve the issue, I am out of suggestions to try.

I believe you are the only person to date who has posted an issue with pico updates failing due to certificate errors. Some have posted about pico updates not working at all at different period of times. When this occured, there were no Eset event log entries created to indicate this status. However, no one has indicated to date the updates failing due to certificate errors.

I would just open up a tech support request with your in-country Eset source. Doubtful in my opinion they can do much unless your install Wireshark as @Marcos requested quite a while back. Then capture the Eset pico update traffic as it arrives in your network.

[Samoréen 8]

15 minutes ago, itman said:

If this doesn't solve the issue, I am out of suggestions to try.

Anyway, thanks for your help. I might be the only one with this issue but I rather believe that many people just don't care or even look at the event log. They click on the Check for updates button until everything is OK. My system has nothing fancy. It's not a development system and I only have image processing, office applications and various utilities. There are only 2 programs that could interfere : MalwareBytes Premium (with real-time Protection enabled - I use it as a complement to ESET) and Acronis True Image Home which now has an Active Protection feature against ransomware (which I turned off). I think I have already asked about possible incompatibilities and I'm not aware of any.

[itman 1,659]

14 minutes ago, Samoréen said:

MalwareBytes Premium (with real-time Protection enabled

Did you disable MBAM realtime status and see if the issue with pico updates disappeared?

Edited August 1, 2018 by itman

[Samoréen 8]

1 hour ago, itman said:

Did you disable MBAM realtime status and see if the issue with pico updates disappeared?

Yes, I did. I'm currently trying again.

[itman 1,659]

55 minutes ago, Samoréen said:

Yes, I did. I'm currently trying again. 

I would also try uninstalling it temporarily to fully rule it out as a possible "culprit."

Note that there have been multiple postings in the forum about MBAM ver. 3+ not co-existing well with Eset. Also don't know how Win 10 is allowing two third party AV's to run concurrently with realtime scanning enabled. Technically only one can be registered in the Windows Defender Security Center.

Edited August 1, 2018 by itman

[itman 1,659]

Another thing you could try is to export your existing NOD32 settings. Then uninstall it and install Internet Security in trial mode.

If the same pico update certificate errors occur in Internet Security, it can be safely assumed that man-in-the-middle activity is either occurring internally within your local network or externally.

Also Internet Security's firewall and IDS protection might help isolate where the man-in-the-middle activity is coming from.

[Samoréen 8]

On 6/9/2018 at 3:44 PM, itman said:

Do you monitor outbound firewall communication? Given you are using NOD32, this would be done by some non-Eset based software.

Eset modules use a code signed Eset certificate. This cert. is not stored in Windows root CA store. As such, cert. "pinning" path to root CA issuer must be validated via Internet connection. If this chain validation lookup is blocked locally, Eset certificate validation will fail.

Hi itman,

Back to the above... So, this means that even if the update file is not corrupted (tampered with), the update will fail anyway with the same error message if something prevents the update compiler from communicating with the ESET server during the update process when trying to check the hash code ? That "something" could be a setting (a filter) enabled in the firewall (I'm not using the Windows firewall but the one embedded in my ISP's modem) ? Do you know which ports are involved in this process ?

[Samoréen 8]

2 hours ago, Samoréen said:

That "something" could be a setting (a filter) enabled in the firewall (I'm not using the Windows firewall but the one embedded in my ISP's modem) ?

I just discovered that my ISP box was by default "protecting" ports 135, 137, 138, 139 and 445 (I don't know exactly what it does, there's no documentation about this). Most of these ports are used by the ESET Remote Administrator. I don't know whether ERA is used for the pico updates... I have disabled this "protection".

[itman 1,659]

3 minutes ago, Samoréen said:

I just discovered that my ISP box was by default "protecting" ports 135, 137, 138, 139 and 445 (I don't know exactly what it does, there's no documentation about this). Most of these ports are used by the ESET Remote Administrator.

I would re-enable that protection. Ports 135 - 139 are used for NetBIOS, an archaic networking protocol. Port 445 is used by SMB protocol and I am sure you are aware of all the SMBv1 exploits in existence by now. None of those ports would be used in Eset update communications which would occur via HTTP(Port 80) or HTTPS(Port 443).

As far as calculating a hash value for a downloaded file, there are a number of readily available utilities that can be download from the Internet to do so. Assumed is Eset internally has like code to do the same. Eset would not be connecting to its cloud servers to do this.

My advice is to not fool around with your ISP's router firewall settings and to enable at least the Win firewall. Both firewalls have different purposes. The router's firewall purpose is to provide NAT and stateful inspection for outgoing going traffic and protect the inbound WAN(external) side router from unsolicited traffic. The Win firewall will protect you against inbound LAN(internal) side of the router unsolicited traffic.

[Samoréen 8]

42 minutes ago, itman said:

I would re-enable that protection. Ports 135 - 139 are used for NetBIOS, an archaic networking protocol. Port 445 is used by SMB protocol and I am sure you are aware of all the SMBv1 exploits in existence by now. None of those ports would be used in Eset update communications which would occur via HTTP(Port 80) or HTTPS(Port 443).

My intent was to protect these ports via the Windows Firewall instead of letting the ISP's router doing something that is not documented. If these ports are not used when ESET updates itself (I had a doubt because of the ERA), there's no reason to leave them without any monitoring.