The New Year in Cybersecurity: Supply Chain Attacks, Part 1

Hey there, and happy New Year. I wanted to take a moment and write about what I think the coming year is going to look like for information security professionals. This is going to be an introductory post to a multi-part series of blogs so I can talk about different topics a bit more in-depth. 

I’m gonna kick this collection off by talking about the elephant in the room: supply chain attacks. 

What are supply chain attacks?

Supply chain attacks are likely going to be a focus for a lot of security vendors, researchers, and cybersecurity conference talks/keynotes for a significant period of time because of the recent SolarWinds breach. 

But let’s step back for a minute. What’s a supply chain attack? 

A supply chain attack is, more or less, the compromise of a trusted third party with the intent of gaining access to–or attacking–other desired targets. Let’s talk about some examples of supply chain attack compromise: 

• One form of a supply chain attack may involve compromising a third party partner and leveraging their network access to pivot to a more desirable target. 
• Another form may involve compromising a third party’s software update feature to infect as many targets as possible. 
• A more subtle form of the same attack may involve compromising the third party software vendor, implanting a backdoor, and distributing it, but then only allowing it to trigger under certain conditions and only on certain targeted networks. 
• The hardest to both detect and pull off would be interdicting (that is, intercepting goods in transit) hardware destined for a target and implanting hardware backdoors.

Supply chain attacks represent a major cybersecurity risk because the attack abuses a trusted relationship that an enterprise has with a third party. Although they aren’t frequent occurrences, when they are found, they have a tendency to be highly targeted. Of course there are exceptions, but largely that depends on the goals and motivations of the attacker. 

For instance, the M.E. Doc incident (second bullet in the list above) was notable because practically every customer that could contact the update server was targeted with an update that contained ransomware. In a twisted way, it makes sense–the ransomware operators are financially motivated, and they only get money if they convince infected targets to pay in order to decrypt their data. 

On the other hand, the recent SolarWinds incident was highly targeted; while thousands of customers downloaded the SolarWinds Orion software packages that had the initial backdoor compiled into the product, the attacker’s backdoor was very carefully implemented. It was slow, methodical, and would only implement additional functionality during the wake-up period if the backdoor was located in a network of interest to the attackers. 

In several break-downs of the backdoor, the tradecraft exhibited by the attackers was extremely sophisticated. I know the word “sophisticated” gets thrown around like sprinkles on an ice cream cone in most advanced threat reports, but in this case, I think the description is entirely warranted:

• After a customer initially installed the backdoored version of SolarWinds Orion, the implant would wait up to two weeks after initial installation date before it attempted to “call back” to command and control servers.
• The command and control servers and their domains had a long “history” and were hosted on well-known providers. This would prevent most application-aware firewalls, and proxies with blacklist lookup and/or categorization lookups to label the domain as “unknown” and block access.
• Other backdoor C2 traffic was made to mimic actual SolarwWnds Orion network traffic.

This logic and additional “fencing” ensured that only specific networks would trigger additional stages and functionality in the backdoor, and it is likely why we learned about the backdoor in December 2020, as opposed to March 2020, when the backdoors were first inserted in the SolarWinds software packages. This is why thousands of organizations were affected by having the backdoor product, but only a handful out of those thousands were considered targets in which adversaries utilized additional functionality and operated with a particular goal in mind.

Defending Against Supply Chain Attacks: The Answers You Probably Don’t Want

So, what can be done to defend against supply chain attacks? Unfortunately, there are no easy shortcuts to take towards defending networks against supply chain attacks. The same building blocks of information security that have been recommended for decades mostly apply here.

Asset and Software Management 

Know what systems you have, the purpose they serve, and the mission/business critical tasks they accomplish. For asset management, consider documenting the following information:

