WithSecure Elements Vulnerability to isolate all companies

Introduction

This blog post uncovers a serious bug in WithSecure Elements, detailing how a seemingly simple issue had a major impact. Exploiting this bug allowed us to isolate all machines in a company's network, leading to an unstoppable and devastating Denial of Service (DoS) attack. The incident highlights the importance of manual assessments, as automated scanners often miss such straightforward vulnerabilities.

From WithSecure's own page we can read that Withsecure Elements is "our single modular cyber security solution made up of a full range of cyber security applications. It includes our award-winning vulnerability management, patch management, endpoint protection, endpoint detection and response technologies, M365 coverage as well as cloud security posture management."

As part of their vulnerability research program, we concentrated on assessing the features of Endpoint Detection and Response. WithSecure quickly and correctly remediated the vulnerability once notified.

The Vulnerability

WithSecure Elements offers a platform featuring Endpoint Protection and Endpoint Detection and Response for safeguarding a company's fleet of machines. During our examination of their platform, we discovered a feature known as Automated actions. This functionality empowers users to automate responses on machines in the event of malware infection or similar threats.

The rules allowed are Device isolation when given a specific Risk level. In other words, this rule will automatically place a machine in network isolation when a specfic risk level has been reached.

When we send this request for adding the rule to the company and intercept it through Burp we can see the following request:

POST /proxy/ras/p/v1/<company_uuid>/scenarios HTTP/2
Host: rdr.elements.withsecure.com
Cookie: STRIPPED

{
   "action": {
      "type": "FULL_NETWORK_ISOLATION",
      "config": {
         "hosts": {
            "importance": ["NORMAL"]
         }
      }
   },
   "active": true,
   "applies_to": [
      {
         "customer_id": "<company_uuid>",
         "name": "SomeCompanyName"
      }
   ],
   "conditions": {
      "min_risk": 50
   },
   "continue_processing": true,
   "name": "Device isolation",
   "priority": 1,
   "schedule": {
      "type": "CONTINUOUS"
   }
}

But if we look at the following bit we can see that a applies_to is present:

"applies_to": [
   {
      "customer_id": "<company_uuid>",
      "name": "SomeCompanyName"
   }
],

This allows us to choose an arbitrary company_uuid and then put all company devices in isolation. Pretty severe. Yet, the UI suggests that device isolation is only possible for severity levels Severe, High, or Medium, restricting our impact. This limits our ability to affect everything in the machine. However, if we look at the previous request we notice the following:

"conditions": {
      "min_risk": 50
},

This flag controls the risk. Through testing, we found it can be set very low, impacting all machines with just an info event, which is likely sent by everything.

Now, we can isolate devices in a network remotely without prior privileges, using only the company uuid.

If administrators want to remove this rule after it's maliciously set on their company, they'll encounter the following blocking message:

This rule was created by another user.

In other terms, a complete DoS of the company that cannot be removed without super admin intervention.

Automated scanners

Automated scanners is missing contextualization. These issues seems obvious for seasoned attackers manually reviewing the code. However when using a automated scanned whether it is a State of the art™ scanner, it does not fare well against these bugs. This is due to most scanners being dependent on making a request and receiving a response.

What happens in this particular exploit is:

1. Attacker leaks a valid company uuid in a subsequent endpoint
2. Attacker knows from contextualization that the id in applies_to is a company uuid and can be switched
3. Attacker receives a HTTP 200.
4. Attacker can now see the effect that the machines are being isolated.

Almost every step in this way is trivial to seasoned attackers, but at the moment impossible for automated scanners to reason about. They are geared for vulnerabilities where you input something and immediately get something back.

Therefore it is crucial that you always make sure that your critical applications are manually assessed, which we can assist you with.