Danger of Misconfigured ArgoCD on EC2 Instance

Introduction to GitOps and ArgoCD

Continuous deployment for Kubernetes is made possible with GitOps, which is utilized as an operating model for Kubernetes and cloud-native application development. The GitOps methodology takes its name from Git, the most widely used version control system. Code review methods and version-control systems allow for the controlled deployment and rollback of configuration changes.

When it comes to GitOps instruments, ArgoCD is among the top choices. It is a declarative GitOps tool designed for developers that do not require full access to the Kubernetes infrastructure, and it is used to deploy apps to Kubernetes. ArgoCD checks the current state of running apps against the ideal state as stated in Git. ArgoCD will alert you to any discrepancies between the live and target states of your application and facilitate the automatic synchronization of the live state to the target state.

The potential dangers of improperly using ArgoCD

As with any other GitOps tool, ArgoCD may be customized and set up in the cloud to help developers working in the Kubernetes environment. The cloud’s infrastructure may be at risk if connections using these tools aren’t secured.

When setting up an application in ArgoCD, the user is prompted to specify the location of a file (either local file on URL) containing the necessary key/value pairs. Knowing that our Kubernetes infrastructure with it’s tools are running on AWS EKS, we can use our IMDS expertise to enable ArgoCD’s communication with IMDS endpoints and collect the EC2 instance’s metadata.

Using Instance Metadata Service, AWS grants users access to the metadata of their EC2 instances (IMDS). IMDS is available in two versions, IMDSv1 and IMDSv2. IMDSv1 is regarded as less secure than IMDSv2 since it does not need authentication to interact with the instance meta data service, whereas IMDSv2 is session-based.

You can try it yourself, to retrieve the information from the instance metadata service, you need to run the below cURL command on an EC2 instance running on Linux operating system:

[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/

With the aforementioned information and points, malicious actors with authorized or unauthorized access to ArgoCD can take advantage of the new application creation feature in ArgoCD to initiate an unauthorized communication with IMDS, resulting in the leak of sensitive information like the EC2 instance metadata (operating system, account id, region, etc.), allowing them to collect even more information about the running EC2 instance, which can be used to proceed with further attacks.

To carry out the exploit, you must visit the “Create new application” page. Then specify the following URL as the file from which you wish to extract the desired key/value pairs.

http://169.254.169.254/latest/dynamic/instance-identity/document

Once the application has been created, the Parameters section may be accessed from the application details page. Key/value pairs representing the obtained results can be found there.

EC2 instance metadata

Let’s get the AWS credentials

Access tokens for your AWS infrastructure may be retrieved by the users of any public-facing internet application by establishing connection with the IMDS. Additionally, if the role assigned to the EC2 instance has an overly permissive policy, the attack can spread to compromise the infrastructure, resulting in the disclosure of sensitive information, unauthorized access to other AWS services, and, worst case scenario, complete access to the infrastructure.

Malicious actors who want more information, for example temporarily access tokens, can repeat the same steps above, but with a new endpoint:

http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Then, the aws_access_key_id, aws_secret_access_key and token that can be used to run commands against the AWS environment are retrieved to the UI.

AWS access token was retrieved

After obtaining credentials, malicious actors are interested to gain access to the AWS infrastructure and know which permissions they have now to proceed with further attacks. A good tool that helps in such situation is Enumerate IAM permissions.

https://github.com/andresriancho/enumerate-iam

After enumerating the permissions and knowing which permissions does the assigned role have, the official AWS CLI tool comes in place, it supports the AWS administrators to control multiple used AWS services from the command line.

In the worst-case scenario, malicious actors could bypass all the security restrictions and take control of the Kubernetes infrastructure, putting the users of the applications in danger through the modification of the CI/CD pipeline leading to modify the components and push malicious content from untrusted resources.

Execute commands against AWS with the leaked credentials

Solution

While this is not a problem with ArgoCD itself, you should block access to the AWS instance metadata service from any application that has a feature allowing users to construct connection with a destination determined by user input (which, in this case, is ArgoCD). Also, ensure to limit the IP addresses and TLDs that users can use to retrieve data from (GitHub servers, Values files location, etc).