Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by itman

  1. So far, the Sophos suggested Sandboxie mitigation posted previously: https://forum.eset.com/topic/20056-eset-issue-with-sandboxie-persistent-holding-of-registry-keys/?do=findComment&comment=97716 appears to be working as observed through testing here: https://www.wilderssecurity.com/threads/sandboxie-acquired-by-invincea.357312/page-213#post-2840059 Appears to be no conflicts with Eset by doing this.
  2. Again using IE11, go to the AMTSO Desktop tests web site: https://www.amtso.org/security-features-check/ . Then left mouse click on the yellow colored padlock symbol shown in IE11's toolbar. A popup should be displayed as shown in my above posted screen shot showing what root certificate is being used. When the popup is shown, take a screen shot of the web page and post it.
  3. This is what I referred to previously as far as Quantum ver. 68 goes. What FireFox is informing you of is Eset is not a recognized root CA certificate issuer which obviously it is not. If you were to see this same wording for an Eset non-SSL protocol filtered web site, then that would be cause for concern.
  4. To clarify, are you stating that Eset's root certificate does not show in IE11? Instead GoDaddy's root certificate shows?
  5. @BeanSlappers there is another test that needs to be performed. Using a browser that uses the Win root CA certificate store such IE11 or Edge, go to the AMTSO Desktop test web site. Click on the lock symbol as shown in the below IE11 screen shot and verify that Eset's root certificate is shown.
  6. Check out this Eset knowledge-base article as a possible solution: http://support.eset.com/kb7241/
  7. As noted in the above linked Eset research article on this vulnerability, all Windows desktop versions except Win 8.1 and 10 are affected:
  8. To clarify, did adding ekrn.exe to Sandboxie's "leader programs" list stop the issue of the sandbox not being able to be cleared? -EDIT- per postings on wilderssecurity.com here: https://www.wilderssecurity.com/threads/sandboxie-acquired-by-invincea.357312/page-213#post-2839871 , the "leader programs" proposed solution doesn't work.
  9. I am using DoH option in FireFox Quantum ver. 68 via default use of Clouldflare DNS servers. No issues to date using EIS ver. 12.1.34 running on Win 10 x(64) 1809. As best as I can determine via testing and Eset alerts, Eset's SSL/TLS filtering protection is fully functional with Firefox DoH use. In reality, Eset doesn't monitor UDP port 53 DNS activity other than what is provided by default firewall rules. Therefore, DoH using HTTPS is more secure. -EDIT- To further clarify, Windows DNS service only performs DNS resolution to existing cached DNS resolved entries. Actual initial DNS resolution is performed from the router via ISP lookup or alternatively, via third party DNS servers specified in network adapter IPv4/IPv6 settings. The Windows DNS cache is then updated from this resolution. Note that Windows DNS cache poisoning attacks have been an ongoing issue: https://www.howtogeek.com/161808/htg-explains-what-is-dns-cache-poisoning/ . Note that Eset's IDS protection should be able to detect a DNS poisoning attack. -EDIT- In regards to DoH specifically, it is no longer "bullet proof." The first malware against it was just recently discovered; https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/ . Luckily, Eset also detects this one.
  10. One last check to perform, After this, I am out of ideas on what your issue is with Eset in regards to SSL/TLS filtering capability. In FireFox using Options -> Privacy & Security -> Certificates -> View Certificates, navigate to the Eset certificate in the Authorities certificate store. Select the certificate and click on "Edit Trust" as shown in the below screen shot. Verify that "This certificate can identify websites" setting is check marked. If it isn't; check mark it, click on "OK" tab, and repeat the AMTSO Desktop web site tests.
  11. OK. We can rule out MITM activity. I just noticed something. Firefox Quantum 68 is no longer going to FireFox's Authorities root certificate store in regards to Eset's root CA certificate. Appears it is directly accessing it from the Win 10 root CA certificate store. This in spite of the fact that Eset's root certificate is presently stored in Firefox's Authorities store. Did you verify that Eset's root certificate is present in the Win 10 root CA certificate store? If not, do the following: 1. Enter certmgr.msc in the Win 10 desktop taskbar search area. 2. Open certmgr.msc. 3. Under "Logical Store Name" section, open the "Trusted Root Certificate Authorities" folder. 4. Open the Certificates folder. 5. Navigate down to the beginning of certs. that begin with "E." 6. Verify that a certificate named "Eset SSL Filter CA" exists. 7. Double click on the cert. to open it. Click on the Certificate Path tab. Certificate status should show it is OK. 8. Close certmgr.msc. Report back on your findings.
  12. Someone will have to run it on a lab test device or in a VM and see what happens.
  13. There is one last thing you can try for detection of external MITM activity. There is a small developer, well known at wilderssecurity.com, that has developed a small utility program specifically designed to check for external MITM activity. The product is currently in beta testing but works fine; I just previously ran it. Go here: https://www.trustprobe.com/fs1/apps.html . Click on the "NoSnoop" link to download the utility. Unzip it. Open the unzipped NoSnoop folder. Double click on nosnoop.exe to run the utility. All the web sites shown on the resulting output from the utility should show OK. Note: Windows SmartScreen will alert on this since it was not a Win Store download. So you will have to override it to run the utility. Also, Eset might immediately submit it to LiveGrid; it did for me. Again to be expected, since it appears Eset has no reputation on the utility. What this utility does is make external and independent connections to the web sites listed to verify the root CA certificates associated with them. It does this without using a browser; only using the device where run from existing network connections to verify that no MITM certificate interception has occured.
  14. That is not correct. See the below screen shot for Win 10 x(64) 1809. There are only three cases when these services would be running: 1. Windows Defender is the default realtime scanner. 2. Windows Defender periodic scanning option has been manually enabled. 3. Effective with Win 10 1809 if the third party AV solution installed does not use the Windows Early Launch Anti-malware driver, Windows will additionally activate WD's realtime protection. It will run concurrent with the third party AV realtime solution. In any other instance when WD's realtime protection is running concurrent third party AV realtime protection, it would be indicative of either a malfunction within Windows itself or the third party AV solution installation processing malfunctioned.
  15. I believe the only solution for this would be to disable Eset's scan alert for removable medium. This could pose a security risk.
  16. No. As far as Eset is concerned, the default installation settings assuming PUA protection is enabled at that time provide the maximum protection.
  17. Switch to pre-release updating in Eset. After that processing completes, check if current version is 12.2.23. If it is not, then perform a manual update check which should download version 12.2.23.
  18. What browser is this behavior being observed for? Have you tried different browsers and the same behavior manifests?
  19. The only other thing I can think of at this point is some type of man-in-the-middle is occurring. When this happens, HTTPS traffic is intercepted en-route and decrypted using the attacker's root certificate. In most cases but not always, this breaks "the chain of trust" in the browser resulting in a warning from the browser this activity has taken place. One possibility is the MITM activity is occurring externally with the Eset root certificate being replaced with the site's original chained root certificate. Go to this web site which will validate SSL/TLS communication: https://badssl.com/dashboard/ In FireFox Quantum 68 and EIS 12.1.34, the only tests shown in light red indicating a minor concern are SHA-1 Intermediate and dh1024 Crypto cypher issues. The test area to be noted is the Interception Certificates area.
  20. Did you try @Sammo suggestion of setting firefox.exe in Eset's SSL/TLS filtered applications to "Scan" versus the default setting of "Auto?" While in that section, make sure that there are not multiple firefox.exe applications listed. You should have only one entry for Firefox and its path specification is C:\Program Files\Mozilla Firefox\firefox.exe assuming your using Win 10 x(64). Next in the Web Access protection section, open the Web Protocols section and verify that only port 443 is shown in the HTTPS Scanner Setup section.
  21. Ahh........... It's the obvious stuff that can "trick you up." Totally ignored that parameter under the assumption logs are created in all scanner modes.
  22. @Marcos this might be the reason for the Win 7 driver errors when attempting to install Sandboxie:
  23. Detection was had when I was signed off from Win 10. Cleaning mode is "Strict." File was indeed quarantined but I would expect Eset to also write a Detection log entry. If one never referred to Eset Quarantine, they would never know a malware was detected and mitigated.
  24. https://fileinfo.com/extension/com In other words, malware runs via a batch script. https://en.wikipedia.org/wiki/COM_file
×
×
  • Create New...