CVE-2024–20492 — A Privilege Escalation in Cisco Expressway

CVE-2024–20492 — A Privilege Escalation in Cisco Expressway

By Wyatt Dahlenburg

Summary

As a large company, State Farm writes our own software and also uses many third-party products. Our Offensive Security teams are responsible for testing applications, networks, and services to help keep our customer’s data secure. We actively work with vendors to help remediate vulnerabilities that we identify.

CVE-2024–20492 was identified against Cisco Expressway by the Penetration Testing Team at State Farm, where an official fix from Cisco was made available after disclosure to Cisco’s Product Security Incident Response Team (PSIRT). A privilege escalation vulnerability was present in the restricted Tandberg shell that enabled administrators with read-write privileges to obtain root privileges.

Cisco Expressway is a series of appliances that support collaboration services. The software is typically deployed to bridge internal and DMZ networks. Due to the network access this software could make for a valuable target for attackers.

Note that a read-write administrator has the permission to reset the software and set a new root password. This vulnerability avoided resetting application settings and passwords, which provided a stealthier approach to obtaining root permissions over an Expressway host.

The security advisory from Cisco can be found here: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-expw-escalation-3bkz77bD

Discovery

One of the techniques used during the early stages of pentesting is called application mapping. The process serves to explore every bit of functionality that an application exposes and to take detailed notes on interesting behavior. While mapping a test deployment of Expressway applications as an administrative user, two components were notable. The first was SSH was enabled and logged users into a restricted shell, which was known as the Tandberg shell. The second was the web application allowed for system snapshots to be taken which downloaded verbose system settings and files.

The restricted Tandberg shell provided a limited subset of commands compared to a standard Bash shell. The CLI, web application help pages, and public documentation could be referenced to see what commands the Tandberg shell supported.

The supported commands had many subcommands to perform various functionality such as configuring the Expressway application or viewing existing settings. The xCommand command enabled read-write admins to perform most of the same actions that could be done through the web application.

There are many techniques for attempting to escape a restricted shell. A common goal of an attacker is to break out of a limited shell context and execute arbitrary OS commands. Basic examples are to SSH with a user-supplied command (ssh user@host /bin/bash) or to abuse the restricted shell syntax.

The xCommand command supported several subcommands that read and wrote files to the underlying OS. This was surprising behavior as only the root user would be aware of the OS file structure. The root user would login to a Bourne shell (/bin/sh) by default. Other users that logged in via SSH would be restricted to the Tandberg shell and would be unable to list directory contents or change the working directory.

The xCommand HttpAllowListExportTest command accepted an arbitrary file that would write a CSV with allow list rules. The accompanying command to generate the rule set was xCommand HttpAllowListTestAdd which accepted several arguments:

• URL: URL to be allowed/blocked
• HttpMethod: OPTIONS/GET/HEAD/POST/PUT/DELETE
• ExpectedResult: allow/block
• Description: A text description of the rule

Through trial and error, it was determined that the HttpAllowListExportTest subcommand could be used to write arbitrary files on the OS. Note that portions of the OS were mounted on a read-only filesystem, which prevented critical OS files like those in /etc and /var from being overwritten. The documentation noted that only the /tmp directory should be written to but the subcommand did not enforce this restriction. The export subcommand additionally did not restrict the name of the file that was written, which could be used to omit the intended *.csv extension. Due to a CSV being written the CSV headers were included in the file output which prevented full control over the file contents.

An example CSV file looked like the following:

Url,HttpMethod,ExpectedResult,Description
http://example.com,GET,allow,text

An attacker could attempt to blindly write the CSV file to any directory or to potentially overwrite an existing file. This may have been able to cause a Denial-of-Service by overwriting an arbitrary file name referenced in Expressway documentation or by attempting to fill up the disk. This arbitrary write vulnerability had more potential so additional effort was put in to find a better exploit vector.

Finding a Side-Channel

The testing was performed from a standard level of access, which did not include the root user. Referencing the application mapping showed that the system snapshot functionality allowed for a dump of verbose system files to be downloaded from the web application.

Inspecting the snapshot showed a file structure that mirrored the layout of portions of the OS.

The initial approach taken was to search for an interpreted script that was automatically running on the host or could be triggered by some action. The concept was that partially controlling the contents of an executed script may allow for code execution. For example, modifying the CSV contents with a subshell allows for commands to be executed when the file is ran with bash:

Url,HttpMethod,ExpectedResult,Description
http://example.com,GET,allow,$(touch /tmp/z)

