Security compromise caused by leaked credentials has been a persistent issue recently, particularly in the last couple of years. One significant contributing factor to such breaches is using long-term security credentials that are not rotated during their lifespan. As a result, these credentials become highly vulnerable to exploitation by malicious actors, who leverage them to gain unauthorized access to sensitive information.

What is IAM, and why is it used?

IAM is a crucial component of AWS and holds a significant position in cloud computing. AWS IAM is a web-based platform that enables the secure and centralized management of access permissions to AWS resources. The service plays a pivotal role in determining who is authenticated and authorized to use the available resources within AWS. With IAM, organizations can effectively manage the access rights of users, ensuring that sensitive information is protected.

However, we will focus on two features of IAM that present some inherent risks with incorrect usage:

• Shared access to your account with either services or humans
• Granting granular permissions to entities (humans/services) for different resources

Are you using IAM correctly?

Cloud practitioners commonly recommend that each entity, whether a human or a service, should have its own unique IAM user within the AWS environment. While this approach facilitates effective management of access permissions, it can present a challenge for security professionals due to the creation of static credentials.

Static credentials, in this context, refer to long-term access keys consisting of an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). See the example below:

provider "aws" {
region = "us-east-1"
access_key = "AKIAIOSFODNN7EXAMPLE"
secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
...


These long-term access keys, linked to an IAM user or role, pose a security risk due to their prolonged lifespan. Unlike other credentials, static credentials can remain valid for up to one year without rotation. This extended lifespan can result in accidental exposure or sharing, leading to unauthorized access to AWS resources until the credentials are deactivated.

Why Developers Hard-code Secrets

There are three main reasons why developers hard code access keys:

1. Convenience

Hard coding secrets in code can be convenient for developers who need to get an application or service up and running quickly. It eliminates the need to set up a separate secrets management system or retrieve secrets from another location, especially when using a code base with thousands of lines. However, problems arise when these keys are forgotten and pushed to public repositories, becoming susceptible to exposure.

2. Lack of resources

Developer teams working on a tight budget may struggle to implement a robust and secure secret management solution. So, they turn to an in-house management solution that is “technically” secure until … it’s not! However, the lack of resources should not be used to justify hard coding credentials into applications and services that will be accessible to the public.

3. Lack of awareness

In recent years, developer teams have implemented security into their development process, using Continuous Integration/Continuous Deployment (CI/CD), which streamlines high-quality software development. Usually, as long as the application was working as intended, security could be addressed later.

Terraform is one of the most common examples security professionals come across using hard-coded AWS access keys. Most individuals use crash courses to glance at the use and implementation of Terraform so that they can start deploying resources in their AWS environment as soon as possible. However, these courses do not provide enough depth on how individuals can grant access to their AWS environment in various ways, and things can get misconfigured. Because it is convenient to hardcode the access keys into the provider block, they do so.

Breaches Caused By Leaked Static Credentials

• An exposed Postman server with hard-coded access keys stored in the project variables led to a compromise. This exposure was uncovered when the Kali Linux user agent made API calls via the Command Line Interface (CLI). (source)
• Long-term access keys were pushed to a publicly available code repository. This breach was detected due to a console login followed by API calls to create another user with long-term access keys, and a policy with high privileges was attached to it. (source)
• A Gitlab vulnerability was exploited to access sensitive data, including admin-level access keys. This data breach was detected due to API calls creating new users and launching too many Elastic Compute Cloud (EC2) instances. (source)
• A compromised access key created a way for an attacker to access Aruba’s environment for 18 days without detection. (source)

Preventing Leakage of Static Credentials

To secure access to resources within the AWS environment and prevent the leakage of static credentials, minimizing the use of long-term credentials is imperative to start with. In addition, the creation and management of IAM users should be restricted to a limited number of trusted individuals, and their access should be carefully monitored.

One solution for centralizing and securing user identities is using AWS IAM Identity Center. This tool enables single sign-on access to multiple AWS accounts through directory credentials and can be accessed through the AWS CLI and AWS Software Development Kit.

Another option is for organizations to manage user identities through services such as Active Directory, Identity Federation, and Providers (IdP and IdF). By using well-known identity providers, such as Facebook and Google, to log in, organizations can eliminate the need for long-term security credentials, which are vulnerable to leaks.

To further reduce the risk of exposure, applications requiring access to AWS should be running within the environment. Applications like Amazon SageMaker Studio have integrated single sign-on capabilities, and support for Security Assertion Markup Language (SAML) 2.0 applications such as Salesforce and Microsoft 365 is also available. For applications outside of AWS, IAM Roles Anywhere can obtain temporary security credentials that follow the same IAM policies and roles as AWS applications, thus eliminating the need for long-term credentials for external workloads outside AWS.

To manage secrets during the development process, tools such as AWS Secret Manager and AWS Vault can be leveraged for secure key storage. AWS Secrets Manager is a fully-managed service that enables you to store and manage secrets and retrieve them through an API call. In addition, it provides features such as automatic secret rotation, integration with AWS services, and granular access control. The tool can also be integrated with a CI/CD pipeline using the AWS SDK for Python (boto3). Here's an example of how you could use boto3 to retrieve secret values, such as database passwords or API keys, from AWS Secrets Manager during a CI/CD pipeline and, in turn, use those secret values to configure applications or run automated tests:

import boto3
import json

def get_secret_value(secret_name):
# Create a Secrets Manager client
session = boto3.session.Session()
client = session.client(
service_name='secretsmanager'
)

# Retrieve the secret value
response = client.get_secret_value(
SecretId=secret_name
)

# Parse the secret value as JSON and return it
return json.loads(response['SecretString'])


Therefore, ensuring that the CI/CD pipeline is configured with appropriate IAM permissions to access the secrets in AWS Secrets Manager is essential. In addition, the pipeline should also be configured with secure mechanisms, such as environment variables or encrypted key files, for storing and managing the AWS access keys.

Opportunities For Detection

Many access keys have been discovered in various sources, such as Docker container images, Postman servers, and build scripts. To mitigate the risk of exposure of access keys, it is advisable to utilize code scanning tools before pushing code to publicly accessible repositories. These specialized tools, such as Snyk and GitGuardian, can be implemented by organizations to prevent such incidents of leaked access keys.

In case of a compromise, alerts can be raised for some of the following events to assist in detection:

• API enumeration calls from the same IP address with different access keys;
• Creation of IAM users;
• Creation of long-term access keys; and
• A sudden spike in EC2 resource usage (this event may be the result of crypto mining).

Key Takeaways

• Most cloud practitioners create IAM users for each entity that needs access to the AWS environment, but this introduces the risk of static credentials, which are long-lived access keys associated with IAM users or roles.
• Static credentials are a security risk because of their long lifespan and potential for accidental leakage or sharing, leading to unauthorized access to AWS resources.
• To prevent leakage of static credentials, organizations can implement SSO using AWS IAM Identity Center, IdP, or IAM Roles Anywhere and limit the creation of IAM users.
• Detection tools can be implemented to scan code before it is pushed to repositories and detect events such as API enumeration calls, creation of IAM users together with access keys, and sudden spikes in EC2 resource usage.

About the Authors

Tadiwanashe Kadango is an Associate Security Engineer at Certus Cybersecurity. Tadiwanashe is responsible for various web application and cloud security engagements.