Effective threat detection often begins long before the detection engineering itself. A proactive defense strategy includes an in-depth knowledge of the specific patterns that attackers like to abuse. To know what to look for, you need to understand how vulnerabilities work. Let’s analyze a tricky AWS IAM bug that’s been around for years and is finally fixed. Nevertheless, its roots run deep, and the whole principle behind this problem can be abused time and time again in other vulnerable places.
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 the 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 indistinguishable from the legitimate requests. We’ll give you a quick overview, then dive deeper into the root cause.
The CVE-2022–2385 affects the AWS IAM Authenticator for Kuberneteswhich is used by Amazon Elastic Kubernetes Service (EKS) and was discovered by security researcher Gafnit Amiga at Lightspin.
According to Amazon:
“Researcher identified a query parameter validation issue in the authentication plugin when configured to use the ‘AccessKeyID’ template parameter in query strings. This issue could have allowed a knowledgeable attacker to elevate privileges within a Kubernetes cluster.
If you are unsure how AWS IAM Authenticator works, you should know that IAM provides authentication and authorization on your Kubernetes cluster which can be found in your Kubernetes control panel. You can check more information here.
The vulnerability affects anyone using versions of aws-iam-authenticator v0.5.2 — v0.5.8. So, if you’re on this list, please consider upgrading now to avoid critical issues (like privilege escalation activity.)
The problems have been fixed version 0.5.9while its severity is considered high.
The main problem is in the action that allows users to add mappings to the “aws-auth” ConfigMap which includes the {{AccessKeyID}} placeholder. Here is the part of the code that is specifically affected by this problem:
This AccessKeyID could be abused by attackers when they manipulate and use a malicious token. If, as an attacker, I can do this action, then I can replace the {{AccessKeyID}} placeholder with any string I need to perform my attack, and AWS will use them in a mapping action. This could lead to privilege escalation on the EKS cluster.
Interesting way, the AccessKeyID had been workable for almost two years — as of September 2020, when this feature was introduced, until the release of the official patch, which was only added to the master on June 30, 2022. During this time, users of the Prime Detection as Code SOC platform had enough visibility off threats like that, including zero days. Thus, they could detect any suspicious activity long before it is corrected.
The following rules should help you disable anonymous requests to Kubernetes and the execution of malicious commands in legitimate images via obtained credentials. Both of these behavior patterns are related to CVE-2022–2385.
So, using these rules, even if the attackers try to mess with different string parameters other than the corrected one, you can still detect their behavior.
The AWS IAM authentication issue is part of an old bug that still occurs here and there, just like a good old buffer overflow. And it’s not just about usernames. Poor input validation leads to a whole host of problems. If attackers can inject the unexpected input, it may lead to execution of arbitrary code, hijacking of asset control, alteration of control flow, and alteration of data flow.
How do you think the threat detection community should deal with such tricky vulnerabilities?
Unfortunately, case sensitive or insensitive query parameters are like a chicken and egg problem. They often need to be case-sensitive to work properly, which makes input collision possible.
Engineers’ opinions can also vary and be quite specific:
- Query string parameter matching in the case of usernames should be case-sensitive, unlike some scheme-specific calls.
- To make the parameter name case-insensitive, parse the query parameters and create a hash of all lowercase parameters.
- Configure a query parameter matcher with specific value attributes.
- Add a function to avoid duplicate parameter names (like AWS did).
- … and more.
However, all of these ideas require writing code, not using a ready-made thing. And while we all understand the paradox itself, each use case is unique and requires a custom solution.
If you consider the risk to be low, you can limit the security policy to fine-grained threat detection, which can recognize anomalous activity that often looks like valid activity. Otherwise, you can consider using safer third-party services instead of vulnerable ones or develop your own.
