Another SSL Protocol Issue

[itman 1,659]

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

[itman 1,659]

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.

Edited April 26, 2015 by itman

[SweX 871]

So something/someone else made those screenies. ? That's both scary and crazy, why would these screenshots be found on your system just like that. Especially of your bank logon page! 

 

I hope your system is "clean" as this surely sounds a bit suspicious and worrisome.

[bbahes 29]

Try investigate system processes with Sysinternals Procexp. If you don't Know how then ask someone to do it for you. Else if this is not option I would suggest to clean your hard drive and do new installation.

[itman 1,659]

Try investigate system processes with Sysinternals Procexp. If you don't Know how then ask someone to do it for you. Else if this is not option I would suggest to clean your hard drive and do new installation.

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.

[bbahes 29]

I think they did change something about their certificates...they won't say.

 

I had problems with accessing their forum last week but nobody confirmed any problem or change:

https://forum.eset.com/topic/4776-forumesetcom-this-page-cannot-be-displayed-ie11/

 

As for your screenshot you should have looked details about when it was created and who is creator/owner of the file...

[itman 1,659]

So something/someone else made those screenies. ? That's both scary and crazy, why would these screenshots be found on your system just like that. Especially of your bank logon page! 

 

I hope your system is "clean" as this surely sounds a bit suspicious and worrisome.

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.

Edited April 27, 2015 by itman

[bbahes 29]

If it's in USER cert store then my guess is that you or process can update it without any prompt. I will check this.

ESET did do something with their certificates last week....

[itman 1,659]

If it's in USER cert store then my guess is that you or process can update it without any prompt. I will check this.

ESET did do something with their certificates last week....

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.

[bbahes 29]

I guess Windows allows root CA update in certain conditions...and Primary Root CA for ESET certificates (at least for this forum) is Thawte.

 

hxxp://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows/

[rugk 397]

@bbahes
No the article you linked has nothing to with the case we're talking here.

Here we are talking about ESETs SSL scanning which means ESS imports a root certificate into trusted root certification stores (Windows and Firefox e.g.)

 

@itman

You're issue really looks suspicious.

Someone or something seems to replace root certificates and made screenshots. AFAIK ESS doesn't update the root certificate by itself so if it was really replaced this could be done by malware.

 

You could also try to look at the running processes and look whether there are some recognized by LiveGrid with a state which is not green.

Similar you could do this with ESET SysInspector.

[bbahes 29]

@bbahes

No the article you linked has nothing to with the case we're talking here.

 

I was just pointing out that some root certificates in Windows are self updateable in certain conditions.

So if trusts Thawte root CA it is possible it trusts ESET root CA.

[itman 1,659]

@bbahes

No the article you linked has nothing to with the case we're talking here.

Here we are talking about ESETs SSL scanning which means ESS imports a root certificate into trusted root certification stores (Windows and Firefox e.g.)

 

@itman

You're issue really looks suspicious.

Someone or something seems to replace root certificates and made screenshots. AFAIK ESS doesn't update the root certificate by itself so if it was really replaced this could be done by malware.

 

You could also try to look at the running processes and look whether there are some recognized by LiveGrid with a state which is not green.

Similar you could do this with ESET SysInspector.

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.  

 

 

Edited April 28, 2015 by itman

[rugk 397]

@itman

I think you misunderstood something there. AFAIK The ESET root certificate isn't protected at all. It can be changed by any software on the computer - like all other root certificates too.

 

If there is really everything clean in SysInspector this would be great. However in nearly every SysInspector log I have seen are at least some files unknown.

Su just FYI you can filter the SysInspector logs with a slider.

[cutting_edgetech 25]

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.

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.

Edited April 29, 2015 by cutting_edgetech

[itman 1,659]

 

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.

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.

Edited April 29, 2015 by itman

[itman 1,659]

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.

 

 

[rugk 397]

Okay, great that it doesn't seem to be such bad as we suspected.

[cutting_edgetech 25]

I actually like to filter SSL protcol, but i'm afraid to try it now. I have had problems in the past with many pages just timming out, and it was a big headache. I disabled SSL protocol scanning, and that fixed the problem. This was like in NOD 32 version 5, or 6 though so a lot could have changed since then. I'm beta testing some other software right now so  if I did run into problems it would take even more of my limited time to report it so i'm going to hold off on trying it again for now. Maybe I will try enabling SSL Protocol again once I have more time.

Edited May 2, 2015 by cutting_edgetech

[itman 1,659]

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.

Edited May 8, 2015 by itman