Last autumn there were news about chromium browsers and other software being vulnerable to zero-click exploit when rendering webp pictures. The vulnerability was so serious that it got maximum rating from CVSS score. And to make things even worse these exploits were reported to be used in ongoing attacks.

This raises questions where is this being used? According to this article a greater deal of messaging apps and password managers were affected.

I have few questions for you: What did you do last autumn? Did you have clear vision over what all needs to be patched? Who is responsible for patching? Now that few months have passed are you certain that you did patch everything?

ENISA Threat Landscape 2023 tells that 61% of companies have been impacted by supply chain attack in time range of twelve months. Cost on businesses were forecasted to grow 75% from 2023 to 2026. Supply chain attacks is sadly a subject that different organizations are struggling with today.

Many faces of the problem

Supply chain generally means all the necessary equipment, processes and components to deliver your ideas to your end users. To attack your supply chain attacker can do any of the following and likely even more:

1. Attack and compromise your privileged users
2. Attack and compromise computers used by privileged user or by the system
3. Contaminate dependencies used by software
4. Contaminate software used to build or deploy the system

By ENISA Threat Landscape 2023 the definition of supply chain attack requires that the supplier is being attacked to gain access to its customers. This definition rules out compromising generally used software libraries but I wish to talk about them still. In the end software libraries are still part of your supply chain and Log4Shell type of attacks will compromise it. It seems that ENISA partly agrees because they had mentioned Log4Shell in their report under supply chain attacks.

Protection in theory

Theory is straightforward and simple. You need to be aware of list below and implement protections according to your threat models:

• Inventory of systems and what software is being related to them
• Software being used and their versions
• Software dependencies being used and their versions
• Suppliers and the suppliers of the suppliers
• Ways to remotely access your systems
• Levels of privileges required
• Time window for privileges required
• Potentially limit the computers that are being used to built the system

If you have been around in IT you know that this is not easy task. Not all systems are known or in distributed environments not all the maintainers are at the same knowhow level and people tend to choose the best tools they see fit for the job.

Implementing inventory

How would you know what systems you have, what software you have and what dependencies those software are using? Who has access to the systems?

Well it starts with company-wide policies. You need to know these things. You can’t protect, update or harden something that you don’t know. Here is a rough maturity model to check where you are at:

• Maturity none: Unable to list systems, system owners, suppliers with
  access and component versions
• Maturity low: Ableness to reach few system owners and eventually figure out
  components being used on those few systems and the suppliers involved
• Maturity medium: Ableness to reach majority of system owners to figure out
  components being used and the suppliers involved
• Maturity high: Ableness to reach all system owners and get the exact versions of
  components being used and list of supplier personnel with access
• Maturity superb: Up-to-date centralized view over all systems and their
  components with just-in-time privileges

In case of mentioned libwebp vulnerability you would have needed to contact your system owners to check if there would be underlying dependency to that and if it was patched. To be able to do that and verify that each system is safe you would need a catalog of systems and owners and then keep track if the system is vulnerable or not.

Eventually you want an answer to a question: “Is there a system that is not being maintained and what risks it possesses?”

Depending on your organization size the inventory can be a text document or it can be bought commercial solution integrated directly to your development processes.

Updating software

When you either have “the one inventory” or multiple distributed inventories in place the next step is to sit down and think about following questions:

1. How often should I update software or their dependencies?
2. Where do I get trigger that I need to do it immediately?
3. Do I want to limit the amount of different technologies being used?
4. When I can update this system?
5. How do I test the system after it is being updated?

In multiple situations the best practice is to update early and often. There are still a cave at. If the update itself is malicious or if the update itself introduces new attack vectors then first ones to update gets the unwanted prize. Using PaaS or SaaS cloud software solves this because then updates done by cloud vendor and you get the “one version”.

IaaS, On-Premises or building your own software takes you immediately deeper into the thought process. Eventually you come to think about if you should take all the dependencies away. Well that seems to be impossible. You are unlikely to build your own BIOS, OS, CPU architecture, peripherals, drivers and whatnots that are used in the process. But you still need to think which parts you take as granted and what should you do yourself. Should I trust this random developer who has done this one open-source library that seems to be cornerstone of the whole ecosystem? What if the person is being intimated, bribed or the persons development equipment are being compromised? Well it is balancing act that you need to adapt to your threat models.

You might be also wondering that if somebody plants a malware or changes license (e.g. HashiCorp Licensing Firestorm Fuels Open Source Debate – forbes.com) terms of a component then could you update it or do you need to stay at older version? Another balancing act. Eventually majority of people would like to use components that have been already battle-proven by somebody else. But when new zeroday exploit is being patched then there is race against time to patch everything (thank you Log4Shell).

Identity and access management

In large environments where multiple different organizations are maintaining multiple different systems few cave-ats makes organizations vulnerable to attacks.

First of all it is easy to forget dormant accounts here and there waiting for somebody to steal them. Combined with bad password hygiene eventually it is likely that somebody has reused password and it will become known for some malicious actor via information disclosure in totally unrelated system.

Violating least privileges principle or not being able to timeframe access also makes it possible to attack. Blog from Cloud Security Alliance references 11 supply chain attacks in 13 months. Majority of these are about stolen tokens or exposed credentials. At the same time OWASP Top 10 has now “Broken Access Control” on top of the list of most common vulnerabilities in Web Applications. Limiting the time window of privileges with Privileged Identity Management system or limiting exposure of access with Just-In-Time and conditional access policies will make it harder and noisier for attacker to leverage the stolen identities.

Meanwhile also Identity providers like Okta has been targeted by attacks: October Customer Support Security Incident. 

Endpoint protection

Computers used by privileged users to build the system is something that you want to have an eye on. If software developers machine is compromised then there will be trust issues down the road. Can you trust anything that come out of the developers endpoint if it is compromised? Can you trust that it won’t be able to inject malicious content that will contaminate the build servers and actual runtime too?

But be aware. If you make too harsh restrictions it might be that people are not able to do their job or that they vote with their feet. Changing how laptops are being monitored might also need more than just technical implementation for example negotiation with the employees. 

Awareness is crucial

Understanding threats from vulnerable software components and different aspects of Identity Protection is crucial in being able to defend against supply chain attacks. Maintaining inventories and reminding system owners about their responsibilities can be tedious work. Understanding and building awareness helps in motivation.

This is why you should be open about the threats and build up threat models in your organization. We will talk about threat models at another day.