Unpatched remote code execution flaw in Zimbra Collaboration Suite actively exploited

2 years ago 119
BOOK THIS SPACE FOR AD
ARTICLE AD

Threat actors are exploiting an unpatched severe remote code execution vulnerability in the Zimbra collaboration platform.

Researchers from Rapid7 are warning of the exploitation of unpatched zero-day remote code execution vulnerability, tracked as CVE-2022-41352, in the Zimbra Collaboration Suite.

Rapid7 has published technical details, including a proof-of-concept (PoC) code and indicators of compromise (IoCs) regarding CVE-2022-41352 on AttackerKB.

The bad news is that the vulnerability has yet to be patched by the company, the issue has been rated as CVSS 9.8.

“CVE-2022-41352 is an unpatched remote code execution vulnerability in Zimbra Collaboration Suite discovered in the wild due to active exploitation.” reported Rapid7. “The vulnerability is due to the method (cpio) in which Zimbra’s antivirus engine (Amavis) scans inbound emails. Zimbra has provided a workaround, which is to install the pax utility and restart the Zimbra services. Note that pax is installed by default on Ubuntu, so Ubuntu-based Zimbra installations are not vulnerable by default.”

The experts pointed out that the vulnerability is due to the method (cpio) used by Zimbra’s antivirus engine (Amavis) to scan the inbound emails.

According to Zimbra users, the vulnerability is actively exploited since early September 2020. Threat actors are exploiting the issue to upload jsp files into Web Client /public directory by simply sending in an email with a malicious attachment.

“We have an incident where the attacker managed to upload jsp files into Web Client /public directory by simply sending in an email with malicious attachment.” a user wrote on the Zimbra forum.

“Our system already patched to P26 on Zimbra 9. The incident timeline and steps:

Send a malicious file to one of the user. The amavisd will process this file and I think via cpio loophole, got the file extracted into the target folder /opt/zimbra/jetty/webapps/zimbra/public.The attacker access this file (webshell) via the public and executed “zmprov gdpak” to generate preauth and login into any user they targeted.They login to xxx@yyy.zzz account to delete the file they sent in via step1 to try erase the trail.”

Zimbra is urging users to install the “pax” utility and restart the Zimbra services to avoid the Amavis component falling back to using cpio.

“All Zimbra administrators should make sure the pax package is installed on their Zimbra server. Pax is needed by Amavis to extract the contents of compressed attachments for virus scanning.” reads an update published by the company. “If the pax package is not installed, Amavis will fall-back to using cpio, unfortunately the fall-back is implemented poorly (by Amavis) and will allow an unauthenticated attacker to create and overwrite files on the Zimbra server, including the Zimbra webroot.

For most Ubuntu servers the pax package should already be installed as it is a dependency of Zimbra. Due to a packaging change in CentOS, there is a high chance pax is not installed.”

Summarizing, the flaw can be exploitable if these two conditions are met:

A vulnerable version of cpio must be installed, which is the case on basically every system (see CVE-2015-1197) (see CVE-2015-1197)The pax utility must not be installed, as Amavis prefers pax and pax is not vulnerable

Rapid7 researchers pointed out that pax is not installed by default on Red Hat-based distros, this means that they are vulnerable by default. Below is the list of Linux distros tested by Rapid7:

Linux DistroVulnerable?
Oracle Linux 8Vulnerable
Red Hat Enterprise Linux 8Vulnerable
Rocky Linux 8Vulnerable
CentOS 8Vulnerable
Ubuntu 20.04Not vulnerable (pax is installed by default)
Ubuntu 18.04Not vulnerable (pax is installed, cpio has Ubuntu’s custom patch)

Zimbra is going to address it by removing the dependency on cpio by making pax a prerequisite for Zimbra Collaboration Suite.

“Since cpio has no mode where it can be securely used on untrusted files, the attacker can write to any path on the filesystem that the Zimbra user can access. The most likely outcome is for the attacker to plant a shell in the web root to gain remote code execution, although other avenues likely exist.” concludes Rapid7.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Zimbra)

Read Entire Article