Skip to content

Unauthenticated Command Injection Vulnerability in VMware NSX SD-WAN by VeloCloud

Unauthenticated Command Injection Vulnerability in VMware NSX SD-WAN by VeloCloud

Exploits for network devices including routers, switches, and firewalls have been around for as long as networking has been a thing. It seems like every week a researcher discloses a new vulnerability or publishes proof of concept (PoC) code online for these types of devices, and that is exactly what is happening in this article. Today, we walk through the discovery of an unauthenticated command injection vulnerability discovered by myself and the TEAMARES penetration testing team during a recent engagement.

We began our reconnaissance by probing external IPs and we quickly stumbled upon an NSX SD-WAN by VeloCloud that was quite interesting. The device required no authentication to access the web UI and disclosed sensitive information such as internal IP addresses. Diving further into the device we found that it has a nice diagnostics functionality that allows users to troubleshoot network connectivity and retrieve other metrics directly from the device. Naturally, the team decided to test the device to see if it could be exploited as an initial entry point to pivot into the organization’s internal network from the WAN.

After identifying a potential pivot point, we start by researching the device to see if any vulnerabilities have been announced by the vendor or if anyone has published an exploit/PoC code online. The device being targeted was updated to the latest version (3.1.1), which patched the existing vulnerabilities announced by VMware. No PoC code or exploits existed for version 3.1.1 yet, so we set out to find a new vulnerability in the device and create an exploit that would allow us to breach our target.

Redirecting our attention back to the previously mentioned diagnostic functions, we first targeted the Traceroute tool, since the input field would accept either an IP address or a hostname, with the thought that since the field would accept both, it might be easier to break out of due to less strict sanitization of user input.

Figure 1 – Screenshot of the Traceroute Diagnostic Function

The team’s assumption here was that the user input would be passed to the underlying operating system as a command to perform a traceroute. Since many network appliances run on some sort of embedded Linux, we worked towards breaking this command using Linux-friendly escapes to inject malicious commands. Once the proper escape characters were identified $(<COMMAND>) the HTTP request was loaded into Burp Suite’s Repeater. Success.

Figure 2 – HTTP Request in Burp Suite Containing PoC Exploit

In the screenshot above you can see that the code is being injected just after the IP address. The code executes the Linux command “id” (which prints out information as the current user) and returns the output of the command to a server under our control via a netcat connection. On the receiving end, a netcat listener was opened prior to submitting the POST Request to catch the output.

Figure 3 – Output of ‘id’ Command Returned to a netcat Listener

From this output, we learned that commands were being executed as the user “root”. Perfect. This code is just a quick PoC to show that it was vulnerable and exploitable. Since these commands are running as root, the possibilities are endless, and a malicious actor would have complete control of the device at this point.

But Why Did This Work?

After investigating the code running on the device itself, we discovered that the utilities and scripts were written in the Lua language. Lua is a powerful language, useful for experienced programmers, but it is considered easy for less experienced programmers at the same time. While researching vulnerabilities and exploits for systems running things written in Lua we found a write-up on seclists.org with great examples that thoroughly explained the vulnerabilities and how to exploit them, including vulnerable code samples (Link: http://seclists.org/fulldisclosure/2014/May/128 ).

From the seclists write up:

“OS COMMAND INJECTION

OS command injection flaws (CWE-78) allow attackers to run arbitrary commands on the remote server. Because a command injection vulnerability may lead to compromise of the server hosting the web application, it is often considered a very serious flaw. In Lua, this kind of vulnerability occurs, for example, when a developer uses unvalidated user data to run operating system commands via the os.execute() or io.popen() Lua functions.”

In the example code following the description above, a reader can clearly see where the injection point exists at the os.execute Lua function.

Vulnerable code examples:

Reporting and Patching

VMware has released a patch to address this vulnerability. Remediation actions required for affected devices including updating to version 3.1.2. Details can be found in the VMware Security Advisory VMSA-2018-011.1.

CyberOne’s TEAMARES penetration testing team followed responsible disclosure procedure by submitting the vulnerability to VMware’s Security Response Center, and waiting for a patch to be released for the affected devices before publishing any information. The vulnerability was also disclosed independently to VMware by security researcher Brian Sullivan from Tevora.