How I got Time Based SQL Injection in an Old Public Bug Bounty Program

Hi Hekurrrrrrrrrrzzzzzzzzzzzzzz…..

Hope y’all doing well.

I have been doing bug hunting on this particular Bug Bounty Program since last 3 years, It’s a very old program yet I was able to find SQL Injection on it.

I will tell you how.

I cannot disclose the target name hence let’s call it site.redacted.com.

I logged in to the application and saw a chatbox functionality on it for the logged in users through which they can get support assistance. It was a third party chatbox hence I didn’t bother much to test it knowing it would be Out-of-scope. However, I saw a very new feature in it “Connect with AI Assistant”. So this AI assistant feature was a part of the main chatbox when you launch it, it opens an AI chatbox inside the main chatbox.

This was all interesting but the question still remains the same. It would be out of scope, right?

To find the answer I intercepted the “launch AI chatbox” request with my burpsuite interceptor and I noticed that it was trigger an API request to the chat-agent with the authorization token from site.redacted.com.

Once the authorization is complete, the AI chatbox launches and when I enter text in it and send it, it triggers the API request on our target host only.

The request goes like this (with some paramaters in the POST body):

https://site.redacted.com/external-api/chat-agent/api/conversation/message

This is the integration API to the chat-agent and it has many POST parameters in the body so I started testing them for SQLi one by one.

I entered single quote and double quote in all the parameters to see if any parameter is vulnerable to Error-based SQL Injection but no luck.

Now the main domain of this site redacted.com showed in the wappalyzer that it is using MySQL.

With this information, I guessed that this subdomain would also be using MySQL hence I tried to below MySQL Time-based SQL Injection payloads in all the parameters:

(select*(from(select(sleep(5)))a)

And it worked in the userId parameter but something was wrong.

I entered “5” in the sleep function but the application responded in 15 seconds.

To understand this, I entered values 1,3 and 5 in the playload and below are the results.

sleep(1) -> Response time = 3.9 seconds

sleep(3) -> Response time = 9.9 seconds

sleep(5) -> Response time = 15.9 seconfs

Conclusion: The application was adding it’s own processing delay of around 3 second with every 1 second of sleep and it was all fine. It wouldn’t make any difference.

Now it was the time to dump the database using SQLMAP and I was able to do it.

There was one more parameter accountId in the same request which was also vulnerable. I just appended the payload ‘+(select*(from(select(sleep(5)))a)+’ with the existing value of accountId parameter like this to achieve a delayed response:

“accountId”:”12345'+(select*(from(select(sleep(5)))a)+’”

I reported these bugs to the program, they fixed the bugs and rewarded me with bounty.

Tips:

Always test the integration APIs, the burpsuite scans might not reach there.Use the below google dork on your existing targets to find recently updated pages and ind new features or API in them to test for SQLi.

site: target.com after:10 september 2024

There are high chances that those features or APIs are not explored by other bughunters yet.

That’s all for today.

I hope you guys enjoyed reading it. If yes, then don’t forget to clap.

-Kshunya