# How I could have compromised a local company's entire AWS infrastructure

While exploring a renowned local company's website, I encountered a link that redirected me to a suspicious-looking web application. Upon inspecting the application, it became evident that it was certainly susceptible to a security issue; however, the specific vulnerability was not immediately identifiable.

## Analysing JavaScript code for Juicy Secrets

One of my initial steps in hacking a web application involves analyzing JS files. This practice typically aids in identifying the API endpoints that the web application interacts with. To accomplish this, I utilize [LinkFinder](https://github.com/GerbenJavado/LinkFinder), a Python CLI tool designed to extract API endpoints from specified JS files.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703007082432/f1b32a8e-6bac-42c9-aea4-1f97104c44f4.png align="center")

The API endpoints that were identified didn't offer much functionality since the majority of them necessitated a valid session for interaction. Consequently, I returned to manually search for any hardcoded secrets within the JavaScript file.

Upon interacting with the application, I could tell that it was hosted on AWS. Thus, I initiated my search in the JS file for the pattern `AKIA` which serves as the initial characters for AWS Access Key ID, except those retrieved from AWS STS service, which start with `ASIA`. Astonishingly, I discovered several instances matching this search pattern. Consequently, I was able to uncover the AWS Secret Access Key, displayed in plain text, along with other credentials for Auth0. Enclosed below is a heavily redacted screenshot depicting the hardcoded credentials.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703008656874/ef482c72-e8c0-4718-832f-dc71b4da830c.png align="center")

Exporting the AWS access keys on my terminal and running `aws sts get-caller-identity` command confirmed the credentials were valid.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703009045727/e99392a4-4e62-46a2-9153-9056de3bc319.png align="center")

Using the credentials to list all AWS S3 buckets in the organization.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703009305321/bf04c53e-ad5f-4031-8395-7304a3be8251.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703010124392/eefc8f9a-7e6e-48ae-8dd4-4659ada67aca.png align="center")

List all `IAM` users in the AWS account

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703009425540/fc5f350d-e57c-4027-b3c1-4164204fe1c7.png align="center")

Listing all database instances

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1703009530886/d33af866-41cb-4e92-805e-cc812d8e38e8.png align="center")

The exposed AWS credentials evidently possessed Administrator permissions throughout the AWS account, likely resulting from linking the `AdministratorAccess` AWS policy to the `IAM` user. This potential scenario could have empowered a malicious user to inflict significantly greater damage to the provisioned AWS resources.

I sent an email to the mentioned company, clearly outlining the issue and providing recommended steps for remediation. Due to their delayed response, I felt compelled to call them, considering the sensitivity of the issue after which they promptly resolved the vulnerability.

## Conclusion

* It's crucial for developers not to assume that minifying JavaScript code hides any hardcoded sensitive information.
    
* A proactive approach, such as implementing basic security scans in the CI/CD pipelines, helps in identifying and resolving issues like hardcoded credentials before deploying the application. This `shift-left` strategy enhances security measures.
    
* Monitoring the usage of AWS credentials through services like CloudTrail is essential for detecting any abnormal activities or deviations from the usual pattern.