The document provides an overview of common AWS misconfigurations and exploitation techniques. It begins with an introduction of the speaker and their background and expertise in AWS security. It then covers popular AWS services like S3, IAM, and EC2 and common misconfigurations like publicly accessible S3 buckets, excessive permissions in IAM policies, and using SSRF to access EC2 instance metadata. Tools demonstrated include Bucket-Flaws and IAM-Flaws for scanning AWS environments, and Pacu for post-exploitation of AWS accounts. The document emphasizes that while cloud providers secure infrastructure, misconfigurations of services within the cloud can still lead to breaches.
4. WHY CLOUD?
• Migrating to cloud reduces the risk of being exploited up to a
certain extent and is sometimes better than a traditional
architecture approach.
• The cloud provider is responsible for providing powerful servers
and patching all the servers to protect against known exploits.
• But what about stuffs inside the cloud?
• Do they have proper access control set?
• Are all the services configured in a secure manner?
• You sure you’re not disclosing any api keys or bucket names
publicly?
5. REAL EVENTS
• Capital One Breach : EC2 SSRF > S3 Bucket Access
• FedEx : S3 Public Access
• Imperva : Access to Database snapshot (RDS) via leaked AWS API key
• Tesla : Unprotected Kubernetes Console to AWS S3 Access key and
secret key disclosure
• BHIM UPI : S3 Public Access
And Many More !!
6. WHAT IS AWS?
• Amazon Web Services (AWS) provides on-demand cloud computing platforms and APIs to individuals, companies,
and governments, on a metered pay-as-you-go basis. In aggregate, these cloud computing web services provide a
set of primitive abstract technical infrastructure and distributed computing building blocks and tools. (Source :
Wikipedia)
• Popular Services include:
• S3 – Simple Storage Service
• IAM – Identity and Access Management
• EC2 : Elastic Compute Cloud
• RDS : Relational Database Service
• VPC : Virtual Private Cloud
• Currently one of the leading cloud computing providers in the market.
• Easy to learn and deploy.
7. AWS S3(SIMPLE STORAGE SERVICE)
Amazon S3 is object storage built to store and retrieve any amount
of data from anywhere on the Internet. It’s a simple storage service
that offers an extremely durable, highly available, and infinitely
scalable data storage infrastructure at very low costs.
It provides a simple web service interface that you can use to store
and retrieve any amount of data. Since Amazon S3 is highly scalable
and you only pay for what you use. (Source :
https://aws.amazon.com/s3/faqs/)
8. AWS S3(SIMPLE STORAGE SERVICE)
All the bucket names are unique worldwide and the same bucket name can’t be used by some other
account until and unless the bucket is deleted by the user. The S3 buckets are also associated with the
regions where the user needs to specify the region in which he/she would like the create the bucket.
Few of the URL formats using which you could view your bucket over your browser:
• http://bucket_name.s3-aws-region.amazonaws.com
• http://bucket_name.s3.amazonaws.com
• http://s3.aws-region.amazonaws.com/bucket_name
• http://s3.amazonaws.com/bucket_name
9. FINDING BUCKET NAMES
• Read JavaScript files and search keywords like ‘amazonaws’ in your Burp History. Plugins like Asset Discovery and
AWS Security Checks might help as well.
• Try to generate errors in the target application and sometimes the bucket name might get revealed within the
error.
• Download as torrent files by appending ?torrent after the file name and view the torrent file in some text editor,
you should get the bucket name there itself. (Source :
https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html)
(Note: Amazon S3 does not support the Bit Torrent protocol in AWS Regions launched after May 30, 2016.)
10. FINDING BUCKET NAMES
• Many static websites use the domain name as their bucket name. Try appending s3.amazonaws.com
after the URL or try something like this https://s3.amazonaws.com/domain_name
• Check the DNS records of the target to view it’s CNAME or Canonical name which species a domain is an
alias of another domain.
11. FINDING BUCKET NAMES
• Try using tools like lazys3, bucket finder, s3recon, etc.
• Try appending %c0 or any valid hex values more than two digits like %aa, %b4 etc. after the file name.
This trick was given by Daniel Matviyiv. But this would only work if the domain is pointing to
s3.amazonaws.com/bucketname and not bucketname.s3.amazonaws.com. (Source :
https://twitter.com/0xdabbad00/status/1065668988577828864)
12. FINDING BUCKET NAMES
• Grayhat Warfare (https://buckets.grayhatwarfare.com/): A very well created tool or an open searchable
database that contains around 70,000 open S3 buckets containing interesting files. Bucket names or
files could be easily searched using different keywords.
13. SETTING BUCKET PERMISSIONS
• IAM Policies : Policies applied over users/groups/roles specifying what kind of permissions are allowed
or denied to a particular aws service.
14. SETTING BUCKET PERMISSIONS
• Bucket Policy : Policies applied over S3 Buckets directly specifying what kind of permissions are allowed
or denied to a particular aws user account. (Principal variable in the policy document holds the list of all
aws users that have access to the particular bucket)
15. SETTING BUCKET PERMISSIONS
• Bucket ACL: This is the old way of managing S3 buckets and can control access level of not only buckets
but also of an object.
• Access could be given to specific AWS accounts using canonical id/email id or to multiple pre-defined
AWS groups:
- All Users : Everyone
- Authenticated Users : All AWS users
- Log Delivery : group that has the permission to write access logs objects to the bucket
• Different ACLs include:
- read
- read_acp
- write
- write_acp
- full_control
17. MISCONFIGURATIONS
• Wildcard set as principal or action unintentionally : would lead to a bucket being exposed publicly or
could lead to giving administrative access to the whole bucket
• S3:ListBucket permission set along with S3:GetObject : would lead to directory listing of the bucket.
• AllUsers and AuthenticatedUsers group given full-control or write_acp access : all the users would be
getting administrative access on the whole bucket directly or indirectly
• Bucket Permissions = Union of IAM policies, Bucket Policies & Bucket ACLs (Explicit deny will always
override allow no matter in whatever order it is defined) : might create confusion
• Flawed Group names like AuthenticatedUsers creates confusion : would lead to giving full access to all
the users indirectly.
18. AWS-CLI
• Installation: apt-get install awscli
• Configuration: aws configure (Enter your access key and the secret key of your aws account)
• Formats:
aws ec2 ….
aws s3api ….
aws iam ….
19. BUCKET-FLAWS
• Lightweight bash script that scans for aws s3 bucket misconfigurations and tries to exploit it with some additional
features
• Performs both authenticated and unauthenticated checks
• Scans at bucket and object level
• Uses the aws inbuilt cli
• Can check for a single bucket as well as list of buckets
• GitHub Link: https://github.com/nikhil1232/Bucket-Flaws
21. AWS IAM
• AWS Identity and Access Management (IAM) enables you to manage
access to AWS services and resources securely. Using IAM, you can
create and manage AWS users and groups, and use permissions to
allow and deny their access to AWS resources. (Source :
https://aws.amazon.com/iam/)
• Simply put, AWS IAM ( Identity and Access Management ) is a web
service that allows handling authorization mechanism in the AWS
environment/console. It is used to set users, groups, roles, policies in
order to give different permissions to different entities.
• The AWS IAM consists of identities and resources where the identities
include the users, groups, roles and the resources include services like
S3, EC2, RDS, etc.
22. AWS IAM : IDENTITIES
• User : A user is an entity that you create in AWS to represent the person or application that uses it to
interact with AWS. A user in AWS consists of a name and credentials.
• Group : A group is an entity that you can create in AWS in order to manage multiple users with ease.
Groups help in assigning and managing permissions of multiple users sharing the same needs.
• Roles : An IAM role is similar to an IAM user, however, instead of being uniquely associated with one
person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard
long-term credentials such as a password or access keys associated with it. Instead, when you assume a
role, it provides you with temporary security credentials for your role session. They are used to grant
specific permission to specific actors for a set of duration of time.
23. AWS IAM : POLICIES
• Policies: A policy is simply an entity/object in AWS which is applied to identities and resources wherein
you could specify what permissions are allowed and denied to a specific set of resources/identities.
• AWS Managed Policies: These are a set of pre-built policies that are managed by AWS itself and each of
the policies is associated with their specific ARNs and could be attached to any of the AWS identities.
• Custom Managed Policies: These policies are created and managed by the customer/user and is also
associated with ARNs. They could be attached to any of the AWS identities.
• Inline Polices: Inline policies are the policies that are specific to a particular specified identity and are
not associated with an ARN. All users, groups, roles could have their own inline policies containing a set
of permissions applied on certain resources. These policies can’t be attached or reused with any other
identity
24. MISCONFIGURATIONS = EXCESSIVE PERMISSIONS
• Pre-Requisites : AWS Keys (Access Keys and Secret keys)
• Post Exploitation Approach
• Rhino labs had come up with a list of 21 possible privilege escalation ways through excessive
permissions in AWS IAM. (https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-
mitigation/)
• This includes escalation to an existing policy, creation of another policy, gaining administrator privileges
and a lot more.
• How to check for misconfigurations/privilege escalation? = ENUMERATION
• Enumeration of all the permissions associated directly or indirectly with the given user.
• We will be discussing 4 possible ways in this session because of the time limit ☺
25. GETTING AWS KEYS
• Since this is a POST Exploitation approach you would need the AWS keys to begin with your scanning.
• AWS keys could be leaked in number of places due to various different scenarios so there is no
particular approach to search for leaked keys.
• Although GitHub is a great place to search for these and maximum amount of leaked credentials are
usually found over GitHub.
• Eg: “anything.com” aws_access_key_id
“anything.com” secret_key
“anything.com” aws_key
• If you are performing an application security assessment, try going through the JavaScript files as the
developers sometimes leave the AWS keys in the comments.
26. FEW MISCONFIGURATIONS SCENARIOS
• New Policy Version Creation:
This leads to creation of a new version of the policy and setting it as the default version.
Permission Required: iam:CreatePolicyVersion
Command:
aws iam create-policy-version –policy-arn <ARN of the policy> –policy-document file:///<path to the json document> –set-as-default
• Policy Attachment to a User:
This would allow a user to attach a managed policy to itself.
Permission Required: iam:AttachUserPolicy
Command:
aws iam attach-user-policy –user-name <username> –policy-arn <arn of the policy to attach>
27. FEW MISCONFIGURATIONS SCENARIOS
• Adding a user to a group:
This would allow a user to add themselves to a group of which they are not a part of.
Permission Required: iam:AddUserToGroup
Command:
aws iam add-user-to-group –group-name <group name> –user-name <username>
• Setting an Inline Policy for a User:
This would allow to either create a new inline policy or update an old inline policy for a user.
Permission Required: iam:PutUserPolicy
Command:
aws iam put-user-policy –user-name <username> –policy-name <policy name> –policy-document <Path to Json Document>
28. IAM-FLAWS
• Lightweight bash script that performs enumeration, scans for aws iam misconfigurations and tries to elevate
privileges along with some additional features.
• Performs enumeration of AWS IAM User, Groups and it’s associated Policies.
• Performs privilege escalation scanning and exploitation based on the enumeration results.
• AWS IAM related CIS Benchmarks checks.
• GitHub Link: https://github.com/nikhil1232/IAM-Flaws
30. AWS EC2
• Amazon Elastic Compute Cloud (Amazon EC2) provides scalable
computing capacity in the Amazon Web Services (AWS) cloud. Using
Amazon EC2 eliminates your need to invest in hardware up front, so you
can develop and deploy applications faster. You can use Amazon EC2 to
launch as many or as few virtual servers as you need, configure security
and networking, and manage storage. Amazon EC2 enables you to scale
up or down to handle changes in requirements or spikes in popularity,
reducing your need to forecast traffic. (Source:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)
31. SSRF TO EC2 METADATA
• What is SSRF? : Server-side request forgery (also known as SSRF) is a web security vulnerability that
allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain
of the attacker's choosing. In typical SSRF examples, the attacker might cause the server to make a
connection back to itself, or to other web-based services within the organization's infrastructure, or to
external third-party systems. (Source: https://portswigger.net/web-security/ssrf)
• What is Instance Metadata? : Instance metadata is data about your instance that you can use to
configure or manage the running instance like public and private IP address, security groups, ami-id,
instance profile keys and etc.
• Instance Metadata can be fetched by calling http://169.254.169.254/latest/meta-data which is a link-
local address and can be called only from an EC2 instance.
32. SSRF TO EC2 METADATA
• However if an IAM Role is assigned to an EC2 instance, the access keys of the instance profile can be
fetched by making a web request to http://169.254.169.254/latest/meta-data/iam/security-
credentials/<name of the role}>.
• Thus a successful SSRF attack over a web hosted on an EC2 Instance by calling the above URL would
fetch the access credentials of the IAM role attached to that instance. This would let the attacker to
impersonate the role attached to the instance and perform any operations as specified in the role.
33. NEW SECURITY FIX: IMDS V2
• The new Instance Metadata Service v2 (IMDSv2) acts as a layer of defense against these kind of SSRF attacks
relying on GET requests.
• With this new version you have to set up a session with the metadata service before you can retrieve
anything.
• A PUT request to http://169.254.169.254/latest/api/token needs to be made with the custom header “x-aws-
ec2-metadata-token-ttl-seconds” with the number of seconds for which the token needs to be active. This
generates a token that would be needed in the next step.
• The token generated would then be supplied as a header value for “x-aws-ec2-metadata-token” in the next
GET request.
• However this is an optional security fix and many organizations that use automated scripts to perform actions
over an EC2 instance would still be relying on the IMDS v1.
• So there is a high chance that the IMDS v1 would still be used by a lot of organizations and won’t be updated
very soon.
More On This : https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-
vulnerabilities-ec2-instance-metadata-service/
35. PACU – AWS EXPLOITATION FRAMEWORK
• Pacu by Rhino Security Labs is a comprehensive AWS security-testing toolkit designed for offensive security
practitioners.
• While several AWS security scanners currently serve as the proverbial “Nessus” of the cloud, Pacu is designed to
be the “Metasploit” equivalent. Written in Python 3 with a modular architecture, Pacu has tools for every step of
the pentesting process, covering the full cyber kill chain.
• GitHub Link: https://github.com/RhinoSecurityLabs/pacu
36. ENDING NOTE
“The blunt realities of public cloud security is that, to date, almost all of the cloud security failures have been attributed
to customer actions. There’s been lots of breaches where people have just left stuff on the cloud, open to everyone.
This is actually the elephant in the room when it comes to cloud security as we are opening ourselves up to the naked
internet with no controls.”
- Craig Lawson, Gartner