PwnedLabs - Leverage Leaked Credentials for Pwnage
Summary
In this blog, we will take a look at the "Leverage Leaked Credentials for Pwnage" lab, in which sensitve credentials and keys are exposed in a company's public repository which leads access to company's AWS console and SecretsManager further revealing the credentials of database.
Topics Covered
Here are the topics covered in this blog -
Lay of the attack chain.
Detailed explanation of the attack steps.
Possible defensive measure.
Attack Scenario
Official scenario description.
Before we move further into exploitation, I would like to visualize the whole attack chain.
The attacker here is an un-authenticated IAM user -
Discovers an organization's open-source github repository.
Extract sensitive credentials from the .env file.
Uses the credentials to login to the organization AWS Managemet Console.
Discovers secrets and database credentials in AWS Secrets Manager.
Uses database credentials to login and extract the flag.
Setup
For this attack demonstration, we don't require an initial access key of authenticated IAM user. We can use our own AWS keys but it's optional here.
GitHub Repo Enumeration
We're already provided with the target organization's GitHub repository.
https://github.com/huge-logistics/aws-react-app
Visit the following repository.
This is a basic AWS React JS application. There is a .env file which is a hidden file used by a variety of applications and frameworks to define environment variables including credentials.
This file has a lot of credentials related to Laravel, Devops and MySql Databases. Taking a further look.
As we can see that there is AWS Access Key, AWS S3 Bucket name and the region mentioned. We can maybe form an idea to get the AWS account ID from the access key, and see if the database credentials referring to the user Jose are also valid AWS IAM credentials, as password reuse is a common bad practice.
Before that let's verify is the Access Key ID is genuine or not using aws sts get-caller-identity
Now that we have the account ID we can try to login to the AWS Management Console with the URL
For the credentials we can use the Jose username and it's password DevOps0001!
The credentials worked and we got a successful login. Checking out the resources in the recently visited tabs, I found some secrets in Secrets Manager.
Two secrets seems to be intersting.
Employee-database
Employee-database-admin
Clicking on the service we see two secrets relating to an employee-database. We're denied access to the admin secret, let's check the other one which is employee-database-admin.
Checking the “employee-database” secret, then go to “secret value” then click on “retrieve secret value”
From the above screenshot, we can see that it has MySql credentials. Let's login using the credentials.
After logging into MySQL, there is a database called 'employees'.
Changing the database to 'employees' and listing the tables. There are lot of interesting tables.
Checking out the employees table with the query - select * from employees
We retrieve employee data including their full name, email address, phone numbers and salary.
Listing more tables and their contents.
At this point the attacker has gained full access to the target organization's database and can query sensitive data. To finish this lab retrive the flag from the flag database.
Possible Mitigation
The only possible solution is to not to push the .env file into the production which can leak sensitive credentials open to the attack. It is also recommended to implement secure CICD pipelining.
To constantly check for possible leaks in your repository we can use a tool called gitleaks tool to detect.
Thank you for reading 🔥
Last updated
