Grab Your AWS Cloud Security — Part-1

Let’s start by reviewing the typical roadmap for cloud security before delving into AWS cloud security specifically. This will provide a better understanding of the steps and considerations involved in securing cloud environments in general.

To ensure the security and compliance of a cloud environment, it is necessary to conduct a thorough cloud security audit that involves several essential steps. Here is a roadmap that outlines the process of performing a cloud security audit.

• Define the scope: Determine the boundaries of the cloud environment that needs to be audited, including the cloud service provider, the cloud infrastructure, and the data stored in the cloud.
• Identify the risks: Conduct a risk assessment to identify potential security risks associated with the cloud environment. This should include a review of the cloud provider’s security controls, as well as any potential vulnerabilities in the infrastructure or applications.
• Evaluate compliance: Determine whether the cloud environment complies with any relevant regulatory requirements, such as HIPAA, PCI-DSS, or GDPR.
• Review access controls: Assess the cloud provider’s access controls to ensure that only authorized users have access to sensitive data and that the appropriate permissions are in place.
• Review data protection: Review the cloud provider’s data protection measures, including data encryption, backup, and recovery processes.
• Review incident response plans: Evaluate the cloud provider’s incident response plans and determine if they have the necessary processes in place to detect and respond to security incidents.
• Review network security: Review the cloud provider’s network security measures, including firewalls, intrusion detection and prevention systems, and other security controls.
• Review physical security: Assess the physical security measures in place to protect the cloud infrastructure, including access controls, surveillance, and environmental controls.
• Conduct penetration testing: Perform penetration testing to identify potential vulnerabilities and assess the effectiveness of the cloud provider’s security controls.
• Review third-party security: Review any third-party applications or services that are integrated with the cloud environment to ensure that they meet the necessary security requirements.
• Develop a remediation plan: After identifying any potential security gaps or vulnerabilities, develop a remediation plan to address them and improve the overall security of the cloud environment.
• Conduct regular audits: Perform regular audits to ensure that the cloud environment remains secure and meets any relevant regulatory requirements.

Information on AWS

• Default settings in AWS Organizations
• Tracking connections in the cloud environment
• Identifiers for IAM users and roles
• Overview of Instance Metadata Service
• Introduction to User Data in AWS
• Risks and prevention measures related to stolen IAM credential

Default settings in AWS Organizations

• Using multiple AWS accounts through a multi-account architecture is a widely adopted best practice in mid-to-large sized AWS environments. This approach provides numerous benefits, and AWS offers a service called AWS Organizations to help organize and manage multiple accounts.
• For Penetration Testers and Red Teamers, it’s essential to have an understanding of the default configuration of AWS Organizations, given its widespread use. When an organization is created, the account that creates it becomes the management account for the organization. Each organization has only one management account, which effectively has ownership of the organization.
• These things combined mean that, should an attacker compromise the management account, the default behavior of AWS Organizations provides a path to compromise every account in the organization as an administrator. For offensive security professionals, identifying paths into the management account can be an incredibly fruitful exercise, and may result in an entire organization compromise.
• For defensive security teams, it would be a good idea to ensure no infrastructure is deployed into the management account to reduce attack surface. Additionally, carefully controlling who has access to it and monitoring that access would also help to reduce risk.

Tracking connections in the cloud environment

• Connection Tracking is a feature of Security Groups in AWS. By tracking network traffic, security groups can allow/deny traffic based on security group rules.
• There are two types of traffic flows: tracked and untracked. For example the AWS documentation mentions a tracked flow as the following, “if you initiate an ICMP ping command to your instance from your home computer, and your inbound security group rules allow ICMP traffic, information about the connection (including the port information) is tracked. Response traffic from the instance for the ping command is not tracked as a new request, but rather as an established connection and is allowed to flow out of the instance, even if your outbound security group rules restrict outbound ICMP traffic”.
• An interesting side effect of this is that tracked connections are allowed to persist, even after a Security Group rule change.
• Here is a simple example: An EC2 instance runs a web application. There is a simple Security Group on this EC2 instance that allows all traffic outbound, as well as SSH, port 80, and port 443. There is an internet-facing EC2 instance in a public subnet.
• https://docs.aws.amazon.com/pdfs/AWSEC2/latest/UserGuide/ec2-ug.pdf#security-group-connection-tracking

• During a penetration test, you gain command execution on an EC2 instance and establish a reverse shell. After performing your attack, you trigger an alert which prompts the defender to follow incident response protocols, potentially based on AWS’s official whitepaper.
• In the “Isolate” step, the goal is to limit the affected EC2 instance’s access with a restrictive Security Group or an explicit Deny Network Access Control List (NACL). However, using a Deny NACL affects the entire subnet, which could disrupt a large number of EC2 instances. Therefore, the preferred course of action is to switch the instance’s Security Group to one that blocks all inbound and outbound traffic.
• The defender changes the Security Group associated with the affected EC2 instance from one that allows web and SSH traffic to one that completely restricts all traffic.

