{"id":59046,"date":"2022-10-24T09:37:54","date_gmt":"2022-10-24T01:37:54","guid":{"rendered":"https:\/\/version-2.com\/?p=59046"},"modified":"2023-10-16T17:35:14","modified_gmt":"2023-10-16T09:35:14","slug":"massive-infection-through-0-day-in-the-zimbra-email-suite-cve-2022-41352","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2022\/10\/massive-infection-through-0-day-in-the-zimbra-email-suite-cve-2022-41352\/","title":{"rendered":"Massive Infection through 0-day in the Zimbra Email suite (CVE-2022-41352)"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

Incident Overview<\/h2>\n

On October 7, the email server of a big commercial pharma organization was attacked. It was running Zimbra 8.x version on CentOS and got quickly compromised. Malicious actor exploited Internet-facing Zimbra Collaboration Suite using CVE-2022-41352 \u201ccpio\u201d zero-day vulnerability.<\/p>\n

Our investigation revealed and was able to confirm that unknown APT groups are massively exploiting an unpatched vulnerability (CVE-2022-41352) in Zimbra Collaboration Suite to infect vulnerable servers. <\/p>\n

Initial foothold was discovered through CrowdStrike EDR on that Linux mail server unfortunately for the sutomer it just detected but did not prevent the exploitation because of the insufficient Prevention Policy aggressiveness as customer had just started dealing with Crowdstrike software and it was in fine-tuning mode. Soon after the detection, MDR\/SOC team initiated Incident Response, gathered information and contacted the client\u2019s representatives via Google Meet.<\/p>\n

After the approval, the host was network-isolated<\/strong>, all client\u2019s endpoints were moved to the highest<\/strong> Prevention Policy.<\/p>\n

Recommendations & Remediation<\/strong><\/h2>\n

Since Zimbra released a patch for this vulnerability, the best course of action is to update your devices immediately. If this, for some reason, is not possible, installing pax on the machine hosting the Zimbra installation will prevent the vulnerability from being exploitable. pax is available from package managers (such as apt and yum) of all major Linux distributions. Among all Linux variants officially supported by Zimbra, only Ubuntu installs pax by default and is therefore not affected by CVE-2022-41352:<\/p>\n

Distribution<\/strong><\/td>Vulnerable to CVE-2022-41352<\/strong><\/td><\/tr>
Red Hat Enterprise Linux 7<\/td>Yes<\/td><\/tr>
Red Hat Enterprise Linux 8<\/td>Yes<\/td><\/tr>
CentOS 7<\/td>Yes<\/td><\/tr>
CentOS 8<\/td>Yes<\/td><\/tr>
Oracle Linux 7<\/td>Yes<\/td><\/tr>
Oracle Linux 8<\/td>Yes<\/td><\/tr>
Rocky Linux 8<\/td>Yes<\/td><\/tr>
Ubuntu 16.04 LTS<\/td>No<\/td><\/tr>
Ubuntu 18.04 LTS<\/td>No<\/td><\/tr>
Ubuntu 20.04 LTS<\/td>No<\/td><\/tr><\/tbody><\/table><\/figure>\n

<\/h2>\n

Please note that installing pax doesn\u2019t address the root issue with any distribution, where other program paths, both within and outside of Zimbra could still cause cpio to process untrusted data.<\/p>\n

After taking the aforementioned mitigation steps, owners of Zimbra servers are encouraged to check for traces of compromise. The following paths are known locations for webshells deployed by malicious actors currently leveraging CVE-2022-41352:<\/p>\n

123456<\/td>\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/.error.jsp\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/ResourcesVerificaton.jsp\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/ResourceVerificaton.jsp\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/ZimletCore.jsp\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/searchx.jsp\/opt\/zimbra\/jetty\/webapps\/zimbra\/public\/seachx.jsp<\/td><\/tr><\/tbody><\/table><\/figure>\n

In addition, it is worth noting that the Metasploit exploit drops its webshell in the following location:<\/p>\n

1<\/td>\/opt\/zimbra\/jetty_base\/webapps\/zimbra\/[4-10 random characters].jsp<\/td><\/tr><\/tbody><\/table><\/figure>\n

If you discover one of these files on your Zimbra installation, please contact an incident response specialist as soon as possible. Removing the file is not enough. Performing disinfection on Zimbra is extremely difficult, as the attacker will have had access to configuration files containing passwords used by various service accounts. These credentials can be used to regain access to the server if the administrative panel is accessible from the internet. In addition, considering the rudimentary nature of all webshells we have discovered so far, it is almost certain that attackers will deploy more robust and sophisticated backdoors as soon as they get the chance.<\/p>\n

Case Details<\/strong><\/h2>\n

October 7, <\/strong>mail server running Zimbra 8.x version on CentOS was compromised. An unidentified malicious actor exploited Internet-facing Zimbra Collaboration Suite using CVE-2022-41352<\/a> \u201ccpio\u201d zero-day vulnerability.<\/p>\n

After the approval, the host was network-isolated<\/strong>, all client\u2019s endpoints were moved to the highest Prevention Policy.<\/p>\n

Based on the CrowdStrike data, IR team stopped the threat quickly enough and did not find any traces of data exfiltration, confidential data access or any activity that may severely harm business continuity.<\/p>\n

<\/p>\n

Initial Access<\/strong><\/h2>\n

On October 7, at 15:55<\/strong>, malicious actor achieved RCE with root <\/strong>permissions via Zimbra vulnerability.The server infection began from downloading a few unknown files, most notably \/tmp\/.opt\/sh<\/strong>. Content and purpose of other files are unknown, as well as the reason for the new Nginx server execution.<\/p>\n

<\/figure>\n

Execution & Reconnaissance<\/strong><\/h2>\n

A few seconds later after the download, malicious actor executed an unknown file: \/opt\/zimbra\/common\/libexec\/slapd -u root -g root -f \/tmp\/.opt\/cfg2<\/strong><\/p>\n

Immediately after, the main infection script was started. Its purpose was to deeply persist on the system.<\/p>\n

<\/figure>\n

Persistence & Defense Evasion<\/strong><\/h2>\n

As seen from the CrowdStrike process timeline, the malicious script was executed successfully, given the wget <\/strong>command to the attackers host with status=0<\/strong> URL parameter.<\/p>\n

\u201cZero\u201d status indicates successful persistence via SSH key, which will be proven a few slides later.<\/p>\n

<\/figure>\n

Main Script: Bash copy with SUID<\/strong><\/h2>\n

The hacker copied the Bash binary to \/usr\/lib\/sftp<\/strong> in order to avoid detection via logs analysis.<\/p>\n

To make it work, new Bash copy was made executable and was given SUID <\/strong>flag to run as root<\/strong>.<\/p>\n

The last trick to avoid detection was to use touch -r<\/strong> command and copy modification time from passwd<\/strong> to the newly created backdoor.<\/p>\n

\/tmp\/.opt\/sh<\/strong> script is well-written and divided into parts. Each part is basically a new persistence mechanism 
<\/figcaption><\/figure>\n

Main Script: Web shell & SSH key<\/strong><\/h2>\n

The web shell part seems to be incorrect<\/strong>. It does not create a new one, but only renames the old web shell, if exists. According to our analysis, old web shell did not exist<\/strong> during the script execution.<\/p>\n

Then, the hacker prepares a few reusable functions and creates new SSH key pair<\/strong>. It was meant to be used for SSH backdoor on root user.<\/p>\n

<\/figure>\n

Main Script: SSH persistence details<\/strong><\/h2>\n

The adversary verified many sshd <\/strong>file configurations to ensure that backdoored key will work as expected.<\/p>\n

Furthermore, the hacker tuned firewall <\/strong>rules and changed default root shell to guarantee correct exploitation.<\/p>\n

As a part of defense evasion, touch -d<\/strong> command was used to revert original modification time of the affected sshd config.<\/p>\n

<\/figure>\n

Main Script: Cleanup and callback<\/strong><\/h2>\n

The last action the script performed was to notify the attacker-controlled server about the end of exploitation. As was shown in the logs before, the callback status is zero, which means success.<\/p>\n