npm event-stream supply-chain vulnerability(2018)

npm event-stream supply-chain vulnerability (2018).md

@@ -0,0 +1,114 @@
+The URL to Github issue is : https://github.com/mitre/secure-coding-case-studies/issues/9
+
+The URL to GIthub Pull request is : https://github.com/shreyashitole02/secure-coding-case-studies/pull/2
+
+
+Essay (case study):-
+
+Title: npm event-stream supply-chain vulnerability(2018)
+License: This work is released under CC 4.0 license.
+
+Introduction:
+In this incident in 2018, the original maintainer of a popular Node.js library handed control over to a new developer, who later added a malicious dependency called flatmap-stream. That code was designed to steal cryptocurrency wallet keys from specific apps using the package. It became one of the most well-known examples of how easily trust in open-source projects can be abused.
+
+This case study will provide an overview of what led to the compromise of event-stream, the way in which the attack occurred, and what measures could have stopped this attack.
+
+
+ Software:
+The software that was compromised was the npm package event-stream.
+Name: event-stream (Node.js library)  
+Language: JavaScript  
+URL: https://github.com/dominictarr/event-stream
+
+
+ Weakness:
+1.CWE-1392: Use of Insufficiently Verified Packages in Software Package Management Systems.
+When a package manager does not verify the identity of the publisher and the contents of their packages, the software becomes vulnerable. An attacker can leverage this vulnerability by injecting malicious code into a unchecked package, which can then reach to downstream applications that use the package manager.
+2. CWE-494: Download of Code Without Integrity Check.
+Due to lack of integrity checks, the malicious code was injected in the flatmap-stream package and its contents. The npm ecosystem at the time did not enforce such checks, allowing the modified code to run without verification.
+
+
+ Vulnerability:
+The vulnerability was caused when:
+1. the new maintainer added the flatmap-stream package to event-stream which is a node module, as a dependency
+2. the new maintainer had injected malicious code inside the flatmap-stream
+3. it had also released a new version of event-stream, whcih updated the dependency to flatmap-stream.
+
+Hence, if any applications that had installed event-stream through npm had automatically installed flatmap-stream and execute this malicious code during build time, which could be configured and therefore limited by a variety of means, reducing its detectability.
+
+Reasons why vulnerability happened:
+1. Developers were not required to verify identity, signatures or ownership.
+2. There were no automated methods to prevent or block suspicious dependencies from being added.
+3. Development teams blindly trust implicit transitive dependencies.
+
+
+ Exploit:
+CAPEC-683: Supply Chain Risks
+This attack fits CAPEC‑683 because the attacker targeted the software supply chain instead of attacking the application directly. By gaining control of the flatmap‑stream package, the attacker was able to insert malicious code into the event‑stream. Since many people automatically install and update dependencies, the harmful code spread to users without them noticing. This allowed the attacker to deliver a hidden payload which showcased it as a legitimate software update for all.
+
+
+ Fix:
+When the vulnerability was caught,
+- The npm security team removed the malicious version of flatmap-stream.
+- event-stream maintainers published safe versions without the malicious dependency.
+- Copay rotated compromised credentials and replaced affected builds.
+
+However, these reactive fixes were not able to address the systemic concerns that enabled the attack in the first place. Preventing this class of vulnerability requires infrastructure-level and policy-level changes.
+
+Prevention:
+These vulnerabilities can be prevented by following ways:
+
+1. Pin Dependency Versions and Treat Updates as Security-Relevant Changes
+
+Organizations can create a separate lockfile for each version of every direct and transitive dependency. Rather than performing bulk updates to dependencies, automated tools such as Dependabot or Renovate will generate an individual pull request for each dependency that has been updated. This enables teams to quickly review what changed, review the changelogs, and uncover warning signs (for example, a package with a new maintainer, an update after many months of inactivity, or the introduction of a new dependency). After the event-stream incident, all of these warning signs were present, but nobody within the ecosystem raised them as a concern until the developers became aware that the dependency was malware.
+
+2. Automated Behavioral Analysis and Detection of Suspicious Patterns
+
+In order to provide protection against malicious libraries, registries and build environments need to implement automated behavioral analysis which can detect activities that should not be performed by legitimate libraries.
+
+Examples:
+
+- Unknown network communications: flatmap-stream called out to an externally hosted command-and-control server.
+- Obfuscated JavaScript: the malicious payload was hidden behind multiple layers of encoded code.
+- Access to Cryptocurrency Wallet Data: performed behavior that had no relation to the purpose of the event-stream package.
+- New environment at runtime of library: a harmless library should not suddenly gain filesystem or network privileges.
+
+Any of the tools capable of detecting these behavioral anomalies would be able to flag the malicious event-stream package as malicious.
+
+3. Package Vetting and Trust Indicators:
+Developers require improved visibility into the integrity of the packages they use. Different tools like the OpenSSF Scorecards and Socket.dev allow users to determine if a given package contains certain security indicators associated with it such as: how frequently has it been updated? Are the official releases signed? Are there any suspicious activities or behaviours associated with the package in question?
+
+Additionally, package registries should warn users when:
+
+- A package has changed ownership
+
+- A previously stable package suddenly introduces new maintainers
+
+- A package with a very large number of downloads has received an unexpected update
+
+In the event-stream attack, a stranger was given ownership of a widely-used package without any verification or accountability. A visible alert would have prevented many users from blindly updating.
+
+4. Create and Update a Detailed Software Bill of Materials (SBOM).
+
+Teams should maintain an SBOM that clearly tracks all dependencies, the exact versions in use, and how the dependency tree changes over time.
+This will allow organizations to immediately determine whether they are affected when a malicious package is discovered. 
+
+
+Conclusion:
+The event stream attack shows us that attackers have the ability to exploit open-source software through the misuse of trust. The actual cause of this attack wasn't because there was a bug in the code; it was because an evil maintainer was able to add a malicious dependency without anyone noticing. Millions of users were impacted and a legitimate cryptocurrency wallet was targeted.
+
+The case illustrates an important lesson about dependency management and verifying who maintains these dependencies. Stronger checks on dependencies, reviewing changes made to dependencies, and monitoring all packages can help prevent similar types of supply chain attacks from happening again.
+
+ References:
+1. npm blog archive:  https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
+2. The Register: https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/
+3. Synk blog: https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/
+4. Paper: https://es-incident.github.io/paper.html
+5. BLackDuck blog: https://www.blackduck.com/blog/malicious-dependency-supply-chain.html
+
+ Contributions:
+- Author: Shreya Shitole    
+- License: This work is released under CC 4.0 license.  
+
+
+