Identifiers for IAM users and roles

How IAM works ! AWS Identity and Access Management

ABIA-AWS STS service bearer token

ACCA-Context-specific credential

AGPA →User group

AIDA →IAM user

AIPA →Amazon EC2 instance profile

AKIA →Access key

ANPA →Managed policy

ANVA →Version in a managed policy

APKA →Public key

AROA →Role

ASCA →Certificate

ASIA →Temporary (AWS STS) access key IDs use this prefix, but are unique only in combination with the secret access key and the session token.

Overview of Instance Metadata Service

• Every EC2 instance has access to the instance metadata service (IMDS) that contains metadata and information about that specific EC2 instance. In addition, if an IAM Role is associated with the EC2 instance, credentials for that role will be in the metadata service. Because of this, the instance metadata service is a prime target for attackers who gain access to an EC2 instance.

How to Access the Metadata Service

• The metadata service can be accessed at http://172.254.169.254/latest/meta-data/ from the EC2 instance. Alternatively, it can also be reached via IPv6 at http://[fd00:ec2::254]/latest/meta-data/ however this only applies to Nitro EC2 instances.
• To get credentials, you will first need to make a request to http://172.254.169.254/latest/meta-data/iam/security-credentials/. The response to this will return the name of the IAM role associated with the credentials. You then make a subsequent request to retrieve the IAM credentials at http://172.254.169.254/latest/meta-data/iam/security-credentials/*role_name*/.
• Please refer to this URL:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata- data-categories.html

Recommended permissions to audit accounts

The following privileges grant various read access of metadata:

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
• codebuild:ListProjects
• config:Describe*
• cloudformation:ListStacks
• logs:DescribeMetricFilters
• directconnect:DescribeConnections

CLI Authentication

• To authenticate a regular user to AWS via CLI, local credentials are required. These credentials can be configured manually in the ~/.aws/credentials file or by running the “aws configure” command. The credentials file can contain multiple profiles, with the [default] profile being used if no profile is specified. Here’s an example of a credentials file with multiple profiles:
• If you need to access different AWS accounts using a profile that has been granted access to assume a role within those accounts, there is a more convenient way than manually calling the STS service every time using the “aws sts assume-role” command and configuring the credentials. Instead, you can use the ~/.aws/config file to specify which roles to assume, and then use the — profile parameter as usual. The assume-role operation will be performed transparently for the user. Here’s an example of a config file that specifies the roles to assume:

[profile acc2]

region=eu-west-2

role_arn=arn:aws:iam::<account-id>:role/<role-path>

role_session_name = <session_name>

source_profile = <profile_with_assume_role>

sts_regional_endpoints = regional

With this config file you can then use aws cli like:

aws — profile acc2 …

Risks and prevention measures related to stolen IAM credential

• Stolen IAM credentials can pose significant risks to AWS environments, as they can provide unauthorized access to critical resources and data. Some of the risks associated with stolen IAM credentials include:
• Data Breaches: Attackers can use stolen credentials to access and exfiltrate sensitive data from an AWS environment, which can lead to data breaches and potential legal and reputational damage.
• Malicious Activity: Attackers can use stolen credentials to perform malicious activities such as deleting data, modifying configurations, launching new instances, or modifying permissions, among other things.
• Financial Costs: Stolen credentials can result in financial losses due to the misuse of AWS resources or unexpected charges resulting from the unauthorized use of services.

To prevent the risks associated with stolen IAM credentials, organizations can implement the following measures:

• Implement Multi-Factor Authentication (MFA): MFA provides an additional layer of security, making it more difficult for attackers to gain access to AWS resources, even if they have stolen credentials.
• Use IAM Best Practices: Organizations should follow best practices for IAM, such as creating strong passwords, enforcing password rotation policies, and restricting access permissions to the minimum necessary.
• Monitor Activity: Organizations should monitor their AWS environments for any suspicious activity, such as unusual login attempts or access to resources from unfamiliar locations or devices.
• Regularly Review and Rotate Credentials: Organizations should regularly review and rotate IAM credentials, such as access keys and passwords, to reduce the impact of a potential compromise.
• By implementing these measures, organizations can reduce the risk of stolen IAM credentials and improve the overall security of their AWS environments.

Part-2

What are the steps to conduct a penetration test within an AWS cloud environment?

To be Continued..

“Thank you for reading my blog post! I hope you found it informative and helpful.”😀