The destructive power of supply chain attacks and how to secure your code

In this Help Net Security podcast, Tomislav Peričin, Chief Software Architect at ReversingLabs, explains the latest and most destructive supply chain attacks, their techniques and how to build more secure apps.

Here’s a transcript of the podcast for your convenience.

Jasmine: I’m here today with Tomislav Peričin, Chief Software Architect with ReversingLabs, talking about the hot topic of supply chain attacks. So, Tomislav, the media is all the buzz about Kaseya and SolarWinds and labeled them as supply chain attacks. How should we think about these attack techniques?

Tomislav: Yeah. Thank you, Jasmine. This is a great question. So, they are both in fact labeled as software supply chain attacks, something that the industry has started to talk about deeply for the last year or so. And the idea behind software supply chain attacks is compromising the trust between the software publisher and the end-user, and essentially using software as a backdoor entry into the environment. With that definition, both of these attacks are essentially the same.

So, SolarWinds was a build environment compromise where the backdoor was injected into the piece of software SolarWinds produces, while Kaseya was a little bit different. They had the vulnerability, which was misused to target their own customer base, which in fact were managed service providers and at the very end, the customers of those managed service providers got hit by ransomware.

Even though we kind of bundle these two different attacks in the same category called software supply chain attacks, there’s a key difference, and I would say that SolarWinds is a software supply chain attack through the actual software, while Kaseya is a software supply chain attack through the solution that Kaseya is actually providing. So mainly through software, versus as an actual software backdoor.

Jasmine: Let’s focus in on the supply chain compromise techniques, and what does that mean for a software?

Tomislav: Yeah, there’s, as I said, many different types of software supply chain attacks, and we just talked about two, but there’s other popular ways software is attacked. There’s this concept of repository attacks where the attacks are uploading packages onto the open-source package repositories, with names which are similar to those of frequently used packages. The idea is then that the developer will kind of mistype the name of the package and inadvertently install a piece of malicious software, right? So, there’s one type, one additional type of supply chain attacks.

There’s also source compromise where in case of Codecov, which happened earlier this year, a shell script being hosted by Codecov was modified maliciously to exfiltrate data. And again, all sorts of different compromises within software supply chain attack, build compromise being one of them, and SolarWinds being one of the key examples of how that can have.

Jasmine: Given that backdrop, what advice do you have for software providers trying to secure their code?

Tomislav: Yeah, there’s many different practices today which are being recommended as updates, post SolarWinds compromise. But for us, the key tenet is actually the ability to inspect the fully built release package, because at the very end of this SUNBURST attack you had a compromised release image, and that was really the only way to actually detect this particular type of an attack.

The ability to analyze deeply the final package before you actually deploy it is crucial. And then there are additional pieces to securing that particular build. You have to think about are there any known vulnerabilities within that software package as well? Are there any misconfigurations when it comes to vulnerability mitigations? Is everything properly signed and can that integrity of the signed packages be validated? Are there any trade secrets or certificates or anything like that embedded within the package? And finally, are all of the behaviors trustworthy, right?

And that final thing is the actual point, when it comes to detecting software supply chain attacks. They’re really difficult to detect when it comes to traditional methods like signatures and heuristics and machine learning algorithms. The only line of defense, when it comes to defending from software supply chain attacks that actually modify the build environment and inject themselves at that point, is to actually investigate final build package as is and inspect and audit the underlying behaviors. So, developers can augment their processes with additional set of tooling, which, goes through all these checks I mentioned, and if everything is checked and is reasonably well secured, then the software can be securely released.

And that is exactly the type of service ReversingLabs has started to offer to its clients. We have built a site called secure.software, which is able to tear apart installation packages, describe the underlying behaviors, generate software build materials, validate certificates, and ensure that the packages are properly configured and there’s no blind spots when it comes to configuration management.

Jasmine: So, what about software consumers? Are they really truly helpless or do they have more control over this process than they think?

Tomislav: I think they do. The mantra is at this point “trust but verify”. There’s this inherent trust between the publisher of software and its users. Obviously, you’re purchasing or using their software, so you kind of anticipated they have the best intentions. There’s not going to be any obvious backdoors or anything like that.

But still, we do need to hold our vendors accountable. They need to provide paperwork to say that those software packages have been inspected for any malicious tampering that can happen, as this SolarWinds install, at any point in the process, and it might not even be the developer. So yes, trust but verify, and also rely on other parts of the system, as checks and balances, that even if a software got compromised, that the damage it could possibly do to the environment is minimized.

Jasmine: How do we move security forward? How do software consumers and suppliers start the conversation to build more secure apps?

Tomislav: Well, it really starts with the consumers asking the question. There’s a lot of people out there who have security questionnaires that the vendors are required to fill in, and the questions in those questionnaires are pretty general, but a lot of them do actually refer to best practices when it comes to securing the build environment. What kind of code quality check tools they’re actually using? How are they building software? Who has access to the source code, and things like that.

That gets you, as a consumer, a peace of mind when it comes to “is this company really doing everything possible to secure the build? “ And extending that beyond those questionnaires and writing those requirements into the best security practices being used by the industry, and finally augmenting the policies we have today to make sure that all of these checks are not voluntary, that they’ve become mandatory part of the process.

So, as we’ve just learned from Kaseya, it takes a very little to go from a compromised software developer or publisher to a ransomware attack, which has an ability to infect millions of machines, in this particular case. So, at this very stage, not just talking about securing software build environments is required, we need to also be doing things and improving policies to move this needle forward.