• Device hostnames
• DNS entries
• IP addresses
• Hardware Manufacturer
• Product Designation/Version
• Number of network interface cards
• Network segments to which they are attached
• MAC addresses for all network interfaces 
• Base operating systems installed
• Hardware resources allocated (Disk space, RAID array configurations, RAM allocations, Number of physical CPUs, special peripherals, etc.)
• The business unit the assets belong to
• Who the asset owners are (as well as their contact information 
• What purpose(s) the assets serve
• Whether or not the asset should be classified as mission critical

In addition to knowing what systems exist out there and the purpose they serve, it’s important to know what software is installed on those assets. You should also be documenting: 

• Software applications
• Network services
• Version information for installed applications and network services 

Software inventory management tends to be a little bit harder than hardware/asset management. Have you ever heard of the uncertainty principle? To paraphrase it and directly quote one of my favorite YouTube video series ever: 

“It’s like the classic debate about why measuring the position of an electron changes its momentum and vice versa. The only correct answer is to get drunk and set fire to things.” Gordon Freeman, Freeman’s Mind

Software management is almost always in a constant state of flux. Because of that, documenting installed software becomes a constant task: Users require new software to perform specific tasks, new updates are being released, patches are being issued, etc. Trying to take a snapshot of what software is installed, and the versions installed always ends up with that snapshot immediately becoming outdated. That doesn’t mean that the work is unimportant, however. If the supply chain attack you are attempting to detect or remediate is a software backdoor, knowing what assets are running the affected software and software versions is extremely important. 

How to Get Good at Asset/Software Management

The only way to get good at asset management is to commit time and resources towards doing it. Assuming you’re starting from scratch with no information or an outdated, four-year-old spreadsheet, it’s okay to make use of network data to begin filling things out. 

Here is a list of data sources to consider pulling from when compiling your list:

• Passive network fingerprinting
• Vulnerability scans
• DHCP allocations 
• Enumerations from EDR tools
• Network monitoring suites
• Patch management tools

Start by meeting with key stakeholders in your organization, or business units and ask them what their workflows look like. Ask them to identify systems they consider to be mission/production critical. These are the assets you should add to your asset management database first. Once you have that covered, expand from there to cover secondary and tertiary systems.

If you aren’t implementing change control procedures to document when changes are being made to your assets, especially mission/production critical assets, then now is as good a time as any to start. You should implement these procedures in each of these scenarios:

• Ensure every new device, every new VM, and every new cloud instance is tagged, has an owner, and has the software installed on it defined. 
• Any time a change control request is completed (e.g. new software is installed, patches are issued, etc.), that should automatically trigger an audit of the host to verify asset and software information about that host, or group of hosts. This way, when changes are implemented on the network, your asset database information is updated in lockstep–new hosts are added, decommissioned hosts are removed, and existing hosts are updated regularly. 
• Any time somebody leaves the company or organization, this should trigger an automatic check to determine whether or not they were responsible for a production asset. If so, the new asset owner should be determined immediately to avoid the “Joe was the owner in charge of that thing. He left five years ago” scenario.
• Consider auditing your asset management database regularly–I’d say at least once annually. I know this is an arduous task that nobody wants to do, but the thing about good security posture is that sometimes you have to do the things that you think are awful to protect yourself from truly awful things in the future.  

If you are planning on building an asset management system, database, or even spreadsheet, I would recommend ensuring that there is a field for “last time audited/updated.” With this field, you can perform queries to look at assets that haven’t been updated in a while. This enables you to perform better housekeeping, faster annual audits, and ensures you don’t run into the dreaded “This spreadsheet has all our assets listed. It hasn’t been updated in six years” scenario.

Conclusion

In this post, we discussed the definition of what a supply chain attack is and why it’s so scary; a lot of organizations rely on third parties to either perform mission critical tasks or manage vast portions of their networks. That is a lot of privileged access to be entrusting to an outside entity, and most of us do it everyday. With the scope and complexity of this threat coming to light with the SolarWinds compromise, I wanted to really drive home that one of the primary defenses against supply chain compromise is knowing what assets on your network are directly involved with that supply chain. 

Both asset management and having a software inventory are extremely important when it comes to identifying affected assets and containing the threat as soon as possible. Asset management and software inventories lay the groundwork for better overall awareness and defense. 

In the next post of this series, we’ll discuss a few more things that can be done to better defend against supply chain compromise, once you’ve started building a more robust asset and software inventory. Stay tuned, and thanks for reading.