CyberWire Daily - Exploring vulnerabilities of off-the-shelf software. [Research Saturday]

Episode Date: August 21, 2021

Guest Tomislav Peričin, Reversing Labs' Chief Software Architect and Co-Founder, joins Dave to discuss his team's research that addresses the importance of validating third-party software components as a way to manage the risks that they can introduce. Developing software solutions is a complex task requiring a lot of time and resources. In order to accelerate time to market and reduce the cost, software developers create smaller pieces of functional code which can be reused across many projects. The concept of code reuse is one of the cornerstones of modern software engineering and it is universally accepted that everybody should strive towards it. However, in addition to the positives, organizations need to be aware of the security risks introduced by such third-party components. The growing number of cyber incidents that target the software supply chain are focused on high-value target compromises. With the latest surge and public uproar, the US President Biden has issued the Executive Order on Improving the Nation’s Cybersecurity in order to create an institutional framework addressing these kinds of security risks. The research can be found here: Third-party code comes with some baggage Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts

tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And the question was, well, how many of these outdated dependencies, which might be vulnerable to some serious CVs, are out there? That's Tomislav Perichin from Reversing Labs, where he's chief software architect and co-founder. The research we're discussing today

is titled Third-Party Code Comes With Some Baggage. And now a message from our sponsor Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing

IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security.

Well, so walk us through how you approach this. How did you all get started on this research journey? Yeah, so we actually scan all these package repositories continuously. One of our core missions is to be able to find any malicious packages which might reside in them. So what we do is we scan things like NuGet and NPM and PyPy and all the other open source repositories. So that drew us to the conclusion of, well, we're checking for malware, what would happen if we start looking for vulnerabilities as well? And how did you go

about doing that? I mean, what's the process for digging in here and finding what's buried in these packages? So the package managers themselves host all the versions of the packages themselves. You can relatively easily go and crawl all of the packages themselves. You end up collecting a vast amount of data. So NPM, I think, is about 9 million different package versions that you kind of crawl and maintain over time. And then, obviously, after you have all these packages, you start doing static analysis.

So unpacking them, analyzing the contents, looking at, you know, are they only using script languages intended by the package manager, or are they also including native binaries as well? And what did you find here? Take us through some of the results. Well, the interesting bit is that you kind of expect that the package managers kind of serve the programmers for that platform, and you kind of expect them to have only

JavaScript in NPM world. What we actually uncovered during our research is that all of these package managers, alongside their core missions, have additional libraries and executables for all sorts of platforms. So we found Windows executables, executables for even mobile applications

in all these packages. So with that idea, then we said, okay, so we know a lot about So with that idea, then we said, okay, so we know a lot about analyzing, for example, Windows binaries, and we know we can have static linked libraries in those applications. Is this something that developers are actually actively updating as well? So that led us through this path of making some signatures to identify commonly used compression, encryption, and networking libraries that we know for a fact are updated all the time. And they are updated all the time because frequently vulnerabilities get discovered in them. discovered in them. So with those sets of signatures and doing this large data analysis, we were able to uncover

hundreds of thousands of different packages across many different versions they have that actually do still have vulnerabilities which might get exploited. So help me understand here. Is this a matter of people using other snippets of code, you know, open source things, as you said, you know, popular libraries and so on. Is it a matter of them using ones that are out of date and not going through the process of updating them?

Is it neglect or what exactly leads to these being consistently within the things that you're looking at here? Yeah, so it's not on the end user. So the end user uses the package manager correctly. So they say, okay, update all the packages, bring down the latest versions. And the developers of those packages tend to update that code frequently. However, the statically linked libraries do not appear in the list of dependencies. And you have no idea if the original developer has actually updated the statically linked libraries or not. And as our research shows, there's quite a few developers out there who kind of include a third-party project and forget,

and then just ends up accumulating this large number of vulnerabilities in open source repositories. Can you give us an example of some of the things that you found here? Yeah. So we've looked for, as I said, common compression encryption libraries. And for example, Zlib is the most common compression library out there. There's only like two dozen or so versions that it has, but almost every single version has a vulnerability or two. And it's relatively easy to identify if you create a signature which just includes the banner,

