RSAC insights: Software tampering escalates as bad actors take advantage of ‘dependency confusion’

By Byron V. Acohido

It’s not difficult to visualize how companies interconnecting to cloud resources at a breakneck pace contribute to the outward expansion of their networks’ attack surface.

Related: Why ‘SBOM’ is gaining traction

If that wasn’t bad enough, the attack surface companies must defend is expanding inwardly, as well – as software tampering at a deep level escalates.

The Solar Winds breach and the disclosure of the massive Log4J vulnerability have put company decision makers on high alert with respect to this freshly-minted exposure. Findings released this week by ReversingLabs show 87 percent of security and technology professionals view software tampering as a new breach vector of concern, yet only 37 percent say they have a way to detect it across their software supply chain.

I had a chance to discuss software tampering with Tomislav Pericin, co-founder and chief software architect of ReversingLabs, a Cambridge, MA-based vendor that helps companies granularly analyze their software code. For a full drill down on our discussion please give the accompanying podcast a listen. Here are the big takeaways:

‘Dependency confusion’

Much of the discussion at RSA Conference 2022, which convenes this week (June 6 – 9) in San Francisco, will boil down to slowing attack surface expansion. This now includes paying much closer attention to the elite threat actors who are moving inwardly to carve out fresh vectors taking them deep inside software coding.

The perpetrators of the Solar Winds breach, for instance, tampered with a build system of the widely-used Orion network management tool. They then were able to trick some 18,000 companies into deploying an authentically-signed Orion update carrying a heavily-obfuscated backdoor.

Log4J, aka Log4Shell, refers to a gaping vulnerability that exists in an open-source logging library that’s deeply embedded within servers and applications all across the public Internet. Its function is to record events in a log for a system administrator to review and act upon. Left unpatched, Log4Shell, presents a ripe opportunity for a bad actor to carry out remote code execution attacks, Pericin told me.

This type of attack takes advantage of the highly dynamic, ephemeral way software interconnects to make modern digital services possible.


“As we go about defining layers on top of layers of application code, understanding all the interdependencies becomes very complex,” Pericin told me. “You really need to go deep into all of these layers to be able to understand if there’s any hidden behaviors or unaccounted for code that introduce risk in any of the layers.”

Obfuscated tampering

Dependency confusion can arise anytime a developer reaches out to a package repository. Modern software is built on pillars of open-source components, and package repositories offer an easy access to the wealth of pre-built code that makes development faster. However, not all of that code is safe to use. Capitalizing on dependency confusion, threat actors seek ways to insert malicious elements; and they take intricate steps to obfuscate their code tampering. Most often their objective is to install a back door through which they can come and go – and take full control of the underlying system anytime they please, Pericin says.

Last year, white hat researcher Alex Birsan shed a bright light on just how big an opportunity this presents to malicious hackers. Birsan demonstrated how dependency confusion attacks could be leveraged to tamper with coding deep inside of system software at Apple, PayPal, Tesla, Netflix, Uber, Shopify and Yelp!.

Then in late April, ReversingLabs and other vendors shared stunning evidence of such attacks moving beyond the theoretical and into live service. A red team of security researchers dissected a dependency confusion campaign aimed at taking control of the networks of leading media, logistics and industrial firms in Germany.

The basic definition of software tampering, Pericin notes, is to insert unverified code into the authorized code base. In the current, operating environment, there’s limitless opportunity to tamper with code. This is because such a high premium is put on agility.

“There are many places in the software supply chain where you can add unverified code, and the attackers are actually doing that,” Pericin says. “And that’s also why it can be so hard to detect.”

Implementing SBOM

Even as their organizations push more operations out to the Internet edge, senior executives are starting to realize that their internal attack surface is riddled with security holes, as well. Some 98 percent of the respondents to the ReversingLabs poll acknowledged that software supply chain risks are rising – due to their intensive use of built-on third party code and open source code. However, only 51 percent believed they could prevent their software from being tampered with.

For its part, ReversingLabs supplies an advanced code scanning and analysis service, called Software Assurance, that can help companies verify that its applications haven’t been tampered with. Software developers at large shops are getting into the habit of using this tool to deeply scan software packages as a final quality check, just before deployment, Pericin told me.

Some companies are going so far as using this tool to selectively scan mission-critical software arriving from smaller houses and independent developers for behavioral oddities, as well, he says.

Having the ability to granularly scan code also plays well with the drive to mainstream SBOM, which stands for Software Bill of Materials.

SBOM is an industry effort to standardize the documentation of a complete list of authorized components in a software application.

President Biden’s cybersecurity executive order, issued in May, includes a detailed SBOM requirement for all software delivered to the federal government.

And now advanced scanning tools, like those supplied by ReversingLabs, are ready for prime time – to help companies detect and deter software tampering, as well as implement SBOM as a standard practice.

“One of the outcomes of doing this analysis is you gain the ability to correctly identify what’s present in the software package, which is the software bill of materials,” Pericin observes.

In today’s environment, organizations need to figure out how to secure their external edge, that’s for certain. But it’s equally important to account for their internal edge, to stop software tampering in its tracks. It’s encouraging that the technology to do that is available. I’ll keep watch and keep reporting.


Pulitzer Prize-winning business journalist Byron V. Acohido is dedicated to fostering public awareness about how to make the Internet as private and secure as it ought to be.

(LW provides consulting services to the vendors we cover.)



Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone