rbowes-r7 (46)

Because this is CSRF, it’s very difficult to exploit – it requires an attacker to know the network layout, then either get super lucky or socially engineer an administrator. Although it’s an interesting vulnerability with a great payoff, I’ll be surprised if this gets exploited.

On the flip side, the PoCs I wrote create a persistent backdoor, and don’t require the attacker to have direct network access to the management interface – it can all be done through the administrator’s browser.

This permits a user who already has an administrator account to create a shell on the target device. There are other (authorized) ways to do this, so this vulnerability is pretty minor, IMO, although if it IS exploited it grants access to a network load balancer which is kind of a big deal.

A vulnerability lets you send requests to the backend API service that appear to be coming from a trusted frontend application. As a result, you can call any REST API without authentication, which is pretty bad considering this is a security appliance.

This is I think the 6th major issue with Zimbra this year. It’s not really their fault, they use Amavis which uses cpio which is vulnerable to CVE-2015-1197, but the attack surface for incoming emails is HUGE.

Not to mention, this is one of several vulnerabilities this year that was being exploited in the wild before being discovered, which means Zimbra is an active target for the Bad Guys.

If you’re still using Zimbra, you might want to seriously reconsider. I betcha there are others, and they’re probably being exploited.

Very easy patch to reverse and exploit to develop. Public proof of concept exist, as well as a Metasploit module. Very important to patch!

This is a privilege-escalation vulnerability in Zimbra, to go from the zimbra user to root. As of writing, this has been publicly known for nearly a near, and reported to Zimbra for about a month.

Although it requires an account, there have been a whole pile of recent CVEs that get you there – CVE-2022-30333, CVE-2022-27925, and CVE-2022-27924

This is basically cve-2022-27925 – it’s the same exploit, but you don’t send an auth cookie and it fails to prevent access.

This is really bad – remote root on an organization’s email server, if combined with other (currently 0-day vulnerabilities). Patch ASAP!

Ultimately, this is annoying and unreliable to exploit, but we did get it working and confirm it’s a problem.

While we focused on Zimbra in our analysis, there are almost certainly other targets for this vulnerability that we are not aware of yet.

Exploiting this against Zimbra is really bad – it can be done fairly quietly and it doesn’t require direct access to the server, and can easily lead to root access to the server hosting users’ email. This is super urgent to patch on Zimbra!

CVE-2022-22954 came out at nearly the same time, is easier to exploit, and grants access to the underlying OS rather than the web interface. I think that’s going to be the issue that ends up mattering, and this will be overshadowed.

The biggest problem is that this requires an Internet-facing SSL server, so attacks can’t easily be automated.

The patch was difficult to analyze, due to the sheer amount of code and changes. But once Horizon3 released a PoC, tracking down the root cause and analyzing what’s going on was much easier. Cheers!

Super underwhelming, IMO – requires a confluence of bad configuration. Microsoft’s claims that they see vulnerable configurations in the wild are dubious – it takes some effort to make yourself vulnerable (I just used sudo to run as the networkd user, but that’s cheating). Definitely not a name-worthy vulnerability!

With publicly available information, this was super trivial to exploit! In the Rapid7 analysis, I chained it together with what I thought was CVE-2022-22960 (I’m not sure it was anymore) to go from unauthenticated HTTPS access to root very easily.