Last updated at Wed, 27 Dec 2023 14:51:44 GMT

Over the course of routine security research, Rapid7 researchers discovered that the Akkadian Provisioning Manager version 4.50.18, a provisioning solution for a Cisco Unified Communications environment, has a trio of vulnerabilities, which, when combined, can lead to remote code execution on the affected device with elevated privileges. Those issues are summarized in the table below.

In addition to these issues, two other questionable findings were discovered: the ability to read the cleartext local MariaDB credentials, and the inadvertent shipping of an entire GitHub repo with commit history. At the time of this writing, it's unclear if these findings present unique security issues, but nonetheless, should be reviewed by the vendor.

Product Description

Akkadian Provisioning Manager (PME) is a management platform for Cisco Unified Communications (UC) devices and applications, which are largely VoIP and video solutions for communications. PME is usually seen in larger enterprises where provisioning and reconfiguring these solutions is a fairly common occurrence. More can be learned about Akkadian PME from the vendor's website.

Credit

These issues were discovered by Cale Black, Ryan Villarreal (@XjCrazy09), and Jonathan Peterson (@deadjakk) of Rapid7, and it is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Exploitation

The following were observed and tested on version 4.50.18 GA 2020-04-07 - Build 1.1.36 (Linux) of the Akkadian Provisioning Manager (PME).

CVE-2021-31579: Use of Hard-Coded Credentials

During a penetration test on a client site, Rapid7 researchers were able to gain access to a PME OVA virtualized appliance and was able to interrupt the boot process and force the init system to be an interactive shell, as can be seen below:

This successfully presented Rapid7 researchers with a root shell environment:

Once shell access was achieved testers identified the enabled `akkadianuser` in the user /etc/passwd database:

Investigating the user home directory revealed a set of developer files on the production server:

Rapid7 researchers identified developer configuration scripts for configuring a high availability user, /home/akkadianuser/scripts/create_haakkadianuser.sh and /home/akkadianuser/tmp/akkappmanager_installation/scripts/create_haakkadianuser.sh. These scripts revealed that the high availability user was created with the default password `haakkadianpassword` as can be seen below:

Using the knowledge of the created high availability user password, Rapid7 researchers were able to successfully guess the credential of the existing `hakkadianuser` user, which was `hakkadianpassword`. Rapid7 was able to verify this credential would give access to the Akkadian PME restricted shell:

Rapid7 was then able to successfully bypass the restricted shell menu environment via the techniques described below, CVE-2021-31580 and CVE-2021-31580, and identified that the running `akkadianuser` user was given unrestricted sudo privileges without a password:

This was confirmed by using the shell escapes with the sudo command, allowing Rapid7 researchers full access to the root user:

CVE-2021-31580: Shell Escape via 'exec' command

Rapid7 researchers identified that the restricted shell in use by the Akkadian Appliance Manager component of the PME was not directly set to the restricted shell binary, and instead was set to bash, and could be bypassed by the procedure outlined below. First, the default bash shell was observed:

The restricted shell environment is triggered via the /home/akkadianuser/.bashrc configuration file which invokes the `akkadianAppManager` shell via sudo:

Knowing that the shell was bash and that the python restricted shell environment was interactive, Rapid7 researchers switched the OpenSSH channel from `shell` to `exec` by providing the ssh client a single execution parameter. This triggered the interactive Python script to unsuccessfully find the `/dev/tty` file and exit, but as the shell is running in the context of a bash shell, the failed exit condition does not fail the parent shell and the command is passed on through to the operating system allowing a bypass, as shown below.

Combining this issue with the default hard-coded root user, hakkadianuser:hakkadianpassword, will allow an otherwise unauthenticated, network-based attacker with unrestricted access to an interactive shell with root privileges.

CVE-2021-31581: Shell Escape via 'vi' editor interface

Rapid7 researchers identified that the restricted shell environment of the Akkadian Appliance Manager component of the PME could be bypassed using the shipped version of `vi`, a popular terminal-based text editor. When authenticated, normally, the following prompt is shown:

