Zero Day Zimbra Mail Vulnerability Discovered

A new zero-day XSS vulnerability in the Zimbra webmail client, dubbed “Operation EmailThief” was discovered by the incident report company Volexity.

According to a blog post, Volexity discovered a series of targeted spear-phishing campaigns last year in December against a customer from a threat actor identified as TEMP_Heretic.

The attacker targeted organizations in the European government and media primarily.

Who Was Responsible for the Campaign?

Although there’s no confirmation, it doesn’t appear the attack came from any previously classified threat groups.

However, several things indicate that TEMP_Heretic is a Chinese APT actor, including:

  1. The vast majority of phishing messages were sent during UTC+8 hours, somewhere between 4:00 AM and 8:30 AM, fitting the Chinese working hours;
  2. The email headers show the time zone as UTC +0800;
  3. The attacker also used JavaScript code and the headers in the Zimbra requests show that the time zone is “Asia/Hong_Kong”.

How Did the Campaign Work?

The campaign itself had two phases, each with several waves, the reconnaissance and spear-phishing phase.

The first phase was conducted on 14th December, while the second was done on 16th, 23rd, 24th and 27th December, 2021.

Here is an overview of the attack phases:

The attacker also created 74 unique Outlook.com addresses for this campaign, with mostly female names (the names in some instances repeated as you can see in the two examples above). The format of these email addresses was usually <first name>_<last name>_<random numbers>@outlook.com or <first name><last name><random numbers>@outlook.com.

1st Phase – Reconnaissance

During the first phase of the attack, the attacker would send email messages with generic subject lines that contained embedded remote images in the body, but otherwise no other content.

The image links were used to validate the email addresses and were unique for each target, which was mainly used to vet which targeted organization has a better chance to open the phishing message,

The images had URI such as:

Where the [integer] part is used to pinpoint the victim itself.

These emails also contained a subject line such as:

2nd Phase – Main Spear Phishing Attack and Using XSS Vulnerability

Supposing that the reconnaissance phase was successful and the target opened the email message, the attacker moved on to the second and main phase of their attack.

This phase happened in multiple waves and the spear-phishing campaign was run during the second half of December, on 16th, 23rd, 24th and 27th.

The spear-phishing campaign had two themes:

  1. An invitation to a Sotheby’s charity auction (such as the email below);
  2. Fake interview requests from BBC, AFP, or other news companies (such as the email below).

While most email messages were targeted to a specific victim and had custom content, some were more generic and mainly claiming to be from different airlines such as British Airways, Lufthansa, Air France, United Airlines, or Southwest Airlines, or from Amazon.

These messages were mostly about Christmas and New Year greetings, inviting victims to click on a link in the email to receive a discount or check Amazon Prime.

For example, an email from an airline might have a subject line such as:

“Merry Christmas and New Year from Lufthansa!”

And would also contain an embedded video or image that the user would click on.

The URI pattern used in the second phase was similar to the first one, with the exception that the subdomain was consistent this time around.

These URIs typically had the following format:

Where the [second_integer] part indicates the targeted organization.

When the user clicks on a malicious link in the email message, the hacker’s infrastructure would then redirect them to a page on the organization’s Zimbra webmail host.

This page had a URI, formatted in such a way as to help the attacker load an arbitrary JavaScript code (provided the user is logged in) in the context of a Zimbra session.

Basically, if the user clicks on a malicious link and also leaves their browser window open, the remote attacker would be able to steal their mailbox contents.

At the time of writing this, Zimbra has not released an official patch for the vulnerability.

Not the First Cross-Site Scripting XSS Vulnerability in Zimbra Webmail Client

This isn’t the first cross-site scripting vulnerability found in the Zimbra webmail client.

Previously last year, SonarSource, a Swiss-based company developing open-source software for continuous code quality and security, discovered two potential XSS vulnerabilities and exploits in Zimbra 8.8.15 and 9.0 series.

Thanks to these security vulnerabilities, an unauthenticated attacker could compromise an organization’s Zimbra webmail server and even gain access to sent and received emails from all employees of that organization.

What are the Vulnerabilities in Question?

You can check the CVE details for both vulnerabilities here (CVE-2021-35208 and CVE-2021-35209)

1) CVE-2021-35208

The first vulnerability was a cross-site scripting bug that activates in the victim’s browser upon viewing a malicious email.

Cross-site scripting (XSS) is a code-injection attack where the attacker exploits a vulnerability in the website or app and injects a malicious code into the victim’s computer. We explain more what it is in this article.

This email contained a crafted JavaScript payload. When the JS payload is executed, the hacker would gain unrestricted access to the employee’s email account and their webmail sessions. From there, the attacker could also access other Zimbra features and use this as a springboard for further attacks.

2) CVE-2021-35209

The second vulnerability identified by SonarSource was an SSRF (Server-Side Request Forgery) vulnerability. SSRF vulnerabilities are an increasingly dangerous bug class, particularly for cloud-native applications (no information if Zimbra Cloud is affected by it).

The vulnerability itself is a bypass of an allow-list that can be abused by an employee with any permission role. This could then allow the hacker to extract the AWS IAM credentials or Google Cloud API Tokens.

Zimbra security team fixed both vulnerabilities with patches 18 for the 8.8.15 and Patch 16 for the 9.0 series. Note that versions before these on both branches are still vulnerable.

How Do the Vulnerabilities Work?

In the blog post about the vulnerabilities, SonarSource also explains the technical details of how these work if you’re interested in reading about them more.

In short, the cross-site scripting vulnerability exploits the fact that Zimbra uses three different clients to view emails:

  1. Desktop client;
  2. Static, HTML client;
  3. Mobile-optimized client.

In order for all three clients to have the same security guarantees, the HTML content from an incoming email is sanitized on the server-side using the OWASP Java-HTML Sanitizer.

The problem with this is that each client can transform the trusted HTML of an email and display it in their own way. This can then lead to HTML being corrupted and an XSS attack.

When it comes to the second vulnerability, this has more to do with one of Zimbra integrations, namely Webex and not Zimbra itself.

In order to integrate Webex on front-end Ajax requests are needed to get the info from Webex, but the Same-Origin-Policy prevents this normally. However, Zimbra uses proxied requests through Servlet to fetch data from Webex instead.

What this means is that an open redirect on a Webex domain leads to an SSRF vulnerability.

Conclusion

Zimbra email platform is used by 200,000+ businesses, as well as more than 1,000 financial institutions and governments. However, these vulnerabilities can enable an unauthenticated attacker to steal the user’s mail data and more.

To protect your email from attacks that run arbitrary JavaScript, sign up for CTemplar’s secure email. CTemplar is the only email service that provides checksums that show that our GitHub code is the same as you get on the website and not tampered with.