ccondon-r7 (197)

Added to CISA KEV on Sept. 18, 2023, but exploited for at least the past two years. Vuln only affects sites with debug mode enabled, which are evidently more common than one perhaps would’ve thought. In any event, it’s a two-plus-year-old vuln — please patch it.

Per @sfewer-r7’s Rapid7 analysis:

CVE-2023-28771 was introduced into the firmware from version 4.60, which was released on October 21, 2020, more than two and a half years ago. The vulnerable component is the Internet Key Exchange (IKE) packet decoder, which forms part of the IPSec VPN service offered by the device. Note: A VPN does not need to be configured on the device for the device to be vulnerable — an affected device is vulnerable in a default state. An attacker can send a specially crafted UDP packet to port 500 in the WAN interface and achieve unauthenticated command execution as the root user.

40K+ exposed web interfaces, which probably undersells exposure. Attackers tend to like these devices, and the vuln’s been hiding in the firmware for years now. Likely to be exploited at scale, possibly exploited under the radar already.

This was discovered because of zero-day exploitation perpetrated by a skilled adversary — final payload was Nokoyawa ransomware in at least one case, as Kaspersky details here. We’ve seen a sustained burst of driver exploitation by a range of threat actors the past two years. The trend continues.

Patched in April 2023 Patch Tuesday, so grab those updates quickly as always!

This is a Forti-thing, so there’s a valuable target population, but I’d be surprised if a heap underflow got exploited widely. Not exploited as 0day, according to the advisory, and no hackery in the wild that I can see. There are easier Forti-targets out there than this one.

The core vuln here is an info leak in ZK Framework, which — yep, you guessed it! — is a popular open-source Java library used to create enterprise mobile and web apps. The original advisory, NVD entry, and CVSS score are all predicated on the mere info leak, but as it turns out, other popular software that uses ZK Framework is vulnerable to full-on remote code execution via CVE-2022-36537. Both Huntress and NCC Group have noted that this bug is being exploited in vulnerable ConnectWise R1Soft Server Backup Manager software to gain initial access to target systems and then do a variety of not-good things, including installing malicious JDBC database drivers to backdoor systems, deploying ransomware, and so on.

Per various write-ups and public PoCs analyzed by @sfewer-r7, the following seems to happen:

• Attacker uses the CVE-2022-36537 to leak the contents of /Configuration/database-drivers.zul, which yields a unique secret ID value
  
• Armed with this value, attacker exploits vuln again to reach an endpoint that allows them to upload the JDBC driver, which functions as a handy backdoor
  
• Attacker can now use the REST API to issue commands to registered agents to do nefarious things, like, you know, deploy your ransomware of choice to downstream systems
  
• Oh and hey there are supply chain implications
  

We know the ConnectWise R1Soft vector is in active use and is easily exploitable, but this being a library vuln (so hot right now), that’s almost certainly not going to be the only attack vector. Some light recon done by folks smarter than me (namely the aforementioned @sfewer-r7) indicates there are plenty of other things that use ZK Framework. The question is which are vulnerable to remote exploits out of the box. Knocking this down an exploitability point overall simply because other applications may not be quite as easily exploitable remotely as the ConnectWise software.

If you’re using a vulnerable R1Soft Server Backup Manager version, please patch immediately. The NCC Group’s FOX IT team has a great write-up with IOCs and attack details.

This is getting a lot of attention, but despite the chatter, it doesn’t actually appear to be exploited widely (yet) and has virtually no internet-exposed attack surface area, so I’m not sure it’s gonna get there. The device itself looks like a great target and if you use it you should patch it, but it’s not commonly exposed, and this shouldn’t be confused with other Fortinet vulns that live in products with tens or hundreds of thousands of systems chillaxin’ on the internet.

No opinion from our research folks yet on exploitability if you’re in a network with access to a vulnerable target. Public PoC exists and it looks like a few different security vendors are seeing honeypot hits, but only from a couple IPs so far. May increase, may not, we’ll see.

