Step by step AWS Cloud Hacking

Slide 1

Slide 1 text

Step by Step AWS Cloud Hacking SecTor 2019 @AndresRiancho

Slide 2

Slide 2 text

The most common attack Using publicly available tools, widely known techniques and no zero days. This is how one of your AWS accounts will eventually get compromised.

Slide 3

Slide 3 text

Storing AWS credentials Most applications running in EC2 instances need credentials to consume the AWS API. Developers can provide these in multiple ways: ● Hard-coded into the application ● Environment variables ● Provided via an instance profile

Slide 4

Slide 4 text

EC2 instance metadata AWS and other cloud service providers attach a virtual HTTP server to each compute instance This server stores information about the instance such as host name, IP address, and instance profile credentials

Slide 5

Slide 5 text

Permissions and least privilege Instance profile credentials have a set of IAM permissions that grant access AWS services such as S3, DynamoDB or EC2. Least privilege principle should be used when configuring these permissions, but...

Slide 6

Slide 6 text

Metadata URLs The instance metadata server lives at: The following paths are used to gain access to the instance profile credentials: The first one returns the role name, which is required to perform the second HTTP request. The second HTTP response yields a JSON document containing the credentials. http://169.254.169.254/ /latest/meta-data/iam/security-credentials/ /latest/meta-data/iam/security-credentials/{role-name}

Slide 7

Slide 7 text

Server-Side Request Forgery

Slide 8

Slide 8 text

Web application vulnerable to SSRF from urllib.request import urlopen from flask import request @app.route('/ssrf') def handler(): url = request.args.get('url') return urlopen(url).read()

Slide 9

Slide 9 text

SSRF Instance metadata Compromised S3 buckets

Slide 10

Slide 10 text

The attacker's view

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

Enumerate IAM permissions In the AWS cloud there are two ways to enumerate permissions for a given credential set: ● Use the IAM service to get the role permissions. In most cases this will fail because the role itself has no permission for the IAM API. ● Call each AWS API and analyze the response: Brute-force

Slide 13

Slide 13 text

Read only calls Enumerate Get* / List* / Describe*. Try anything else and you might change (break) the target AWS account and generate an undesired denial of service attack. There are thousands of API calls

Slide 14

Slide 14 text

Pacu permission enumeration The iam__bruteforce_permissions module implements enumeration for only two services: SUPPORTED_SERVICES = [ 'ec2', 's3' ]

Slide 15

Slide 15 text

Permission enumeration enumerate-iam.py

Slide 16

Slide 16 text

The attacker's view

Slide 17

Slide 17 text

WebApplicationRole Policy { "Statement":[ { "Effect":"Allow", "Action":[ "s3:*", "lambda:*", "..." ], "Resource":"*" } ] } After permission enumeration the attacker knows that he's able to run all read-only API actions for S3 and Lambda. The most common scenario is that all API calls for S3 and Lambda are allowed. Even after permission enumeration there are many things the attacker doesn't know.

Slide 18

Slide 18 text

Escalating IAM privileges Most attackers will try to elevate privileges to a principal with full access to the AWS account There are 28 well known privilege escalation techniques. Most of them are implemented in Pacu. { "Statement":[ { "Effect":"Allow", "Action":[ "*", ], "Resource": "*" } ] }

Slide 19

Slide 19 text

Lambda function and privileged role A commonly exploited privilege escalation method: ● Identify an existing IAM role with high privileges ● Create a new Lambda and associate the role ● Run the lambda function The Lambda function will have access to the IAM role, just like EC2 instances have access to EC2 instance profile credentials.

Slide 20

Slide 20 text

Privilege escalation Getting * on *

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

Hiding the attack There is a small chance of being detected when a new lambda function is created and removed. Another alternative is to change the source code for an existing lambda function to include our exploit.

Slide 23

Slide 23 text

Persistence via trust policies Trust policies limit which principals are allowed to iam:AssumeRole. In the compromised AWS account there is an existing trust policy in the AdminRole which allows all principals in the SSO AWS account to assume role.

Slide 24

Slide 24 text

Persistence via trust policies

Slide 25

Slide 25 text

{ "Effect": "Allow", "Principal": { "AWS": ["arn:aws:iam::925877178748:root", "arn:aws:iam::320222540496:root"] }, "Action": "sts:AssumeRole" } Trust policy modification { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::925877178748:root" }, "Action": "sts:AssumeRole" }

Slide 26

Slide 26 text

Backdooring IAM Role Trust policies

Slide 27

Slide 27 text

Backdoor notifications Each time the backdoor lambda function runs, the attacker receives the ARN for the backdoored role:

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

The Private VPC At this point the attacker was able to gain access to most resources in the AWS account. The accounts payable EC2 instance remains out of reach. The VPC is completely isolated from the Internet.

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Pivoting into VPC networks vpc-vpn-pivot automates the process of creating a VPN between the attacker's workstation and a VPC.

Slide 32

Slide 32 text

Pivoting into VPC networks The permissions required to create a VPN connection using vpc-vpn-pivot depend on the technique being exploited. When no permissions are limiting the attack the default technique with AWS Client VPN is used

Slide 33

Slide 33 text

Connecting to private VPCs vpc-vpn-pivot

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Attack summary From SSRF to complete pwn

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Top #3 Countermeasures Blue team tips

Slide 38

Slide 38 text

AWS credential compromise AWS credentials for your company accounts will be eventually compromised by an evil third-party. SSRF is the most common attack vector but others such as credentials hard-coded in applications, misconfigured AWS Cognito instances, phishing and developer workstation compromise also exist. The following countermeasures focus on reducing blast radius and threat detection.

Slide 39

Slide 39 text

1# Least privilege principle Implement least privilege principle for all IAM principals. Restricted permissions on the web server role WebApplicationRole will prevent S3 bucket access and privilege escalation Restricted permissions on MonitoringRole would have reduced the impact of the privilege escalation.

Slide 40

Slide 40 text

2# Use multiple AWS accounts Reduce the blast radius of any breach by using different AWS accounts to host your company workloads. The accounts payable application should have been deployed in a different AWS account within the same AWS Organization.

Slide 41

Slide 41 text

3# Monitoring Every action performed during this attack created a log entry in CloudTrail, but nobody watches the logs. Use StreamAlert and GuardDuty to identify threats in your AWS accounts.

Slide 42

Slide 42 text

Closing thoughts

Slide 43

Slide 43 text

Key takeaways These are the three most important things to remember: ● It is possible to enumerate AWS credential permissions in a fast, safe and in-depth manner using enumerate-iam ● Cloud exploitation can be automated using pacu ● Private VPC networks can be breached using vpc-vpn-pivot Follow @AndresRiancho on twitter for more interesting cloud security content

Slide 44

Slide 44 text

Thanks!

Slide 45

Slide 45 text

For hire Does your company or startup need these services? ● Cloud Security Assessment ● Intro to AWS Hacking training ● Application Penetration Test ● Source Code Review Let me know, I can help you deliver secure web applications.