Amazon Web Services (AWS) has grown into a powerful platform used by businesses around the world to manage their data, infrastructure, and applications in the cloud. From its beginnings in 2006 with Simple Storage Service (S3), AWS has evolved into a multi-layered service offering that powers much of today’s internet.
----------------------------------------------------------------------------------------------------------
AWS Control Tower and AWS Organizations: Structuring Your Cloud Environment
At the heart of AWS deployments is the AWS account. Each AWS account provides a dedicated environment where you can host services like S3, EC2 (Elastic Compute Cloud), databases, and more. But managing these services across multiple departments or projects in a single account can get tricky. This is where AWS Control Tower and AWS Organizations come in.
What is AWS Control Tower?
AWS Control Tower is a tool designed to help set up and manage a multi-account AWS environment. Think of it as a blueprint or template that helps you organize and secure multiple AWS accounts under a single organization. Even though it’s not mandatory, using Control Tower is a recommended practice for companies managing a large cloud environment. It provides an easy way to enforce security policies and best practices across all accounts.
What is AWS Organizations?
AWS Organizations allow you to group multiple AWS accounts together under one roof, making it easier to manage them from the top down. This structure enables you to apply consistent administration and security policies across all your accounts. Within AWS Organizations, you can create Organizational Units (OUs) to group accounts for specific business units or projects, and apply different policies to each group.
For example, your HR department could have separate accounts for hosting employee data, while the Sales department could have accounts for managing customer data. By separating these functions, you can secure them independently and keep billing records clean and accurate for each department.
----------------------------------------------------------------------------------------------------------
Managing AWS Accounts and Root Users
Each AWS account has a root user created when the account is first set up. This root user has full control over the account, but best practices suggest minimizing the use of the root user to prevent security risks. Instead, it's better to create Identity and Access Management (IAM) users or roles to manage day-to-day operations.
IAM Users and Roles
IAM (Identity and Access Management) is AWS’s system for managing user permissions and access. It allows you to create users and assign roles based on what tasks they need to perform. For example, an administrator might have full access to everything, while a developer might only need access to specific services like EC2 or S3.
IAM users: These are individual identities with specific permissions. For example, Jane might have an IAM user account with access to AWS Lambda but not EC2.
IAM roles: These allow temporary access to an AWS account for specific tasks. Roles are often used for cross-account access or to allow external services to access AWS resources.
The principle of Least Privilege is key here—only give users and roles the minimum permissions they need to do their jobs.
----------------------------------------------------------------------------------------------------------
AWS Secure Token Service (STS) and Temporary Credentials
When users or services need temporary access to AWS resources, they can use the AWS Secure Token Service (STS). STS generates temporary credentials that can last from a few minutes to several hours. This is particularly useful for external users or cross-account access, where you don’t want to hand out long-term credentials.
STS credentials: These are similar to regular IAM credentials but are short-lived, reducing the risk of them being compromised. After they expire, users need to request new credentials.
Federation and roles: If you have users who are authenticated through external services (like Google or Active Directory), STS can provide temporary AWS access by using federated roles.
For example, if a consultant needs access to your AWS environment, you can create a temporary IAM role with limited permissions, and they can assume that role using STS.
----------------------------------------------------------------------------------------------------------
Best Practices for Secure AWS Authentication
There are several ways to log into AWS, but the most common methods are through the AWS Management Console, AWS CLI, or programmatically using access keys. Here’s how to make sure your environment stays secure:
1. Use Multi-Factor Authentication (MFA)
For both the root account and any IAM users, it’s highly recommended to enable MFA. This adds an extra layer of security, requiring both a password and a one-time code from a mobile app or hardware token.
2. Rotate Access Keys
For programmatic access, AWS provides access key and secret key combinations. It’s important to regularly rotate these keys to reduce the risk of exposure. AWS allows each user to have two active sets of access keys, making it easier to rotate them without disrupting services.
3. Use Short-Term Credentials
When possible, avoid using long-term credentials like access keys. Instead, use temporary credentials via STS or instance roles. These credentials expire after a set time, reducing the risk of misuse.
-----------------------------------------------------------------------------------------------------------
AWS Roles, Federation, and Cross-Account Access
One of AWS’s strengths is its ability to manage roles across different accounts and even organizations. For instance, AWS allows cross-account access through roles. Let’s say your company is collaborating with a third party, and they need access to your AWS resources. You
can create a role for them to assume in your account, granting them limited, temporary access.
Federation: Allows users from an external directory (like Active Directory) to access AWS resources using Single Sign-On (SSO) or SAML authentication.
Cross-account roles: These allow users from one AWS account to assume roles in another AWS account, similar to trusts between domains in Microsoft Active Directory.
----------------------------------------------------------------------------------------------------------
For further reading, check out AWS's comprehensive guides on best practices:
----------------------------------------------------------------------------------------------------------
What is the AWS Instance Metadata Service (IMDS)?
The AWS Instance Metadata Service (IMDS) is a feature available on Amazon EC2 instances that provides information about the instance and temporary IAM credentials. It allows the instance to retrieve details like its hostname, network configuration, and most importantly, the IAM role credentials assigned to the instance. While useful for many applications, IMDS also presents a potential security risk if misused, as seen in the infamous Capital One data breach.
The Instance Metadata Service (IMDS) runs on a dedicated non-public network and is accessible only from within the EC2 instance itself. IMDS provides crucial information for an EC2 instance, including temporary credentials for any IAM role assigned to the instance. The metadata can be accessed at the following endpoints:
IPv4: http://[169.254.169.254]/latest/meta-data/
IPv6: http://[fd00:ec2::254]/latest/meta-data/
IAM Role Credentials via Metadata
When an EC2 instance is configured with an IAM role, you can retrieve the role’s temporary access credentials using the metadata service. By querying:
You’ll receive the Access Key ID, Secret Key, and Session Token in clear text, which can be used to interact with AWS services like S3. The temporary credentials are typically short-lived, providing an extra layer of security since they expire after a certain time.
While this service is extremely convenient for developers and system administrators, it can also be exploited if an attacker manages to access the EC2 instance or misconfigurations allow indirect access.
----------------------------------------------------------------------------------------------------------
Potential Exploits of IMDS
Though the metadata service is restricted to internal network access, attackers can still gain access to sensitive data through various techniques if the EC2 instance is compromised.
Server-Side Request Forgery (SSRF) Attacks
One of the most notorious attack vectors is Server-Side Request Forgery (SSRF), where an attacker tricks a vulnerable application into querying internal services, such as the metadata service. By manipulating web requests, an attacker can obtain the instance's metadata, including the IAM role credentials, which they can then use to access AWS resources.
For example, misconfigured reverse proxies can be exploited by sending HTTP requests with modified headers to trick the proxy into querying the metadata service. A 2018 article by Michael Higashi, “Instance Metadata API: A Modern Day Trojan Horse,” highlighted how simple this can be using a curl command to obtain sensitive credentials by querying the internal metadata service.
----------------------------------------------------------------------------------------------------------
The Capital One Data Breach
In 2019, one of the largest cloud data breaches in history affected Capital One, resulting in the exposure of sensitive information of more than 100 million customers. This breach was directly related to the misuse of AWS instance metadata.
How the Attack Happened
SSRF Vulnerability: The attacker identified a vulnerable web application firewall (WAF) running on an EC2 instance in Capital One’s environment. By using a Server-Side Request Forgery (SSRF) attack, the attacker was able to query the instance metadata service and steal the EC2 instance’s temporary IAM role credentials.
Using IAM Role Credentials: After obtaining the credentials, the attacker used them to gain access to Amazon S3 buckets. These credentials provided read access to over 700 S3 buckets containing sensitive data. The attacker copied the data, which included personal and financial information.
Data Exfiltration: The attacker exfiltrated sensitive data belonging to Capital One customers, including Social Security Numbers, bank account details, and credit scores.
This breach not only revealed security misconfigurations within Capital One’s infrastructure but also highlighted the risks associated with IMDS when misused.
Mitigating the Risk: IMDSv2
After the Capital One breach and similar incidents, AWS introduced IMDSv2 to address these risks. The key improvements include:
Session Token Requirement: IMDSv2 requires a session token to be obtained using an HTTP PUT request before any data can be accessed. This prevents simple GET requests from accessing sensitive metadata.
Protection Against SSRF: Most WAFs and reverse proxies do not support PUT requests, making it much harder for attackers to exploit SSRF vulnerabilities to access IMDS.
TTL Settings: The new version sets the Time-to-Live (TTL) for metadata requests to 1, which prevents external routing hosts from passing the requests further, reducing the chances of metadata leaks.
While IMDSv2 greatly reduces the risk of metadata service attacks, AWS has not deprecated IMDSv1. Organizations need to actively switch to IMDSv2 and enforce its use to protect their EC2 instances from similar exploits.
----------------------------------------------------------------------------------------------------------
How to Secure EC2 Instances Against Metadata Exploits
Here are key steps you can take to protect your AWS environment from metadata-related attacks:
Use IMDSv2: When launching new EC2 instances, configure them to use IMDSv2. AWS allows you to enforce this via instance metadata options. You can set a requirement for all metadata requests to use session tokens, adding an extra layer of security.
Limit IAM Role Permissions: Apply the principle of Least Privilege to IAM roles assigned to EC2 instances. Ensure that roles only have access to the minimum AWS resources they need.
Monitor for SSRF Exploits: Regularly audit your web applications for SSRF vulnerabilities. Tools like AWS WAF and third-party security solutions can help detect and block suspicious requests that could lead to SSRF attacks.
Enable Logging and Alerts: Use AWS CloudTrail to monitor API activity, including the usage of temporary credentials retrieved from the metadata service. Set up alerts for unusual activity, such as large-scale S3 data access.
Use Network Security Groups (NSGs): Apply Network Security Groups to control inbound and outbound traffic for your EC2 instances. Restrict network access to only what is necessary for the instance to function.
----------------------------------------------------------------------------------------------------------\
Conclusion
AWS provides a powerful and flexible cloud platform, but managing its security requires a thoughtful approach to account structure, user management, and access controls. By using tools, you can ensure that your AWS environment remains secure, scalable, and easy to manage. The AWS Instance Metadata Service (IMDS) is also an powerful tool, but it comes with significant risks if misconfigured or exploited. By upgrading to IMDSv2, following best practices for IAM role management, and actively monitoring for vulnerabilities, organizations can secure their cloud infrastructure and avoid similar incidents.
Akash Patel
Comments