Accessing the website directly through its IP address, a case of a poorly hidden sql injection

4 years ago 209
BOOK THIS SPACE FOR AD
ARTICLE AD

Vuk Ivanovic

Image for post

Image for post

an example: where website.com resolves to ip address 10.2.3.2

You may have heard the expression: hiding in plain sight. And specifically in IT security there is another expression: security through obscurity. This article will be my experience with a bug where one could argue that it was the case of security through obscurity, but it could have been a coincidence. This will be a story of me stumbling onto sql injection (a simple login bypass which logged me into admin panel), but not in a usual way. Either way, it should give you an idea or two for what to look for in the future. Unless if you are already on to it.

First impression, wrong impression:

The bbp in question had a wide scope, the trusty *.website.com. Love those :) Which, of course, meant time to do a lot of recon action. Using tools like massdns, amass, a bit of crt.sh, etc.

When all the subdomains were collected, I started going through those that sounded interesting. And, there was this subdomain which just showed a simple Help/About me type of page. At first glance — nothing there. No forms, no additional links, nothing to give a clue about it being anything, but a static page. Time to move on?

Image for post

Image for post

example of a static/boring web page, no bugs here?

Second impression, through different lenses:

When bug hunting, it is essential to think outside the box, which goes hand in hand with not giving up easily. When the target website looks “empty”, think again. There are headers that you can mess with (Host, Referer, User-Agent, etc. especially for blind xss, sql injection), and then there is adding headers that aren’t part of requests by default like X-Forwarded family of headers. But, there is one more thing worth giving a shot, a thing that can be easily either forgotten or wrongly assumed to be a waste of time — ip address.

WAF or no WAF:

Personally, if the target website resolves to an ip address that in turn belongs to akamai, cloudflare, aws, and similar, I tend to leave it be. The whole thing about figuring out the true ip behind the waf is something I had no luck with. But, when the ip doesn’t end up resolving to any of the waf-s or cloud providers, while it may still be associated with vhosts of some kind, you can never tell, unless if you go directly to the ip address in question.

A different kind of wonderful/a simple PoC:

Entering the ip address in the browser loaded a different page, much different.

Image for post

Image for post

The obvious thing to do when seeing login form is:

username: admin’ #

pass: doesntmatter

Of course there are other sql injections for login bypass. And, in rare cases, they work, even in 2020, and this was one of those rare cases.

Read Entire Article