Select Page

I have used DNSstuff and its great online tools for many years to help test the various DNS setups. As a matter of fact, the company I work for was a paying client for some of its advanced professional tools for many years. It provides an independent view of our web-based connection to the outside world. Solarwinds, a provider of IT Management software, acquired DNSstuff in October 2011 and continues to offer its suite of online professional tools for free. I definitely appreciate their tools!

In the recent years I’ve been involved in security testing and remediation at my day job. So when I look at a web application I automatically think about how it can be exploited.

Last week as I looked at one of my favorite tools, https://www.dnsstuff.com/tools, a question came to mind. Could their DNS Lookup tool, which has a field that allows specifying an “optional server” to point the DNS query to, be queried on their local IP?

DNS Lookup

The reason why this would be a significant finding is that it would imply a Server Side Request Forgery (SSRF) vulnerability exists. Sure enough when I used 127.0.0.1 the localhost IP, the DNS server responded! (see below)

dns lookup internal IP

I could have stopped there and submitted a bug report to Solarwinds for a DNS SSRF. I decided to continue because I didn’t think it was necessarily enough to show how serious this vulnerability could be. Providing more evidence of how it could be exploited would make a stronger case of why this sort of misconfiguration should be taken seriously. As my friend Preston Rohner put it so well, it really turned out to be the “top of the rabbit hole!”.

The next logical step for me was to try to find an internal DNS server because it would allow me to learn a lot about the internal infrastructure of the environment. If the service was responding on localhost then I hypothesized it would accept IPs reserved to internal private networks. Sure enough it did.

BurpSuite from Postswigger is a great http interception proxy with powerful tools for manual and automated testing. It was right for the next step. Specifically I used the intruder tool to brute-force for responding IP addressess in the range of 10.0.0.0/16. This can be automated by configuring the corresponding HTTP POST “optionalServer” parameter (see screenshot below). Not wanting to cause any service interruptions, I configured throttling to ensure I wouldn’t overwhelm the service.

burpsuite intruder

My initial attempt at enumeration failed so I sent the POST to BurpSuite’s repeater for closer examination:

burpsuite repeater

Notice the “status”:“PENDING” JSON response:

pending response

Looking closer at the request I noticed the “asynch”: “1” setting. I thought that changing the parameter might make the server wait for a response rather than return “pending.” So I changed it to “asynch”:”0”.

Async response

Sure enough I got results this time and enumeration would now work.

burpsuite results

So, back to BurpSuite’s intruder. Keep in mind the private address space is pretty big right (we’re talking millions of IPs) and I’m using throttling so this could take a while! Going through a couple thousand IPs on 10.0.0.0/16 didn’t return any internal DNS so I decided to stop and try another private range: 192.168.0.0/16. That paid off, I quickly found DNS responding on 5 different IPs from inside the network.

At this point all I’m looking for to close the case is an internal DNS zone to query. Now here I could have gone the brute force way but decided to try finesse instead. One way I may get some clues is by performing a reverse lookup on those IPs basically to query the PTR record of some of the internal IPs that were responding in the hopes of getting some significant results. However, I didn’t get any results on those IPs.

Looking at some of the other tools on https://www.dnsstuff.com/tools, I thought that if one of the tools allowed querying inside the network then another one might also. So I tried the traceroute tool to one of the internal IPs that responded to my DNS queries:

traceroute to internal IP

Uh Oh… Someone didn’t think it would be a great idea to allow a traceroute to internal IPs after all. I noticed that when the query runs, web form passes the IP address in the query string. So I thought that maybe the IP validation was performed only in the HTML form. I found that by modifying the URL I could bypass the validation completely.

traceroute2 URL

OK now we’re getting some interesting information and are literally discovering the internal network, plus we just discovered another SSRF vulnerability.

Traceroute Results

I could’ve stopped here but I really wanted an internal DNS zone to close the case.

The information gathered in that traceroute proved very valuable. It revealed several subnets that the route took to the DNS server and allowed me to discover yet another internal DNS server. I queried the newly uncovered DNS server’s PTR record in the hopes of finding more clues.

Reverse DNS

Yes! This time it paid off and returned the fully qualified name of the host including the internal zone that I was looking for.

One last query I made for good measure:

As you can see I use the internal REDACTED.solarwinds.net zone and using the tools on the webform with the dig-like display type which returns results in a similar format as the Linux dig dns lookup utility.

The results are exactly what I was looking for:

Several internal hosts and internal IP addresses that reveal parts of the internal infrastructure of the environment.

Zone return 1

Zone return 2

Zone return 3

I could’ve probably gone further but I decided this was a good place to stop. I didn’t want to overstay my welcome.

In the process of my discovery not only was I able to map out some of Solarwinds important internal infrastructure but I also discovered additional elements including a VPN tunnel between Solarwinds and Edvantis a Software consulting partner at one of their Ukraine locations judging by the IP in the traceroute below.

Notice how the traceroute travels: we start in the Solarwinds private space, their gateway 10.X.X.1 and end up reaching a VM in Edvantis private space 192.168.X.X going through the public IP registered in Ukraine.  To go from a private space to a public space and then into another private space requires the use of a VPN tunnel.

VPN Traceroute

Discovered VM Host

An SSRF vulnerability like this is very serious. This little hole opens a network up to several different kinds of attacks. I couldn’t find any place where Solarwinds advertises a bug bounty program with clear Rules and Scope, but they did have contact information at https://hackerone.com/solarwinds and I did make contact with their administration so they can fix the vulnerability. Their information security team was quick to respond and remediated the vulnerability I submitted to them in my report.

Share This