Previously we have set up AWSGoat using terraform and AWS cli. Now its ready to receive requests.
What is The AWSGoat?
AWSGoat is a Vulnerable AWS Infrastructure for teaching people to AWS cloud vulnerabilities and pentesting. It has some vulnerabilities like;
· XSS
· SQL Injection
· Insecure Direct Object Reference
· Server Side Request Forgery on Lambda Environment
· Sensitive Data Exposure and Password Reset
· S3 Misconfigurations
· IAM Privilege Escalations
· ECS Container Breakout
The terraform apply command after finishing gave us this link:
app_url = "https://lboeqh1eq7.execute-api.us-east-1.amazonaws.com/prod/react"
visiting the URL:
Cross Site Scripting (XSS)
In the search bar if I search something that will give me search results:
This is a possible XSS, So I tried a simple XSS Injection and it worked
This proves the site is vulnerable to Reflex XSS attacks.
Clicking on the profile icon at the top - right there is a login page and when we visit it there is a Register page too, lets create a fake account and see what it holds.
lets create a fake account.
After registering it took us to the home page
Insecure Direct Object Reference (IDOR)
Surfing through all the pages there is a profile page where I can change my profile. The possibility of IDOR existing here is high.
I opened burp and started intercepting the requests that's going to the server to understand which API call is used and how it is being used.
Looks like its just changing the password based on an id . That means if we manipulate it we can change the password of another user.
And it worked I successfully changed the password of another user. This confirms the existence of IDOR vulnerability.
SQL injection
Going to the user tab there is a search box, and upon tinkering with it, I found that each time you type something it sends a request to the backend, There is a possible SQL Injection here.
Lets type something and inspect the request
That gives is this an SQL Injection is possible here, lets send it to the repeater.
Now lets go to the repeater tab in burp, and try the SQL Injection
And it works, it gives us all the details about the users present.
Now if we want we can change any users password and impersonate him. But that is not going to get us anywhere.
Server Side Request Forgery SSRF
Now we can check for SSRF vulnerabilities in the webpage, when I went to the newpost tab, I saw that we can upload an image or enter a URL for the image.
What if we put a file URL instead? so I tried to get the contents of /etc/password .
Click upload and submit. Now to view the post go to the Posts tab, and click on all posts.
Click on the post we have created. Go to inspect and refresh the page.
We know that in AWS most of the time, images are stored in S3 buckets, so most probably the file we uploaded in place of the image will also be uploaded to the S3.
Looking at the request there is a png that failed, and it is being loaded from a bucket. Lets see what's inside of it by downloading it. Right click and copy its URL and use wget to download.
This gave us the contents of /etc/passwd
Now we can understand that SSRF is completely possible here.
Lets check other files like environment variables. Lets create a new post and instead of file:///etc/passwd we will look for /proc/self/environ
Now click Upload and go to Burp Suite to intercept the request, turn on response intercept.
We have a bucket link, lets download it and check the contents.
That's the entire dump of the environment variables that has been set in the instance. With a few commands we get a clear view:
Now this has all the credentials and endpoint URL's we need.
lets load this credentials to a separate aws profile by editing the ~/.aws/credentials file.
lets run a identity check command to see if the creds worked:
Okay, that worked. We have the user ID, Account No, and the AWS Resource Name
Gaining access to the EC2 Instance
After surfing around using the credentials and seeing what we have access to, we can finally find s3 buckets, lambda function and two dynamodb tables blog_posts and blog_users.
Use this command to find the functions:
aws dynamodb list-tables --region us-east-1
lets take a look inside those tables
firstly blog-users:
aws dynamodb scan --table-name blog-users --region us-east-1
This contains a list of all the users and their details including security questions and password hashes.
Now lets look at the S3 buckets
This looks odd, a development bucket is also present with the production one. Sometimes this contains important information
lets go through all those files to find something
In this folder: /shared/files/.ssh/ there are multiple keys that was supposed to stay hidden. And in the same folder there is file called config.txt, this file contains information such as IP, hostname, port, user, and the location to the key. Lets download it:
And this is the config.txt:
since we have the IP addresses lets see if they are actually open to receive SSH connections, we will use nmap to scan those ports
Looks like the second IP is ready to accept connections, lets try logging in with its SSH key
We have successfully logged into the EC2 instance.
IAM Enumeration
In the newly exploited EC2 instance lets check the roles we have.
Lets see what all policies does AWS_GOAT_ROLE role have:
The role AWS_GOAT_ROLE has full access to AWS S3.
The other role is in development. lets take a closer look at it:
IAM policies can have up to 5 versions but this only has one.
This looks like we can perform multiple IAM action with this policy. one that stands out is iam:CreatePolicy . This could allow us to create a policy that will escalate our privileges to Admin.
So In order to create a admin account that has privileges to everything like a root account we need to create a policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Now lets create the policy with the name adminesc:
aws iam create-policy --policy-name adminesc --policy-document file://policy.json
Now that we have created a policy that has access to anything like a root user we need to attach it to a user, group or role:
Before we logged into this ec2 machine we had a different role we got from the SSRF attack, its name was blog-application-data .
This role by default this didn't have any high level access like to create a new user or something
as the AWS_GOAT_ROLE we have access to create and attach policies, so we can attach the high privilege policy to blog-application-data
Lets try creating a user again
lets give him maximum administrative access by attaching a administrative policy
We successfully created a Administrative user with maximum privileges.
Roadmap
Top comments (0)