VMware customers had a very busy week due to the vulnerability of Apache Log4j 2, Nearly half of global enterprises are affected，According to a report provided by the Threat Intelligence Department of Check Point, a well-known network security solution provider , the Apache Log4j 2 vulnerability may persist. This means that VMware customers have to continue to deal with malicious attacks by hackers using Apache Log4j 2 vulnerabilities.

However, one wave is not flat, one wave rises again. According to the vulnerability security report released by VMware, although VMware fixed the vulnerabilities of 51 products since the 10th on the 17th, it still can not guarantee to completely solve the impact caused by Apache Log4j 2. On the 16th, VMware also reported a security vulnerability similar to Log4j, all by means of forged requests. Apache Log4j 2 can carry out malicious attacks, while VMware's vulnerability is to obtain sensitive information. The risk level of the vulnerability is 9.1 (out of 10 points), which is at the same high risk level as Log4j 2.

December 16 VMware vulnerability Security Report

The VMSA-2021-0029 security report released by VMware on the 16th involves CVE-2021-22054. The vulnerability describes a server-side forged request in VMware's Workspace ONE unified endpoint (UEM) product. The vulnerability is rated 9.1 in the general vulnerability scoring system, and the full score of the rating is 10, which means that if you ignore it, you will be miserable.

This vulnerability can allow malicious users with UEM network access to send requests without authentication, and use this vulnerability to obtain sensitive information of others. Since the UEM system manages tens of thousands of endpoints, malicious actors can obtain a large amount of sensitive information through this vulnerability, and VMware's UEM system can process and run Windows, macOS, ChromeOS, iOS, Android and loT devices. Therefore, if it is not repaired in time, it will have a great impact.

Image source VMware

Vulnerability resolution

VMware provides two solutions in the report, one is patch and the other is configuring web Config file, which requires only 7 lines of simple instructions. Of course, before the patch update mentioned in VMSA-2021-0029 is released, changing the application file of the product is only a temporary solution.

patch

There are versions of the patch. If the version you use does not apply to the patch, you need to update the version. If you want to know whether your current VMware UEM system is applicable, See WS1 UEM console publishing KB To get a list of all supported versions and their availability to SaaS and local customers.

Interim workaround - modify web Config file

You need to find the file to apply the changes according to the following xpath. Add the changed rewrite rule to the rule key (xpath: /configuration/system.webServer/rewrite/rules)

<rule name="Blob_Handler_Block" enabled="true" stopProcessing="true">
     <match url="^(Catalog|AirWatch)\/BlobHandler\.ashx" />
     <conditions>
         <add input="{QUERY_STRING}" pattern="(&amp;url|^url)=" />
     </conditions>
     <action type="CustomResponse" statusCode="404" statusReason="Security" statusDescription="Resource not found" />
</rule>

Note: you should repeat this step on each Windows Server in the environment where UEM Console application is installed. After saving the above changes, restart the system. After all server instances are patched with the solution, next verify whether the solution is successful.

If your configuration file does not contain system Webserver section, the following is a complete rewriting example.

<system.webServer>
    <rewrite>
        <rules>
            <rule name="Blob_Handler_Block" enabled="true" stopProcessing="true">
                <match url="^(Catalog|AirWatch)\/BlobHandler\.ashx" />
                <conditions>
                    <add input="{QUERY_STRING}" pattern="(&amp;url|^url)=" />
                </conditions>
                <action type="CustomResponse" statusCode="404" statusReason="Security" statusDescription="Resource not found" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

How to validate the solution

The solution blocks any access to the BlobHandler. Any request with blocking mode will result in a web page 404 Not Found response. To test the solution, you need to open your browser and navigate to the following web address:

https://<UEM Console URL>/airwatch/blobhandler.ashx?url=test
https://<UEM Console URL>/catalog/blobhandler.ashx?url=test
https://<UEM Console URL>/airwatch/blobhandler.ashx?param1=test&url=test
https://<UEM Console URL>/catalog/blobhandler.ashx?param1=test&url=test

Note: if the server is configured to automatically redirect when 404 responds, you may see the web page redirected to the console login page.

Impact of change on workspace

When searching for a public application on the console screen, the application icon will not be displayed. System reset will cause the logged in server instance administrator to be logged off. Of course, administrators can log back in soon. Therefore, it has no impact on the managed devices

Reference link: VMSA-2021-0029