Analyzing AWS IAM for Kubernetes Vulnerability: Oldest Trick in the Book?
Efficient threat detection often starts far before the detection engineering itself. A proactive defense strategy includes deep knowledge of specific patterns which attackers love to abuse. To know what to look for, you need to understand how vulnerabilities work. Let’s analyze one tricky AWS IAM bug that had been around for years and now is finally fixed. Nevertheless, its roots are deep, and the whole principle behind this issue can be abused in other vulnerable places time and time again.
Spoiler: there is no magic pill 🤷 (maybe you can create one?)
Our Threat Hunting Engineer Ariel Millahuel analyzes the recently disclosed vulnerability in parameter validation in authentication service. CVE-2022–2385 allows attackers to impersonate other identities and gain privileged access to the EKS cluster. The problem is that the malicious request is not discernible from legit ones. We’ll give you a quick overview and then dive deeper into the root cause.
The CVE-2022–2385 affects the AWS IAM Authenticator for Kubernetes, which is used by the Amazon Elastic Kubernetes Service (EKS) and was discovered by the Security Researcher Gafnit Amiga of Lightspin.
According to Amazon:
“The researcher identified a query parameter validation issue within the authenticator plugin when configured to use the “AccessKeyID” template parameter within query strings. This issue could have permitted a knowledgeable attacker to escalate privileges within a Kubernetes cluster.”
If you’re not sure how AWS IAM Authenticator works, you need to know that IAM provides authentication and authorization on your Kubernetes cluster that’s located inside of your Kubernetes control panel. You can check more information here.
The vulnerability affects everyone who uses versions of aws-iam-authenticator v0.5.2 — v0.5.8. So, if you’re on this list, please consider updating now to avoid critical issues (like Privilege Escalation activity.)
The issues were patched in version 0.5.9, while its severity is considered high.
How does the vulnerability work?
The main issue resides in the action that allows users to add mappings to the “aws-auth” ConfigMap that includes the {{AccessKeyID}} placeholder. Here’s the portion of the code that is specifically affected by this issue:
This AccessKeyID could be abused by attackers when they manipulate and use a malicious token. If I, as an attacker, can do this action, then I can replace the {{AccessKeyID}} placeholder with any string that I need to perform my attack, and AWS will use them during a mapping action. This could lead to Privilege Escalation on the EKS cluster.
Interestingly, the AccessKeyID had been exploitable for nearly two years — from September 2020, when this feature was introduced, all the way to the release of the official patch, which was added to the master only on June 30, 2022. Meanwhile, users of SOC Prime Detection as Code platform have been having quite a broad visibility of threats like this, including zero-days. So they could detect any suspicious activity way before it was patched.
How to Prevent Malicious Behavior
The following rules should help you disable anonymous requests to Kubernetes and the execution of malicious commands in legitimate images via obtained credentials. Both these behavioral patterns are related to CVE-2022–2385.
- Allowed Anonymous Request to Kubernetes Components Detected
- Possible Malicious Commands Execution into Container (via AWS Kubernetes)
So, by using these rules, even if attackers try to play around with different string parameters other than the patched one, you can detect their behavior anyway.
Diving Deeper: Improper Input Validation
AWS IAM authentication problem is part of an old bug that still occurs here and there, just like a good old buffer overflow. And it’s not only about usernames. Improper input validation leads to a whole bunch of problems. If attackers can inject the unexpected input, this may result in arbitrary code execution, hijacked control of assets, altered control flow, and altered data flow.
How do you think the threat detection community should go about such tricky vulnerabilities?
Unfortunately, case-sensitive or insensitive query parameters are like a chicken and egg problem. They often have to be case-sensitive to work properly, making the input collision possible.
Engineers’ opinions might also vary and be quite specific:
- Query string parameter matching in the case of usernames should be case-sensitive, unlike some scheme-specific calls.
- For the name of the parameter to be treated case-insensitively — parse the query parameters and create a hash of all lowercase ones.
- Configure a query parameter matcher with specific value attributes.
- Add function to avoid parameter name duplication (like AWS did).
- … and more.
However, all of these ideas require writing a code, not using a ready-made thing. And although we all understand the paradox itself, every use case is unique and requires a custom solution.
If you consider the risk to be low, you might limit the security strategy to fine-tuned threat detection, which can recognize anomalous activity that often looks like a valid one. Otherwise, you can think of using safer third-party services instead of vulnerable ones or develop your own.