which says I am Zlib and specific version, you'd be able to identify if the library is actually statically linking an outdated Zlib and specific version, you'd be able to identify if the library is actually statically linking an outdated Zlib version. So we did that, and through the scan we found quite a few popularly used packages which statically link these things. I think one of the most interesting ones was the application which is used to edit and create new DICOM images. And DICOM images are used in medical devices, right? So this is very interesting because they're using an outdated version. And then if you're parsing an image which has a vulnerability within,

the parsing itself could trigger code execution. So that's why having these libraries continuously updated is important, even though they might not be declared by people creating the packages. So how would someone go about doing what you've done here? I mean, in order to... I guess it's...

Is it a matter of how deep do you dig? I mean, if I'm developing something here and I've got these dependencies, what's the best way for me to go about making sure that there aren't these sorts of things lurking within? So for developers, it is relatively hard because the tools they have at their disposal coming from the package managers themselves, they only show the declared dependencies. To be able to find the ones which are not, you need to use additional tools. And there are commercially available tools today called, you know, SCA tools or software composition analysis tools. A lot of them will just,

you know, look at the package manifest as well and stop there. The ones which are really good will try to do static analysis and figure out, is there any static link code? Those are limited, and they tend to use a pretty fine set of signatures to find common vulnerabilities. So we would recommend using those in addition to open common vulnerabilities. So we would recommend using those in addition to open source tools. In terms of the bad guys being able to exploit this, I mean, if it's not obvious to the developers, is it also not obvious to the bad guys

that these vulnerabilities would be here? Or is there a disproportionality here where the bad guys have the advantage? It is relatively simple to create these signatures. So let's say you're a bad guy, and you're trying to do kind of mass exploitation of these vulnerabilities. For the static link libraries,

which are easy to identify like we did, writing a simple signature will do, you can easily find the vulnerable packages and you can find them way before the actual developers do. We haven't yet really seen large-scale exploitation like that, but given what's happening with software supply chain and attackers finding new and novel ways to exploit the developers, this might be just a matter of time. And what about the notion of a software bill of materials? I mean, is that the

sort of thing that would help out here, where if you had a manifest of everything included, would that help us get where we want to be? Absolutely. That is the way forward. However, most software-built materials for open-source packages are being created based on the self-declared list of dependencies. Additional tooling is actually required to be able to detect statical link code and add that to the software-built materials. Typically, software-built materials is created manually by the developers and it suffers the same drawbacks as anything else maintained by humans.

It can be outdated. It might not even be accurate. It can change over time. Dependencies could be forgotten or added. So it really is up to security providers to actually develop tooling that can accurately define the software build materials. And how do you rate the seriousness of this? I mean, to what degree should this be on people's radar? How seriously should they take the possibility of vulnerability here?

the possibility of vulnerability here? Well, we'll start with the basic one, which is, do I understand the software build materials for the packages I'm actually using? And if the answer is no, and in most cases, it is going to be no, what can be done about it? Because we already are looking for software build materials to detect certain issues, right? We're trying to find license violations. We're trying to find license violations.

We're trying to find vulnerabilities in commonly used components. Extending that process to make us a little bit more secure is actually required. So what are your recommendations then for folks who want to do a better job here? How do they get started? What's the best way to approach this?

Well, I would look at additional security tools. If you are not using any software composition analysis tools today, this would be a good time to start because we've seen that gaps in protection are actually being exploited by the attackers. So we've seen people misusing the known vulnerabilities. We've seen people misusing the known vulnerabilities. We've seen people misusing the lack of vulnerability mitigation protections enabled. And adding additional tooling, both commercial and open source,

is required to start bridging that gap and reducing the actual attack surface so the packages that we provide to other people and other developers are depending on are a little bit more secure. Our thanks to Tomislav Perichin from Reversing Labs for joining us. The research is titled Third Party Code Comes With Some Baggage. We'll have a link in the show notes.

And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home. Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak. Learn more at blackcloak.io.

The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Trey Hester, Elliot Peltzman, Puru Prakash, Justin Sabey, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Vilecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.