Further exploits for DNS Remote management vulnerability

Last Friday Microsoft announced a new security vulnerability in DNS management, today the advisory was updated to include reports of an attack in the wild that is trying to exploit this hole.

Whilst the security hole is an issue I'm not overly concerned about it. Certainly I'm tracking it and Microsoft have provided a couple of work arounds for the issue but this is typical security hole that a good security policy would at best prevent and at worst severely restrict.

The explain what I mean let's have a look at the vulnerability in detail:

DNS is a server service that listens on port 53. All DNS servers have to listen on port 53 as it's part of the requirements for running DNS - Changing the port is not an option so that already opens up possible attack vectors and so you lock that down by accepting traffic on port 53 from just a limited range of IP addresses.

However, This new security hole isn't based around DNS as it works on port 53 it's a hole in how DNS accepts remote management requests over RPC. This is a very important thing to understand. Just because it's DNS it's not port 53.

RPC is another protocol that uses ports which cannot be changed and it's also been known as an attack vector for some years. Additionally, RPC is the protocol that allows access to things like the c: drive on most computers and this is one of many reasons that most ISP's block RPC port traffic.

I'm hoping that this goes someway to explaining how this exploit works, if you understand then you will understand what I'm about to say:

The biggest risk from this security vulnerability is from INSIDE the corporate network.

Got that? Good.

Any company that exposes RPC ports inside the network for any user on the Internet to access has already been attacked and has hopefully wised up.
The threat from this security hole is more related to remote management of DNS from internal networks. Most administrators will install the adminpak.msi tools onto their machines and then connect to the DNS server and manage them remotely.

A good security policy which includes locking down remote access to the server for management functions to a limited subset of users would render this type of hole useless before it even gets off the ground.
The fact that an exploit has been crafted which is not a proof of concept is proof itself of companies inabilities to take proper responsibility for the security of their infrastructure.
Windows has shipped with security templates since before Windows 2000 was released, the templates in Windows 2000 were FAR superior to those that you could get for NT but even Windows NT had a lock down tool.

Microsoft often gets blamed for poor security practices but most administrators are guilty of exactly the same. A good sense of security and a good lock down policy will mitigate against most attacks that we see these days.

Author image
Maidstone
IT Person | Veeam Vanguard | VMware vExpert | Windows admin | Docker fan | Spiceworks moderator | keeper of 3 cats | Avid Tea fan