Windows security features test

  • Article

Tests the app to verify it uses the Windows security features and strong ACLs.

Background

Changing the default Windows security protections can put customers at increased risk.

Test details

Tests the app's security by running the BinScope Binary Analyzer and the Attack Surface Analyzer.

Corrective actions

Troubleshoot and fix the problem identified by the tests. Rebuild and re-test the app.

BinScope Binary Analyzer tests

The BinScope Binary Analyzer tests examine the app's binary files to check for coding and building practices that make the app less vulnerable to attack or to being used as an attack vector.

The BinScope Binary Analyzer tests check for the correct use of these security-related features:

  • AllowPartiallyTrustedCallersAttribute
  • /SafeSEH Exception Handling Protection
  • Data Execution Prevention
  • Address Space Layout Randomization
  • Read/Write Shared PE Section
  • AppContainerCheck
  • ExecutableImportsCheck
  • WXCheck

AllowPartiallyTrustedCallersAttribute

Windows App Certification Kit error message: APTCACheck Test failed

The AllowPartiallyTrustedCallersAttribute (APTCA) attribute enables access to fully trusted code from partially trusted code in signed assemblies. When you apply the APTCA attribute to an assembly, partially trusted callers can access that assembly for the life of the assembly, which can compromise security.

What to do if your app fails this test

Don't use the APTCA attribute on strong named assemblies unless your project requires it and the risks are well understood. In cases where it's required, make sure that all APIs are protected with appropriate code access security demands. APTCA has no effect when the assembly is a part of a Windows Store app.

Remarks

