CVE-2020-15589.md

CVE-2020-15589

A design issue was discovered in GetInternetRequestHandle, InternetSendRequestEx and InternetSendRequestByBitrate in the client side of Zoho ManageEngine Desktop Central 10.0.552.W. By exploiting this design issue, an attacker-controlled server can force the client to skip TLS certificate validation, leading to a man-in-the-middle attack against HTTPS and unauthenticated remote code execution (RCE).

"Desktop Central is a unified endpoint management (UEM) solution that helps in managing servers, laptops, desktops, smartphones, and tablets from a central location. It's a modern take on desktop management that can be scaled as per organizational needs.

Desktop Central augments a traditional desktop management service, offering more depth and customization. Automate regular endpoint management routines like installing patches, deploying software, imaging and deploying OS. In addition, it also lets you manage assets & software licenses, monitor software usage statistics, manage USB device usage, take control of remote desktops, and more."

Successful exploitation of CVE-2020-15589 allows attackers to eavesdrop on and modify traffic exchanged between a client and the Desktop Central server. As a direct consequence of the attacker's ability to modify traffic, it will be made possible to distribute malicious updates (settings, configurations, executables) to any affected client. This will lead to unauthenticated remote code execution with SYSTEM privileges. In order to exploit this issue, an attacker must be able to redirect vulnerable clients to an attacker-controlled server, for example by conducting a DNS poisoning attack.

After five (consecutive) failed attempts of sending a POST request to the Desktop Central server via HTTPS, the Desktop Central client falls back to using an unsafe mechanism. From there on, the client will be accepting any invalid TLS server certificate by design. The Desktop Central client does so by creating a Windows Registry setting named "EnableCertFlag", which is set to "1" by default (potential IOC):

if ( WinHttpSendRequest(hRequest, 0, 0, v34, v35, v35, 0) )
{
  if ( *(_DWORD *)dword_89F9C8 )
    writeValue(HKEY_LOCAL_MACHINE, ArgList, (int)"CertMETrackingAdded", 0, 4u);
}
/* ### sending of POST request failed... ### */
else
{ 
  last_error = GetLastError();
 
  /* ### wrong certificate ### */
  if ( last_error == ERROR_WINHTTP_SECURE_FAILURE )
  {
    cert_flag = 0;
    ReadDwordRegistryData(HKEY_LOCAL_MACHINE, ArgList, "EnableCertFlag", (LPBYTE)&cert_flag);
    if ( cert_flag )
      goto LABEL_133;
    dbg_log("InternetSendRequestEx : Enabling Certificate ignore flags \n", v66);
    
    /* ### enable a registry setting that will cause certificate checks to be bypassed ### */
    writeValue(HKEY_LOCAL_MACHINE, ArgList, (int)"EnableCertFlag", (int)"1", 4u);    
    last_error = CertRecoveryMechanism((int)&hRequest, 0, 0, v34, v35, v35, 0, Buffer, 0);
  }
  if ( last_error )
    goto LABEL_133;
}

In subsequent calls to GetInternetRequestHandle/InternetSendRequestEx/InternetSendRequestByBitrate by the client, a function GetSecFlags() is responsible for checking this "EnableCertFlag" Registry setting. If it's non-zero, a combination of flags is returned.

unsigned __int32 __cdecl GetSecFlags(unsigned __int32 flags)
{
  unsigned __int32 result; // eax
  BYTE Data[4]; // [esp+0h] [ebp-4h] BYREF

  *(_DWORD *)Data = 0;
  ReadDwordRegistryData(HKEY_LOCAL_MACHINE, ArgList, "EnableCertFlag", Data);
  if ( *(_DWORD *)Data )
  {
    sub_6A39B0("GetSecFlags: Ignoring Certificate check flags added for communication \n");
    result = flags | SECURITY_FLAG_IGNORE_CERT_DATE_INVALID|SECURITY_FLAG_IGNORE_CERT_CN_INVALID|SECURITY_FLAG_IGNORE_WRONG_USAGE|SECURITY_FLAG_IGNORE_UNKNOWN_CA;
  }
  else
  {
    sub_6A39B0("Security certificate installed, so validating certificate AND Certificate flags are ignored \n");
    result = flags;
  }
  return result;
}

The combination of flags (SECURITY_FLAG_IGNORE_CERT_DATE_INVALID, SECURITY_FLAG_IGNORE_CERT_CN_INVALID, SECURITY_FLAG_IGNORE_WRONG_USAGE and SECURITY_FLAG_IGNORE_UNKNOWN_CA) returned by the call to GetSecFlags() is applied by the WinHttpSetOption() API function which then causes any TLS server certificate errors to be ignored by the Desktop Central client:

security_flags = GetSecFlags((_DWORD *)security_flags);
if ( WinHttpSetOption(hRequest, WINHTTP_OPTION_SECURITY_FLAGS, &security_flags, 4u) )

This allows attackers to conduct man-in-the-middle attacks on any vulnerable Desktop Central agent. As a consequence, the designated Desktop Central server can be impersonated with an attacker-controlled custom server. Application protocol compatibility given, any such custom server will also be given the ability to distribute arbitrary (update/troubleshooter) executables and server configuration to affected clients. Any newly received server configuration is applied persistently by affected Desktop Central clients, which represents a complete takeover of the client that will then no longer be able to commmunicate with its designated server. Executables distributed to affected clients are executed with SYSTEM privileges by default.

"PwnCentral" is an example implementation of a custom server that exploits this and other Desktop Central vulnerabilities and can be found here.

Disclosure Timeline:
2020-07-04 - Vulnerability reported to vendor
2020-07-07 - Vulnerability acknowledged by vendor
2020-10-05 - Public Disclosure (fix available, in reference to https://www.manageengine.com/products/desktop-central/untrusted-agent-server-communication.html)