itman

Most Valued Members
  • Content count

    961
  • Joined

  • Last visited

  • Days Won

    29

itman last won the day on March 17

itman had the most liked content!

1 Follower

About itman

  • Rank
    N/A

Profile Information

  • Gender
    Male

Recent Profile Visitors

794 profile views
  1. Please do and post back your results.
  2. Eset should demand a retraction from the author. Vulnerable Antiviruses The list of vendors that have been tested and found to be vulnerable to DoubleAgent. The tests were done on the latest version of the vendor on Windows 10 x64 using our POC code. Avast (CVE-2017-5567) AVG (CVE-2017-5566) Avira (CVE-2017-6417) Bitdefender (CVE-2017-6186) Trend Micro (CVE-2017-5565) Comodo ESET F-Secure Kaspersky Malwarebytes McAfee Panda Quick Heal Norton BTW - Eset ver. 10 does run as a Level 0 protected process, the same level as System as shown in the below screen shot. Appears CERT is rapidly descending into "toilet bowel space" these days. Or more likely, Microsoft recently made a sizable contribution to Carnegie Mellow.
  3. Actual, its the root cert. that is using insecure cypher i.e. SHA1 w/RSA: GeoTrust Global CA Fingerprint SHA1: 7359755c6df9a0abc3060bce369564c8ec4542a3
  4. Yes. And as I previously posted, I could not get it disabled. Additionally, Eset was in the status previously described in that desktop GUI icon status showed no issues but opening up the GUI showed Eset realtime protection was disabled. I forgot to note the Win 10 system date after reboot. If it was reset to current date, it did not have any effect on correcting Eset current status as noted above. I suspect the issue after reboot was that Win 10 was overriding WD's disabling since Eset's realtime scanning was disabled. Appears system was in some type of realtime scanning "deadly embrace" in that WD couldn't be disabled since Eset realtime scanning was disabled and Eset realtime scanning couldn't be enabled since WD was enabled There also might be a BIOS factor involved. My motherboard is a bit dated and not UEFI based. Suspect that updating Win 10 system date also updated BIOS date -EDIT- Saw at least one web posting that noted "As time settings tend to be saved to BIOS at time of shutdown." In that case, date change would have persisted after a reboot.
  5. Yes. The issue disappeared for me with the ver. .390 update.
  6. I can verify it is an issue. The following was performed on Win 10 x64 1607, Smart Security v10 .390. Warning: The following will "trash" your Eset installation and you will have to uninstall and re-install to get Eset working again. 1. Open an admin command prompt window. 2. Type "Date 3/18/2018" less the quotes for example. At this point, you will receive a notification from Eset that realtime protection is disabled. After a minute or so, you will receive a notification that Window Defender has been enabled. I forgot to open Process Explorer, so I have no way of verifying that WD was immediately enabled after Eset's realtime protection was disabled. However since the notification took a minute, I suspect there was a period of time when no real time protection was in effect. 3. Repeat above step 2 to reset to current date. At this point, Eset is "trashed." Eset GUI status on desktop does not indicate any issues. However when the Eset GUI is opened, it indicates realtime scanning is disabled. Opening up Windows security center notes that Eset needs to be renewed with a "Renew" button displayed. Pressing the button does nothing. It also shows that only Windows Defender is running. Subsequent various attempts to enable Eset realtime scanning were fruitless. This included an attempted repair install. Only fully uninstalling Eset and subsequently re-installing put Eset back to full operational status with Windows Defender turned off.
  7. In regards to this CERT advisory, it based the advisory on the research report I referenced in this posting: https://forum.eset.com/topic/10953-another-research-report-that-gives-esets-ssl-scanning-a-grade-of-f/ . What I didn't fully realize till today was that this report wasn't independently funded but: Research paper triggered CERT warning The CERT advisory came after a group of security experts published a research paper at the start of the month titled "The Security Impact of HTTPS Interception." The research team, made up of experts from Google, Mozilla, Cloudflare, and the University of Michigan, showed that around 62% of the HTTPS connections they've studied featured "reduced security," while 58% contained "severe vulnerabilities." Ref.: https://www.bleepingcomputer.com/news/security/us-cert-security-products-that-perform-https-interception-weaken-security/ So there it is, "proof in the pudding" that Google and Mozilla are resorting to whatever tactics necessary to further their own end objectives.
  8. Looks like the AV vendor bashing has "jump the pond" with the U.S. now joining in. CERT just issued this advisory: https://www.us-cert.gov/ncas/alerts/TA17-075A . I am repeating below my comments posted on wilderssecurity.com about this advisory. In regards to this recommendation to use the web site, badssl.com, by CERT: The website badssl.com [3] is a resource where clients can verify whether their HTTPS inspection products are properly verifying certificate chains. Clients can also use this site to verify whether their HTTPS inspection products are enabling connections to websites that a browser or other client would otherwise reject. My response: The badssl.com test was specifically designed to test Chrome SSL configuration. So how accurate it is against other browsers remains to be determined. For example, the pinning test performed on the badssl web site is for HPKP pinning: HPKP is supported in Firefox and Chrome,[7] but not in Internet Explorer/Edge.[8] Ref.: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning What I think is behind the CERT advisory: I do question CERT's recommendation to use of a SSL test that does not apply to all browsers. I also question the motivation behind this alert issue. SSL protocol scanning has been a topic for at least two years. However, the recent WikiLeaks CIA revelations include a recommendation to their agents not to use SSL/TLS encryption because it is insecure. I find it a bit too coincidental that this CERT report was released a few days thereafter. My take is it's a diversion to shift emphasis away from the real issue which is fixing the insecurities in the SSL/TLS encryption protocol by again bashing the AV vendors as somehow part of the issue. This also lines up nicely with Google's and Mozilla's goal of eliminating AV vendor SSL/TLS protocol scanning altogether since it costs them more in developmental costs.
  9. AMTSO web site is back online. So anyone wanting to perform the "cloudcar" test can now do so. What should be displayed is shown in the below screen shot:
  10. Actually if you want to know if LiveGrid is working, just access "Tools" from the Eset GUI and select the LiveGrid option. You will see a screen as shown below that shows the reputation of all running processes on your PC.
  11. No problem on my PC. You having problems with password entry on any other web sites?
  12. Appears the AMTSO web site is down. Try it again later.
  13. I believe in the past, Malwarebytes detected this as a PUP: https://blog.malwarebytes.com/cybercrime/2016/10/explained-wmi-hijackers/ . Appears they have upgraded it to full malware status. You install anything recently?
  14. Sounds like a browser or mouse problem to me. On the Eset download web site, position your mouse on the "Download Now" button. Does the green color slightly lighten in color? This indicates that a live link so to speak has been encountered. Also check your mouse settings as shown in the below screen shot and ensure the "Switch primary and secondary buttons" setting is not enabled.
  15. Check this folder permissions, C:\Users\Phoenix\AppData\Local\Microsoft\Windows\WebCache, and verify that System, yourself i.e. Phoenix, and Administrators have full control.