A signed .NET application is detected as WS.Reputation.1

Products

Endpoint Protection

Issue/Introduction

You developed a .NET application and signed it with a strong name, using one of the methods described in How to: Sign an Assembly with a Strong Name.
After deploying the application in your environment, you find it is detected as WS.Reputation.1.

Cause

Creating a strong-named .NET assembly is done for the purposes of versioning and naming protection. It allows the assembly to be installed in the Global Assembly Cache (GAC), located in C:\Windows\assembly\GAC. The GAC stores assemblies specifically designated to be shared by several applications on a system. Signing with a Strong Named Key (SNK) is done to uniquely identify an application, for the purpose of inter-assembly trust. As pointed out in Strong-Named Assemblies, it should not be relied upon for security. As such, it does not weigh into Symantec's software trust verification process.

It cannot be emphasized enough that, while strong-naming an assembly attempts to guarantee its integrity, it does not at all guarantee its safety. As literally anyone with a free copy of Visual Studio (or open source alternative) can create a strong-named assembly, endpoint security companies cannot assign any level of trust to the fact that an assembly has been strong-named. Microsoft themselves emphasizes this point in Enhanced Strong Naming:

Strong name signatures help prevent malicious parties from tampering with an assembly and then re-signing the assembly with the original signer’s key. However, strong name keys don’t contain any reliable information about the publisher, nor do they contain a certificate hierarchy. A strong name signature does not guarantee the trustworthiness of the person who signed the assembly or indicate whether that person was a legitimate owner of the key; it indicates only that the owner of the key signed the assembly. Therefore, we do not recommend using a strong name signature as a security validator for trusting third-party code. Microsoft Authenticode is the recommended way to authenticate code.

While it was fine to rely on conventional strong naming when it was introduced some 15 years ago, it makes use of SHA-1 hashing, against which successful collision attacks have been performed (different files with the same SHA-1 hash were produced). Given that, strong-named malware could be created that has the same SHA-1 hash as one of your assemblies and deployed in your environment. While one could make use of enhanced strong naming (strong naming with a SHA-256 hash) to mitigate this, the fact remains that code signing applications is the only recommended way to authenticate them.

Unsigned internal applications are particularly prone to WS.Reputation.1 detection, as we combine file age, file download source, digital signature, and file prevalence using a proprietary algorithm to determine their safety reputation.

Resolution

In addition to strong-naming your assemblies, consider code signing them, even if the concerned application is internal only. Code signing an application will give it a good rating at the outset, thereby making a WS.Reputation.1 detection of that application unlikely (albeit not entirely impossible). Code signing can be fully automated, by adding it as a post-build event in Visual Studio.

Code Signing is the process of digitally signing executables and scripts to allow to confirm the software author. It guarantees that the code has not been altered or corrupted since it was signed. It adds a Digital Signatures tab to a file's properties in Windows and enables software trust verification through Windows' WinVerifyTrust function. The same function is used in our product to verify whether or not software can be trusted (as part of SymVerifyTrust). The SymVerifyTrust check is what your software failed, as a result making it a lot more likely to be detected as WS.Reputation.1.

Should you choose to forego code signing, it is recommended to submit every new version of your application via the Symantec Security Response False-Positive web site and wait until you receive actual confirmation that it has been whitelisted prior to deploying it in your environment. If you are a core customer, you are welcome to join our Enterprise Customer Software Whitelisting Program to greatly facilitate the whitelisting process. To do so, reach out to your designated support/sales contact. Our Whitelisting team will then reach out to you and provide all relevant information. Note that only the Whitelisting can provide this information to you. It is not available to Symantec Support.