Select 4: Product Settings Menu and the next set of options gets prompted:

Select 1: Akkadian PM/HCS Services and the next set of options appears:

Select 2: MySQL Service option and follow to the next screen:

Select 4: Edit MySQL Configuration (my.cnf), which finally drops the user into a vi editor interface for `/etc/my.cnf`:

This can be bypassed by using the execution functionality in the shipped version of `vi` on the PME by hitting `:!` and then the desired command. The following screenshot shows that the restricted shell is running as the root user (due to the sudo invocation of the shell as mentioned in CVE-2021-31580):

Combining this issue with the default hard-coded root user, hakkadianuser:hakkadianpassword, will allow an otherwise unauthenticated, network-based attacker with unrestricted access to an interactive shell with root privileges.

CVE-2021-31581: Exposure of Sensitive Information

Rapid7 researchers also identified that the application was serving sensitive data via the exposed web server. Listing the `/var/www/html/pme/` directory Rapid7 identified the ionCube packed PHP files, but an additional set of files that were marked with readable permissions:

Many of these files contained sensitive data that was accessible via the web server. Of note the `/pme/database/pme/phinx.yml` file contained cleartext local MariaDB usernames and passwords:

Rapid7 researchers were able to use local shell access in order to successfully validate that these credentials were valid and worked to connect to the underlying MariaDB host listening locally. The scope of the original client's penetration test additionally included an LDAP integrated environment, and this issue was leveraged to successfully recover cleartext LDAP BIND credentials from the database:

Additional Finding: Shipping Git Repository (No CVE ID)

The web server additionally exposed a git repository `.git/` directory. This was verified by visiting `/pme/.git/config` which exposed information about the ionCube packed Akkadian PME repository:

Due to the predictable structure of git repositories, Rapid7 was able to extract the repos directly from the exposed network facing web server:

Rapid7 then extracted each of the commits and was able to view additional files and the ionCube encoded backend PHP files, both historical and current:

While this git structure does seem to include sensitive information, Rapid7 researchers did not validate if that information was useful to an attacker. In any event, it should be removed from production installations of Akkadian devices.

Impact

As mentioned previously, combining CVE-2021-31579 and either CVE-2021-31580 or CVE-2021-31581 will allow an otherwise unauthorized attacker complete, root-level shell access to the affected devices; this can open a door to installing cryptominers, keystroke loggers, persistent shells, and any other type of Linux-based malware.

While further access to the Cisco Unified Communications environment appears technically possible, it appears unlikely that real time or recorded calls or conferences could be gathered directly from these compromised devices.

Remediation

For the first issue, network access to the SSH port (22/tcp) should be limited only to trusted users, and certainly not exposed to the internet. Furthermore, system operators should know that, in the absence of a fix, users who have access to the Akkadian Appliance Manager effectively have root shell access to the device, due to the second and third issues described above.

Rapid7 researchers have attempted to communicate with Akkadian Labs, but were unable to elicit a response to this vulnerability disclosure. Customers should seek out their sales representatives to inquire about a fix timeline, after ensuring only authorized users have access to affected devices' SSH ports.

Disclosure Timeline

January, 2021: Issues discovered by Rapid7 researchers Cale “poptart” Black, Ryan Villarreal, and Jonathan “deadjakk” Peterson

Wed, Feb 3, 2021: Initial disclosure attempt to the vendor, ticket 51058 created.

Mon, Feb 22, 2021: Followup to the vendor via support ticket

Wed, Mar 10, 2021: Second followup to the vendor via support ticket

Tue, Jun 8, 2021: Public Disclosure

Wed, Jun 11, 2021: Vendor provided information about fixes

Update: On June 11, 2021, the vendor reached out to Rapid7 and provided information regarding fixed versions of the components tested. On June 16th, it was determined that the issues described here are resolved in the following components and versions: Akkadian OVA appliance version 3.0 (and later), Akkadian Provisioning Manager 5.0.2 (and later), and Akkadian Appliance Manager 3.3.0.314-4a349e0 (and later).