Interesting case of SQLi
2020-11-22 05:18:43 Author: medium.com(查看原文) 阅读量:276 收藏

Nik srivastava

Hey everyone, didn’t get time this year to blog about my findings. But this one, I found around 2–3 months back, it was an interesting case and since it's fixed now, I am going to write about it a bit.

I got an interesting case of SQLi on one of Synack program. Since the Program get assigned to me after 3–4 days and there was already an SQLi reported on this one as given in their vulnerability analytics.

I tried to replicate the same, and just by looking at the behaviour of application for this SQLi, I was pretty confident that if I get another endpoint and different parameter, I am gonna have another SQLi and full payout too.

Since only unauthenticated testing was allowed, I started with directories and files brute-force, but the applications keep redirecting me to a login page on each directory and file brute and login page redirecting me to portal page, hence creating a loop.

Image for post

Image for post

I tried to change the method to see if any a particular method is restricted. But the same result.

Well, next I notice that application is using a third-party solution. I googled it and found its a hosted e-invoicing solution. From here, I thought, let's retrieve the application paths and try brute-forcing again with those.

I checked it to see if I can get a copy of it. No, you can’t, because a demo will be available on request

Image for post

I didn’t want to waste my time in requesting for a demo version and it’s a tedious process too(fill the form, talking to the sales guy, giving requirements and bla bla). I searched on GitHub etc to see if any demo version of the application is available with credentials, nothing found. I just had a youtube video of application demo on their channel and nothing else. From the video, i was only able to disclose Invoice details of all of their clients and few rxss but my motive was SQLi. From here, i also got to know that redirection only happen in directories under /portal/ which looks like a core part of the application.

I decided to check the subdomains of the application to see if I can get any demo version hosted on one of their subdomain itself. I mostly use sub-finder for discovering subdomains, so I run a quick scan of it.

Image for post

Cool, I got plenty of subdomains that have demo instance running. The good thing is they weren’t even password-protected lol. But that’s a bit strange too because all demo instance doesn’t have authentication and other subdomains which belong to a client was having the same behaviour as I was getting (redirect loop on login). I started wondering, what if there is no authentication at all? and from their demo video on youtube, client’s don’t need to login into the app, some very specific links were generated and sent to their email, by clicking it, they can view all information related to invoicing or even can pay directly for it.

So, I changed my plan, instead of application path, I captured all post requests from demo instances and replaced the domain to in-scope application domain and then replayed it. To my surprise, it worked without a redirect loop.

Cool, next I checked the SQLi on a parameter and as expected it was vulnerable too. I quickly run sqlmap and got access to all data

Image for post

I reported it and it was accepted within a couple of hours. Synack has a max payout of $3k for SQLi (FYI) if blitz isn’t involved.

Image for post

Stay Home, Stay Safe, Stay Curious!


文章来源: https://medium.com/bugbountywriteup/interesting-case-of-sqli-84cc3f4a5255?source=rss----7b722bfd1b8d--bug_bounty
如有侵权请联系:admin#unsafe.sh