Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

Microsoft Dot Net Framework 4.0 STIG

V1R2 · · · Released 24 Jan 2014 · 21 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

Applicable to systems and applications utilizing the Microsoft .Net version 4.0 framework.
Sort by
b
Digital signatures assigned to strongly named assemblies must be verified.
Medium - V-7055 - SV-7438r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0031
Vuln IDs
  • V-7055
Rule IDs
  • SV-7438r2_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. System AdministratorDCSL-1
Checks: C-3958r8_chk

Use regedit to review the Windows registry key HKLM\Software\Microsoft\StrongName\Verification. There should be no assemblies or hash values listed under this registry key. If there are assemblies or hash values listed in this key, each value represents a distinct application assembly that does not have the application strong name verified. If any assemblies are listed as omitting strong name verification in a production environment, this is a finding. If any assemblies are listed as omitting strong name verification in a development or test environment and the IAO has not provided documented approvals, this is a finding.

Fix: F-12596r7_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
Windows systems must be configured to prevent application use of Test Root certificates.
Medium - V-7061 - SV-7444r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0046
Vuln IDs
  • V-7061
Rule IDs
  • SV-7444r2_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. A root certificate is a public key certificate or self signed certificate that identifies the Root Certificate Authority. Digital certificates are verified by using a chain of trust. The trust anchor for digital certificates is the Root Certificate Authority (CA). A CA may generate a Test Root Certificate that is used for testing purposes. Configuring production Windows systems to allow applications to use Test Root Certificates in order to ascertain trust can create an integrity risk.Systems that are compliant with this STIG requirement, may experience operational issues when attempting to run or install signed applications and device drivers that have been signed with a test root certificate. This is due to the production system being configured to require that certificates marked as being for test purposes only are not used. System AdministratorDCSL-1
Checks: C-3966r17_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the user's "State" registry key. Each character in the hex string will be referred to as a "nibble". For example, a hex value of 100a0 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the users registry key. Select "Bin". The value will automatically convert to a binary value. Start the count from 1 (not 0) and count the bit values starting from the right and moving to the left. The total number of bits will vary from 18 to 20 depending upon the hex values input into the calculator. If bit positions 6 and 8 are not values of "0" on production systems, this is a finding. If bit positions 6 and 8 are not values of "0" on a development system and the IAO has not provided documented approval, this is a finding.

Fix: F-12602r10_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal value in nibble position 2 to "0". For development systems, change the hexadecimal value in nibble position 2 to "0" or the IAO must approve the settings. Example fix: Hex value: 100a0 Nibble position: 54321 To apply fix, example hex value "a" in nibble position 2 would be changed to hex value "0" resulting in a hex value of 10000.

b
Windows must check for expired application certificates
Medium - V-7062 - SV-7445r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0047
Vuln IDs
  • V-7062
Rule IDs
  • SV-7445r2_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not check for expired certificates creating an integrity risk which could result in malware running on the system. APPNET0047_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
Checks: C-3971r15_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the users "State" registry key. Each character in the hex string will be referred to as a "nibble". For example, a hex value of 10c00 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. The nibble position must be utilized when applying the fix to the hexadecimal value. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the user’s registry key. Select "Bin". The hex value will automatically convert to a binary value. Start the count from 1 (not 0) and count the bit positions starting from the right and moving to the left. The total number of bit positions will vary from 18 to 20 depending upon the hex values input into the calculator. If bit position 9 is not a value of "0" on production systems, this is a finding. If bit position 9 is not a value of "0" on a development system and the IAO has not provided documented approval, this is a finding.

Fix: F-12603r8_fix

Using regedit, verify the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal value in nibble position 3 to "0". For development systems, change the hexadecimal value in nibble position 3 to "0" or the IAO must provide documented approval. Example fix: Hex value: 10c00 Nibble position: 54321 To apply fix, example hex value "c" in nibble position 3 would be changed to hex value "0" resulting in a hex value of 10000.

b
Developer certificates used with the .NET Publisher Membership Condition must be approved by the IAO.
Medium - V-7063 - SV-7446r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0048
Vuln IDs
  • V-7063
Rule IDs
  • SV-7446r2_rule
