Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


01:00 PM
Connect Directly
E-Mail vvv

How SolarWinds Busted Up Our Assumptions About Code Signing

With so much automation in code writing process, results are rarely double-checked, which opens the door to vulnerabilities and downright danger.

As the fallout from the SolarWinds hack broadens, we continue to learn more about just how it happened in the first place. There have now been four malware strains identified, one being Sunspot, which was installed on the SolarWinds build server that developers use to piece together software applications.

When it comes to software supply chains, code signing is a commonly used practice to indicate the provenance of software. In theory, the process validates the authenticity and integrity of the code. But as we all now know, that isn't always the case. 

Related Content:

Alphabet's Chronicle Explores Code-Signing Abuse in the Wild

Special Report: Understanding Your Cyber Attackers

New From The Edge: Breach Etiquette: How to Mind Your Manners When It Matters

As it turns out, code signing is the very last step in what is often a convoluted process to get from original source code to finalized packaged software. An attacker that can inject changes into a software build pipeline or continuous integration (CI) process — as was the case with SolarWinds — will be able to make changes that are included in the signed final product, altogether defeating the purpose of the signature.  

Many software vendors may not have thought to take great care in securing their software release pipeline, but these recent attacks have more and more taking a deep look at how they can do that effectively. They need a system to certify that every step from source code to software has been executed correctly. 

The Real Problem With Code Signing: Assuming It's Fool-Proof
The process of code signing isn't inherently bad. The problem is that it can (and often does) give people a false sense of security. The whole idea behind code signing is that it verifies that the code itself hasn't been modified by anyone who doesn't have the proper access. 

A lot of the process is typically automated, and people don't usually double-check things when it's all set up — it's just supposed to work. That's when vulnerability and downright danger can strike.  

If a cybercriminal or anyone else with malicious intent is able to make a change before code signing takes place, everything can seem to be working perfectly and no one will dive deep because everything is expected to function. In other words, code signing is designed to verify the software supply chain is legit, but if you're signing something that's already wrong or has been tampered with, it doesn't matter. 

Further, the size of an individual project may correlate with the amount of risk involved. If a mobile phone vendor is putting together a big release of an operating system such as Android, for example, there are so many components involved that not a single person understands every single thing. And more people involved creates more risk. 

Strengthening the Integrity of Software Supply Chains 
Fortunately, there are some steps vendors can take to better protect their software supply chain. On the most basic level, they can scour a list of all of the code components used to help identify potential vulnerabilities. This sort of "code audit" via a software bill of materials can help eliminate security risks for a specific release the vendor is working on, as well as provide guidance on what to look out for with future releases.  

In my eyes, an emerging solution that vendors should consider is confidential computing, which is already being used in security-focused industries such as healthcare to improve clinical AI algorithms or financial services to prevent fraud. This, too, can come with a significant level of investment, particularly as it relates to underlying infrastructures, but it shouldn't be an issue for many software vendors considering the software release pipeline is one of the most critical pieces of their business. 

As SolarWinds has shown, the risk of a software vendors' code being the source of a data breach to its customers can forever damage its reputation and relationships with its customers. With this precedent in place, enterprises will increase the level of scrutiny applied to the supply chain of its software vendors. Software app makers such as Signal are already taking advantage of using better privacy and security as a differentiator to encourage users to move from WhatsApp.

The key to implementing confidential computing is a trusted execution environment that secures encryption keys within secure enclaves to protect them from external threats such as root users, a compromised network, rogue hardware devices, or, as was the case in the SolarWinds attack, advanced malware. 

A rule of thumb to live by, particularly for larger organizations, is to operate under the assumption that you've already been compromised. That assumption shouldn't go away as confidential computing becomes more widely adopted, but it will be far less damning. I see this as the next logical evolution in automating and securing software releases, and vendors who take advantage now will future-proof themselves for years to come.

Dr. Jethro Beekman is a technical director and is working on next-generation cloud computing security at Fortanix. Jethro received his M.S. and Ph.D. degrees in Electrical Engineering and Computer Sciences from the University of California at Berkeley in 2014 and 2016, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
3/9/2021 | 4:53:21 PM
Look To This Very Old Method For The Solution To Code Audit Problems
The personal accountability and liability that comes with professional licensing shows us the way to the solution to the problems of code unreliability.

In all of the developed world, a building cannot be deemed habitable without an occupancy permit. That means that an architect, contractor, structural engineer and building inspector all put their livelihoods on the line when they sign their good names to their declaration that the structure is ready to be occupied.

(An interesting corollary to that is that if the architect hasn't been paid, they are unlikely to sign off on the occupancy permit; professional licensing is thus an income assurance tool.)

Check out Osmio Professional Licensing, which brings duly constituted public authority to the digital world. When code is signed by an Osmio professionally licensed code auditor, that means that they're putting their good name and reputation and livelihood on the line. If it turns out there is some funny business in the code that introduces vulnerabilities, well, it's as though that architect had signed off on a  set of drawings that didn't mention a secret subterranean entrance to the building. End of career!
User Rank: Strategist
3/3/2021 | 2:45:23 PM
Source Signing
Another potential tool to use would be source signing. Where every file would be signed and the compiler would verify each file used (even OS headers/libraries). To be fully covered, all tools, such as make would need to be signing aware. This would at least push the problem back to the code repositories where tampering would need to occur.. possibly pushing signing even further, into those tools (e.g. git) as the authors commit each change.

Now had someone said this idea just a few years ago, people would have said they were mad/paranoid, but it seems it maybe required to truly ensure software integrity.

Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-18
Use of hard-coded credentials vulnerability in php component in Synology Calendar before 2.4.0-0761 allows remote attackers to obtain sensitive information via unspecified vectors.
PUBLISHED: 2021-06-18
Server-Side Request Forgery (SSRF) vulnerability in cgi component in Synology Media Server before 1.8.3-2881 allows remote attackers to access intranet resources via unspecified vectors.
PUBLISHED: 2021-06-18
Improper neutralization of special elements used in a command ('Command Injection') vulnerability in task management component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to execute arbitrary code via unspecified vectors.
PUBLISHED: 2021-06-18
Improper privilege management vulnerability in cgi component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to execute arbitrary code via unspecified vectors.
PUBLISHED: 2021-06-18
Server-Side Request Forgery (SSRF) vulnerability in task management component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to access intranet resources via unspecified vectors.