Researchers on Tuesday found two vulnerabilities in open source Zimbra code that could allow an unauthenticated attacker to compromise a targeted organization’s Zimbra webmail server — a maneuver that would let the attacker gain unrestricted access to all sent and received emails of all employees.
In a blog post, SonarSource researchers said the first vulnerability was a cross-site scripting (XSS) bug (CVE-2021-35208) that could get triggered in a victim’s browser when viewing an incoming email. The other vulnerability was a bypass of an allow-list that leads to a powerful server-side request forgery vulnerability (SSRF) (CVE-2021-35209).
The researchers said that the 2019 Capital One breach used a similar SSRF vulnerability, noting that SSRF vulnerabilities have become an increasingly dangerous bug class, especially for cloud-native applications.
SonarSource said all these issues were fixed by the Zimbra team with Patch 18 for the 8.8.15 series and Patch 16 for the 9.0 series.
XSS vulnerabilities are unfortunately pretty common because of the large variety of front-end client types for web and mobile, as well as user device types with varying operating systems, said Michael Isbitski, technical evangelist at Salt Security. Isbitski said attackers will frequently exploit XSS vulnerabilities to obtain authenticated sessions.
“The ways that clients sanitize input can vary, which is why it's often recommended to sanitize data in the back-end,” he said. “The Zimbra developers seemed to follow security best practice here, sanitizing user-submitted data in the back-end with a well-vetted OWASP sanitizer library. Unfortunately, one of the Zimbra front-ends transformed the sanitized content in an unsafe way, which led to the XSS issue.”
Isbitski added that SSRF vulnerabilities have been gaining in popularity by attackers because of the extent of damage they can do to back-end services. By exploiting an SSRF vulnerability in a back-end service, it's possible to leverage that vulnerable back-end service as a trusted connection to other back-end services and data.
“We saw this in the case of Capital One in 2019, where an attacker was able to bypass web filtering controls and submit commands to back-end services hosted in AWS,” Isbitski said. “The web filtering mechanism was a trusted resource within Capital One's AWS private cloud segment.”
