My Adventure in Bug Bounty: Sharing My Very First Successful Discovery

I felt both excited and terrified as I entered the world of bug bounties. It seemed an endless ocean of opportunities where new challenges arrived with each wave. I felt prepared to make the move after a few months of studying, practicing, and becoming familiar with different tools and techniques. The goal of my research was to gather and promote security feature information for a fictional cloud-based document management startup called InstaDocs. However I was dedicated to find any vulnerabilities, so I began exploring into their document retrieval and user authentication systems.

I started my expedition with a reconnaissance. I wanted to gather information about the application and its endpoints.

Subdomain Lookup
I listed the subdomains for InstaDocs using Sublist3r:

Download Genuine Kali Linux from this link:-

https://www.microsoft.com/store/productId/9PKR34TNCV07?ocid=pdpshare

A few interesting subdomains were identified as a result, especially www.instadocs.com and api.instadocs.com. I worked on www.instadocs.com, which allowed users to access and manage documents.

After browsing the login page, I noticed that users needed to enter their password and username. The login endpoint to which the request was sent looked like this:

POST https://www.instadocs.com/api/login

I made the decision to change the input fields in order to explore further to figure out if the program was vulnerable to SQL Injection.

First Input Check

I started by using some simple payloads to test the login form. For example, I tried entering a single quote (‘) in the username field, which is a common way to test for SQLi vulnerabilities:

I received a generic error message indicating that there might be an issue rather than a specific fault or authentication failure. However, it wasn’t definitive proof of a vulnerability.

Following a few initial experiments, I explored a more advanced method: Time-Based Blind SQL Injection. This method is useful when the SQL query is executed by the program even when no error messages are returned.

I created a payload that would enable me to verify the presence of a vulnerability without instantly sending data. I changed the login request to see if the program would wait to respond depending on how the SQL query was evaluated. For example, I tried the following in the username field:

This payload checks whether the condition 1=1 is true (which it always is), and if so, it instructs the database to sleep for 5 seconds before returning a response. If the application delayed its response, it would indicate that SQL Injection was indeed possible.

Analyzing the Request for Login

I received the request using a tool like the Burp Suite, and I changed the username as you can see above. The server took much longer to respond after the request was sent, indicating that the SQL injection was successful!

I had to extract sensitive data now that I knew how to run SQL queries. I shifted to a more complex payload in order to figure out the username’s length:

In this case, I was trying to see if the length of the username for the first user in the database was 5 characters. If the server delayed its response, I would know that it was indeed 5 characters long.

Repeating With Lengths

In order to find the true length of the username and, by extension, the password, I applied a binary search technique, progressively increasing the length. During this procedure, the payload was slightly changed for every test:

username: admin’ OR IF(LENGTH((SELECT username FROM users LIMIT 1))=6, SLEEP(5), 0) —

After several iterations, I confirmed the username was indeed 6 characters long.

I then wanted to retrieve the username itself. I created a payload that would inform me if, for example, the username’s first character was a “a”:

username: admin’ OR IF(SUBSTRING((SELECT username FROM users LIMIT 1), 1, 1)=’a’, SLEEP(5), 0) —

Again, if the server delayed, I would know the first character matched.

After verifying my ability to obtain usernames and passwords, I got ready to write my report for InstaDocs. This is how it appeared:

Title: Blind SQL Injection with Time-Based Authentication for Users

Summary: InstaDocs’ user authentication method has a Time-Based Blind SQL Injection vulnerability that I found. This vulnerability lets an attacker extract sensitive data from the database without producing any output directly.

Steps to Reproduce:

Impact: This vulnerability allows attackers to extract sensitive information from the database through timing attacks, potentially leading to further exploitation.

Suggested Fix: The recommended solution is to use prepared statements and parameterized queries to stop SQL Injection. Furthermore, ensure appropriate input validation and error handling to prevent error messages from revealing database structure.

After submitting my report, I awaited feedback. A few days later, I received confirmation from the InstaDocs security team that my submission was valid, and they were implementing a fix.

I was excited to get $250 from InstaDocs to celebrate the discovery. This was a huge accomplishment for me, and the satisfaction of finding a genuine vulnerability ignited my interest in bug bounty hunting.

I learned about the complexities of SQL Injection and how crucial it is to understand how databases handle user input from this experience. When performed properly, Time-Based Blind SQL Injection can be subtle yet highly effective.

It also increased my understanding of the ethical responsibility as bug hunters. Not only can reporting such vulnerabilities benefit the organizations involved, but it also improves the overall security environment.

Be creative and diligent as you explore your bug bounty journey; they will be your allies. There’s a chance that applications that appear to be the safest may really have unseen security issues!