The growing number of software supply chain attacks is putting pressure on validation of software integrity and authenticity.
One of the main tools in the security arsenal for assuring integrity and authenticity of software products are digital signatures. Digital signing of executable files is nothing new, yet often gets omitted or poorly implemented. The ideal scenario would have all components of a software package digitally signed, but that is hardly ever the case. Nevertheless, packages that have digital signatures must be properly validated. There are plenty of tools for validating a certificate, and that can even be done manually for a small number of executables.
Typical software packages consist of hundreds of components. It’s challenging to manually verify such large amounts of components, so an automated process needs to be used.. This process gets even more complicated when software packages contain several layers of packing in different file formats. The secure.software platform supports extraction with unpacking for hundreds of different file formats, and can detect dozens of problems related to digital code signing. Some of the most important problems include invalid or malformed signatures and the use of revoked or self-signed certificates. The best part: the list of problems that need to be addressed can be configured based on organizational needs.
[ Get key takeaways from a survey of 300+ security professionals on software security. Plus: Download the report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks ]
A real-world example
These capabilities of our platform could perhaps be best described in a real-world case where we detected a malformed signature in one of Microsoft-published software packages: Exchange Server 2016. A report was generated using secure.software platform, and it showed that this software package contained more than 10,000 digitally signed components.
Among other issues related to digital signatures detected in the analyzed software package, the report also contained a warning about an executable whose digital signature failed the integrity validation check. This effectively meant that the executable was tampered with after signing. The report showed that the affected component was a PerfView executable also published by Microsoft.
.jpg?width=1400&name=1%20(3).jpg)
Figure 1: Digital signature issues detected in the Exchange Diagnostics package
The official download for this version of the PerfView executable (1.9.0) had a valid digital signature, so the issue was related to the Exchange Server software package.
The secure.software platform can compare two versions, subsequent or not, of the same software and detect changes introduced between them. This feature can be used to track the effect of the improvements to the software package and its components. Those changes cover all aforementioned software quality issues, including all the behavior changes that affect the packaged software components. Our platform can recognize 10,000s of different behaviors, giving a highly detailed, fine-grained insight into the capabilities of the analyzed software. This is incredibly useful for spotting unexpected behavior changes that can be a hint for detecting potentially malicious behaviors introduced by an attacker, or a compromised software dependency. This way, any malicious software components can be quickly pinpointed and sanitized.
.jpg?width=1400&name=2%20(3).jpg)
Figure 2: Behavior differences between compared versions of the PerfView executable
In the case of the PerfView executable, behavioral differences showed that the broken signature is the only significant behavior change. This means the modification of this executable was likely not malicious, but instead was caused by a mistake in the signing process. Detailed inspection was performed to find the root cause of the broken signature. Doing a simple binary diff of the two PerfView executable versions shows that the only difference is one bit of the CLI header related to .NET assembly flags.
.jpg?width=1400&name=3%20(3).jpg)
Figure 3: Hex comparison of two PerfView executables
These flags are used to specify the architecture that the assembly was built for. The reason why someone would want to change these flags could be compatibility issues, as described in Microsoft’s documentation. It looks like Microsoft’s CorFlags Conversion Tool was used to modify the target architecture of the executable so it could run on any CPU instead of being able to run exclusively on x86 architecture.
.jpg?width=1400&name=4%20(3).jpg)
Figure 4: Modifying PerfView executable using CorFlags to change target architecture
Only a few parts of a PE executable file can be modified without breaking its digital signature. This includes the content checksum, the physical location, and the size of the appended certificate. More information about tampering with digital signatures can be found in other ReversingLabs blogs.
Post-signing modifications of binary executable contents made with tools like CorFlags will break their digital signature, and make the signing effort useless. Even worse, to an end user, these files look like a supply chain attack. Very few users would be equipped to triage the integrity validation warnings, and discern if they are a simple developer mistake or if they are caused by a threat actor doing malicious code tampering.
Therefore, if content-modifying tools like CorFlags are part of a deployment process, they should always be used before code signing tools. Contents of the signed executable shouldn’t be modified, so that its integrity remains intact.
This issue was disclosed to Microsoft, and they released an update to fix this problem. Anyone could have detected these changes by comparing isolated PerfView files, but Microsoft's Exchange Server is a large software package. Finding such problems manually in a package with more than 10,000 components is nearly an impossible task. This is where the secure.software platform comes to aid. Even though in this case the modification of the software package wasn’t malicious, there is a great chance that real malicious tampering could slip by unnoticed.
Go below the surface
ReversingLabs secure.software platform gives a detailed insight into complex software packages. It describes the state of important software quality aspects found in a software product, enabling efficient management of related security risks for organizations of any size. Tampering with digitally signed content can be an early indication that malicious actors have made their way into the codebase. Checking software integrity at all levels can uncover threats hidden beneath the surface, and that has never been more important than now — in the age of software supply chain attacks.