Tagging this as both “easy to weaponize” and “difficult to weaponize” since it depends on the product the attacker is targeting. ServiceDesk Plus is trivial to exploit using public PoC (see @rbowes-r7’s assessment), but other vectors like ADSelfService Plus seem to require some type of info leak to supply the attacker with unique environment values needed to allow the exploit code to execute successfully, as @sfewer-r7 has demonstrated in our lab. So exploitability for (at least) ServiceDesk Plus is very high, but so far exploitability for (so far) ADSelfService Plus is relatively low. If someone finds an automagical way to obtain the GUID and issuer URL for ADSSP, that’d change the risk calculus some.

Rapid7 is seeing ongoing exploitation of this vulnerability in ServiceDesk Plus, and our honeypots are also seeing activity. The Rapid7 analysis tab has a ton of detailed technical info.

Evidently this is being used for privilege escalation in ransomware attacks when threat actors have initial access to systems through existing Raspberry Robin, FAKEUPDATES, and/or Qakbot infections. Not necessarily surprising given the Windows print spooler’s popularity with attackers, but the existing intel on Raspberry Robin and Qbot ecosystems is a little light on specific CVE mentions. I was surprised to see the RiskIQ article, especially considering that it’s fairly buried in run-of-the-mill Patch Tuesday roundup drivel in Google search results.

Lots of advanced-ish threat notifications this week…Citrix published a security advisory and a companion blog on this zero-day bug today, noting that it’s been exploited in the wild. The NSA also released information about APT 5 targeting Citrix ADC installations; their bulletin includes threat intel.

ADC is always a nice target, and often hangs out on the internet. Leaving “Exploitability” as a medium for now since there’s not a ton on the vuln inself, other than that it’s SAML-related. I’d expect more vuln details out on this one shortly, and probably a rise in exploitation—just in time for the holidays.

Sounds like Cisco was seeing small-ish-scale exploitation of this bug over the summer to gain initial access and deploy TrueBot payloads. I’d never heard of this product before now, but looking at its website, it looks to be security/IT management software with lots of enterprise customers—i.e., one of those things that’s probably under-scrutinized by researchers (and thus a nifty fun-time target for attackers). Not a lot of internet-facing attack surface area, which is good, but I have to wonder how many people even know there’s a serious vuln in this stuff, let alone how many have actually patched.

Heap-based buffer overflow in the sslvpnd component of Fortinet SSL VPNs. Fortinet disclosed publicly on December 12 with a note that it had been exploited in the wild, evidently after putting out a private warning to customers the week prior. Since then, there’s been community discussion about whether this was exploited as 0day or not, as the vendor evidently silently patched the vuln roughly two weeks before public disclosure (giving attackers plenty of time to reverse the patch before many customers were aware there was a problem).

Heap-based BOF probably isn’t quite as easily exploitable as, say, a stack-based cousin. Even if this wasn’t true 0day, my bets are on an advanced and/or state-sponsored threat actor being the culprit for initial exploitation. Not sure we’ll see mass exploitation right away, or even at all…unless of course someone figures out where the bug lives and develops a public exploit, in which case, the exploitability rating on this will ratchet up. The attacker value of compromising a Fortinet device is high enough to motivate folks.

Rapid7 has a blog on this vuln with a particularly apt title. On the surface, the hyped-up internet chatter comparing this to Log4Shell might be justifiable, since we’re talking about an open-source library vuln, but practically speaking, it will be rare for real-world applications to be remotely exploitable out of the box. We’re seeing reports of “exploitation” in the wild, but the upshot of those reports so far seems to be that opportunists are hurling clumsy exploits at the internet without actually finding any vulnerable code paths. There’s a trees falling in the forest metaphor somewhere in here.

This bug was evidently used by LAPSUS$ in the wild as part of the attack on Okta.

Seemingly ubiquitous logging library—vulnerable implementations are going to be widespread. Multiple PoC exploits are publicly available, and broad opportunistic attacks already occurring, but I’d expect with all the different implementations, we’ll be seeing new attack vectors for weeks or months to come. Update all your dependencies ASAP, and/or take systems and services with known-vulnerable implementations offline right away. Exploitation sure to increase even further. https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/

Rapid7’s services teams are observing opportunistic exploitation of this vulnerability in the wild. Sounds like coin miners are the payload so far.