DNS? Yes, we have that - Part 1
A few years ago we tested a company that truly made it a point to invest in good security and built proper planning and awareness. After a few weeks of searching, mapping, trying, and re-trying, we couldn't find a way in. There were some things we could exploit but it was not clean. Yet, we tried. We focused on exploiting any vulnerability on their internet facing systems hoping that some of those systems would not be fully updated, configured or security-hardened. We tried phishing via an email with a weaponized PDF and another with a Word document. We tried social engineering over the phone (we did find several voice mails vulnerable since they used the default password). The employees of this company were well trained and their security department really went out of the way to keep their assets and networks secure.
Short of trying to buy a 0day and play it that way, we really didn't find anything we could use in a short period of time. So, we went for the service providers and partners.
It turned out that this company relied on a 3rd party provider to aggregate all the marketing data and provide research info to their business department. Essentially, their sales people in the field across the world would enter their data on sales, things their customers wanted different, ideas for new products, etc, into this cloud service that could be accessed anywhere in the world. However… The way this was setup, was that the cloud services provider needed to have access to our customer's databases to dump the data. I don't why this was done and who had approved it, but it was a good way to piggy back into the network.
Well, to make it short, we were surprised when we found a neat SQL injection in the login page of the cloud provider. With a bit of playing around, we were able to focus the queries and get data that belonged to our customer. The way their backend was set up, usernames were saved in the clear, right along with real names of the sales and marketing people. Furthermore, one of the tables contained the hashes needed for authentication during the connection to our customer's datacenter. Nice.
We wrote a little utility to test this and we found ourselves being blocked. Well, after some trial and error (and a lot of breaking our eyes going over Wireshark captures) we figured that either a specific IP was expected to be the initiating party for the connection, or we were missing something in the authentication.
So, it was back to the research table.
It was JS that provided a simple solution to try. In the past we've seen customers set firewalls in a way that only a certain IP range can be allowed in. For example, if employees that live nearby all use Comcast as their provider, then the firewall would be set to accept the Comcast IP ranges. JS thought, well, maybe this is the case. Before discarding the little connecting utility, why not try it first coming from an IP that belongs to the same range as the cloud service provider? Sure, challenging since they had their own static IP addresses, but not impossible. We tried that.
It worked… And what we found was, well, very good.
To be continued...