Problem with eamsi.dll certificate

[Pavol Cerven 0]

Hello,

during testing our program we found out your dll file eamsi.dll inject into our process. Because this file is signed with Microsoft's certificate it will be no problem. File has 3 signatures:

1. ESET, spol. s r.o. -> it's ok
2. Microsoft Windows Hardware Compatibility Publisher -> it's ok
3. ESET, spol. s r.o. -> If you open "view certificate" then you will see: "This certificate cannot be verified up to a trusted certification authority" and if you open "Certification Path" then you will see "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store."

I did a quick check and think many other files have the same problem (dmon.dll). 

Can you please update your certificates or maybe inject your files more hidden way?

[Marcos 5,234]

ESET does not inject eamsi.dll anywhere. It's other process that load registered AMSI provider dlls themselves.

The signatures are correct, not sure what you mean that dmon.dll has the same problem. What problem?

[itman 1,741]

12 hours ago, Marcos said:

The signatures are correct

Windows doesn't think they are;

And my Win Code Integrity Event log is full of errors because of this;

[itman 1,741]

As far as what the OP is referring to, it appears Eset's cert. has expired;

[Marcos 5,234]

What matters is the countercertificate. Moreover, the above cert. is a self-signed certificate which is validated internally regardless of the expiration date.

[Pavol Cerven 0]

Marcos if you think your certificates are correct, then you try to call WinVerifyTrust function. For eamsi.dll it returns error code 0x800B0109 which is CERT_E_UNTRUSTEDROOT. 

Before you reply try opening (ALT+ENTER)  eamsi.dll in Windows and check what Windows display for your certificates. It doesn't look correct. I am sorry.

I have 3 licenses of ESET Internet Security and it's the same at Win11, Win10, and Win7.

 

 

Edited July 21, 2023 by Pavol Cerven

[Marcos 5,234]

The above signature is irrelevant. It's signed by a self-signed ESET certificate which doesn't need to be trusted by WIndows but it's trusted by ekrn.exe and that's the point.

[itman 1,741]

22 hours ago, Pavol Cerven said:

during testing our program we found out your dll file eamsi.dll inject into our process. Because this file is signed with Microsoft's certificate it will be no problem.

You need to further define what the problem is.

Did you setup this program to only accept valid code signed .dlls? Is eamsi.dll loading into this program failing for that reason?

As best as I can determine, loading of eamsi.dll into a process will occur regardless of the code integrity error;

Edited July 21, 2023 by itman

[Pavol Cerven 0]

Our protection solution accepts in process only dlls with known certificates and valid signed dlls  . I can add Eset's certificate as a known certificate. It is not the problem. The problem is a return value from WinVerifyTrust function. All correctly signed files normally return ERROR_SUCCESS. But eamsi.dll returns  CERT_E_UNTRUSTEDROOT. 

[itman 1,741]

10 hours ago, Pavol Cerven said:

Our protection solution accepts in process only dlls with known certificates and valid signed dlls  . I can add Eset's certificate as a known certificate. It is not the problem. The problem is a return value from WinVerifyTrust function. All correctly signed files normally return ERROR_SUCCESS. But eamsi.dll returns  CERT_E_UNTRUSTEDROOT. 

As @Marcos explained previously, your protection solution shouldn't be performing WinVerifyTrust activities for self-signed certs.. I would contact the protection solution vendor about the issue.

-EDIT- As I see it, your protection solution should be first performing;

Quote

The WTHelperCertIsSelfSigned function checks whether a certificate is self-signed. This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Wintrust.dll.

https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-wthelpercertisselfsigned

Then bypassing the WinVerifyTrust function if the cert. is self-signed.

Edited July 22, 2023 by itman

[Pavol Cerven 0]

itman: Thank you for your answers, they are very helpful. But one thing I don't understand. 

You will add Eset's certificate to the whitelist of allowed certs. Then the security solution will check if it is the same cert. At this point everything is fine. Then you will call WTHelperCertIsSelfSigned function. It will return "it is self-signed cert". And then what? You can't call WinVerifyTrust because it will return CERT_E_UNTRUSTEDROOT. But how you will check if certs are ok and nobody changed the file? Then anybody can use a self-signed cert for another file or change eamsi.dll and you will allow it? 

This is what I don't understand. And I appreciate your opinion because your answers make sense.

Btw: I looking for answers for others, because we have our's cert handling, checking, etc. You give me the correct way how we will do it for problematic certs like this (we will see if we can really do it in the correct way).

Edited July 22, 2023 by Pavol Cerven

[itman 1,741]

Since your concern seems to be with eamsi.dll not be validily signed, note the following;

Quote

Starting in Windows 10, version 1903, if your AMSI provider DLL is not Authenticode-signed, then it may not be loaded (depending on how the host machine is configured). For full details, see IAntimalwareProvider interface.

https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal .