Securing the Cloud: From S3 Credentials to RDS Database Access

I recently went on a bit of adventure with an application used for webinar and 1:1 meetings. It's a start-up based in Bangalore, and guess what? It ended with me accessing the RDS database! Let me take you through how it all happened.

Discovering the Problem

Everything began when I was messing around with an API used for uploading files. While I was looking at how files got uploaded, I noticed something odd. There were S3 credentials in the API response. These credentials are used to upload customer files to a particular s3 bucket

Digging Deeper

Using these keys, I decided to see what was in the storage. And wow, there were two big areas I got into. One was keeping recorded videos of users webinar , and the other had a bucket with secret-keys-staging

One of the first things I did was list the contents of the bucket, where I discovered a very interesting file named secrets.json. Inside this file were critical details:

The PostgreSQL database's username , password , host and port . Finding such sensitive information was a massive red flag and a clear indicator of severe security oversight.

Interestingly, the secrets.json file also stored the SendGrid API key. If you're not familiar, SendGrid is a popular service used for sending emails, so having its API key is like having the key to the email kingdom! I decided to check out its scope, and it had more permissions than it should have. This would allow unauthorized actions on user's emails and profiles like creating, reading, updating, and even deleting!

The privileges were as follows:

• user.email.create

• user.email.read

• user.email.update

• user.email.delete

• user.profile.create

• user.profile.read

• user.profile.update

With these database access credentials in hand, my next step was to interact directly with the database. To do this, I installed the PostgreSQL client on my machine. This tool, often called psql, is a command-line interface that lets you execute queries, manage data, and interact with the database server more efficiently than many graphical interfaces.

Once psql was set up, I was able to connect to the database using the credentials I found.

Once I got into the database, I could see everything. This capability to directly access and potentially manipulate the database was alarming, as it could lead to unauthorized data access, data tampering, and a host of other security breaches.

As a final step, I decided to explore the actual data to understand the severity of the exposure further. I executed the command SELECT * FROM user_user;

With that command, I was able to see all the user data from the user_user table. I had all the users' data right in front of me. This is the sort of data that should be highly guarded and never be this easily accessible.

After discovering the security vulnerability, I promptly reported my findings to the company's Chief Technology Officer (CTO) and discussed them over a call. The CTO was genuinely impressed with the depth of the findings. In recognition of my contribution to strengthening the company's security measures, I was immediately rewarded with $250. It's worth noting that as a startup in its early stages, they were new to the concept of bug bounties.