An extremely serious vulnerability in the Kyverno admission controller for container images could permit malicious actors to import a raft of malicious code into the production environments of cloud providers by exploiting this vulnerability.
Using the Kyverno admission controller, the ability to verify signatures is provided as a mechanism for ensuring that only validated and signed containers are pulled into a given cluster running Kubernetes. Many potentially disastrous scenarios can be averted by doing this. There are a lot of malicious payloads that can be found in booby-trapped container images. These include cryptominers, rootkits, container escapes, lateral movement exploit kits, credential stealers, and more.
However, there is a bug (CVE-2022-47633) that can be exploited to undermine the functionality of this mechanism. It has been revealed that an attacker could take advantage of this vulnerability and inject unsigned images into any protected cluster, bypassing the policy of image verification. This was stated in a blog post on Dec. 21 by researchers at ARMO.
There are high stakes here: an attacker can effectively take control of a victim's pod, and let themselves access all of the assets, credentials, and service account tokens of the pod, including the token of the service account, used to access the API server, the researchers cautioned.
Taking advantage of the vulnerability, one can completely bypass the verification process for image signatures. This gives an attacker a wide range of target options when it comes to an attack on a Kubernetes cluster. Ben Hirschberg, CTO, and co-founder of ARMO describe how any workload can mount cluster secrets and data volumes. By having access to the vulnerability of the Kubernetes cluster of the victim of the attack, the attacker can inject code into the cluster. This code steals data and credentials from the cluster. Additionally, the attacker is also able to inject his or her own code, thus allowing the attacker to take advantage of the victim's CPU for cryptocurrency mining.
Subverting the Container Admission Controller: An inside look at the bug
When a new workload is requested from a Kubernetes API server that is defined via an image with a tag, that API server sends a request to the Kyverno admission controller to validate the new workload as defined in the image.
There are several ways in which the admission controller determines whether a workload is admissible to the cluster. This includes requesting the image manifest and the container registry's signature.
The container runtime starts a new workload based on the image. This is true if the image is checked out, and if the image is not checked out, the image does not proceed.
According to the advisory, the vulnerability was discovered as a result of the controller's signature validation process downloading the image manifest twice - but only verifying the signature for one of those downloads.
Hence, the attack looks like this: a malicious registry or proxy is used to socially engineer an administrator into pulling a container image from an infected registry or proxy. In the initial import of the malicious registry file, the admission controller receives a valid, benign, signed image that has been imported by the malicious registry. As of now, everything seems to be working well.
This is followed by a second request from the admission controller for the manifest of the signed image so that the digest for mutation can be retrieved - and it can then be used to alter the human-readable tag associated with the container. In this instance, no signing validation is performed. This allows a different, unsigned and malicious image to be returned by the malicious registry. This image is ultimately the one that will run on your system if you push the button to start it.
This is a classic example of a TOCTOU problem, which means a time-of-check-to-time-of-use problem, in which an attacker can bait and switch their victim, according to a research paper published by ARMO.
Because the image manifest which is going to be used in the end is a different one from the one that was verified, it gives the attacker the chance to trick the client.
Kyverno users should update to version 1.8.5 as soon as possible since this vulnerability was introduced in version 1.8.3 and has been fixed in the updated version. It is ensured that the same hash of the image will be used for modifying the workload specification and verifying the signature in the patch.
In particular, this vulnerability affects only Kubernetes with the Kyverno container manager. Hirschberg warned that other methods of verifying image signatures also need to take care not to be vulnerable to this technique.
Concerns About Container Security are on the Rise
Hirschberg has noted that containers are an excellent target for cybercriminals because they are typically hosted in the cloud. This gives them access to a huge amount of computational resources, which are extremely valuable and expensive. This enables hackers to steal computational resources and data in a relatively short time while also staying unnoticed for a long period.
According to him, there are no exact statistics. However, based on the current trend of containers being widely adopted, it is clear that this type of problem is becoming more prevalent in the industry.
"Security teams are learning how to handle them, and Kubernetes in general. I don't think that it is a true 'blind spot,' but container security teams are still learning the whole environment with many neglected areas", Hirschberg added.
Even though image signature verification has just begun to take off, admission controllers still represent one of those potential areas that may have been neglected due to the early stages of its adoption. Nonetheless, they are also part of a broader dialogue that should be conducted about supply chain software security in a way that considers them an imperative issue.
During the SolarWinds attack, Hirschberg indicated that the world saw how sensitive this issue is when it comes to trusting the security of external code. Kyverno is a security tool that includes signature validation for the first time in the Kubernetes world, and with this, it introduces additional vulnerabilities. However, it does seem that with these vulnerabilities come security improvements that will enable users to overcome this issue in the future.
