Kubernetes Image Builder Vulnerability

Executive Summary

On October 15, 2024, it was disclosed by NIST that the software application, Kubernetes, had a critical vulnerability (CVE-2024-9486) in relation to its Image Builder application.  This vulnerability allowed for threat actors to use default credentials originating from the image building process for virtual machines, to obtain root access to a system.  This vulnerability is critical to address due to the level of access that a threat actor would be able to obtain, taking complete control over a system and allowing the threat actor to conduct malicious activities without being thwarted.  Users who suspect they are using affected images are encouraged to rebuild and redeploy their images to their virtual machines.

Background

Kubernetes, also known as K8, is an open source and portable software application that helps manage, scale, and deploy the containerization of workloads and services.  Kubernetes provides users with the ability to be mobile, being able to run through on-site, hybrid, or public-cloud infrastructure.  Some key features of Kubernetes include automated self-healing, storage orchestration, automated rollbacks and rollouts, IPv4 and IPv6 stacking, and several other key features [1].  For virtual machine execution, Kubernetes Image Builder is helpful because the software helps users create images for a variety of platforms, creating custom images, as well as automatically re-distributing intensive workloads to nodes that are healthy.  This ability allows for improved resource management on a system [2]. The vulnerability, CVE-2024-9486, was determined to have a base score of 9.8 and a ranking of critical, making it extremely important to address and mitigate to prevent further exploitation [3].

Exploitation

It was determined that CVE-2024-9486 was able to be exploited when users installed and configured their virtual machines using custom builder images from version 0.1.37 or earlier [4].  Once installed, the nodes failed to remove and disable the builder account with default login credentials, allowing threat actors to take advantage of this vulnerability through a SSH connection.  From this connection, and the ease of login using default credentials, threat actors can obtain root access to the impacted system [3].

Significance and Impact

While the extent of the vulnerability is not publicly disclosed, potential impact of this vulnerability is extensive because threat actors were able to gain root access to impacted systems.  This would have allowed threat actors to have complete control and do severe system damage including malware/ransomware installation, data theft, and overall disruption to services.

Mitigation

To discover the Image Builder version being used, users can run the several commands [5].

For git clones:

cd <local path to image builder repo>

make version

For installations using a tarball download:

cd <local path to install location>

grep -o v0\\.[0-9.]* RELEASE.md | head -1

For a container imager release:

docker run –rm <image pull spec> version

Or

podman run –rm <image pull spec> version

If the Imager Builder version is found to be version 0.1.37 or earlier, users should then run the command, last builder, in linux to view login attempts onto the builder account.  To mitigate potential exploitation, users are encouraged to rebuild affected images using image versions that are from Image Builder version 0.1.38 or later [4].  The patch disables the builder account once image construction is complete, and assigns a randomly generated password during the image build; this helps ensure that threat actors are less likely to be able to access the system’s root privileges.  If unable to immediately rebuild and restore affected images, users are encouraged to run the command, usermod -L builder, in their affected VMs to disable the builder account [5].

Conclusion

The Kubernetes Image Builder Vulnerability highlights the importance of file and security verifications.  While the vulnerability pertained to custom file images, it is important to always validate files and images being downloaded from the internet either by checking the source URL to ensure that the site is legitimate, file checking using checksums and hashes, or verifying the integrity of a file with digital signatures.  Finally, it is important to check system logs to see activity on a system, if there is activity from users and accounts that are atypical, it is important to investigate and act accordingly to maintain system integrity.

References

[1] Kubernetes. (2024, October 1). Production-grade container orchestration. https://kubernetes.io/

[2] Olaogun, D. (2023, April 27). Making the Right Choice: Kubernetes on Virrtual Machines vs. Bare Metal. https://deploy.equinix.com/blog/making-the-right-choice-kubernetes-on-virtual-machines-vs-bare-metal/#:~:text=Running%20Kubernetes%20on%20VMs%20across,to%20nodes%20that%20are%20healthy

[3] NVD. (2024, October 15). CVE-2024-9486 Detail. https://nvd.nist.gov/vuln/detail/CVE-2024-9486

[4] Toulas, B. (2024, October 16). Critical kubernetes image builder flaw gives SSH root access to VMS. https://www.bleepingcomputer.com/news/security/critical-kubernetes-image-builder-flaw-gives-ssh-root-access-to-vms/

[5] Smith, J. (2024, October 11). CVE-2024-9486: VM images built with Image Builder and Proxmox provider use default credentials #128006. https://github.com/kubernetes/kubernetes/issues/128006