We're an RSA Conference 2024 Innovation Sandbox Finalist!

READ THE BLOG

Time and again, new vulnerabilities are discovered and published, just as we saw when VMWare announced new vulnerabilities in vCenter Server and Cloud Foundation in September. You are probably using these servers right now, in your network or cloud environments. These critical vulnerability disclosures do not offer a quick and easy patch – so if you are using either vCenter Server or Cloud Foundation, you must declare an emergency and treat it like you have already been compromised.  

According to Bob Plankers, Technical Marketing Architect at VMware, "This vulnerability can be used by anyone who can reach vCenter Server over the network to gain access, regardless of the configuration settings of vCenter Server." Plankers went on to add: "In this era of ransomware it is safest to assume that an attacker is already inside your network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible.”

An attacker can compromise VMware vCenter Server using CVE-2021-22005 (a critical vulnerability with a CVSSv3 score of 9.8), which is “a file upload vulnerability that can be used to execute commands and software on the vCenter Server Appliance.” Regardless of the configuration settings, anyone who can access vCenter Server over the network can get access. This allows attackers to perform other malicious actions in your environments.

This VMWare security advisory also included 18 other vulnerabilities in vCenter Server 7.0, many of which had important severity ratings. These vulnerabilities also apply to Cloud Foundation 4.x (vServer Center). Fixed versions are available for all of them, and workarounds are available for some.  

Patches aren't enough

Working exploits became publicly available quickly, helping attackers to quickly target unpatched environments, which is why patching is a critical step. Fortunately, there are also detection methods and indicators of exploit available that can help defenders as they seek to determine whether their organization has been exploited by attackers. However - just patching is not sufficient, as VMWare indicated quite clearly in the VMWare vulnerabilities case.

When you are thinking about known vulnerabilities, particularly ones that are severe and announced with no patch available, or when there is a patch that requires considerable resources to implement (and therefore take time to put in place), there is another aspect to consider. It's important to determine whether a cybercriminal has already used the vulnerability against you in the past. Asking this question leads to compromise assessments and threat hunts in your environment. If you assume that bad guys have already used the vulnerability against you, indicators of compromise or artifacts can help you to either prove the thesis or determine that it has not been used against you and eliminate it as a potential problem in your environment.  

Hunting for evidence of attacks

When you are focusing on a specific vulnerability, you should be looking for evidence of it being used, or for evidence of the next steps of the attack. For example, the VM security advisory warned about vulnerabilities in vCenter Server and Cloud Foundation, which have the potential to lead to a large variety of attacks. But how far back should organizations look for evidence of exploitation?

Should you look for evidence in just the last 10 days? Do you need to look a bit further, perhaps in the last 30 days? Or do you need to do a more in-depth investigation, analyzing your data for the last three years? It may not be possible to conduct as thorough an investigation as you might like, because there is often a limit on forensic data retention, and an in-depth investigation is challenging if not impossible without forensic data.

That lack of forensic data is a problem because we know that attackers sometimes get access to an environment or network and stay for extended periods of time. In that period, how can you tell what they might have done without forensics to follow the trail? Even if they did not stay in the system, it may be that an attacker had access in the past and left, leaving behind more potential weaknesses. To take control when a critical vulnerability is disclosed, such as the vCenter Server and Cloud Foundation disclosures, patching quickly is step one. Analyzing your forensic data will give you a much better picture of what has happened and how to fix it, which means that you need to store forensic data for longer periods of time than is common, especially in cloud environments.  

Ongoing data collection improves IR

Collecting data on an ongoing basis for effective incident response is really a step you need to take prior to the four step incident response life cycle that NIST lays out. It is part of an overall readiness approach that improves an organization’s resilience, whether it is facing a data breach, a ransomware attack, a distributed denial of service attack, or something else. Proactively storing forensic data helps investigators examine a situation so your organization can make informed decisions quickly and bounce back faster after an attack. Attackers are always looking for easy entry points, and quickly exploiting zero- and one-day vulnerabilities is expected behavior from cybercriminals. Shifting your organization to a readiness mindset will help reduce the impact of these types of vulnerabilities and create more resilience in the case of future attacks.  

Protecting your enterprise against one of tday's most dangerous cyberthreats: ransomware

LAST UPDATED:

April 20, 2024

Don't miss these stories:

Introducing Investigation Workbench

We’re proud to release Investigation Workbench, a first-of-its-kind cyber solution that provides instant clarity on all multi-cloud and Software-as-a-Service (SaaS) activities through a single pane of glass. This innovative capability further enhances Mitiga's IR2 Platform, the industry’s only complete cloud investigation and response automation (CIRA) solution.

How AWS EKS Pod Identity Feature Enhances Credential Management

This past week at re:Invent, AWS announced a very cool new product feature: EKS Pod Identity. As an AWS user, and specifically an EKS (Elastic Kubernetes Service) user, I spend a great deal of time connecting my pods and workloads to other AWS services and clusters in other regions and accounts, so for me, this feature arrives just in time.

Why Incident Response Retainers Don’t Work for Cloud—and What Does

Incident response (IR) retainers have been a staple for security teams for years. You pay an upfront fee to an IR firm to be "on call" if an incident occurs. The basic idea is that IR experts are ready to parachute in when disaster strikes.