SSL/TLS filtering affects cscript.exe

[kakolukia91 0]

Hi.

I've got the following setup that I'm facing a problem with when SSL/TLS filtering is turned on. This is within a Windows 10 environment.

• Eset Smart Security Premium
• A local WIndows Service that uses a self-signed SSL/TLS certificate. The certificate is generated on the fly when the service is started. The generation logic uses an installed certificate from the local computer trusted store to generate a self-signed session certificate. 
• A library that communicates with the local Windows Service using the public key of the installed certificate from the trusted store.
• A VBScript client that makes use of the library above. The VBScript is hosted by the cscript.exe from C:\Windows\Syswow64

The problem I'm facing is that when the VBScript is run, the SSL/TLS handshake fails when communicating with the Windows Service if Eset SSL/TLS filtering is turned on. What's confusing is that if I create a .NET/C# client that makes use of the same library as the VBScript one, the communication does not fail when Eset SSL/TLS filtering is on. The only difference is that the .NET/C# client is its own executable, whereas the VBScript is hosted within the cscript.exe one.

I can workaround the issue by telling Eset to ignore filtering cscript.exe or the certificate in question, but I don't understand why Eset is affecting cscript.exe, but not standard .NET/C# apps?

The Eset documentation suggests self-signed certificates should be put in the trusted store, and the root certificate that the session one gets generated from is definitely in the trusted store.

Any ideas please?

Thanks.

[Marcos 5,074]

What Windows service and library are you referring to?

[kakolukia91 0]

32 minutes ago, Marcos said:

What Windows service and library are you referring to?

It's a proprietary Windows Service and library we develop, so not something that comes out of the box with Windows.

The service runs behind a C++ gRPC server.

The library is an ATL COM library that allows it to be used from both .NET and VBScript. The library itself makes client calls to the Windows Service.

All works fine without Eset SSL/TLS filtering turned on, and only the VBScript client is affected when the option is turned on.

[itman 1,659]

4 hours ago, kakolukia91 said:

The problem I'm facing is that when the VBScript is run, the SSL/TLS handshake fails when communicating with the Windows Service if Eset SSL/TLS filtering is turned on. What's confusing is that if I create a .NET/C# client that makes use of the same library as the VBScript one, the communication does not fail when Eset SSL/TLS filtering is on. The only difference is that the .NET/C# client is its own executable, whereas the VBScript is hosted within the cscript.exe one.

My best guess at this point is it has something to do with Eset AMSI scanning of scripts.

To verify this assumption, you can temporarily disable AMSI scanning as shown in the below screen shot. Then test to see if this resolves the issue. When done testing, re-enable AMSI scanning:

 

[kakolukia91 0]

2 hours ago, itman said:

My best guess at this point is it has something to do with Eset AMSI scanning of scripts.

To verify this assumption, you can temporarily disable AMSI scanning as shown in the below screen shot. Then test to see if this resolves the issue. When done testing, re-enable AMSI scanning:

 

Thanks for the suggestion. I've tried to turn AMSI off, but unfortunately the same issue persists. For what it's worth, here's what gets written to the console when I run cscript.exe against the VBScript:

E0206 21:00:55.058000000  7936 ssl_transport_security.cc:1455] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.