itman

Here's a few other "goodies" I found about SSL protocol scanning. If you turn it off then turn it back on, Eset will generate a new self-signed root CA cert.. No problem with that. However, any previous certificate exclusions you have established no longer work with the new Eset cert. What the ..............! Appears Eset somehow pins those exclusions to the cert. in existence at the time the exclusion was set. Bottom line, you have to repeat all those exclusions again ............. ridiculous! URL Address Management. Appears to work just fine but has no effect on SSL protocol scanning. I verified this by setting on the notify option and having the popup appear when I navigated to the web site whose URL domain name was excluded. However, when I looked at the root cert in use for that SSL web site, it was Eset's.What the .............! Here's my suggestion to make SSL protocol usable. Add an option to the Eset's desktop taskbar icon display to turn SSL protocol scanning on and off. You can even add time intervals that it will remain off. This way I could easily turn off SSL protocol scanning when I wanted to use a site where I wanted my privacy maintained and when finished, easily re-enable SSL protocol scanning.

When is Eset going to fix this and other security issues of SSL protocol scanning mentioned in the below referenced article? Disabling of HTTP Public Key Pinning Each and every TLS intercepting application I tested(Avast, Eset, and Kapersky) breaks HTTP Public Key Pinning (HPKP). It is a technology that a lot of people in the IT security community are pretty excited about: It allows a web page to pin public keys of certificates in a browser. On subsequent visits the browser will only accept certificates with these keys. It is a very effective protection against malicious or hacked certificate authorities issuing rogue certificates. Browsers made a compromise when introducing HPKP. They won't enable the feature for manually installed certificates. The reason for that is simple (although I don't like it): If they hadn't done that they would've broken all TLS interception software like these Antivirus applications. But the applications could do the HPKP checking themselves. They just don't do it. ref: https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

About time to put this thread to sleep. I saw the explorer.exe process running again today that I mentioned previously. Here it is: C:\Windows\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding This is a normal shell execution of explorer.exe. It can be initiated for a number of reasons. No need to get into all that now. It is sufficient to say it is not a malicious process. As far as I am concerned, Eset did indeed update its certificates. Again whether they admit it is immaterial since I have no intentions of activating SSL protocol scanning again. As we say here in the States, "it's not ready for prime time." As far as the screen shots in temp storage, I strongly suspect those were caused by SLL protocol scanning "flaking off" when its exclusion processing of my bank web sites malfunctioned due to the Eset certificate update and EMET certificate pinning interaction. If malware originally updated the Eset certs., it would have most certainly tried again since the original incident. No such activity like that has been observed by me.

Did you notify your bank yet? If someone else really did take those screen shots then you should notify your bank immediately. If they were able to take the screen shots then they were definitely able to obtain that information remotely. Edited 4/28 @10:51: Are you sure they were screen shots? I don't think there is an option to save screen shots as .htm. htm is like html. I'm not sure if the browsers should be saving web images of secure logins in the cache. I think that is the question that should be asked. The other instance of explorer.exe can't be good though. Sorry, they are .html files and I actually saved them in folder on my PC. I did change my bank userid. I am not too concerned since the bank uses multi-factor authorization. The password screen is tied to your PC. Anyone attempting to log into that screen from another PC will have to answer a hidden validation question. Like I said previously, I believe the screen shots were due to the collision of EMET cert validation and Eset SSL protocol scanning. Caused by Eset not excluding the web site as should have.

LiveGrid I have used previously and ran yesterday. Results - all green. Ran SysInspector yesterday and it did not show anything malicious. If this was indeed malware, it must have been an exploit. Also it must have been targeted specially for users of Eset with SSL protocol scanning turned on. A bit of a stretch here ......... The only thing changed in my root CA store was the Eset self-signing cert.. It is also beyond me how it could have added the new Eset cert. to Thunderbird since its certs are stored in a .db file. Nothing else has been changed in Win or Thunderbird root CAs since this incident. If malware had access to those root stores, I assume it would be still attempted to add its own certs there. Below are two screen shots of areas in the registry that Eset appears to use for SSL protocol scanning. If you are using it, check what Eset is storing there. If it's root certificate is there and stored in an insecure manner, it would explain how something could access and update the Eset cert.. However it would have to be running with Creator credentials to do that. Again, I am at a loss to explain how the Thunderbird Authorities root store had a new Eset root certificate added to it.

No. Eset's cert is in WIN's CA root store. It has to be there for Eset to create a new countersigned browser cert for every HTTPS web site. The WIN Root CA is the "Holy Grail" of all areas in Windows. In Thunderbird, the Eset cert was stored in the Authorities store which is the equivalent of WIN's Root CA. If Eset did update their cert's last week, I do not how it could be possible that they could add this new cert to Thunderbird since I had to manually add it originally. The only possible explanation is Eset has an arrangement with Mozilla. Then Thunderbird update processing will search for an issuing authority and if it finds a match will add the new cert to that respective authority. Note the word "add" since the original Eset cert was still present in the TBird Authorities store as shown in my prior posting.

I am really more concerned over how something could update Eset root cert in WIN 7 and in Thunderbird CA area. I did observe how Eset stores it root cert in the registry and it's not locked down like normal root certs are. There is one possible explanation for the screen shots. At the time of the incident as I explained originally, both Eset and EMET were performing pinning activities on the bank web site. This was due to the failure of Eset to exclude the bank web site; appears due to a change in its root certificate. I had the web site set to block mode in EMET which didn't work; I only received the pop-up alert. Again, this occurred due to the pinning conflict. It is possible EMET is actually the process that wrote the pages to temp storage in an attempt to block connection in IE. In a normal scenario, EMET would have deleted those temp storage web pages after blocking them.

Yes, I use Process Explorer on a daily basis usually. No unusual activity or processes. Only issue I have had for some time, well before this incident, is svchost -netsvcs using a huge amount of system memory at boot time. For example, this morning peak usage was over 2 GB! Note I have 8 GB of memory, so that is only 25% of available memory. But rapidly drops to 18 KB or so and stays there afterwards. Only outbound I/O during that time is WIN Updates for the most part.

I just wanted Eset to know that this issue was serious. After the incident, I checked my C:/Users/username directory areas and found .htm screen shots of my bank logon screens; one showing my user id. Of course, I promptly deleted those. Also at the time of the incident, appears a shell or something of the like had started another explorer.exe process using C:\Windows\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding since this was running. I have scanned my PC using multiple AVs and anti-malware plus anti-rootkit software and am clean as a whistle. I also downloaded and ran Eset's PowerLiks cleaner and it did not detect anything. I have had no further above activity like this since the original incident. Of course, I immediately deleted the Eset cert from both WIN 7 root store and Thunderbird and turned off SSL protocol scanning.

Yesterday, I had something occur I can find no logical explanation for. I also find it more than a bit concerning. I went to access my bank site and I received an alert from EMET about a certificate issue. Previously I had excluded all my bank HTTPS sites from Eset's SSL protocol scanning and had pinned those same sites in EMET thankfully. Everything worked fine until yesterday. A bit of PC detective worked yielded the following: 1. Something replaced the original Eset certificate in my Windows 7 root certificate store. From the date on the new certificate, it appeared to occur two hours prior to the access of my bank site or approx. 10 AM EST. Note - I had made no changes to SSL protocol scanning prior to this event. Does Eset periodically update it's self-signed root certificate? If so, then why do prior created exclusions no longer work with the new certificate? 2. Additionally, this same new Eset certificate was added to the root certificate area in Thunderbird? I now had two Eset certificates present in Thunderbird. How is this possible since I had to manually add the original Eset certificate to Thunderbird? Note - am using the latest version of Thunderbird and as I was lead to believe, there is no automatic integration between Eset's e-mail facility and the later versions of Thunderbird. Below are two screen shots of the original and new Eset certificates from Thunderbird. The original certificate is dated 4/14/2015. I am also attaching my EMET event log entry that show the full public key of the new Eset certificate that was installed. EMET_Eset_SSL_Cert_Detection.txt

Elaborating on my initial posting, I believe Eset SS is presently working as designed. Quoting the documentation manual when you select "No" from the initial untrusted certificate prompt, the following occurs: 1. "Marks the certificate as untrusted for the current session - the alert window will be displayed on the next attempt to use the certificate. 2. "You can select Block communication that uses the certificate to always terminate an encrypted communication to a site that uses the unverified certificate. The connection is indeed being blocked, but only for this specific instance. Hence, when the web page again attempts to access the bad cert, the whole process repeats. In my instance, the web page was repeatedly trying to access the bad cert and I was stuck in a loop. My recommendation is to add the following: 1. An "Untrusted" section to the existing "Trust" and "Exclude" sections where bad certs would be stored. 2. Add a "No, always" option to the existing unknown/unverified cert prompt. This will mark the certificate as untrusted for all sessions and will add it to the list of untrusted certificates - no alert windows will be displayed for untrusted certificates. All communication using this certificate will be automatically blocked. Additionally, I recommend Eset provide wording on the initial SSL warning window to click on the shown cert name to determine the issue with the cert. The average user would not know to do that.

A bit more info on this incident. I checked the source code on my browser home page and the actual connection was to a sub-domain: https://comet.yahoo.com/comet. Also this web site cert was expired since April 10 and I was only alerted to a problem by Eset on April 19. I believe also that the only reason I was alerted was because there finally was finally an issue with the cert path validation. I consider this a serious problem with Eset since I can no longer trust that it will properly verify the web site certificate when the SSL protocol scanning option is enabled.

I just checked domain comet.yahoo.com at Quals. Its thumbprint is 45a7c9c571177f12486686dd53c0f08ec7efa31f Here is a screenshot of the original cert. with its thumbprint.It is clearly expired: Eset forum will not let me attach the actual .cer file What I figure is going on is AT&T hasn't updated its cert server with the correct certificate. The thumbprint you posted is for the root CA cert. -EDIT- Had a "brain cramp" when I originally posted this ......... Attached is a zip folder containing the cert. comet.yahoo.com.zip

