RSAC insights: SolarWinds hack illustrates why software builds need scrutiny — at deployment

By patiently slipping past the best cybersecurity systems money can buy and evading detection for 16 months, the perpetrators of the SolarWinds hack reminded us just how much heavy lifting still needs to get done to make digital commerce as secure as it needs to be.

Related: DHS launches 60-day cybersecurity sprints

Obviously, one change for the better would be if software developers and security analysts paid much closer attention to the new and updated coding packages being assembled and deployed on the fly, in pursuit of digital agility.

I recently had the chance to discuss this with Tomislav Pericin, chief software architect and co-founder at software security firm ReversingLabs. We talked about how the capacity to, in essence, rapidly reverse engineer new software and software updates — without unduly hindering agility — could make a big difference.

For a full drill down, please give the accompanying podcast a listen. Here are the key takeaways:

Targeting the build

One thing I did not realize about the SolarWinds hack is precisely how the attackers fooled more than 18,000 organizations into accepting an infected update of the widely-used Orion network management tool. I had assumed that they either stole or spoofed a SolarWinds digital certificate, which they then used to authenticate the tainted update. The payload malware: Sunburst, a heavily-obfuscated backdoor.

Actually, these attackers went through a lot of effort to first gain deep access inside of SolarWinds’ network. Next, they located and took control of the build process used to compile the various pieces of coding that SolarWinds’ software developers assembled to make up its Orion software updates.

“People tend to focus on the Sunburst malware, the actual backdoor that ended up in the affected update package,” Pericin told me. “But there was another malicious component, Sunspot, which was a piece of malware specifically designed to run in the Solar Winds environment, on a build machine. Sunspot waited for the build processes to start and then injected Sunburst directly into the build.”

“And once the entire code was built, then it was digitally signed. Actually, it was digitally signed on the machine where it was built, and there was no need for the attacker to steal the digital certificate.”

Advanced cloaking

It is undisclosed how the Russia-sponsored attackers got control of the SolarWinds build machine. However, one possible scenario is that they obtained a targeted employee’s login credentials and then used that employee’s account to pivot to and take control of the build system, Pericin says. Spear phishing, or even bribery of an insider, are tried-and-true ways to gain initial access; and then living-off-the-land techniques work very well for stealthily mapping network resources and escalating privileges.

This type of Advanced Persistent Threat (APT) hack has been around for at least 20 years and first gained global attention when Google disclosed China’s Operation Aurora hack in January 2010, stirring an international dust-up. APT attacks have only solidified as the go-to approach for nation state-backed cyber espionage since then.

What’s distinctive about the SolarWinds hack is that it deeply compromised networks at a stunning scale and made very effective use of leading-edge stealth tactics. The attackers took great care to blend in with SolarWinds’ style of code writing, even mimicking the company’s proprietary naming standards, Pericin told me. Thus cloaked, they were able to add malicious functions to their heart’s content; this included creating an agile distribution path for Sunburst, the backdoor malware.

So what are enterprises doing, currently, to detect and deter such APT attacks? By and large, the same thing they did when Operation Aurora hit. They continue to rely on legacy defenses, i.e. the latest iterations of advanced firewalls, endpoint security, intrusion detection, intrusion prevent and data loss prevention systems, Pericin says.

Theses entrenched defenses, in turn, leverage oceans of data that arrive daily from a sprawling ecosystem of public, private and open-source threat intelligence feeds. Out of this comes whitelists and blacklists on which malware filters are based. This is how any malware known to be in circulation, and any IP addresses supporting malicious activity, generally get identified and quarantined today.

Granular scrutiny

ReversingLabs got started because Pericin and co-founder Mario Vuksan saw a need to go a pronounced step deeper. So they developed a way to leverage available threat intelligence in service of analyzing objects inside of packaged software releases.

“Our vision from the very start was to provide the ability to analyze any given file and to be able to describe the behaviors of that file through static analysis, as quickly as possible, in a couple of milliseconds per file, and then explain in human-readable language what the file is trying to accomplish,” Pericin says.

This level of granular scrutiny, oriented to flushing out coding that shouldn’t be there, can be done thanks to advances in data collection and data analytics.

ReversingLabs, for instance, relies quite a bit on MITRE ATT&CK — a knowledge base of real-world observations describing threat actor tactics and techniques – a resource that is used widely as a foundation for threat modeling.

“Think of what we do as an automated reverse engineering process. We’ve built an automated system to basically extract threat intelligence from any binary object and describe it to an analyst in a language they can understand,” Pericin says. “We’re really grateful for all the work MITRE has been doing categorizing all these behaviors into tools and techniques and procedures that the attackers are using.”

‘Golden image’ validation

It’s encouraging to see convergences of new tools and existing data stores. This is how it should work. An industry group maintains a rich resource and makes it available to any vendor to identify weaknesses and innovate solutions, and then communicate this to the market in a common language schema.

Pericin told me that ReversingLabs is focusing on getting developers at large shops to adopt the habit of using their automated tool to deeply scan software packages as a final quality check, just before deployment. Beyond that, he argues that companies should think about selectively doing such scans for mission-critical software arriving from smaller houses and independent developers who may not have the resources to do so.

Observes Pericin: “Software supply chain attacks can occur indirectly, meaning you’ve ingested a third-party component, which itself may have been attacked – just think about all of the open-source repositories hosting potentially malicious libraries . . . someone needs to assure that when the golden image gets shipped internally or arrives from a third-party, that the golden image has been checked for any behavioral oddities.”

The capacity to, in essence, rapidly reverse engineer new software and software updates — without unduly hindering agility – has become available. That’s a good place to be. 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.)

 

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at: https://www.lastwatchdog.com/rsac-insights-solarwinds-hack-illustrates-why-software-builds-need-scrutiny-at-deployment/