Migrating everything to “cloud” or various online services is becoming increasingly popular in last couple of years (and will probably not stop). However, leaving our most valuable jewels with someone else makes a lot of security people (me included) nervous.

During some of the latest external penetration tests I noticed an increasing trend of companies moving some of their services to various cloud solutions or to their providers. 
When performing the reconnaissance phase of a penetration test, a very important part is to try to map the target assets/network as much as possible. Of course, DNS is one of the most important services, which must be available publicly and which sometimes gets misconfigured (how many times have you seen DNS information about internal assets that gets published on the Internet).

So, a simple dig query will tell us what the DNS servers for our target client are:

$ dig ns target.com
;; QUESTION SECTION:
;target.com.                     IN      NS

;; ANSWER SECTION:
target.com.              1365    IN      NS      zion.target.com.
target.com.              1365    IN      NS      morpheus.target.com.

;; ADDITIONAL SECTION:
zion.target.com.         1366    IN      A       212.71.248.24
morpheus.target.com.     9018    IN      A       88.198.75.37

Now what do we have here? Things look generally OK – there are two DNS servers for our target domain, at two different hosting companies (or, for the sake of this article, we can pretend that they are at the target company’s ISP).

The problem here is that the trust for our most critical infrastructure now completely lays with the ISP (or a hosting company). Why is that a problem? Well – remember all those attacks that happen when an account at a registrar gets hacked and domain information (including DNS servers) gets changed? The same thing applies here – DNS servers are the key to our kingdom.

I recently had to work on an incident that included such an attack where the NS records were modified silently by an attacker that got access to the hosting company. And that attack was very sneaky – the attacker modified only selected DNS records: the MX records. So, for couple of hours during a business day, the attacker changed the MX records (only) to point to his SMTP servers. Those servers were configured just to relay e-mail (and additionally, a specific version of an SMTP server was used to prevent adding headers) to the real destination. This was a very simple Man-in-the-Middle attack that was, unfortunately, very successful for the attacker as he was able to collect and analyze absolutely all e-mail sent to the victim company. While he was not able to see the outgoing e-mails, just remember how many times you’ve seen people actually remove the original e-mail (or reply inline) when replying? This is indeed very rare these days although those older will remember that once upon a time it was part of netiquette. 

Lessons learned here? While outsourcing DNS servers is not necessarily a bad thing, be aware of the risks that come with it (and with cloud usage in general). For this particular case, depending on the business the target company is in, I most of the times recommend that the DNS servers, as critical infrastructure, are kept on premises and managed by local staff. This way, you decrease the risk of the hosting company getting pwned, or simply risk of a disgruntled employee at the hosting company.

If you do decide to outsource DNS anyway, ask yourself first if you would detect the attack I mentioned? What controls do you have in place for detecting such an attack?
Implementation of additional monitoring controls such as regularly checking your critical DNS records (such as NS, MX and possibly A records for critical names) can go a long way and is very inexpensive. For this particular case, SPF would help as well, but unfortunately the majority of servers will simply use SPF information for spam detection and only very rare MUA’s will warn users when SPF records do not match the sending IP address.

Have similar outsourcing war stories? Let us know!

--
Bojan
@bojanz
INFIGO IS