A .Net assembly will satisfy the Publisher Membership Condition if it is signed with a software publisher’s Authenticode X.509v3 digital certificate that can be verified by the Windows operating system as having a chain of trust that leads to a trusted root certificate stored in the user’s certificate store. The Publisher Membership Condition can be used to identify an organization, developer, vendor, or other entity as the ultimate source of the assembly, even if the code itself was obtained from a third party, such as a mirror site. Access to system resources, such as file systems or printers, may then be granted to the assembly based on the trust relationship with the identified entity. Certificates used to sign assemblies so the Publisher Member Condition may be applied must originate from a trusted source. Using a certificate that is not from a trusted source could potentially violate system integrity and confidentiality.System AdministratorDCSL-1
Checks: C-3972r12_chk

Caspol.exe is a Microsoft tool used for working with .Net policy. Use caspol.exe to list the code groups and any publisher membership conditions. The location of the caspol utility is dependent upon the system architecture of the system running .Net. For 32 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319. For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET64\Framework\v4.0.30319. Example: cd %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 To check code groups for the machine, run the following command. caspol.exe -m -lg Sample Results: Microsoft (R) .NET Framework CasPol 4.0.30319.1 Copyright (c) Microsoft Corporation. All rights reserved. Policy change prompt is ON Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - MyComputer: FullTrust (LevelFinal) 1.1.1. StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust 1.1.2. StrongName - 00000000000000000400000000000000: FullTrust 1.2. Zone - Intranet: LocalIntranet 1.2.1. All code: Same site Web 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' 1.3. Zone - Internet: Internet 1.3.1. All code: Same site Web 1.4. Zone - Untrusted: Nothing 1.5. (First Match) Zone - Trusted: Internet 1.5.1. All code: Same site Web 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success Section 1.6 above indicates the presence of a publishers key that meets the Publishers Membership Condition and is also given full trust. If the Publisher Membership Condition is used on a non-default Code Group and the use of that publisher's certificate is not documented and approved by the IAO, this is a finding.

Fix: F-12604r5_fix

Trust must be established when utilizing Publishers Membership Condition. All publishers' certificates must have documented approvals from the IAO.

b
Windows must be configured to check for revoked application certificates.
Medium - V-7064 - SV-41559r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0049
Vuln IDs
  • V-7064
Rule IDs
  • SV-41559r1_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not check for revoked certificates creating an integrity risk that could result in malware being run on the system. APPNET0049_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications. This is due to the system being configured to require certificate validation checks prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
