Compiled App Testing

We test the functionality of traditional compiled applications, including their local functions, dependencies, and interactions with other systems. With applications that make use of multiple processes, the inter-process communication methods are analysed to check against opportunities to manipulate behaviour. 

What should be included in the compiled application test?

The functionality of traditional compiled applications, including their local functions, dependencies, and interactions with other systems. With applications that make use of multiple processes, the inter-process communication methods should be analysed for opportunities to manipulate behaviour. 

Areas of Testing

• Access Controls
• Cryptographic Failures and Data exposure
• Design Flaws in application functionality
• Software and Data Integrity (e.g third-party dependencies and software supply chain)

What are the different testing approaches we offer?

Blackbox Testing

The consultant will be given access to the application in the same form as a legitimate user; this may include user manuals, training material, and other  documentation, however, it will not include the application source code. The consultant will then attempt to identify and exploit any security weaknesses in the application via reverse engineering techniques. 

Whitebox Testing

The consultant will be given access to the application, alongside the  application’s source code. The consultant will then conduct testing using the source code as a reference to allow faster identification of issues and identification of more complex security issues. 

Upon identification of potential security issues, the consultant will attempt to develop  a proof-of-concept exploit for the application. These will allow the consultant to prove the existence of the vulnerability and demonstrate the impact it may have. 

Common Vulnerabilities 

• DLL Hijacking 
• Privilege Escalation
• Hardcoded encryption material 
• Insecure Inter-Process Communication (IPC)
• Credentials stored in configuration files

Reporting

A report is written detailing the processes carried out and the issues found. Generally, this will contain a prioritised list of vulnerabilities discovered grouped by functional area. Remediation advice will be provided, both in terms of an immediate fix and any defence-in-depth measures that could be taken to mitigate risk. Attack-chains, alongside their impact, will be documented. Any higher-level findings that can be abstracted from the testing will be provided. Any architectural or design weaknesses will be highlighted so that these can be avoided in the future. Finally, an executive summary is produced to allow the most severe issues to be communicated quickly to stakeholders.

CHECK Testing

In some  cases, testing may need to be conducted under the NCSC CHECK scheme. When this occurs, certain requirements must be met. 

Testing led by a CHECK Team Leader – Applications (CTL APP) 

On large or complicated tests, the CTL may be supported by one or more CHECK Team Members

It is important to consider whether testing will need to be conducted under the CHECK scheme at the scoping phase.

Considerations for SECRET Networks

Where testing will be conducted on a network rated for SECRET information, additional requirements must be met:

Two CTL INFs are needed at all times.

Additional expenses must be accounted for, as no storage material may leave the facility upon testing being completed.

All testing and reporting must be conducted on-site.

Example attacks from previous engagements

To illustrate the type of real-world attack, these are some possible attacks based on previous tests carried out across a range of networks.

The consultant identified that the application would attempt to load multiple DLLs that did not exist. The process was executed under the context of a privileged user, with the search order for these DLLs including a folder controlled by the user. Therefore, by creating a malicious version of a missing DLL and placing it within the user-controlled folder,  the consultant was able to gain code execution as the privileged user, allowing local privilege escalation on the system.

Within the same application, it was found there were hard-coded encryption keys used to decode settings from a configuration file. By using this key, the consultant was able to decrypt the configuration file and identified administrator level credentials for remote systems stored within them. This would have allowed the consultant to gain access to remote systems via a user-level terminal.

Finally, the application made use of multiple processes linked via IPC. Weaknesses were identified in this IPC process that allowed the consultant to inject commands, bypassing an authentication requirement that would normally be required by the application. This allowed the consultant to conduct privileged operations via the application without knowledge of the pre-requisite password.