Microsoft DotNet Framework 4.0 STIG SCAP Benchmark

  • Version/Release: V2R2
  • Published: 2020-12-11
  • Severity:
  • Sort:
View

Select any old version/release of this SCAP to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
b
Digital signatures assigned to strongly named assemblies must be verified.
RMF Control
IA-5
Severity
Medium
CCI
CCI-000185
Version
APPNET0031
Vuln IDs
V-225223
Rule IDs
SV-225223r615940_rule
A strong name consists of the assembly's identity, simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. Strong names serve to identify the author of the code. If digital signatures used to sign strong name assemblies are not verified, any self signed code can be impersonated. This can lead to a loss of system integrity.
Fix: F-26910r467985_fix

Use regedit to remove the values stored in Windows registry key HKLM\Software\Microsoft\StrongName\Verification. There should be no assemblies or hash values listed under this registry key. All assemblies must require strong name verification in a production environment. Strong name assemblies that do not require verification in a development or test environment must have documented approvals from the IAO.

b
The .NET CLR must be configured to use FIPS approved encryption modules.
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
APPNET0062
Vuln IDs
V-225230
Rule IDs
SV-225230r615940_rule
FIPS encryption is configured via .NET configuration files. There are numerous configuration files that affect different aspects of .Net behavior. The .NET config files are described below. Machine Configuration Files: The machine configuration file, Machine.config, contains settings that apply to an entire computer. This file is located in the %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config directory for 32 bit .NET 4 installations and %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config for 64 bit systems. Machine.config contains configuration settings for machine-wide assembly binding, built-in remoting channels, and ASP.NET. Application Configuration Files: Application configuration files contain settings specific to an application. If checking these files, a .NET review of a specific .NET application is most likely being conducted. These files contain configuration settings that the Common Language Runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the application can read. The name and location of the application configuration file depends on the application's host, which can be one of the following: Executable–hosted application configuration files. The configuration file for an application hosted by the executable host is in the same directory as the application. The name of the configuration file is the name of the application with a .config extension. For example, an application called myApp.exe can be associated with a configuration file called myApp.exe.config. Internet Explorer-hosted application configuration files. If an application hosted in Internet Explorer has a configuration file, the location of this file is specified in a tag with the following syntax. In this tag, "location" represents a URL that point to the configuration file. This sets the application base. The configuration file must be located on the same web site as the application. .NET 4.0 allows the CLR runtime to be configured to ignore FIPS encryption requirements. If the CLR is not configured to use FIPS encryption modules, insecure encryption modules might be employed which could introduce an application confidentiality or integrity issue.
Fix: F-26917r468006_fix

Examine the .NET CLR configuration files to find the runtime element and then the "enforceFIPSPolicy" element. Example: <configuration> <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> Delete the "enforceFIPSPolicy" runtime element, change the setting to "true" or there must be documented IAO approvals for the FIPS setting.

b
Event tracing for Windows (ETW) for Common Language Runtime events must be enabled.
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
APPNET0067
Vuln IDs
V-225235
Rule IDs
SV-225235r615940_rule
Event tracing captures information about applications utilizing the .NET CLR and the .NET CLR itself. This includes security oriented information, such as Strong Name and Authenticode verification. Beginning with Windows Vista, ETW is enabled by default however, the .Net CLR and .Net applications can be configured to not utilize Event Tracing. If ETW event tracing is disabled, critical events that occurred within the runtime will not be captured in event logs.
Fix: F-26922r468021_fix

Open Windows explorer and search for all .NET config files including application config files (*.exe.config). Examine the configuration settings for <etwEnable enabled="false" />. Enable ETW Tracing by setting the etwEnable flag to "true" or obtain documented IAO approvals.

b
Disable TLS RC4 cipher in .Net
RMF Control
CM-7
Severity
Medium
CCI
CCI-001762
Version
APPNET0075
Vuln IDs
V-225238
Rule IDs
SV-225238r615940_rule
Use of the RC4 cipher in TLS could allow an attacker to perform man-in-the-middle attacks and recover plaintext from encrypted sessions. Applications that target .Net version 4.x running on multiple Windows versions could be vulnerable to these types of attacks. The registry settings in this requirement will prevent .Net applications that target the 4.x framework from selecting and utilizing the Schannel.dll RC4 cipher for TLS connections. Applications that use TLS when connecting to remote systems will perform a handshake and negotiate the TLS version and cipher that is to be used between the client and the server. This is standard protocol for all TLS connections. If the server and client are not configured to use the same TLS version and cipher, the TLS connection may fail. Applications should be tested with these registry settings prior to production implementation of the fix in order to avoid application outages.
Fix: F-26925r612667_fix

Use regedit to access the following registry key. For 32-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ For 64-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\ Modify or create the following Windows registry value: SchUseStrongCrypto Set SchUseStrongCrypto to a REG_DWORD value of “1”.