A08—Software or Data Integrity Failures

>Control Description

Software or Data Integrity Failures continues at #8, with a slight, clarifying name change from "Software *and* Data Integrity Failures". This category is focused on the failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts at a lower level than Software Supply Chain Failures. This category focuses on making assumptions related to software updates and critical data, without verifying integrity. Notable Common Weakness Enumerations (CWEs) include *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes*, and *CWE-502: Deserialization of Untrusted Data*. Software and data integrity failures relate to code and infrastructure that does not protect against invalid or untrusted code or data being treated as trusted and valid. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline without consuming and providing software integrity checks can introduce the potential for unauthorized access, insecure or malicious code, or system compromise. Another example of this is a CI/CD that pulls code or artifacts from untrusted places and/or doesn’t verify them before use (by checking the signature or similar mechanism). Lastly, many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization.

>Prevention & Mitigation Strategies

1.Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.
2.Ensure libraries and dependencies, such as npm or Maven, are only consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted.
3.Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline.
4.Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.
5.Ensure that unsigned or unencrypted serialized data is not received from untrusted clients and subsequently used without some form of integrity check or digital signature to detect tampering or replay of the serialized data.

>Attack Scenarios

#1Untrusted web functionality via external provider

A company uses an external service provider to provide support functionality. For convenience, it has a DNS mapping for myCompany.SupportProvider.com to support.myCompany.com. Anyone with access to the support provider's infrastructure can steal the cookies of all users that have visited support.myCompany.com and perform a session hijacking attack.

#2Unsigned firmware updates

Many home routers, set-top boxes, device firmware, and others do not verify updates via signed firmware. Unsigned firmware is a growing target for attackers and is expected to only get worse. This is a major concern as there is often no mechanism to remediate other than to fix in a future version and wait for previous versions to age out.

#3Compromised package from untrusted source

A developer, unable to find a needed package through official channels, downloads it from a website online. The package is not signed, and thus there is no opportunity to ensure integrity. The package includes malicious code, creating a supply chain compromise that can affect the entire application.

#4Insecure deserialization via Java objects

A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing the user state and passing it back and forth with each request. An attacker notices the 'rO0' Java object signature (in base64) and uses the Java Serial Killer tool to gain remote code execution on the application server.

>Related CWEs

>References

Ask AI

Configure your API key to use AI features.