rbowes-r7 (66)

This issue requires a fairly specific configuration to work. First, Apache has to be configured in a pretty specific way – a RewriteRule that passes user-controlled data into a query string. This line, from our configuration file above, is exploitable, as the $1 (user data) is after the ? (start of the query string):

RewriteRule "^/(.*)" "http://localhost:8081/?arg=$1" [P]

Whereas even a small change will break the exploit; this does not work:

RewriteRule "^/(.*)" "http://localhost:8081/$1" [P]

Additionally, this must be a security boundary — that is, smuggling an HTTP request must bypass some sort of access control check. We put together a Github search that tries to find software that would be exploitable if it was running on a vulnerable version of Apache, but nothing stands out as particularly interesting.

Applications and devices that come as complete images with multiple servers (such as a lot of enterprise software) would probably be better targets, but checking each one is difficult. We looked into this as an alternative way to exploit CVE-2022-1388, since the core of that vulnerability involved bypassing a reverse proxy’s security checks, but its configuration is not vulnerable to CVE-2023-25690.

The final place we’d expect to see vulnerabilities is in reverse proxies that are configured to enforce some kind of ACL check or filtering, and that also do URL rewriting. One would have to test the specific configuration and application(s) that are being proxied; there’s no easy way to scan for this sort of issue.

While we are not aware of any specific applications that are vulnerable to this, they may turn up as people investigate this vulnerability more.

This lives on the network perimeter and uses laughably old versions of software (like Ruby 1.9.3). I had more trouble preventing it from crashing than actually exploiting it. This also tends to store privileged information, since it’s a secure file transfer service. Kinda really bad.

This is currently unpatched and vulnerable in the default state. The time from reading the mitigation to having a working exploit was less than day, and that’s for somebody who isn’t super good at Java vulnerabilities.

This is a sorta complicated collection of vulnerabilities. In the Rapid7 analysis, we focused on the two most popular pieces of software, which run an ancient version of Santuario 1.4.1 (in part because the public PoCs target that version). Santuario 1.4.1 has absolutely trivial RCE issues.

But, according to the disclosure blog, other versions have more recent versions of Santuario, but run a version of Xalan that’s vulnerable to a whole other issue – CVE-2014-0107. Dinh found a novel way to exploit CVE-2014-0107, which is super cool, but it was overshadowed by the much simpler vuln in Santuario. I wish they’d named the specific software that CVE-2014-0107 worked against – that’d be a neat one to test, but I don’t think their blog is specific.

The saving grace here is that none of these projects are vulnerable unless SAML is enabled (although in some cases, they’re vulnerable forever if SAML is enabled once).

An exploit is published on the Full Disclosure mailing list, and it’s been exploited in the wild.

According to the vendor advisory, this is an authentication bypass in SugarApplication.php:

The underlying vulnerability relies on a missing authentication check in the loadUser() method in include/MVC/SugarApplication.php

Unfortunately, I couldn’t get ahold of a current version of the software to test. I got the most recent community version running (it’s quite old), but while that file exists, the auth bypass doesn’t seem to work.

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.