A new category for 2021 focuses on making assumptions associated with software updates, critical data, and CI/CD pipelines without verifying integrity. The information from the Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) has one of the highest weighted impacts.

Software and data integrity failures relate to code and infrastructure that don’t protect against integrity violations. An example of this can be where an application depends upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline will introduce the potential for unauthorized access, malicious code, or system compromise. Lastly, several applications currently embrace auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers may upload their 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 will see and modify is vulnerable to insecure deserialization.

Altogether, software and data integrity failures result in a program executing the attacker’s code or prying open a backdoor via combined measures.

Common causes

There are ten CWE under this category. First, we’ll categorize them into three buckets.After that, we’ll look at the threat vectors for each.

Faulty assumptions

CWE-565

and

CWE-784

represent lazy management checks that assert the presence of a particular cookie or cookie value. Despite the presence of a signature for validation, it is not checked. The fact that JWTs carry unencrypted payloads is inconvenient. The assumption is that simply being present is enough to establish trust.

The bulk ofCWE-426: untrusted search path vulnerabilities emerge from the idea that the host’s environment is secure. The OS PATH value is the main offender, but the vulnerability can also be exploited through a variety of traditional path traversal and redirection exploits.

Misguided mechanisms

CWE-915,CWE-829

, and

CWE-830

Existing controls fail to respond to system dynamism, and emerge as a result. It’s cool to have imported functionality. Values obtained across multiple boundaries and abstraction layers are used to initialise or design objects.

Those flaws appear to be primarily honest blunders. When several of an object’s elements or settings are externally sourced, it’s difficult to anticipate, model, and test for thousands of possible states.

Absence of a mechanism

CWE-494 is the worst sort of input validation failure. The code is fetched in its entirety or as a patch.Then, it’s executed without any integrity checks. The attacker will inject malware into the code at the source, in transit, and even at the endpoint cache.

CWE-502is the classic deserialization of untrusted information. Parsers are fickle because they are complex and advanced. Even if they come with a promise to be secure by default or are designed with security in mind, that promise should be entirely disregarded. Continually validate input before desterilizing.

CWE-345andCWE-353 both represent a similar downside that manifests at two completely different levels. The first is at the protocol level. A checksum may even be present. However, it’s not checked. The second is at the application level, and there’s no support for an integrity check for incoming information.

We could blame those vulnerabilities on unreasonable development deadlines that typically force developers to chop corners. However, the absence of a protection mechanism here may be due to disregard for the need for rigor in threat modeling. Common threat modeling systems led us to scrutinize and protect downloaded updates and validate all information before parsing.

Ways to Fix Software and Data Integrity Failures

You can take the following measures to avoid this issue:

• Always check to see if the app you’re using is safe and secure.
• As a developer, make sure your apps are signed and your trusted data sources are secure.
• Ensure that your CI/CD pipelines are secure and any malicious code doesn’t go in
• Audit the code before it makes it to the production
• Get your software pen frequently tested to ensure high-security levels

Example Attack Scenarios

Update without signing

Many home routers, set-top boxes, device codes, and others don’t verify updates via signed code. Unsigned code may be a growing target for attackers and is expected to only worsen. This is a serious concern as, repeatedly, there’s no mechanism to remediate it other than to fix it in a future version and look forward to previous versions to age out.

Insecure Deserialization

A React application calls a collection of Spring Boot microservices. Being useful programmers, they tried to make sure that their code was immutable. The solution they came up with is serializing the user state and spending it back and forth with every request. The “rO0” Java object signature (in base64) is detected by an attacker, who then uses the Java Serial Killer tool to gain remote code execution on the application server.

How to Prevent 

• Use digital signatures or other similar mechanisms to ensure that the computer code or data is authentic and has not been tampered with.
• Ensure libraries and dependencies, like npm or Maven, consume trusted repositories. If you have a better risk profile, consider hosting an internal known-good repository that is vetted.
• Ensure that a computer code providing chain security tools, like OWASP Dependency-Check or OWASP CycloneDX, is employed to verify that elements don’t contain known vulnerabilities
• Ensure that there’s a review method for code and configuration changes to reduce the chance of introducing malicious code or configuration into your software pipeline.
• Ensure that your CI/CD pipeline has correct segregation, configuration, and access control to confirm the integrity of the code flowing through the build and deploy processes.
• Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some variety of integrity checks or digital signatures to detect meddling or replay of the serialized data