Open Source Software Is Under Attack; New Event-Stream Hack Is Latest Proof

Earlier this year, I detailed a new battlefront for open source software based on the fact that bad actors are increasingly polluting public wells like npm. which millions of thirsty developers drink from — to the tune of 6 billion downloads per week — and was recently compromised when a bad actor injected malicious code into the popular JavaScript component, event-stream.

In the Old Days, Hackers Waited to Attack

To give some additional context, five years ago, large and small enterprises alike witnessed the first prominent Apache Struts vulnerability. In this case, Apache responsibly and publicly disclosed the vulnerability at the same time they offered a new version to fix the vulnerability. Despite Apache doing their best to alert the public and prevent attacks from happening, many organizations were either not listening or did not act in a timely fashio, and, therefore, exploits in the wild were widespread. Simply stated, hackers profit handsomely when companies are asleep at the wheel and fail to react in a timely fashion to public vulnerability disclosures.

Since that initial Struts vulnerability in 2013, the development community has witnessed Shellshock, the 2017 attack on Equifax, Heartbleed, and others, including the Commons Collection, all of which followed the same pattern of widespread exploit post-disclosure. 2017 attack on Equifax

Today, Hackers Are Creating Their Own Opportunities to Attack

This new form of attack on our software supply chains, where OSS project credentials are compromised and malicious code is intentionally injected into open source libraries, allows hackers to poison the well. The vulnerable code is then downloaded repeatedly by millions of software developers who unwittingly pollute their applications to the direct benefit of bad actors. In August of this year, 11 real-world examples of this attack pattern were documented in the 2018 State of the Software Supply Chain Report .

Then, in October, the topic of technology supply chain attacks landed on the front page of every news paper in the world when Bloomberg broke the "Supermicro" story. While that pertained to an alleged attack on a hardware supply chain (and questions still remain around its accuracy) — the scary truth was, and still is, that it's much easier for bad actors to infiltrate and hack a software supply chain. With hardware, you need to physically access something in order to conduct a hack. With software, the attack can be carried out from anywhere.

Yesterday's news about event-stream is the latest proof that bad actors are intentionally tainting open source components at the very beginning of the software supply chain so they can efficiently attack production applications in the wild, at the very end of the software supply chain.

The Game Has Changed

A decade ago, organizations were concerned about the possibility that they might be attacked within a few months of a new vulnerability being publicly disclosed. In 2017, Equifax, Japan Post, Canada Revenue Service, GMO Payment Gateway, and India Post had three to five days. Today, as evidenced by event-stream, software development teams and application security professionals must acknowledge the harsh truth: hackers are intentionally planting vulnerabilities directly into the supply of open source components.

To understand the magnitude of the event-stream exploit, one must recognize that the package is downloaded 2 million times per week by 6 million JavaScript developers from around the world. Furthermore, the exploit path was easily constructed when a single developer simply handed his credentials to the hacker who offered to take over maintenance responsibilities.

I talk even more about this with my colleague Mark Miller and Intrinsic's Thomas Hunter.

Corrective Actions Within Reach

The issue at hand is that we, as an industry, need to do a better job addressing these software supply chain attacks — and open source developers need to do a better job of understanding what's in the open source they are using.

Luckily, this is a fixable problem — and it's what we do best at Sonatype. Want to learn more? Schedule a demo here.