Jan 11, 2024NewsroomVulnerability / Patch Management

Cisco has released software updates to address a critical security flaw impacting Unity Connection that could permit an adversary to execute arbitrary commands on the underlying system.

Tracked as CVE-2024-20272 (CVSS score: 7.3), the vulnerability is an arbitrary file upload bug residing in the web-based management interface and is the result of a lack of authentication in a specific API and improper validation of user-supplied data.

“An attacker could exploit this vulnerability by uploading arbitrary files to an affected system,” Cisco said in an advisory released Wednesday. “A successful exploit could allow the attacker to store malicious files on the system, execute arbitrary commands on the operating system, and elevate privileges to root.”

The flaw impacts the following versions of Cisco Unity Connection. Version 15 is not vulnerable.

• 12.5 and earlier (Fixed in version 12.5.1.19017-4)
• 14 (Fixed in version 14.0.1.14006-5)

Security researcher Maxim Suslov has been credited with discovering and reporting the flaw. Cisco makes no mention of the bug being exploited in the wild, but it’s advised that users update to a fixed version to mitigate potential threats.

Alongside the patch for CVE-2024-20272, Cisco has also shipped updates to resolve 11 medium-severity vulnerabilities spanning its software, including Identity Services Engine, WAP371 Wireless Access Point, ThousandEyes Enterprise Agent, and TelePresence Management Suite (TMS).

Cisco, however, noted that it does not intend to release a fix for the command injection bug in WAP371 (CVE-2024-20287, CVSS score: 6.5), stating that the device has reached end-of-life (EoL) as of June 2019. It’s instead recommending customers migrate to the Cisco Business 240AC Access Point.

Dec 28, 2023NewsroomCloud Security / Data Protection

Google Cloud has addressed a medium-severity security flaw in its platform that could be abused by an attacker who already has access to a Kubernetes cluster to escalate their privileges.

“An attacker who has compromised the Fluent Bit logging container could combine that access with high privileges required by Anthos Service Mesh (on clusters that have enabled it) to escalate privileges in the cluster,” the company said as part of an advisory released on December 14, 2023.

Palo Alto Networks Unit 42, which discovered and reported the shortcoming, said adversaries could weaponize it to carry out “data theft, deploy malicious pods, and disrupt the cluster’s operations.”

There is no evidence that the issue has been exploited in the wild. It has been addressed in the following versions of Google Kubernetes Engine (GKE) and Anthos Service Mesh (ASM) –

• 1.25.16-gke.1020000
• 1.26.10-gke.1235000
• 1.27.7-gke.1293000
• 1.28.4-gke.1083000

• 1.17.8-asm.8
• 1.18.6-asm.2
• 1.19.5-asm.4

A key prerequisite to successfully exploiting the vulnerability hinges on an attacker having already compromised a FluentBit container by some other initial access methods, such as via a remote code execution flaw.

“GKE uses Fluent Bit to process logs for workloads running on clusters,” Google elaborated. “Fluent Bit on GKE was also configured to collect logs for Cloud Run workloads. The volume mount configured to collect those logs gave Fluent Bit access to Kubernetes service account tokens for other Pods running on the node.”

This meant that a threat actor could use this access to gain privileged access to a Kubernetes cluster that has ASM enabled and then subsequently use ASM’s service account token to escalate their privileges by creating a new pod with cluster-admin privileges.

“The clusterrole-aggregation-controller (CRAC) service account is probably the leading candidate, as it can add arbitrary permissions to existing cluster roles,” security researcher Shaul Ben Hai said. “The attacker can update the cluster role bound to CRAC to possess all privileges.”

By way of fixes, Google has removed Fluent Bit’s access to the service account tokens and re-architected the functionality of ASM to remove excessive role-based access control (RBAC) permissions.

“Cloud vendors automatically create system pods when your cluster is launched,” Ben Hai concluded. “They are built in your Kubernetes infrastructure, the same as add-on pods that have been created when you enable a feature.”

“This is because cloud or application vendors typically create and manage them, and the user has no control over their configuration or permissions. This can also be extremely risky since these pods run with elevated privileges.”