On March 29, 2022, Trend Micro released a security advisory for a remote code execution vulnerability affecting Apex Central. The vulnerability allegedly allows a remote and unauthenticated attacker to upload an arbitrary file resulting in code execution. Trend Micro assigned this vulnerability, CVE-2022-26871, a CVSSv3 score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H), which is largely inconsistent with remote code execution.

On March 31, 2022, Trend Micro updated their advisory to indicate they had observed “an active attempt of exploitation against this vulnerability in-the-wild … in a very limited number of instances”. At this time, there are no other public reports of successful exploitation or even exploitation attempts. No public proof of concept exploit exists.

While Trend Micro reports exploitation in the wild, widespread exploitation is unlikely. Largely because there are so few internet facing instances, that it would be a stretch to call anything affecting them widespread. Scanning for the software is hindered by the fact that requests to “/” do not forward to the application’s login page, and instead resolves to the default IIS landing page. However, using the default SSL certificate, Shodan shows less than 100 of these are online. Also, Trend Micro reports all SaaS instances were patched on March 9, 2022 (20 days before disclosure).

Assumptions

Unfortunately, the description of CVE-2022-26871 provided by Trend Micro does not contain the actual attack vector:

An arbitrary file upload vulnerability in Trend Micro Apex Central could allow an unauthenticated remote attacker to upload an arbitrary file which could lead to remote code execution.

Apex Central is much more than just a web server. It’s composed of multiple binaries, a number of which are listening for remote connections.

There are two hints that the arbitrary file upload issue is in the web server though. The first is thanks to the product advertisements they’ve placed in their advisory. One IPS rule specifically calls out “HTTP” in the name.

The other hint is in the CVSSv3 vector that Trend Micro created. Every part of Apex Central is running as NT AUTHORITY\SYSTEM except the web server. The web server is configured via IIS to run as NT AUTHORITY\NETWORK SERVICE. I assume that Trend Micro used this lower privileged user to justify the scores of C:L and I:L.

Although, if that is the case, that is absolutely incorrect. C:L and I:L are reserved for cases where no “direct, serious” impact/loss occurs. Attacker execution as NT AUTHORITY\NETWORK SERVICE is C:H and I:H as it does allow an attacker to affect “direct, serious” impact/loss.This is still true even if the attacker is NT AUTHORITY\iusr (see below). It is not lost on the writer that the published vector is scored 8.6 (high) and not 9.8 (critical) as it appears it should be. Of course, there may be mitigating factors to justify the lower score, but those details aren’t offered anywhere in the scant advisory.

Assuming the vector is the web server also leads me to assume the uploaded file is a web shell. This could be completely wrong, but Trend Micro offered no CWE or any other insight so it’s a reasonable starting point. Apex Central’s web content uses ASP, PHP, and compiled exe/dll cgi so there is opportunity for a webshell. However, I also assume that directory traversal is required. Some (not all) of the uploaded content will be placed in an App_Data directory, but executing PHP/ASP out of this path is denied.

But if the attacker can escape upwards, they are free to execute their webshell.

It’s also important to note that Apex Central is strict about file extensions. This is not a scenario in which we can upload r7.gif and still execute PHP. The extensions have to be correct or they won’t be executed:

C:\Users\albinolobster>curl --insecure https://192.168.1.237/webapp/r7.gif
<?php echo(exec("whoami")); ?>

C:\Users\albinolobster>curl --insecure https://192.168.1.237/webapp/r7.png
<%
Set rs = CreateObject("WScript.Shell")
Set cmd = rs.Exec("cmd /c whoami")
o = cmd.StdOut.Readall()
Response.write(o)
%>

In summary, I assume this arbitrary upload vulnerability is a webshell upload where the attacker controls the file path (either absolutely or via path traversal) and the file extension of the created file.

Hunting for the Vulnerability

We were able to acquire two versions of on-prem Apex Central in order to hunt for CVE-2022-26871: the recently patched “Build 6016” and a much older “Build 3752”. The large time gap between versions does not work in our favor, but it’s enough to start with.

The obvious starting point is to find the locations where file upload is allowed, but this is where things start to go off the rails. While there are many places that implement file upload functionality, they largely seem to require authentication. There are a couple of PHP files that allow upload via $_FILES, but they are strict on the file extension and don’t appear to move the file out of upload_tmp_dir which is configured as C:\Program Files (x86)\Trend Micro\Control Manager\PHP\upload_tmp_dir, a path that is outside of the webroot. Here is an example of one of the unexploitable PHP file uploads (https://host/webapp/widget/repository/widgetPool/wp1/widgetComponent/comEEFDE/tmee/uploadfile.php):

<?php

if(isset($_FILES['image']))
{
    $allowed_ext= array('jpg','jpeg','png','gif');
    $file_name = $_FILES [ 'image' ] [ 'name' ] ;
    $file_ext = strtolower( end(explode('.',$file_name)));
    $file_size=$_FILES['image']['size'];
    $file_tmp= $_FILES['image']['tmp_name'];

    $type = pathinfo($file_tmp, PATHINFO_EXTENSION);
    $data = file_get_contents($file_tmp);
    $data = base64_encode($data);

    if(in_array($file_ext,$allowed_ext) === false)
    {
        $error_Msg ='ext_not_valid';
    }
    else if($file_size > 131072)
    {
        $error_Msg = 'size_too_big';
    }
    else
    {
        $error_Msg = 'success';
    }


    $json_data = array("errorMsg"=>"");

    $json_data["errorMsg"] = $error_Msg;
    $json_data["base64"] = $data;

    $json_data = json_encode($json_data);
    header("Content-Type: text/html; charset=utf-8");
    echo rawurlencode($json_data);
}

?>

Apex Central is also fairly meticulous about catching directory traversal issues. In fact, the diff between the two versions that we have showed the developers introducing traversal checks in places that already had traversal checks. The image below shows WebApp/html/suspiciousObjects/ImportFileHandler.php. Note the original on the left already uses the isDirectoryTraversalOrInvalidExtension call to both check for path traversal and ensure the file extension is csv (ruling out exploitation), but they also add an additional traversal check on the right.

This is actually a recurring theme throughout the code base. It’s almost as if someone was assigned the task of applying additional “..” logic to every user controlled filename, and carried out that task whether it was needed or not (which, honestly, isn’t the worst thing). Although some places really did need it. From sCloudService.cs (although this required authentication):

The code base is also fairly good about not using attacker provided file names, and instead preferring hashes or GUID. Here is an example from YARA file upload where the name and contents are hashed to generate a new filename before the file is dropped to disk for validation by yara.exe (from WebAPIIOCsUtility.NET.dll):

Throughout the code base, these three conditions (unauthenticated, traversal, and file extension control) appear to be kept in check by the developers. Using the two versions we have I was unable to pinpoint a vulnerable location. It could be that our old version is too old, and we were doomed from finding the vulnerability from the beginning. Trend Micro did not say which versions, specifically, were affected so it’s hard to know. It could also be that I’ve overlooked the issue. Or it could be that my original assumptions were bad. Regardless, I didn’t find the issue, but hopefully this is useful to someone.

Summary

While I didn’t find the vulnerability myself, nor does Trend Micro give solid information on how to identify potential exploitation, I think you can reasonably assume the following things will aid in preventing or catching exploitation:

• Keep the system away from the internet.
  
• Patch if possible.
  
• Monitor for web shell creation in the C:\Program Files (x86)\Trend Micro\Control Manager\WebUI\WebApp and it’s subdirectories.
  
• Monitor from malicious behavior originating from w3wp.exe (IIS Worker).