Mar 14, 2024NewsroomContainer Security / Vulnerability

Details have been made public about a now-patched high-severity flaw in Kubernetes that could allow a malicious attacker to achieve remote code execution with elevated privileges under specific circumstances.

“The vulnerability allows remote code execution with SYSTEM privileges on all Windows endpoints within a Kubernetes cluster,” Akamai security researcher Tomer Peled said. “To exploit this vulnerability, the attacker needs to apply malicious YAML files on the cluster.”

Tracked as CVE-2023-5528 (CVSS score: 7.2), the shortcoming impacts all versions of kubelet, including and after version 1.8.0. It was addressed as part of updates released on November 14, 2023, in the following versions –

• kubelet v1.28.4
• kubelet v1.27.8
• kubelet v1.26.11, and
• kubelet v1.25.16

“A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes,” Kubernetes maintainers said in an advisory released at the time. “Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.”

Successful exploitation of the flaw could result in a complete takeover of all Windows nodes in a cluster. It’s worth noting that another set of similar flaws was previously disclosed by the web infrastructure company in September 2023.

The issue stems from the use of “insecure function call and lack of user input sanitization,” and relates to feature called Kubernetes volumes, specially leveraging a volume type known as local volumes that allow users to mount disk partition in a pod by specifying or creating a PersistentVolume.

“While creating a pod that includes a local volume, the kubelet service will (eventually) reach the function ‘MountSensitive(),'” Peled explained. “Inside it, there’s a cmd line call to ‘exec.command,’ which makes a symlink between the location of the volume on the node and the location inside the pod.”

This provides a loophole that an attacker can exploit by creating a PersistentVolume with a specially crafted path parameter in the YAML file, which triggers command injection and execution by using the “&&” command separator.

“In an effort to remove the opportunity for injection, the Kubernetes team chose to delete the cmd call, and replace it with a native GO function that will perform the same operation ‘os.Symlink(),” Peled said of the patch put in place.

The disclosure comes as a critical security flaw discovered in the end-of-life (EoL) Zhejiang Uniview ISC camera model 2500-S (CVE-2024-0778, CVSS score: 9.8) is being exploited by threat actors to drop a Mirai botnet variant called NetKiller that shares infrastructure overlaps with a different botnet named Condi.

“The Condi botnet source code was released publicly on Github between August 17 and October 12, 2023,” Akamai said. “Considering the Condi source code has been available for months now, it is likely that other threat actors […] are using it.”

Jan 24, 2024NewsroomCloud Security / Kubernetes

Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster.

The critical shortcoming has been codenamed Sys:All by cloud security firm Orca. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector.

In a report shared with The Hacker News, security researcher Ofir Yakobi said it “stems from a likely widespread misconception that the system:authenticated group in Google Kubernetes Engine includes only verified and deterministic identities, whereas in fact, it includes any Google authenticated account (even outside the organization).”

The system:authenticated group is a special group that includes all authenticated entities, counting human users and service accounts. As a result, this could have serious consequences when administrators inadvertently bestow it with overly permissive roles.

Specifically, an external threat actor in possession of a Google account could misuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for follow-on exploitation such as lateral movement, cryptomining, denial-of-service, and sensitive data theft.

To make matters worse, this approach does not leave a trail in a manner that can be linked back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token.

Sys:All has been found to impact numerous organizations, leading to the exposure of various sensitive data, such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries, the last of which could then be used to trojanize container images.

Following responsible disclosure to Google, the company has taken steps to block the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and later.

“To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won’t allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups,” Google now notes in its documentation.

Google is also recommending users to not bind the system:authenticated group to any RBAC roles, as well as assess whether the clusters have been bound to the group using both ClusterRoleBindings and RoleBindings and remove unsafe bindings.

Orca has also warned that while there is no public record of a large-scale attack utilizing this method, it could be only a matter of time, necessitating that users take appropriate steps to secure their cluster access controls.

“Even though this is an improvement, it is important to note that this still leaves many other roles and permissions that can be assigned to the group,” the company said.

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.”