Cloud Pentesting

Cloud basics

Cloud kill Chain

Untitled

A kill chain is useful to conceptualize and associate the steps that attackers might take in different phases of their operation. Recon involves enumeration and foot-printing of the cloud infrastructure attack surface, as well as interacting with publicly exposed cloud services. Low hanging fruit such as S3 buckets and Azure/GCP storage buckets might yield cloud and SSH keys, passwords, confidential documents and personally identifiable information (PII). With access to keys or other credentials, we could look to infiltrate the target environment. Initial situational awareness activities will be undertaken, such as identification of other cloud resources and of the permissions and privileges associated with their current user or application.

With a foothold in the cloud infrastructure, we would then look to undertake privilege escalation activities. Privilege escalation within a specific cloud resource or the general cloud environment is useful, as it allows us to undertake additional activities, such as accessing other users’ data and cloud shell files, or capture traffic, and demonstrates the impact of our compromise. Being able to assume the role of a more privileged user also increases the likelihood of us being able to move laterally between cloud resources, accounts (AWS), projects (GCP) resource groups (Azure), or move laterally from an Azure tenant to an on-prem AD domain. In the final stage, we can demonstrate impact by the secure exfiltration of resources (assuming that this has been approved by the client).

AWS Systems Manager (SSM) VS AWS Secrets Manager

SSM allows us to view and control our infrastructure on AWS. SSM parameters allows for securely storing and managing sensitive information and configuration data. We can store data such as passwords, database connection strings, and license codes as parameter values. SSM and AWS Secrets Manager differ in cost and functionality. SSM is more cost-effective with free standard parameters up to 10,000 entries, while Secrets Manager charges for API calls and per secret monthly.

Secrets Manager offers automatic password generation and rotation, which SSM lacks. Secrets Manager is recommended for comprehensive secret management, while SSM is a cost-friendly, basic solution.

Checklist

Computing Enum

The Instance Metadata service is bound to the IP address 169.254.169.254, which is an internal link-local address that is not exposed or routable externally. We can interact with the service locally via a REST API.

This metadata can contain sensitive information such as credentials, if the administrators have attached an IAM role to the EC2 instance. As the metadata is only accessible internally, this may not appear to be particularly interesting from a security perspective. The presence of this metadata, on the other hand, makes Server-Side Request Forgery (SSRF) vulnerabilities in applications that are hosted on compute instances even more serious.

While the methods discussed in this post will work in cases where the legacy version of Instance Metadata Service (IMDSv1) is enabled, they won’t work with the more secure IMDSv2, which requires token authentication. However, IMDSv1 is still enabled by default, which means that this problem is still extremely important.

Untitled

User Enum

Storage and S3 Enum

## asking for aws key and secret key from the cloud shell
-----------------------------------------------------------------------------------
TOKEN=$(curl -X PUT localhost:1338/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl localhost:1338/latest/meta-data/container/security-credentials -H "X-aws-ec2-metadata-token: $TOKEN"

Last updated