Despite the file not starting with the interpreter shebang (#!/bin/bash), the bash subshell will execute and create the /tmp/z file.

A suitable script was not able to be identified based on the files exposed through the system snapshot. Many of the candidates were mounted as read-only files. A different approach was needed.

Finding the Perfect Target File

While reviewing alternatives based on the large snapshot file, the /tandberg/etc/passwd.d/ directory was seen to be containing several *.passwd files. Each file appeared to be a standard looking format for the /etc/passwd file. Coincidentally the ash.passwd file even included the SHA256 hash for the root user.

Despite our efforts, this couldn’t be cracked to obtain the root password. The *.passwd files pattern was uncommon. What was the software doing with these files to create the typical /etc/passwd, /etc/group and /etc/shadow files?

Inspecting the /mnt/harddisk/snapshot/plugins/harddisklogs/log/messages file from the system snapshot showed the following:

Each *.passwd file was a fragment that was parsed to generate the /etc/passwd files. With this discovery a *.passwd file could be written to the /tandberg/etc/passwd.d/ directory to potentially create a new user or overwrite an existing one.

The format for the /etc/passwd file is generally flexible, but entries need to be formatted correctly. Systems will ignore lines in the /etc/passwd file that don't adhere to the proper syntax.

The CSV header could be ignored since there was no user-input into this line. The subsequent line started with the URL column, which enforce a strict validation that required that the input started with http:, https:, or wss:. A valid allow list rule that tries to match the /etc/passwd syntax may look like:

http://example.com/a:0:0:a,GET,allow,description:/:/bin/sh

With the goal that the /etc/passwd file would be parsed as:

• user: http
• password: //example.com/a
• user id: 0
• group id: 0
• comment: a,GET,allow,description
• home directory: /
• shell: /bin/sh

The schema restricted the user field to only being named any the following:

• http
• https
• wss

The password field is the next delimited field. Due to the URL validation, the password would have needed to start with // for a full URL prefix such as https://. The /etc/passwd format specifies that the password column can be:

• blank (No password)
• x (Password hash is in /etc/shadow)
• * or ! (Account is locked)
• Password hash ($6$....)

Due to the password column needing to contain the // characters the password value would be processed as a password hash. The prefix doesn't match common hashing algorithms, so this would result in a valid user that couldn't be logged in to. Some systems may fail the authentication if the password field doesn't match an expected pattern.

Quirks in CSV Writers

Trying to adjust where the colon separator was placed in the CSV format was tedious. The description field didn’t perform validations on the text input, so fuzzing was used to test out different character sequences.

The newline character (\n) was found to be supported by the subcommand to write a multi-line description. The CSV writer used would wrap the column in the double quotes to indicate the contents were part of the original column.

Url,HttpMethod,ExpectedResult,Description
http://example.com,GET,allow,"Description\n
test"

• Note the \n characters are included for visualization but represent a newline.

This functionality allowed for arbitrary lines to be written with full control over the content and no restrictions from the Tandberg shell. A description could be written that included a valid /etc/passwd entry on a separate line by surrounding it with newline characters.

Url,HttpMethod,ExpectedResult,Description
http://example.com,GET,allow,"Description\n
user:password:0:0::/:/bin/sh\n
"

With a well-formed passwd entry the CSV could be written to attempt to break out of the restricted shell.

Chaining the Bugs Together

The first step was to SSH to the Expressway hosts as a read-write admin. An allow list of rules needed to be created that included a valid /etc/passwd entry.

xCommand HttpAllowListTestAdd URL: 'http://foobar.com/' HttpMethod: 'POST' ExpectedResult: 'block' Description: '\nuser:$6$...:0:0::/tandberg:/bin/sh\n'

The rules CSV could be exported to the /tandberg/etc/passwd.d/ directory.

xCommand HttpAllowListExportTest File: /tandberg/etc/passwd.d/pentest.passwd

With the file staged, attempt to SSH in as the added user.

The effective user id can be seen as 0, which is equivalent to root permissions.

After the commands were ran the /mnt/harddisk/snapshot/plugins/harddisklogs/log/messages indicated in a subsequent snapshot that the new user fragment was read and used to update /etc/passwd.

Considerations

Depending on the Expressway authentication configuration, Pluggable Authentication Modules (PAM) may be in use to check non-default users against an LDAP group. An LDAP user could be used with the proof of concept in place of a default user such as:

ldap_user:*:0:0::/:/bin/sh

Alternatively, the /tandberg/etc/passwd.d/ash.passwd file could have been overwritten with valid allow list rules to write entries for the root , pwrec, _nobody, _sshd, _tshell, _tlp, _skacs, _crypto, and _pkacs users. The root password could be overwritten with an attacker supplied password hash.

Finally, the advisory from Cisco describes the vulnerability as a command injection, which indicates that another vector may be possible. It is likely there is another script that can be overwritten to perform the previously alluded to command injection.

Remediation

Cisco included the patch to CVE-2024–20492 in version 15.2 of the Expressway series. Users are recommended to upgrade to this version or later.

The recommendations made to Cisco included:

• Restricting the HttpAllowListExport and HttpAllowListExportTest subcommands to only write to a specific directory.
• Validating user input to prevent unexpected data in the allow list rules.
• Running the Tandberg shell with non-root permissions to prevent critical OS files from being overwritten.

Wrapping Up

State Farm is regularly testing our applications and working to best protect our customer’s data. We benefit greatly from other vulnerability reports and are thrilled to work with our vendors to help secure their products. This vulnerability was a neat example of some of the work done by our Offensive Security teams.

If you have a knack for finding vulnerabilities or are able to detect and defend against them, consider looking for career opportunities at State Farm below.

Timeline

• 07–16–2024 — Vendor Disclosure
• 10–02–2024 — Vendor Patch Release
• 12–19–2024 — Technical Details Published

To learn more about technology careers at State Farm, or to join our team visit, https://www.statefarm.com/careers.

Information contained in this article may not be representative of actual use cases. The views expressed in the article are personal views of the author and are not necessarily those of State Farm Mutual Automobile Insurance Company, its subsidiaries and affiliates (collectively “State Farm”). Nothing in the article should be construed as an endorsement by State Farm of any non-State Farm product or service.

<hr /><p>CVE-2024–20492 — A Privilege Escalation in Cisco Expressway was originally published in State Farm Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>