Active Directory Domain Controller Hacked Through Remote DNS Management?

This is my initial reaction to Microsoft's Security Advisory 935964, and should be correct to the extent the advisory is complete and correct.

Through a buffer overflow attack on the RPC port of a Windows server an anonymous user can execute code in the DNS. Since the Windows DNS Service is integrated with Active Directory and often run on a domain controller, this means the attack has the opportunity to compromise a Windows domain controller, which is a great start towards

• Compromising other domain controllers (DCs)
• Compromising computers in the forest, attacking non-forest computers in the zone of trust accessible to the DC
• Escalating any kind of privilege that is controlled by groups, accounts or other objects in the Active Directory
• Intelligence gathering
• Doing mischief with DNS against anything that uses the DNS

No information has been released yet on how Microsoft found out about this targeted, undercover exploit and what was compromised – maybe they saw the vulnerability for sale out in hacker land, but there could be some very unhappy security departments out there that aren’t talking about this publicly!

And the auditors should be asking questions – how does your organization know this couldn’t have happened to you, that it didn’t happen, that it didn’t compromise regulated environments.

I find this to be a very significant advisory because it demonstrates some important concepts my colleagues and I have been writing about

• Risk aggregation in Active Directory forests (first written about by us circa 2000) – don’t integrate sensitive environments with a single forest that contains lower surety elements
• Targeted attacks and undercover exploits – this doesn’t look like a worm put out for show, this is going after the money
• The need for a perimeter layer of security (network IDS and firewall traffic control) to serve as a preventive or detective control for vulnerable hosts that perform critical functions
  

No patch yet. The workaround is to lock down the RPC port on the host (so it can’t be managed remotely) and/or through firewalls (so the RPC port is blocked). The trouble is, organizations actually need to be able remotely manage DNS and other things on the DC. They can shut remote management down temporarily while waiting for the patch, but the longer they have to wait, the more painful this get for network and security support.

Organizations that have implemented what we call a “control zone” – where domain controllers and other sensitive infrastructure are firewall protected so the ports used for remote management are either blocked (if unneeded) or restricted to authorized IP addresses or IPSec authenticated hosts. Microsoft has provided some documentation on how to run domains and forests within firewalls by tunneling DC to DC traffic through IPSec http://www.microsoft.com/downloads/thankyou.aspx?familyId=c2ef3846-43f0-4caf-9767-a9166368434e&displayLang=en but I haven’t reviewed this in depth yet. There is also some good information in the blog entry http://blogs.zdnet.com/Ou/?p=469.

Finally, I want to say that these kinds of exploits can happen to any operating system. Microsoft is to be commended for its responsible disclosure of the problem so that organizations can undertake workarounds. Microsoft also warned about risk aggregation years ago when identified that the domain is not a security boundary when included in a forest. But many customers still persist in creating large forests, not protecting their control zone and may be including things in the forest that they shouldn't.