

SSRF attacks like the one described above can be mitigated by disallowing the HTTP request handler to follow redirects. Zimbra hosts a list of internal services, for example, an administrative console, that can be reached through this SSRF vulnerability. It might also be possible to escalate the impact of the SSRF vulnerability into Remote-Code-Execution impact. This can be achieved by forging a request to: If a Zimbra instance is hosted on a Cloud provider which has a metadata API reachable from the VM the server is hosted on, highly sensitive information could be leaked.įor example, if the server is hosted in the Google Cloud, an API access token could be leaked by forging a request to: Īnother example would be leaking IAM credentials from AWS through EC2 metadata. The SSRF is powerful for two reasons: (1) Arbitrary headers can be set in the outgoing request, and (2) the response can be read. As a consequence, an attacker could create a web server that redirects the HTTP client used by Zimbra to an arbitrary URL, including localhost. If points to a service that uses the Host header to create a redirect, the request is redirected to. WebRoot/js/zimbraMail/mail/view/ZmMailMsgView.js if (arch(/(]+action)(.*?>)/g)) The regex then inserts a secure action attribute with a default value instead: This replacement occurs when a form tag does not contain an action attribute, as the lack of this attribute per default leads to a request on the same page. In Zimbra, the default Ajax client uses a regular expression to perform replacements within form HTML tags. Transformation of already sanitized HTML inputs can lead to corruption of the HTML and then to XSS attacks, as demonstrated in our previous work on, for example, WordPress. The downside of using server-side sanitization is that all three clients may transform the trusted HTML of an email afterward to display it in their unique way. This step is done thoroughly and correctly by utilizing the OWASP Java-HTML-Sanitizer. To ensure that all three different clients receive the same security guarantees, the design decision was made to sanitize the HTML content of incoming emails on the server-side. A desktop client that heavily relies on Ajax, which is the default client.The frontend of Zimbra is used to view emails and 3 different clients are available:

Zimbra’s architecture is divided into a backend that handles incoming mail traffic and provides the HTTP backend for the webmail solution. We first dive into the DOM-based Stored Cross-Site-Scripting (XSS) bug and then examine the Server-Side Request Forgery (SSRF) vulnerability.
#Zimbra desktop issues code#
In the following sections I go into the technical detail of the code vulnerabilities. Prior versions of both branches are vulnerable.
#Zimbra desktop issues Patch#
We have no information whether Zimbra Cloud, a SaaS solution using AWS, was affected by this vulnerability.Īll issues were fixed by the Zimbra team with Patch 18 for the 8.8.15 series and Patch 16 for the 9.0 series. SSRF vulnerabilities have become an increasingly dangerous bug class, especially for cloud-native applications. Capital One was required to pay $80 million as a penalty. In 2019, assets of Capital One were breached utilizing a similar SSRF vulnerability. A remote attacker is then able to extract, for example, Google Cloud API Tokens or AWS IAM credentials from instances within the cloud infrastructure.

It can be exploited by an authenticated member of an organization with any permission role, which means that it can be combined with the first vulnerability. The second vulnerability is an interesting bypass of an allow-list that leads to a powerful Server-Side Request Forgery vulnerability (CVE-2021-35209). With this, other features of Zimbra could be accessed and further attacks could be launched. The malicious email would contain a crafted JavaScript payload that, when executed, would provide an attacker with access to all emails of the victim, as well as to their webmail session. The first vulnerability is a Cross-Site Scripting bug (CVE-2021-35208) that can be triggered in a victim’s browser when viewing an incoming email.
