Novel Attack Via Open-Source Repositories

An ethical hacker managed to breach over 35 companies with a new attack. Businesses must ensure internal code does not end up on open-source repositories.

In the world of software research and development, open-source repositories are an essential part of every project. Repositories are places devs and coders can go to find answers to a problem they can’t solve, to collaborate with other coders and devs, to share ideas and problem solve together. Every software project is an invention, no two are alike, but code that has been written to solve a problem or complete a task can be reused in other R&D projects. Using open-source repositories generally comes with a level of trust in what is shared, but, as we’ve discussed in the past, it’s a place of easy access for threat actors to exploit.

Recently, a white-hat hack was completed by Alex Birsan, an ethical hacker. Threatpost has a great article detailing the attack itself, which has resulted in breaching over 35 companies to date. Big companies like Microsoft, Apple, Netflix and Uber are on that list. But what really got our attention was how the idea for the attack came to be.

Last summer, Birsan was attempting to hack PayPal with another ethical hacker, Justin Gardner. Gardner shared “an interesting bit of Node.js source code found on GitHub” with Birsan. This code was meant for internal PayPal use, but was found on GitHub, and had a combination of public and private dependencies in its package.json file. There were public packages from npm and non-public package names, likely hosted internally by PayPal, that were not on the public npm registry at the time.

According to Birsan’s Medium post, he wondered what would happen if malicious code was uploaded to npm under those names. Would some of PayPal’s internal projects begin to default to the new public packages instead of the private ones? That’s when he decided to upload his own Node packages to the npm registry under the unclaimed names. This code would notify him if it was installed on any of PayPal’s servers. 

The short answer to that question is yes, which is concerning but also concerning is that PayPal had internal dependency information sitting around on an open-source platform. We’ve already seen examples of open-source code containing malware on the npm registry and GitHub, which should have prompted every business to complete a full code review. Now businesses need to make sure that their internal code packages are not hanging out on open-source platforms for all the world to see.

Most of the businesses Birsan breached have 1000+ employees, which means that they likely have quite a few devs and coders. In these cases, internal code dependencies really should be kept somewhere that only the people who need them have access to them. It’s like setting up IAM controls for your devs, it should be done using the least privilege method. Not all of your devs and coders need access to those dependencies. Or maybe they need access to view and copy, but not to edit or share. There are ways to restrict this kind of access.

The next step for businesses in this area is to hire an expert to review open-source repositories for internal code. The majority of workers who touch code inside an organization are already overworked and told to make concessions on projects to meet deadlines. They don’t have time to look through open-source repositories for code, but someone needs to ensure the safety and security of your business and its proprietary information. 

If an ethical hacker can have this kind of success with the attack he planned, what is a threat actor going to be capable of? Birsan was already thinking outside the box when he planned this attack, something threat actors are constantly doing to stay ahead of law enforcement and security professionals. It’s not a matter of “if” a hacker is going to try something similar, it’s a matter of “when.” It is incredibly important to protect the code that your business uses, this is the stability, functionality and security of your livelihood and the livelihoods of your employees. It’s not something to take lightly or gloss over thinking it can be done later. It cannot be done later, it must be done now, or it will be too late.

About the Author

Pieter VanIperen, Managing Partner of PWV Consultants, leads a boutique group of industry leaders and influencers from the digital tech, security and design industries that acts as trusted technical partners for many Fortune 500 companies, high-visibility startups, universities, defense agencies, and NGOs. He is a 20-year software engineering veteran, who founded or co-founder several companies. He acts as a trusted advisor and mentor to numerous early stage startups, and has held the titles of software and software security executive, consultant and professor. His expert consulting and advisory work spans several industries in finance, media, medical tech, and defense contracting. Has also authored the highly influential precursor HAZL (jADE) programming language.

Contact us

Contact Us About Anything

Need Project Savers, Tech Debt Wranglers, Bleeding Edge Pushers?

Please drop us a note let us know how we can help. If you need help in a crunch make sure to mark your note as Urgent. If we can't help you solve your tech problem, we will help you find someone who can.

1350 Avenue of the Americas, New York City, NY