Skip to main content

Security Breach Spotlight: OWASP Top 8 Software and Data Integrity Failures

· 5 min read

For this week's educational blog we're diving into Software and Data Integrity Failures, OWASP's #8 and into the Event-Stream NPM Attack in 2018. This one is particularly close to us here at Protean since we were founded with the goal to protect our customers from these types of attacks!

sdi

OWASP #8 - Software and Data Integrity Failures​

Software and Data Integrity Failures occur when applications rely on untrusted sources for software updates, libraries, or plugins, leading to security vulnerabilities. This includes supply chain attacks, insecure deserialization, and inadequate integrity checks.

Common Causes:​

  1. Untrusted Updates & Dependencies - Using third-party components from unverified sources and not validating the integrity of dependencies.

  2. Insecure Deserialization - Deserializing untrusted data without a proper validation or security protocols can be utilized by attackers to execute arbitrary code or modify the application.

  3. Supply Chain Attacks - Attackers compromise a third-party vendor, injecting malicious code into software used by an application.

  4. Code Injection via CI/CD Pipelines - Poorly secured Continuous Integration/Continuous Deployment (CI/CD) pipelines allow attackers to insert malicious code into production environments.

  5. Lack of Code Signing and Integrity Checks - No digital signatures or hash validation for updates and plugins. Attackers can use this vulnerability to replace real software with tampered versions.

How to mitigate Software and Data Integrity Failures:​

  1. Use Trusted Sources for Dependencies - Download only from official and verified sources and use dependency management tools.

  2. Enable Digital Signatures & Hash Verification - Verify software integrity using cryptographic signatures and checksums while also ensuring that update mechanisms reject unsigned or tampered files.

  3. Secure the Software Supply Chain - Implement SBOM (Software Bill of Materials) to track all dependencies and regularly scan dependencies for vulnerabilities using tools like our own Software Composition Analysis.

  4. Harden CI/CD Pipelines - Use security controls like code signing, access controls, and multi-factor authentication (MFA) in CI/CD systems.

  5. Avoid Insecure Deserialization - Use formats like JSON instead of binary serialization when possible and implement strict input validation and whitelisting to prevent code execution.

Example of what an attack scenario can look like​

Step 1: Identifying a Target Package​

The attacker finds an open-source library that is widely used but poorly maintained. The package has thousands of downloads per week, but the maintainer is inactive and hasn’t updated it in years.

Step 2: Gaining Control of the Package​

The attacker contacts the maintainer and offers to help maintain the package. The maintainer, happy to offload the work, transfers ownership to the attacker. The attacker now has full control over future updates.

Step 3: Injecting Malicious Code​

The attacker publishes an updated version of the package with malicious code that allows him to steal the admin's SSH private key and sends it back to the attacker's private server.

Step 4: Waiting for Users to Update​

Anyone using the updated version of the package is now infected, and all the active users are feeding private data to the attacker. Since the package is updated legitimately no antivirus can detect it.

Step 5: Exploiting Stolen Credentials​

Once the attacker collects enough SSH keys, they can now perform the following actions:

  • Access cloud servers (e.g., AWS, DigitalOcean, GitHub) and steal source code or deploy ransomware.

  • Modify other open-source projects and inject more malware (creating a chain reaction).

  • Sell access to other hackers on the dark web.

Step 6: Detection and Cleanup​

Weeks or months later, a security researcher notices strange network traffic and traces it back to the package. Developers audit their dependencies and find the malicious code. The package is removed, but by then, thousands of applications have already been compromised.

Event-Stream npm package attack (2018)​

The Event-Stream npm package attack (2018) was a major supply chain attack that exploited the trust in open-source software distribution. The attack began when the original maintainer of the Event-Stream package, Dominic Tarr, handed over control of the project to an unknown developer named right9ctrl due to lack of time and interest. Event-Stream was a widely used Node.js package, downloaded millions of times per week, but since it was no longer actively maintained, the new owner was able to introduce a malicious change without raising suspicion.

Once in control, right9ctrl published a new version of Event-Stream that included a dependency on a newly created package called flatmap-stream. This hidden dependency contained obfuscated malicious code designed to target users of the Copay Bitcoin wallet (a popular cryptocurrency wallet). The malware specifically looked for private keys and other sensitive information related to Copay, exfiltrating them to an external server controlled by the attacker. Because the backdoor was deeply embedded within a dependency of a dependency, it went unnoticed for several weeks.

The attack was eventually discovered by a security researcher who noticed suspicious behavior in flatmap-stream. By the time it was removed from npm, thousands of applications had already downloaded the compromised package, highlighting the dangers of blindly trusting open-source libraries. This incident underscored the importance of vetting new maintainers, monitoring dependencies, and using automated security tools to detect malicious code in software supply chains.