What You Need to Know About Tampering
In this episode of ReversingGlass, Matt discusses how tampering is complicated given the complexity of software packages — making it tough to pinpoint. That’s why a final exam of the complete package prior to release is essential.
Learn More
- Definition: What is Software Tampering?
- White Paper: The Monsters in Your Software Supply Chain
- Research: The State of Software Supply Chain Security 2024
Episode Transcript
Hi everyone! Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs, and today's episode is: What is tampering and how does it relate to software supply chain security? Again, we gotta start with a little bit of a movie quote analogy, went way back for this one.
Finding an example of tampering that leads into the whole software supply chain story associated with tampering is a little bit unique, but how many people know what this movie is? It's the first Indiana Jones movie, going back to the 80s, started the franchise of Indiana Jones.
In this scene, if you remember, this is where someone tried to assassinate Indiana Jones by poisoning the dates, and the monkey got to the dates, and Sala saved Indy from eating the dates. And in this scene, he catches the date and says, bad dates, and they realize that it was tampered with and it was an assassination attempt.
Your software package can also be tampered with in a very similar way, but it's a little bit more complex. So as we jump in, thinking about how do you address tampering in a software supply chain world? The first thing is having a final exam of the package itself. You can't look at something and figure out if it was tampered with if you don't examine it. So examining the package, breaking it down to its original parts, and comparing it to something with binary analysis, because breaking it apart is the process of looking at the root cause. So if you think about the recent supply chain attacks from 3CX, the code signing process, even though it was correctly signed, was tampered with and the code was manipulated.
So that final exam is what you need. So complex binary analysis is the first step. Break it back into the parts of the whole, so you can actually look at everything. And then compare it to itself, a good known entity, so you know what was good and what was bad. And really what tampering and binary analysis allows you to do is to give a reality check.
Is this doing things that are unexpected? Are there things happening that are potentially not exactly what you expect them to be? And the only way you do that is, again, comparing two entities. And there's a lot of different more advanced thoughts on this as you go down, and we're going to talk about those in another ReversingGlass episode, and I'm foreshadowing here with reproducible builds. But, in this example, you can actually use AI and other techniques to basically jump in and say: Hey, this was something that happened in the past, like a 3CX attack in the code signing issue or the SunBurst attack where differential analysis was the way that you actually figured out: hey this release had this, this release had something different, which led you down the path to either a novel attack or a known malware attack.
So if you're not thinking about tampering as it relates to software supply chain security you're missing the boat. So tampering is the way to do it, and the way you actually identify tampering in a package is post compilation, get it all compiled together, all the components, then break it back apart and compare it to itself.
If you're not thinking about tampering, you're not thinking about software supply chain security. Hope everybody enjoyed the quick episode. Thanks for watching.
