Hacker Days: Understanding AWS cloud attacks using CloudGoat — OWASP Bay Area
We did an hour-long webinar for OWASP Bay Area Meetup group where I spoke about AWS attacks. As part of the online webinar, I demonstrated attack scenarios for AWS across different services.
The slides and video recording from the online seminar, along with Questions & Answers are presented in this blog post.
Slides
Video
Questions & Answers
How is the permission enumeration done after a get-caller-identity call?
Once the identity of the user is known, the next logical step for an attacker is to identify what privileges they have. In case of AWS there are tools like enumerate-iam that can be used to brute force different List and Get APIs and identify which is success. For more comprehensive results, all Write permissions (Set, Delete, Modify etc.) will also need to be tested which can disrupt the target AWS environment.
It’s not a sure shot way but gives you an idea of what services the user has access to. The only way (without being destructive) to get a complete permission state of the user or role is to look at the attached policy.
Will we just have PPT based walkthrough?
Yes. The screenshots in the presentation are from step-by-step attacks performed on labs that were setup using Cloud Goat.
Can you please explain how SSRF can be protected / mitigated using IMDSv2 at end of session if possible?
IMDSv2 offers API level protection to the instance metadata. So to a certain extent, all Vanilla SSRF can be mitigated.
The new Metadata protocol, EC2 Instance Metadata Service (IMDSv2), mandates making a PUT request in order to get a token. This token must be used in all subsequent requests.
The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates. Sessions can last up to six hours and a session token can only be used directly from the EC2 instance where that session began.
You can also refer this for reference:
But, if your application is hosted on EC2 and provides the ability to users to add custom headers and make requests using arbitrary HTTP methods, then IMDSv2 will not protect the server, as the application can completely mimic requests as if they originate from the server itself.
Is metadata endpoint enabled by default?
Yes.
Can you provide references?
Yes. Here they are. These are also included in the presentation.
From CloudTrail, will we be able to identify these attacks?
CloudTrail will log AWS API requests, which means that all of the demonstrated attacks where an AWS API request was made will be logged.
However, like any logging system, the log themselves will not be flagged as suspicious. A review or analysis of the logs must be done to identify if there was an actual attack. Given that most of these APIs will be used in any case as part of everyday operations, it can get tricky to identify if there was an attack unless a pattern is identified. Source IP address for example could be one of the things to look out for.
What is preventing someone from generating token?
To generate token in IMDSV2, you must be on the EC2 server. So, either you need to have SSH access or console access of the machine or have access to the system in any other way (perhaps via a web application shell) that could allow you to execute cURL commands to perform a PUT request and then pass the token via custom headers.
The IP address 169.254.168.254 is non routable it means you can’t access outside of machine. You have to generate request from machine itself.
If web application is vulnerable to SSRF then user can request for meta data. but if someone outside EC2 instance then there is no way to generate token.
Is there any tool to enumerate s3 bucket?
Here, we are assuming enumerate s3 bucket means finding S3 buckets.
There are multiple tool you can use like Shodan, Certificate Transparency Logs, Censys, GrayHat Warfare bucket search, numerous bucket finder scripts
Some few Bucket finder script /Tools :
nahamsec/lazys3
Contribute to nahamsec/lazys3 development by creating an account on GitHub.
github.com
But, I suggest not to limit yourself to enumerating bucket and downloading data. Also, look for writing permission as well and perform write task as well.
Is there any methodology to Pentest AWS?
There are a lot of resources on the Internet that will walk you through on how to approach a pentest of AWS environment.
From an external attacker point of view, it is not very different from attacking any Internet facing network. You are going to focus the initial discovery on the services that are exposed instead of looking at them as independent AWS things. For example, enumeration of DNS information will point you to EC2 or S3 and then you can test them individually as AWS services.
The MITRE ATTACK threat matrix for IaaS is a good reference document when it comes to AWS. Also, awesome-AWS-security repository on GitHub is a great collection of techniques to use. Focusing on discovery, enumeration and exploitation of each service under AWS is the way to go.
At Appsecco we provide advice, testing and training around software, infra, web and mobile apps, especially that are cloud hosted. We also specialise in auditing AWS environments as per the AWS CIS Foundations Benchmark to create a picture of the current state of security in your AWS environment. Our experience has led us to creating multiple hands on training courses like the very popular “Breaking and Pwning Apps and Servers on AWS and Azure” and “Automated Defence using Cloud Services for AWS, Azure and GCP”.
Drop us an email, contact@appsecco.com if you would like us to assess the security of your AWS infrastructure or if you would like your security team trained in advanced pentesting techniques against AWS.
