High severity flaw allow attackers to bypass Kyverno Signature verification
According to ARMO researchers, The Kyverno admission controller for container images has a high-severity security vulnerability.
Using a malicious image repository or MITM proxy, the bug (CVE-2022-47633) can be exploited to allow an attacker to inject unsigned images into the protected cluster, bypassing the image verification policy.
The flaw could allow attackers to inject malicious code into cloud production environments. Whereby users can use the open-source Kubernetes policy engine Kyverno, which Red Hat maintains on GitHub, to define and enforce policies for their cluster and applications.
Kyverno can be used to ensure that the resources, applications, and other components of a cluster meet operational, security, and compliance requirements. Successful exploitation of the vulnerability could lead to a supply chain problem.
A malicious image registry (or a man-in-the-middle attacker) can inject unsigned arbitrary container images into a protected Kubernetes cluster via the image signature validation bypass vulnerability in Kyverno 1.8.3 and 1.8.4. Because of the use of verifyImages rules for verification, which cannot prevent unknown registries, the vulnerability was introduced in Kyverno version 1.8.3.
According to ARMO researchers, the vulnerability arises because the controller’s signature validation process downloads the image manifest twice but only verifies a signature for one of the downloads.
According to the researchers, after the attack, the hacker can successfully assume command of a victim’s pod and use all of its resources and credentials, including the service account token, to access the API server. By using a malicious image repository or MITM proxy to return a different manifest for the verification process, the validation process was circumvented.
The attackers used social engineering to convince an administrator to insert malicious images into containers. These images are then hosted on compromised accounts, and phishing attacks are used to trick users into using them as well. When the image is first imported, the malicious registry returns to the admission controller a valid image.
The admission controller, on the other hand, demands the manifest of the signed image a second time in order to obtain the digest for mutation; that is, to update the container’s human-readable tag. This time, no signing validation is performed, enabling the malicious registry to return a different, unsigned and malicious image, which is finally spun up and run.
The vulnerability has been addressed in version 1.8.5 by guaranteeing that the same image hash used to authenticate signatures is also employed to modify the workload specification.
The sources for this piece include an article in DarkReading.