I am on the public profile and my Internet connection is just fine. I am connected to my router via a D-Link USB WAP; ID of which is what is penciled out in the screen shot.

Below is a screen shot of a warning I received from an expired cert embedded in my ISP's home web page. Additionally, my settings for the "End Certificate Validation" section are the defaults: TRCA verification - ask If certificate is invalid/corrupt - block If I am interpreting the above correctly, SSL protocol scanning should have auto blocked the expired certificate which it did not. The reason why I believe it did not is because I have the option "Apply created exceptions based on certificates" set to on since there are certs I want to exclude from SSL protocol scanning. It appears this option is overriding the End Certificate Validation settings? The result is I am constantly being prompted to allow, deny, trust, or exclude the expired certificate every time I access my web home page. I have gotten around this issue temporarily by exporting the expired cert to my Untrusted Publishers store and then excluding that cert in Eset. Either Eset needs to fix this so the "End Certification Validation" takes precedence or a "Block" option be added to the existing Trust or Exclude categories in the exceptions area.

Yes, was able to successfully able to exclude what I had to cert-wise. Was an interesting exercise in that I picked up a dodgy hidden cert. on the bank web site. One solution would be for an option for Eset to allow cert path verification for excluded certs. but not scan the traffic using the SSL protocol feature. As I understand it, once the web site cert. is excluded, Eset will not verify the cert. chaining path to the Trusted Root CA store?

Nothing should be intercepting encrypted data to sensitive web sites such as your banking sites and the like for any reason. It violates the whole principle behind SSL encryption. Sorry, I don't trust anyone when it comes to my financial data. I use EMET's certificate pinning for those sites to verify that the certificate authorization chain is intact. If you can't trust your banking web site to be malware free, you need to find a different bank to do business with.

Only thing I suspect is that I was doing a lot of testing with SSL protocol exclude option and after that is when I noticed the change. Actually, I like it better at the begin of the window now.

Strange .......... IE 10 shows that as an option for that window; "show before address bar". Never noticed that before? Also, I know I didn't set it on. Sorry for the inquiry.

Notice in the attached screen shot, the position of the "reset" icon immediately preceding the AT&T globe in the domain name entry window. This appears to have happened after I enable SSL protocol checking in Eset Smart Security 8. Prior to that, this icon appeared at the end of the window after the domain name.

Well, the *.bankofamerica.com url exclusion only worked on the www. domain; not on any of the 8+ other domain names it uses. It uses a cert. for each web page it displays on its web site. So I went the certificate exclusion route for those. I also decided to let Eset's SSL protocol fllter check the other domains I encountered on that site such as *.vo.mscnd.net, x.cardlytics.com, image.get.bills.com and God knows what else. You can't even trust your bank these days! A suggestion to Eset is to follow Avast's lead and auto exclude all bank and major financial web sites from SSL filtering. Would save a lot of work for us poor users. BTW - I exported Eset's certificate into Thunderbird and changed to it to web site verification and that appears to be working OK. Question - There was a web posting last year about Eset's SSL protocol downgrading TLS connections to ver 1.0. From what I can determine, that appears to be fixed . Is this indeed the case?

I thought from what was given in the SS 8 manual that if a HTTPS address was entered in the "list of addresses excluding from filtering", the domain would be excluded from SSL scanning. SSL protocol scanning is set to always. I tried various formats such as https://www.bankofamerica.com, https://*.bankofamerica.com/*, etc., yet Eset SLL protocol scanning is still enabled by virtue of it's cert. being used on the above domain web page.

I re-installed SS 8 with all options active. I did total shutdown Emsisoft Anti-Malware when I did this. I then set exceptions in the real-time scanner and web protection for EAM's start, guard, and service apps. Then I started up EAM and likewise set exceptions for Eset's main apps; equi, ekrn, SysInspector, and one or two more - can't remember their names. I also reset EAM's real-time protection to "balanced" which only scans files on modification. Debating whether I should set Eset's real-time scanner check for file creation to "off" since I have EAM's set to do the same thing? Also, I believe my original Eset's installation might have be "hosed." For that one I use the online installer. This time, I downloaded the full .msi installer. Definitely seemed like this installation took a lot longer than the original online installation did. I also did a re-boot after the initial Eset SS 8 full scan completed. So far, so good. Time will tell. My Win 7 boot files did not get corrupted until two cold boots after the initial Eset installation. Note: I did not set any exceptions in Eset for EMET 5.2. Should I?

Could you give me a bit more info. Did you set exclusions for each? If so, what were they? Did you set Eset's real-time AV to scan on one event and EAM a different one? Addition config. info, etc.

Emsisoft Antimalware has an excellent behavior blocker. I use EMET for exploit protection. Based on latest tests PCSL/Malware Research Group ran for exploit protection, I am far better off using EMET than anything Eset has. Actually, all I really need is the firewall. Based on the user manual for Smart Security 8, most of the protocol, web, and e-mail filtering features are disabled anyway to conform to Windows Filtering Platform. Is there anyway I can just install the firewall portion of SS 8?