ccondon-r7 (232)

On the one hand, it’s backdoored software, so “exploitation” could arguably have already occurred (in the form of an already executed supply chain attack). On the other hand, it’s not immediately clear that anyone has used this backdoor to do specific Bad Things™, so “exploited in the wild” doesn’t sound quite right either. Developers probably most at risk here rather than production systems, but it would appear this got caught pretty quickly.

Bad:

• Backdoor!
  
• In a popular command-line tool
  
• Made it into unstable branches/bleeding-edge releases of some distros (Kali, Arch, etc)
  
• “Open source is unsafe” commentary (c’mon, y’all)
  
• Salacious! Speculation runs rife! xz is drowning out Kate Middleton conspiracy theories in my timelines!
  

Good:

• Didn’t make it into prod systems, stable branches unaffected
  
• Not a simple attack
  
• Not clear that anyone is actively using this backdoor for badness — private SSH key still hasn’t shown up
  

Rapid7 observed pre-patch exploitation of this vulnerability from March through at least August of 2023. Several of the incidents our MDR team investigated ended in ransomware deployment. In September 2023, Cisco assigned CVE-2023-20269, which covers some of the attacker behavior Rapid7 incident responders observed: https://www.rapid7.com/blog/post/2023/08/29/under-siege-rapid7-observed-exploitation-of-cisco-asa-ssl-vpns/

This was disclosed as 0day in September 2023 and then kind of never spoken of again, true to form for Trend Micro product 0days (exhibit 1, exhibit 2, exhibit 3). For CVE-2023-41179, exploitation requires an attacker to have admin console access on the target system, hence the low exploitability rating. As usual with these things, there don’t appear to be any public details.

See the Rapid7 analysis for details on the exploit chain.

Rapid7 saw exploitation of this in customer environments in early December 2023. It’s also been used by the Cactus ransomware group.

Per Google’s Threat Analysis Group (TAG), this bug was exploited as a zero-day and has been used by at least four different threat actors to “steal email data, user credentials, and authentication tokens.” Threat campaigns have targeted Greece, Moldova, Tunisia, Vietnam, and Pakistan.

We’ve continued to see reports of exploitation for CVE-2023-27532. Almost a year out from the initial advisory, there’s been ransomware (Cuba, Akira) and other use of this vuln by financially motivated groups. Patch uptake has reportedly been pretty strong, but notably, this is a solid internal attack vector, so locking down internet exposure alone isn’t a sufficient mitigation plan.

Knocking down attacker value a bit because there appear to be only a few hundred of these exposed and vulnerable, and perhaps surprisingly, it’s been a few months since full details were released and there’s still no known exploitation. Unclear how common the engine is in real-world environments from talking to offensive security folks focused on healthcare. I think it’s fair to balance rightful sensitivity about anything that could compromise healthcare systems with some skepticism about the particular target in this case. If we see IRL exploitation, I’m happy to eat those words :)

See the Rapid7 Analysis for a full technical analysis of this vulnerability, including proof-of-concept code.

The vendor’s advisory has now grown to encompass CVE-2023-7102, another zero-day vulnerability in ESG appliances, in addition to the original CVE-2023-2868. Both attacks attributed to “suspected China-nexus actor” UNC4841 by Mandiant, which has multiple analyses available along with IOCs.

Critical out-of-bounds write vuln in vCenter Server and Cloud Foundation. While we haven’t looked at this in-depth, VMware’s advisory indicates that it’s been exploited in the wild, and they took the unusual step of patching several end-of-life versions of vCenter Server:

While VMware does not mention end-of-life products in VMware Security Advisories, due to the critical severity of this vulnerability and lack of workaround VMware has made a patch generally available for vCenter Server 6.7U3, 6.5U3, and VCF 3.x. For the same reasons, VMware has made additional patches available for vCenter Server 8.0U1.

The vuln requires network access to exploit, for whatever that’s worth at this point in threat-land. Typical skepticism on ease/reliability of exploitation applies given that this is a memory corruption vuln, but with that said, vCenter is a high-value target for skilled and motivated threat actors, including ransomware groups. vCenter Server customers should heed the FAQ advice and patch on an emergency basis.

Edit: Mandiant has published technical information revealing that this vuln has apparently been exploited since 2021 by UNC3886, a China-nexus threat actor. So it is 0day after all.

Rapid7 has confirmed indicators of compromise from this zero-day attack in multiple customer environments. Barracuda has host and network-based IOCs here: https://www.barracuda.com/company/legal/esg-vulnerability

Despite the buzz on this one, so far we haven’t been able to identify any real-world applications that are vulnerable and exploitable out of the box, though that doesn’t mean they don’t exist.

Per @sfewer-r7’s analysis of the bug, this is not trivially exploitable, and exploits may need to be target-specific if there are any real applications discovered to be vulnerable in common configurations. At least three different security firms are reporting exploitation in the wild, but it’s not clear that any of them have seen actual exploitable code paths get hit, or that the attack vectors are production applications rather than demo applications configured to be artificially exploitable (which is what the public PoCs currently target). Happy to be wrong if we’re wrong, but until then, “don’t panic” sounds like the order of the day. If there are follow-on vendor advisories patching this out of their specific product implementations, it’d probably be good to pay attention to those as they roll in.

Edit: Shadowserver actually said explicitly that none of the attempts they’d seen as of December 13 had been successful.

Atlassian released an out-of-band update today that addresses a critical privilege escalation in Confluence Server and Data Center (on-prem only) that has evidently been exploited in a “handful” of customer environments “to create unauthorized Confluence administrator accounts and access Confluence instances.” It’s fairly rare for a privilege escalation to be considered critical, though not unprecedented (lookin’ at you, Zerologon). It would be awfully helpful if there were more information about the root cause, since the bug is evidently remotely exploitable from the internet — also not exactly like your typical privilege escalation. Not sure if Atlassian is deliberately obfuscating that information or not.

Advisory has IOCs: https://confluence.atlassian.com/security/cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html

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.