Lucene search

K
wallarmlabIvanwallarmWALLARMLAB:7A0E7E3752712070F3E75CEF26AC2CC0
HistoryMar 08, 2021 - 8:22 p.m.

Why WAFs can’t catch VMware CVE-2021-21972 Remote Code Execution Exploit?

2021-03-0820:22:27
Ivanwallarm
lab.wallarm.com
316

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

10 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:N/AC:L/Au:N/C:C/I:C/A:C

The recent critical security issue in VMware vCenter was discovered this January and fixed on February 23rd <https://www.vmware.com/security/advisories/VMSA-2021-0002.html&gt;. The exploit looks like a simple JSP shell upload, but for some reason, it's a blind spot for Web Application Firewalls (WAFs). Let's understand why.

The CVE-2021-21972 affects vCenter versions 6.5, 6.7, and 7.0. The exploit for Metasploit released <https://vulners.com/packetstorm/PACKETSTORM:161695&gt; today.

The exploit description is pretty straight forward "This module exploits an unauthenticated OVA file upload and path traversal in VMware vCenter Server to write a JSP payload to a web-accessible directory. ". It should be something like a classic web shell file upload issue from the 90th.

This issue's root cause is behind an unauthenticated OVA upload endpoint on the "/ui/vropspluginui/rest/services/uploadova" URL. But the neat thing is that the payload itself is delivered inside the TAR file package and uses path traversal trick inside.

This part of the exploit source code explains it:

# HACK: Spray JSP in the OVA and pray we get a shell...  
Rex::Tar::Writer.new(ova_file) do |tar|  
jsp_paths.each do |path|  
# /tmp/unicorn_ova_dir/../../&lt;path&gt;  
tar.add_file("../..#{path}", 0o644) { |jsp| jsp.write(payload.encoded) }  
end  
end  

As we can see, a JSP file with a web shell inside added to the TAR achieve with the path traversal attack vector in a file path. As a result, VMware vCenter software extracts the JSP web shell from the TAR file to the webserver's "resources" or "statsreport" folder. Once uploaded, the web shell is available by a direct HTTP request.

So, what happens with WAFs in this case? An answer is simple, and it's encoding. Since malicious payloads like web shell JSP body and path traversal attack in a filename encoded by TAR file format, WAF can't see it. For web application firewalls, it's just binary data that goes to the webserver and nothing more. To catch such cases, WAFs should be able to decode TAR files on a flight, unpack them, check for malicious payloads, and only after that sends to a protected webserver or API gateway.

Unfortunately, not all the WAFs support TAR encodings, as well as JSON, GZIP, XML, and a bunch of more usual web data formats.

To mitigate this issue, we recommend applying a virtual patch for the "/ui/vropspluginui/rest/services/uploadova" endpoint.

Stay secure!

The post Why WAFs can't catch VMware CVE-2021-21972 Remote Code Execution Exploit? appeared first on Wallarm.

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

10 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:N/AC:L/Au:N/C:C/I:C/A:C