Silver Peak Unity Orchestrator RCE

Ariel Tempelhof
Realmode Labs
Published in
3 min readNov 8, 2020

SD-WAN is a big deal. Gartner calls it the “replacement for traditional WAN routers”. But with great power comes great responsibility. Here at Realmode Labs, we researched the top four SD-WAN products on the market and found major remote code execution vulnerabilities. The vulnerabilities require no authentication whatsoever to exploit. In the best case scenario, an attacker can use these vulnerabilities to intercept or steer traffic. However, if an attacker desires, they can instead shutdown a company’s entire international network.

This is a four part series — in each post we’ll disclose another vulnerability in a major SD-WAN vendor. First up is Silver Peak. Gartner calls Silver Peak a “leader in the Magic Quadrant for WAN Edge Infrastructure” and they were recently acquired by HPE. But are they secure?

SD-PWN Part 1 — Silver-Peak Unity Orchestrator

Silver Peak is mostly remembered by us for having the best commercials of the lot:

First, some background. These vulnerabilities are in the Silver-Peak SD-WAN Orchestrator. An Orchestrator is the main management interface centrally controlling the SD-WAN topology of the company. This is obviously a crucial point from a security perspective. In order to gain remote code execution we discovered three different CVEs which join together to allow an attacker to SD-PWN the network.

Apart from Wayne McFarkus, examining Silver-Peak Unity Orchestrator revealed that the system runs on CentOS with JAVA applets running as the web server.

Authentication Bypass — CVE-2020–12145

Looking at the code handling the API calls, we’ve noticed special treatment for API calls originating from localhost where no authentication is being performed. Putting aside that this is probably a bad idea (it can really help in case of SSRF), after further examination we reached the point where the localhost check is being performed:

request.getBaseUri().getHost().equals(“localhost”)

Any requests with “localhost” as their HTTP Host header will satisfy this check. This can be easily forged in remote requests of course.

File Delete Path Traversal — CVE-2020–12146

Some of the API endpoints, which are now accessible thanks to the authentication bypass, allow the ability to upload debug logs to an S3 bucket to be examined by Silver Peak. This mechanism prepares the logs, uploads them and then deletes the locally hosted file. The /gms/rest/debugFiles/delete endpoint performing the deletion does not check for path traversal, creating the ability to delete any file on the system (if permissions allow).

Arbitrary SQL Query Execution — CVE-2020–12147

A special API endpoint exists to run arbitrary SQL queries. This endpoint is accessible only by localhost but same as in the Authentication Bypass this can be easily executed remotely.

The /gms/rest/sqlExecution endpoint can be leveraged to an arbitrary file write by utilizing an INTO DUMPFILE clause. INTO DUMPFILE does not allow overwriting a file but one can use the “File Delete Path Traversal” issue to first delete the file and then rewrite it.

Full RCE Chain

We didn’t find straightforward shell injections. But, by utilizing the three vulnerabilities, one can run arbitrary code using the following steps:

  1. Look for a file being run by the web server
  2. Delete it using the File Delete Path Traversal issue
  3. Recreate it using the SQL Query Execution endpoint
  4. Trigger the execution of the file

One such file found by us is /home/gms/gms/phantomGenImg.js. It’s part of a report generation process and it’s being run by PhantomJS. PhantomJS contains the child_process module making it possible to run arbitrary shell commands on the system.

The Script:

All issues found were disclosed to the respective vendors and resolved by the time of publication.

If you want to hear about the next SD-PWN vulnerability before everyone else then make sure you follow us on LinkedIn or contact us at contact@realmodelabs.com

--

--