Checks: C-3973r19_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate HKEY_USER\[UNIQUE USER SID VALUE HERE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State. Document the Hexadecimal value of the user's "State" registry key. Each character in the hex string will be referred to as a "nibble", so a hex value of 10f00 has 5 binary "nibbles". Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex values obtained from the user's registry key. Select "Bin". The value will automatically convert to a binary value. Start the count from 1 (not 0) and count the bit values starting from right to the left. The total number of bits will vary from 18 to 20 depending upon the hex values. If bit 10 is not a "0" value on production systems, this is a finding. If bit 10 is not a "0" value on a development system and the IAO has not provided documented approval, this is a finding.

Fix: F-35213r9_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal values for nibble position 3 to "0". For development systems, change the hexadecimal values for nibble position 3 to "0" or the IAO must provide documented approval. Example fix: Hex value: 10f00 Nibble position: 54321 To apply fix, the example hex value "f" in nibble position 3 would be changed to hex value "0" resulting in a hex value of 10000.

b
Windows must be configured to block application execution if certificate server status is unavailable.
Medium - V-7065 - SV-7448r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0050
Vuln IDs
  • V-7065
Rule IDs
  • SV-7448r2_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. Certificate validation tests include certificate revocation checks to determine if the certificate has been revoked by the certificate authority. In order for Authenticode to test the certificate for revocation, the authoritative revocation server must be available. If the revocation server is not available, the certificate status is unknown and the software must be prevented from running until the certificate can be validated. By default, Windows will allow application software to run if the certificate revocation server is offline and not available. This creates an integrity risk of malware being introduced into the system. APPNET0050_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate server status validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate server availability status when installing on an isolated network or system, the installer must manually validate certificate server availability prior to application installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA server, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
Checks: C-40063r15_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the user's "State" registry key. Each character in the hex string will be referred to as a "nibble". For example, a hex value of 1da00 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the user's registry key. Select "Bin". The hex value will automatically convert to a binary value. Start the count from 1 (not 0) and count the positions of the bit values starting from the right and moving to the left. The total number of bit positions will vary from 18 to 20 depending upon the hex values input into the calculator. If bit positions 11, 12, 13, and 14 are not "0" values on a production system, this is a finding. If bit positions 11, 12, 13, and 14 are not "0" values on a development system and the IAO has not provided documented approval, this is a finding.

Fix: F-35216r8_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal values for nibble positions 3 and 4 to "0". For development systems, change the hexadecimal values for nibble positions 3 and 4 to "0" or the IAO must provide documented approval. Example fix: Hex value: 1da00 Nibble position: 54321 To apply fix, example hex value "a" in nibble position "3" and hex value "d" in nibble position 4 would both be changed to hex value "0" resulting in a final hex value of 10000.

b
Windows must be configured to check the time stamp servers certificate for revocation.
Medium - V-7066 - SV-7449r3_rule
RMF Control
Severity
M
CCI
Version
APPNET0051
Vuln IDs
  • V-7066
Rule IDs
  • SV-7449r3_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. As part of the overall signing process, a trusted time stamp server also digitally signs the assembly. The time stamp server's signature confirms the developer's certificate was valid at the time the developer signed the assembly. If the system is not configured properly, Authenticode will not check for revocation of the time stamp server’s certificate. Not checking for certificate revocation creates a risk that could lead to a loss of system integrity. APPNET0051_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the time stamp certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered.System AdministratorDCSL-1
Checks: C-3976r17_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the user's "State" registry key. Each character in the hex string will be referred to as a "nibble". For example, a hex value of d0000 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the user’s registry key. Select "Bin". The hex value will automatically convert to a binary value. Start the count from 1 (not 0) and count the bit positions starting from the right and moving to the left. The total number of bit positions will vary from 18 to 20 depending upon the hex values input into the calculator. If bit position 18 is not a value of "0" on production systems, this is a finding. If bit position 18 is not a value of "0" on development systems and the IAO has not provided documented approval, this is a finding.

Fix: F-12607r12_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal value for nibble position 5 to "1". For development systems, change the hexadecimal value for nibble position 5 to "1" or the IAO must provide documented approval. Example fix: Hex value: d0000 Nibble position: 54321 To apply fix, the example hex value "d" in nibble position 5 would be changed to a hex value of "1" resulting in a hex value of 10000.

b
Encryption keys used for the .NET Strong Name Membership Condition must be protected.
Medium - V-7067 - SV-7450r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0052
Vuln IDs
  • V-7067
Rule IDs
  • SV-7450r2_rule
The Strong Name Membership condition requires that member assemblies be defined with Strong Names. 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. If assemblies do not have a strong name assigned, the assembly cannot be unique and the author of the code cannot be uniquely identified. In order to create the strong name, the developer must use a cryptographic key pair to sign the assembly. If the developer does not protect the key, the key can be stolen and used to sign any application, including malware applications. This could adversely affect application integrity and confidentiality.Systems ProgrammerDCSL-1
Checks: C-3977r14_chk

If the application is a COTS product, the requirement is Not Applicable (NA). Caspol.exe is a Microsoft tool used for working with .Net policy. Use caspol.exe to list the code groups and any publisher membership conditions. The location of the caspol utility is dependent upon the system architecture of the system running .Net. For 32 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319. For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET64\Framework\v4.0.30319. Example: cd %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 To check code groups, run the following command: caspol.exe -all -lg Sample response: Microsoft (R) .NET Framework CasPol 4.0.30319.1 Security is ON Execution checking is ON Policy change prompt is ON Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - MyComputer: FullTrust (LevelFinal) 1.1.1. StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust 1.1.2. StrongName - 00000000000000000400000000000000: FullTrust 1.2. Zone - Intranet: LocalIntranet 1.2.1. All code: Same site Web 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' 1.3. Zone - Internet: Internet 1.3.1. All code: Same site Web 1.4. Zone - Untrusted: Nothing 1.5. (First Match) Zone - Trusted: Internet 1.5.1. All code: Same site Web 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success An assembly will satisfy the StrongName Membership Condition if its metadata contains the strongly identifying data associated with the specified strong name. At the least, this means it has been digitally signed with the private key associated with the public key recorded in the policy. The presence of the encryption key values in the StrongName field indicates the use of StrongName Membership Condition. If a Strong Name Membership Condition is assigned to a non-default Code Group the private key must be adequately protected by the software developer or the entity responsible for signing the assemblies. Ask the Systems Programmer how the private keys are protected. Private keys are simply values stored as strings of data. Keys can be stored in files on the file system or in a centralized data repository. Adequate protection methods include, but are not limited to: - utilizing centralized key management; - using strict file permissions to limit access; and - tying strong pass phrases to the key. If the private key used to sign the assembly is not adequately protected, this is a finding.

Fix: F-12608r7_fix

Ask the Systems Programmer how the private keys used to sign the assembly are protected. Private keys are simply values stored as strings of data. Keys can be stored in files on the file system or in a centralized data repository. Adequate protection methods include, but are not limited to: - utilizing centralized key management; - using strict file permissions to limit access; and - tying strong pass phrases to the key. The private key(s) used to sign the assembly must be protected. Utilize centralized key management or strict file permissions along with strong pass phrases and/or other well established industry practices for managing and controlling access to private keys.

b
CAS and policy configuration files must be backed up.
Medium - V-7069 - SV-7452r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0055
Vuln IDs
  • V-7069
Rule IDs
  • SV-7452r2_rule
A successful disaster recovery plan requires that CAS policy and CAS policy configuration files are identified and included in systems disaster backup and recovery events. Documentation regarding the location of system and application specific CAS policy configuration files and the frequency in which backups occur is required. If these files are not identified and the information is not documented, there is the potential that critical application configuration files may not be included in disaster recovery events which could lead to an availability risk.System AdministratorCODB-1, CODB-2
Checks: C-3980r4_chk

Ask the System Administrator if all CAS policy and policy configuration files are included in the system backup. If they are not, this is a finding. Ask the System Administrator if the policy and configuration files are backed up prior to migration, deployment, and reconfiguration. If they are not, this is a finding. Ask the System Administrator for documentation that shows CAS Policy configuration files are backed up as part of a disaster recovery plan. If they have no documentation proving the files are backed up, this is a finding.

Fix: F-12610r3_fix

All CAS policy and policy configuration files must be included in the system backup. All CAS policy and policy configuration files must be backed up prior to migration, deployment, and reconfiguration. CAS policy configuration files must be included in disaster recovery plan documentation.

b
Remoting Services HTTP channels must utilize authentication and encryption.
Medium - V-7070 - SV-7453r2_rule
RMF Control
Severity
M
CCI
Version
APPNET0060
Vuln IDs
  • V-7070
Rule IDs
  • SV-7453r2_rule
.NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. Any unauthorized use of a remoting application provides unauthorized access with FullTrust permissions to the system. This can potentially result in a loss of system integrity or confidentiality. System AdministratorDCSL-1
Checks: C-3981r16_chk

Check the machine.config and the [application executable name].exe.config configuration files for the typefilterlevel="Full" configuration parameter. The machine.config file is contained in the folder %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 or %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Microsoft specifies locating the application config file in the same folder as the application executable (.exe) file. However, the developer does have the capability to specify a different location when the application is compiled. Therefore, if the file is not found in the application home folder, a search of the system is required. If the [application name].exe.config file is not found on the system, then only a check of the machine.config file is required. Sample machine/application config file: <application name=“remoteserver”> <service> <activated type=“sample.my.object, myobjects”/> </service> <channels> <channel ref=“http server” port=“80”/> </channels> </application> <serverProviders> <provider ref="wsdl" /> <formatter ref="soap" typeFilterLevel="Full" /> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> Microsoft provides 3 "channels" that are used for remoting connectivity. They are the HTTP, TCP and IPC channels. The channel that is used is specified via the <channels> element in the config file. HTTP channel example: <channel ref=“http server” port=“80”/> The HTTP Channel only supports encryption and message integrity when the remote object is hosted in Internet Information Services (IIS) using SSL. The above example shows the well known SSL port of 443 is not being used. If encryption and message integrity are not used for the HTTP remoting channel when the ServerProvider element typefilterlevel=”Full”, this is a finding.

Fix: F-12611r8_fix

Ensure encryption and message integrity are used for HTTP remoting channels when the "typefilterlevel" element is set to "Full". The HTTP Channel only supports encryption and message integrity when the remote object is hosted in Internet Information Services (IIS) using SSL. HTTP channels are protected via SSL (HTTPS). <channels> <channel ref=“http server” port=“443”/> </channels> Change the channel ref parameter to utilize an SSL port and leverage SSL on the remote IIS server.

b
.Net Framework versions installed on the system must be supported.
Medium - V-18395 - SV-55642r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0061
Vuln IDs
  • V-18395
Rule IDs
  • SV-55642r1_rule
Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.COMS-1
Checks: C-21095r12_chk

Determine which versions of the .NET Framework are installed by opening the directory %systemroot%\Microsoft.NET. The folder named "%systemroot%\Microsoft.NET\Framework" contains .NET files for 32 bit systems. The folder named "%systemroot%\Microsoft.NET\Framework64" contains .NET files for 64 bit systems. 64 bit systems will have both the 32 bit and the 64 bit folders while 32 bit systems do not have a Framework64 folder. Within each of the aforementioned folders are the individual folder names that contain the corresponding versions of the .NET Framework: v4.0.30319 v3.5 v3.0 v2.0.50727 v1.1.4322 v1.0.3705 Search for all the Mscorlib.dll files in the %systemroot%\Microsoft.NET\Framework folder and the %systemroot%\Microsoft.NET\Framework64 folder if the folder exists. Click on each of the files, view properties, and click version tab to determine the version installed. If there is no Mscorlib.dll, there is no installed version of .Net Framework in that directory. More specific information on determining versions of .Net Framework installed can be found at the following link. http://support.microsoft.com/kb/318785 Verify extended support is available for the installed versions of .Net Framework. Verify the .Net Framework support dates with Microsoft Product Lifecycle Search link. http://support.microsoft.com/lifecycle/search/?sort=PN&amp;alpha=.NET+Framework Beginning with .NET 3.5 SP1, the .NET Framework is considered a Component of the Windows OS. Components follow the Support Lifecycle policy of their parent product or platform. If any versions of the .Net Framework are installed and support is no longer available, this is a finding.

Fix: F-19030r2_fix

Remove unsupported versions of the .NET Framework and upgrade legacy applications that utilize unsupported versions of the .NET framework.

b
The .NET CLR must be configured to use FIPS approved encryption modules.
Medium - V-30926 - SV-40966r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0062
Vuln IDs
  • V-30926
Rule IDs
  • SV-40966r1_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. System AdministratorWeb AdministratorDCNR-1
Checks: C-39583r7_chk

Examine the .NET CLR configuration files from the vulnerability discussion to find the runtime element and then the "enforceFIPSPolicy" element. Example: &lt;configuration&gt; &lt;runtime&gt; &lt;enforceFIPSPolicy enabled="true|false" /&gt; &lt;/runtime&gt; &lt;/configuration&gt; By default, the .NET "enforceFIPSPolicy" element is set to "true". If the "enforceFIPSPolicy" element does not exist within the "runtime" element of the CLR configuration, this is not a finding. If the "enforceFIPSPolicy" element exists and is set to "false", and the IAO has not accepted the risk and documented the risk acceptance, this is a finding.

Fix: F-34734r4_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
.NET must be configured to validate strong names on full-trust assemblies.
Medium - V-30935 - SV-40977r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0063
Vuln IDs
  • V-30935
Rule IDs
  • SV-40977r1_rule
The "bypassTrustedAppStrongNames" setting specifies whether the bypass feature that avoids validating strong names for full-trust assemblies is enabled. By default the bypass feature is enabled in .Net 4, therefore strong names are not validated for correctness when the assembly/program is loaded. Not validating strong names provides a faster application load time but at the expense of performing certificate validation. Full trust assemblies are .Net applications launched from the local host. Strong names are digital signatures tied to .Net applications/assemblies. .Net 4 considers applications installed locally to be fully trusted by default and grants these applications full permissions to access host resources. The bypass feature applies to any assembly signed with a strong name and having the following characteristics: Fully trusted without the StrongName evidence (for example, has MyComputer zone evidence). Loaded into a fully trusted AppDomain. Loaded from a location under the ApplicationBase property of that AppDomain. Not delay-signed. Not validating the certificates used to sign strong name assemblies will provide a faster application load time, but falsely assumes that signatures used to sign the application are to be implicitly trusted. Not validating strong name certificates introduces an integrity risk to the system.System AdministratorDCSL-1
Checks: C-39596r12_chk

Use regedit to examine the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework key. If the "AllowStrongNameBypass" registry key does not exist on production systems, this is a finding. If the "AllowStrongNameBypass" registry key exists and the DWORD value is set to 1 (true) on production systems, this is a finding. If there is documented IAO approval for either setting on development systems, this is not a finding. Approval documentation must include a complete list of all installed .Net applications, application versions, and acknowledgement that IAO trusts each installed application. If application versions installed on the system do not match approval documentation, this is a finding.

Fix: F-34746r7_fix

Change the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AllowStrongNameBypass" to a DWORD value of 0. Or, obtain documented IAO approval for each .Net application installed on the system. Approval documentation will include complete list of all installed .Net applications, application versions, and acknowledgement of IAO trust of each installed application.

a
.Net applications that invoke NetFx40_LegacySecurityPolicy must apply previous versions of .NET STIG guidance.
Low - V-30937 - SV-40979r1_rule
RMF Control
Severity
L
CCI
Version
APPNET0064
Vuln IDs
  • V-30937
Rule IDs
  • SV-40979r1_rule
CAS policy is .NET runtime version-specific. In .NET Framework version 4, CAS policy is disabled by default however; it can be re-enabled by using the NetFx40_LegacySecurityPolicy setting on a per application basis. When invoking the NetFx40_LegacySecurityPolicy setting in .NET 4, earlier versions of the .NET Framework CAS policy will become active therefore previous .NET STIG guidance that applies to the reactivated versions must also be applied. Failure to apply applicable versions of STIG guidance can result in the loss of system confidentiality, integrity or availability. System AdministratorDCSL-1
Checks: C-39675r5_chk

Open Windows explorer and search for all *.exe.config files. Search each file for NetFx40_LegacySecurityPolicy enabled="true". If the .NET application configuration file utilizes the legacy policy element and .NET STIG guidance that covers these legacy versions has not been applied, this is a finding.

Fix: F-34827r7_fix

Apply the .NET Framework Security Checklist for .Net versions 1 through 3.5 when utilizing the NetFx40_LegacySecurityPolicy setting.

b
Trust must be established prior to enabling the loading of remote code in .Net 4.
Medium - V-30968 - SV-41010r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0065
Vuln IDs
  • V-30968
Rule IDs
  • SV-41010r1_rule
In the .NET Framework version 3.5 and earlier versions, if an application assembly loaded code/objects from a remote location, that assembly would run partially trusted with a permissions grant set that depended on the zone in which it was loaded. For example, if an assembly was loaded from a web site, it was loaded into the Internet zone and granted the Internet permission set. In other words, it was executed in an Internet sandbox. If the same program is run in the .NET Framework version 4, an exception is thrown which effectively states; either explicitly create a sandbox for the assembly or run it in full trust. The element specifies the assemblies that run partially trusted in earlier versions of the .NET Framework will be run fully trusted in the .NET Framework 4. If loadFromRemoteSources is set to true, the remotely loaded application code is granted full trust. This could create an integrity vulnerability on the system. The required method to address this is to explicitly create a sandboxed environment for the remotely loaded code to run in rather than allowing remotely loaded code to run with full trust. The appropriate level of trust must be established prior to enabling the loading of remote code in .Net 4 applications and that code must be run in a controlled environment. The following is an example of the use of loadFromRemoteSources. Systems ProgrammerSystem AdministratorDCFA-1, DCSL-1
Checks: C-39628r5_chk

Open Windows explorer and search for *.exe.config. Search each config file found for the "loadFromRemoteSources" element. If the loadFromRemoteSources element is enabled ("loadFromRemoteSources enabled = true"), and the remotely loaded application is not run in a sandboxed environment, or if OS based software controls, such as AppLocker or Software Security Policies, are not utilized, this is a finding.

Fix: F-34779r3_fix

.Net application code loaded from a remote source must be run in a controlled environment. A controlled environment consists of a sandbox, such as running in an Internet Explorer host environment or employing OS based software access controls, such as AppLocker or Software Security Policies, when application design permits. Obtain documented IAO approvals for all remotely loaded code.

a
.NET default proxy settings must be reviewed and approved.
Low - V-30972 - SV-41014r1_rule
RMF Control
Severity
L
CCI
Version
APPNET0066
Vuln IDs
  • V-30972
Rule IDs
  • SV-41014r1_rule
The .Net framework can be configured to utilize a different proxy or altogether bypass the default proxy settings in the client's browser. This may lead to the framework using a proxy that is not approved for use. If the proxy is malicious, this could lead to a loss of application integrity and confidentiality.System AdministratorSystems ProgrammerDCFA-1, DCSL-1
Checks: C-39636r9_chk

Open Windows explorer and search for all "*.exe.config" and "machine.config" files. Search each file for the "defaultProxy" element. &lt;defaultProxy enabled="true|false" useDefaultCredentials="true|false" &lt;bypasslist&gt; … &lt;/bypasslist&gt; &lt;proxy&gt; … &lt;/proxy&gt; &lt;module&gt; … &lt;/module&gt; /&gt; If the "defaultProxy" setting "enabled=false" or if the "bypasslist", "module", or "proxy" child elements have configuration entries and there are no documented approvals from the IAO, this is a finding. If the "defaultProxy" element is empty then the framework is using default browser settings, this is not a finding.

Fix: F-34785r7_fix

Open Windows explorer and search for all "*.exe.config" and "machine.config" files. Search each file for the "defaultProxy" element. Clear the values contained in the "defaultProxy" element, and the "bypasslist", "module", and "proxy" child elements. The IAO must provide documented approvals of any non-default proxy servers.

b
Software utilizing .Net 4.0 must be identified and relevant access controls configured.
Medium - V-30986 - SV-41030r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0070
Vuln IDs
  • V-30986
Rule IDs
  • SV-41030r1_rule
With the advent of .Net 4.0, the .Net framework no longer directly configures or enforces security policy for .Net applications. This task is now relegated to the operating system layer and the security protections built-in to .Net application "runtime hosts" that run on the O.S. Examples of these .Net "runtime hosts" include; Internet Explorer, Windows Shell, ASP.NET, Database Engines or any other "runtime hosts" that utilize .Net and load the .Net CLR. Security protections include utilizing runtime host security controls such as sandboxing to restrict or control application behavior as designed or required. To compensate for these design changes, Windows provides native solutions such as Software Security Policies (SSP) and Application Locker (AL) which are technologies that can be implemented via Group Policy (GPO). SSP, AL and similar third party solutions serve to restrict execution of applications, scripts and libraries based upon cryptographic hash, security zones, path and certificate values that are associated with the application files. Additionally, application developers will utilize "sandboxing" techniques within their code in order to isolate 3rd party code libraries from critical system resources. In order to assign protections to .Net 4.0 applications, the applications must first be identified and the appropriate hosting security mechanisms configured to accomplish that task. .Net STIG guidance cannot be applied if .Net applications are not identified and documented. The lack of an application inventory introduces confidentiality, availability and integrity vulnerabilities to the system.System AdministratorDCSL-1, DCSP-1
Checks: C-39652r8_chk

Ask the system administrator to provide documentation that identifies: - Each .Net 4.0 application they run on the system. - The .Net runtime host that invokes the application. - The security measures employed to control application access to system resources or user access to application. If all .Net applications, runtime hosts and security protections have been documented or if there are no .Net 4.0 applications existing on the system, this is not a finding. If there is no documentation that identifies the existence of .NET 4.0 applications or the lack thereof, this is a finding. If the runtime hosts have not been identified, this is a finding. If the security protections have not been identified, this is a finding.

Fix: F-34808r5_fix

Document the existence of all .Net 4.0 applications. Document the corresponding runtime hosts that are used to invoke the applications. Document the applications security control requirements (restricting application access to resources or user access to the application).

b
Event tracing for Windows (ETW) for Common Language Runtime events must be enabled.
Medium - V-31026 - SV-41075r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0067
Vuln IDs
  • V-31026
Rule IDs
  • SV-41075r1_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.DCSL-1
Checks: C-39677r6_chk

Open Windows explorer and search for all .NET config files including application config files (*.exe.config) NOTE: Beginning with Windows Vista and Windows Server 2008, ETW Tracing is enabled by default and the "etwEnable" setting is not required in order for Event Tracing to be enabled. An etwEnable setting of "true" IS required in earlier versions of Windows as ETW is disabled by default. Examine the configuration settings for &lt;etwEnable enabled="false" /&gt;. If the "etwEnable" element is set to "true", this is not a finding. If the "etwEnable" element is set to "false" and documented approvals by the IAO are not provided, this is a finding.

Fix: F-34847r6_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
Windows must be configured to invalidate PKCS #7 version 1 signed objects
Medium - V-31212 - SV-41412r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0068
Vuln IDs
  • V-31212
Rule IDs
  • SV-41412r1_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not invalidate older PKCS #7 version 1 signed objects creating a risk which could affect the integrity of the system. System AdministratorDCSL-1
Checks: C-39949r12_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each users "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the user's "State" registry key. Each character in a hex string is referred to as a "nibble". For example, a hex value of f0000 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the user's registry key. Select "Bin". The hex value will automatically convert to a binary value. Start counting from 1 (not 0) and count the bit positions starting from the right and moving to the left. The total number of bit positions will vary from 18 to 20 depending upon the hex values input into the calculator. If bit position 17 is not a value of "1" on production systems, this is a finding. If bit 17 is not a value of "1" on a development system and the IAO has not provided documented approval, this is a finding.

Fix: F-35123r8_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal value for nibble position 5 to "1". For development systems, change the hexadecimal value for nibble position 5 to "1" or the IAO must provide documented approval. Example fix: Hex value: f0000 Nibble position: 54321 To apply fix, the example hex value "f" in nibble position 5 would be changed to "1" resulting in a hex value of 10000.

b
Software publishing state table must be configured to only trust items in the users trust database.
Medium - V-31307 - SV-41581r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0069
Vuln IDs
  • V-31307
Rule IDs
  • SV-41581r1_rule
Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will allow only downloads from publishers that are contained in users personal trust database creating an availability risk.System AdministratorDCSL-1
Checks: C-40081r11_chk

This check must be performed for each user on the system. In order to determine compliance, the hexadecimal values contained in each user's "State" registry key must be converted to binary values. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". Document the hexadecimal value of the user's "State" registry key. Each character in a hex string is referred to as a "nibble". For example, a hex value of c0000 has 5 binary "nibbles". For guidance purposes, the nibble positions are numbered 1 through 5 starting from the right and moving to the left. Open the Windows calculator. Select "View", then "Programmer". Select "Hex" and then "Dword". Enter the 5 nibble hex value obtained from the user's registry key. Select "Bin". The hex value will automatically convert to a binary value. Start counting from 1 (not 0) and count the bit positions starting from the right and moving to the left. The total number of bit positions will vary from 18 to 20 depending upon the hex values input into the calculator. If bit position 19 is not a value of "0" on production systems, this is a finding. If bit position 19 is not a value of "0" on development systems and the IAO has not provided documented approval, this is a finding.

Fix: F-35237r6_fix

Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key. For production systems, change the hexadecimal value for nibble position 5 to "1". For development systems, change the hexadecimal values for nibble position 5 to "1" or the IAO must provide documented approval. Example fix: Hex value: c0000 Nibble position: 54321 To apply fix, the example hex value "c" in nibble position 5 would be changed to hex value "1" resulting in a hex value of 10000.

b
Remoting Services TCP channels must utilize authentication and encryption.
Medium - V-32025 - SV-42341r1_rule
RMF Control
Severity
M
CCI
Version
APPNET0071
Vuln IDs
  • V-32025
Rule IDs
  • SV-42341r1_rule
.NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. Any unauthorized use of a remoting application provides unauthorized access with FullTrust permissions to the system. This can potentially result in a loss of system integrity or confidentiality.System Administrator
Checks: C-40657r4_chk

Check the machine.config and the [application executable name].exe.config configuration files for the typefilterlevel="Full" configuration parameter. The machine.config file is contained in the folder %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 or %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Microsoft specifies locating the application config file in the same folder as the application executable (.exe) file. However, the developer does have the capability to specify a different location when the application is compiled. Therefore, if the config file is not found in the application home folder, a search of the system is required. If the [application name].exe.config file is not found on the system, then only a check of the machine.config file is required. Sample machine/application config file: &lt;application name=“remoteserver”&gt; &lt;service&gt; &lt;activated type=“sample.my.object, myobjects”/&gt; &lt;/service&gt; &lt;channels&gt; &lt;channel ref=“tcp server” port=“6134”/&gt; &lt;/channels&gt; &lt;/application&gt; &lt;serverProviders&gt; &lt;provider ref="wsdl" /&gt; &lt;formatter ref="soap" typeFilterLevel="Full" /&gt; &lt;formatter ref="binary" typeFilterLevel="Full" /&gt; &lt;/serverProviders&gt; Microsoft provides 3 "channels" that are used for remoting connectivity. They are the HTTP, TCP, and IPC channels. The channel that is used is specified via the &lt;channels&gt; element in the config file. TCP channel example: &lt;channel ref=“tcp” port=“6134” secure="true"/&gt; The TCP Channel supports encryption and message integrity when the 'secure' flag is set to true as shown in the above example. If encryption and message integrity are not used for the TCP remoting channel when the ServerProvider element typefilterlevel=”Full”, this is a finding.

Fix: F-35975r1_fix

Ensure encryption and message integrity are used for TCP remoting channels when the "typefilterlevel" element is set to "Full". TCP remoting connections are protected via the secure=true configuration parameter. <channels> <channel ref="tcp" secure="true" /> </channels> Include the secure="true" flag in the channel ref parameter of the machine.config and [application name].exe.config file if the [application name].exe.config file exists on the system.