This test is performed only on managed code (C#, .NET, etc.).

/SafeSEH Exception Handling Protection

Windows App Certification Kit error message: SafeSEHCheck Test failed

An exception handler runs when the app encounters an exceptional condition, such as a divide-by-zero error. Because the address of the exception handler is stored on the stack when a function is called, it could be vulnerable to a buffer overflow attacker if some malicious software were to overwrite the stack.

What to do if your app fails this test

Enable the /SAFESEH option in the linker command when you build your app. This option is on by default in the Release configurations of Visual Studio. Verify this option is enabled in the build instructions for all executable modules in your app.

Remarks

The test is not performed on 64-bit binaries or ARM chipset binaries because they don't store exception handler addresses on the stack.

Data Execution Prevention

Windows App Certification Kit error message: NXCheck Test failed

This test verifies that an app doesn't run code that is stored in a data segment.

What to do if your app fails this test

Enable the /NXCOMPAT option in the linker command when you build your app. This option is on by default in linker versions that support Data Execution Prevention (DEP).

Remarks

We recommend that you test your apps on a DEP-capable CPU and fix any failures you find that result from DEP.

Address Space Layout Randomization

Windows App Certification Kit error message: DBCheck Test failed

Address Space Layout Randomization (ASLR) loads executable images into unpredictable locations in memory, which makes it harder for malicious software that expects a program to be loaded at a certain virtual address to operate predictably. Your app and all components that your app uses must support ASLR.

What to do if your app fails this test

Enable the /DYNAMICBASE option in the linker command when you build your app. Verify that all modules that your app uses also use this linker option.

Remarks

Normally, ASLR doesn't affect performance. But in some scenarios there is a slight performance improvement on 32-bit systems. It is possible that performance could degrade in a highly congested system that have many images loaded in many different memory locations.

This test is performed on only apps written in managed code, such as by using C# or .NET Framework.

Read/Write Shared PE Section

Windows App Certification Kit error message: SharedSectionsCheck Test failed.

Binary files with writable sections that are marked as shared are a security threat. Don't build apps with shared writable sections unless necessary. Use CreateFileMapping or MapViewOfFile to create a properly secured shared memory object.

What to do if your app fails this test

Remove any shared sections from the app and create shared memory objects by calling CreateFileMapping or MapViewOfFile with the proper security attributes and then rebuild your app.

Remarks

This test is performed only on apps written in unmanaged languages, such as by using C or C++.

AppContainerCheck

Windows App Certification Kit error message: AppContainerCheck Test failed.

The AppContainerCheck verifies that the appcontainer bit in the portable executable (PE) header of an executable binary is set. Windows Store apps must have the appcontainer bit set on all .exe files and all unmanaged DLLs to execute properly.

What to do if your app fails this test

If a native executable file fails the test, make sure that you used the latest compiler and linker to build the file and that you use the /appcontainer flag on the linker.

If a managed executable fails the test, make sure that you used the latest compiler and linker, such as Microsoft Visual Studio, to build the Windows Store app.

Remarks

This test is performed on all .exe files and on unmanaged DLLs.

ExecutableImportsCheck

Windows App Certification Kit error message: ExecutableImportsCheck Test failed.

A portable executable (PE) image fails this test if its import table has been placed in an executable code section. This can occur if you enabled .rdata merging for the PE image by setting the /merge flag of the Visual C++ linker as /merge:.rdata=.text.

What to do if your app fails this test

Don't merge the import table into an executable code section. Make sure that the /merge flag of the Visual C++ linker is not set to merge the “.rdata” section into a code section.

Remarks

This test is performed on all binary code except purely managed assemblies.

WXCheck

Windows App Certification Kit error message: WXCheck Test failed.

The check helps to ensure that a binary does not have any pages that are mapped as writable and executable. This can occur if the binary has a writable and executable section or if the binary’s SectionAlignment is less than PAGE_SIZE.

What to do if your app fails this test

Make sure that the binary does not have a writeable or executable section and that the binary's SectionAlignment value is at least equal to its PAGE_SIZE.

Remarks

This test is performed on all .exe files and on native, unmanaged DLLs.

An executable may have a writable and executable section if it has been built with Edit and Continue enabled (/ZI). Disabling Edit and Continue will cause the invalid section to not be present.

PAGE_SIZE is the default SectionAlignment for executables.

Banned Files in the Windows Store

Windows App Certification Kit error message: Banned File Check test failed.

Windows Store apps should not contain certain files. These files have a newer version available that provides important security, reliability or other improvements. Microsoft blocks these files in the Windows App Certification Kit to ensure that all developers use a current version.

The Banned File Check in the Windows App Certification Kit currently checks for the following files:

Attack Surface Analyzer

The Attack Surface Analyzer tests examine changes in system state, runtime parameters, and securable objects that occur after installing and running an app to look for specific security weaknesses. Correcting these weaknesses doesn't impose any performance penalty. We can't certify your app for the Windows Store if it has any of these security weaknesses.

The Attack Surface Analyzer tests apply to all programming languages and look for these security weaknesses in an app.

  • Secure executable files that have weak ACLs
  • Secure directories that contain objects and have weak ACLs
  • Secure registry keys with weak ACLs
  • Services that allow access to non-administrator accounts and are vulnerable to tampering
  • Services that have fast restarts or might restart more than twice every 24 hours

Secure executable files that have weak ACLs

This test looks for secure executable files that have weak access control lists (ACLs) by checking the ACLs on each new or changed executable file that an Administrator owns. The ACLs on these files must prevent non-administrators from modifying them. Attack Surface Analyzer tests executable (.exe) files and also files that can contain executable content, such as scripts and help files.

What to do if your app fails this test

If this weakness is detected in your app, check for and remove these rights for any non-administrator account: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, or FILE_WRITE_DATA, DELETE

Remarks

Weak ACLs allow non-administrators to alter an executable file. If an executable file has been altered, it might not work as expected. If the access rights are not correctly configured, an attacker could replace or alter the file's contents and cause it to behave maliciously.

Secure directories that contain objects and have weak ACLs

This test looks for secure directories that contain objects and have weak ACLs by checking the ACLs on new or changed folder hierarchies. Hierarchical ACLs (or inherited ACLs) control access to all files and folders within a folder. The ACLs on these folders must prevent non-administrators from modifying these folders or their contents.

Rather than flagging each executable file and subfolder that is not properly secured, this test identifies the highest folder in a hierarchy that has the weak ACLs.

What to do if your app fails this test

If this weakness is detected in your app, check for and remove these rights for all non-administrator accounts on the directory identified by the test so they cannot be inherited: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, FILE_ADD_FILE, FILE_ADD_SUBDIRECTORY, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, FILE_WRITE_DATA, FILE_DELETE_CHILD, and DELETE. This may involve changing the Inherited flag on the root directory's ACL.

After correcting the rights on the root directory, you might also need to correct the rights of individual executable files as described in Secure executable files that have weak ACLs.

Remarks

This test identifies a hierarchy of directories and their files that all have weak ACLs, which grant inappropriate rights to non-administrators. This hierarchy could be caused by incorrect inherited rights so look at the inherited rights first before changing the rights in the descendent directories and files.

Secure registry keys with weak ACLs

This test looks for secure registry keys that have weak access control lists (ACLs) by checking the ACLs of new or changed keys in the Local Machine registry hive (HKLM). Only Administrators should have write access to the Local Machine registry hive.

What to do if your app fails this test

Remove these rights on the object identified by the test for all non-administrator accounts: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, KEY_SET_VALUE, KEY_CREATE_SUBKEY, and DELETE.

Remarks

Registry values in this section can determine where to find executable files such as .exe and .dll. Apps also use registry keys in the Local Machine registry hive to store or read the path of an executable file. If an attacker alters this key, such as by changing the value to the path of an untrusted executable, an app could execute the wrong file.

If a registry key appears to reference an executable file, this test will examine the key's ACLs to see if it grants inappropriate rights to a non-administrator account.

Services that allow access to non-administrator accounts and are vulnerable to tampering

This test looks for new or changed services that allow access to non-administrator accounts by checking the ACLs on these services. New services must not have weak ACLs on the binary path, the host DLL, the registry keys, or the service itself because they could allow a non-administrator to change how the service runs.

What to do if your app fails this test

Fix the individual files as described in Secure executable files that have weak ACLs.

Remarks

Services have both generic and service-specific rights associated with them. This test looks for inappropriate rights granted to non-administrator accounts. If the rights are not secured, an attacker could redirect the service to execute an untrusted file when it starts.

For example, an attacker could call ChangeServiceConfig to change the path of the service's executable file.

Services that have fast restarts or might restart more than twice every 24 hours

This test looks for services that might restart frequently by checking the service's configuration. Service's must not restart more than twice in a 24-hour period.

What to do if your app fails this test

Change the service's Reset Period to prevent it from restarting more than twice in a 24 hour period.

Remarks

This test looks for a vulnerability related to Address Space Layout Randomization (ASLR). ASLR is a feature that loads executable code into random places in memory, making it more difficult to create reliable exploits of security vulnerabilities. If an attacker can make a service restart repeatedly, they could use brute force to load executable code into all possible locations and defeat ASLR.

This test examines the lpsaActions elements of the Service Failure Actions structure for SC_ACTION_REBOOT and SC_ACTION_RESTART values. These values can be configured by calling ChangeServiceConfig2.

The test determines if there are more than two actions, whether their delay values are less than 24 hours, and whether the server reset period is less than 24 hours.