Cannot download installers with Protect 8.0

[Command IT 7]

When I try to download installers, I get the following

Doesn't matter if it's an existing installer or a newly created one

Edited December 14, 2020 by Command IT
typo

[MartinK 378]

Could you please verify your connection to ESET repository servers? Also if possible, please provide version details of your environment (version of ESET PROTECT Server) and possibly also SERVER's trace.log so that we can check whether there are more details present.

[Command IT 7]

 

ESET PROTECT (Server), Version 8.0 (8.0.1238.0)
ESET PROTECT (Web Console), Version 8.0 (8.0.170.0)

 

consoleApi - Copy.zip trace - Copy.zip

[MartinK 378]

There seems to be some network related issue preventing SERVER to download file:

http://repository.eset.com/v1/com/eset/tools/installers/bootstrapper_era/v4/4.0.12.0/epi.exe

using both HTTP proxy and direct connection. Could you please verify configuration of proxy/firewall whether there is no issue that would prevent download. Version of file has changed since ESMC (v2 -> v4) so maybe it is not whitelisted anymore? In case Apache HTTP proxy is used, I would recommend to restart it if not done already to be sure it is in functional state, even that download error indicates firewall issue.

[Command IT 7]

Thank you. 

Firewall was blocking downloading of that file

[Orkhan Jafarov 0]

Encountered the same issue. While the fix is quite obviuous, I hope devs will auto-add firewall exceptions during installation.

[MartinK 378]

Could you please provide more details of what firewall type was used, and possibly also what detection/blocking module had to be modified? As hostname/IP addresses of repository servers has not changed, I suspect there is some kind of whitelisting of executables or more advanced techniques used by enterprise firewalls.

[Intenta 0]

Same issues here. Turns out that the file under

hxxp://repository.eset.com/v1/com/eset/tools/installers/bootstrapper_era/v4/4.0.12.0/epi.exe

is being declared malicious by various AntiMalware solutions: https://www.virustotal.com/gui/file/950a48235da3dde7f4376cebcceb85353ab2feff03646ff72f9718b9cf5c30a7/detection

[Marcos 5,074]

1 minute ago, Intenta said:

Same issues here. Turns out that the file under

hxxp://repository.eset.com/v1/com/eset/tools/installers/bootstrapper_era/v4/4.0.12.0/epi.exe

is being declared malicious by various AntiMalware solutions: https://www.virustotal.com/gui/file/950a48235da3dde7f4376cebcceb85353ab2feff03646ff72f9718b9cf5c30a7/detection

So it's blocked at your ISP that uses some of the AVs that erroneously report the file as malicious? If it's detected in your network. make sure to whitelist the url to prevent the false positive from being detected.

[Intenta 0]

It's being blocked by our Unified Threat Management solution which uses vendor specific anti-malware measures to be precisely. It's possibly checking file hashes against VirusTotal or whatever. That's not the important point right now.

Just that I understand your proposed solution correctly: you want me to to whitelist the download of the "epi.exe", which isn't digitally signed, and ignore the VirusTotal results of other AntiVir products?

[itman 1,659]

1 hour ago, Intenta said:

Same issues here. Turns out that the file under

hxxp://repository.eset.com/v1/com/eset/tools/installers/bootstrapper_era/v4/4.0.12.0/epi.exe

is being declared malicious by various AntiMalware solutions: https://www.virustotal.com/gui/file/950a48235da3dde7f4376cebcceb85353ab2feff03646ff72f9718b9cf5c30a7/detection

Perhaps the prudent thing to do here is that Eset provide the file hash for epi.exe. Then compare that hash value to the epi.exe file hash value downloaded.

-EDIT- Also the VT detection is for bootstrapper.exe which appears to create the following:

• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\epi.exe
• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\sciter-x.dll
• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\eguiActivation.dll
• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\eguiActivationLang.dll
• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\plgInstaller.dll
• C:\Users\<USER>\AppData\Local\Temp\eset\bts.session\{02D83BBE-EB93-B7D9-1A5E-10CDAD2E32F1}\BootHelper.exe

Checking the file hash for epi.exe yields a clean scan at VT.

Edited January 4, 2021 by itman

[Intenta 0]

36 minutes ago, itman said:

Perhaps the prudent thing to do here is that Eset provide the file hash for epi.exe. Then compare that hash value to the epi.exe file hash value downloaded.

Actually this could help with the process of deciding weather it might be safe to whitelist the file at all. Additionally I'd prefer the file being digitally signed.

 

I'm sure most IT professionals have been following the news regarding SolarWinds. Someone can never be too cautious these days, although the VT result looks indeed like an false positive only and potential threat actors wouldn't be so sloppy to get caught by VT in the first place.

[itman 1,659]

VT is slowing conflicting info. per the below screen shot.

Again, its flagging bootstrapper.exe as the problem. This file is signed. Also, VT lists epi.exe. But, when I scanned the hash for the extracted file, there were no detections. It's as if VT is perhaps detecting the downloaded ver. of epi.exe which I assume is a latest ver. update of the file?

[Command IT 7]

Mine was being blocked on our Fortigate firewall.

Don't have the logs from back then to identify which module, but probably AV. I ended up whitelisting repository.eset.com

[itman 1,659]

Further analysis of VT sandbox findings confirms my early suspicions.

To understand what is going on, two epi.exe, aka bootstrapper.exe, processes are running. One as the parent process and one as a child processes. Note that the epi.exe processes are not the same. The malicious process being detected at VT is the unsigned parent epi.exe process. The child epi.exe process spawned is legit and validly signed.

Ref.: https://www.virustotal.com/gui/file/a7af6d852fadd2bf4b9ef36b3f96e322e08254b20682fe174b0c38738e5f3864/detection

Of note is most of the VT detection's for the parent epi.exe process relate to razy malware. That in itself is interesting in that razy malware is browser extension based. Ref.: https://securityboulevard.com/2020/12/how-to-spot-razy-malware-undetected-by-av-systems/?utm_campaign=Oktopost-Media&utm_content=Cato+Networks&utm_medium=social&utm_source=facebook

Edited January 4, 2021 by itman

[Intenta 0]

Thanks for your eager efforts @itman. However I fear you might possibly cause further confusion to fellow readers of this topic, hehe. No offense intended.

After some further analysis of my own regarding the "epi.exe" with the sha256 hash of 950a48235da3dde7f4376cebcceb85353ab2feff03646ff72f9718b9cf5c30a7 seems to be a confirmable false-positive. I'd like if ESET posted an official statement or tries to build a new bootstrapper which doesn't get falsely flagged as potentially malicious. Similar to their old one from Aug 2020 (hxxp://repository.eset.com/v1/com/eset/tools/installers/bootstrapper_era/v2/2.0.47.0/epi.exe - sha256: d821eb22cbe802d4077a6f57bf8b9ed1a6fc93bdc1605e50426b09f41ca7ec7b).

[itman 1,659]

2 hours ago, Intenta said:

Thanks for your eager efforts @itman. However I fear you might possibly cause further confusion to fellow readers of this topic, hehe. No offense intended.

No offense taken.

My advice is submit the installer to Hybrid-Analysis: https://www.hybrid-analysis.com/ , for a full sandbox analysis and see what it determines.

[Intenta 0]

Some vendors updated their signature databases and no longer flag the file "epi.exe" as malicious. The download of All-In-One installers through the ESET Protect UI is finally working for us now (without configuring any exceptions). Thanks!