RPC DNS exploit can compromise your whole company

Companies that haven't applied the workarounds for the Microsoft DNS server flaw yet need to make it their top priority. This is NOT something that can wait for a planned weekly or monthly outage; the workarounds need to be applied immediately because of what's at stake. There is already evidence of worm and malware activity probing for this vulnerability because of the value of hacking a Microsoft DNS server, especially the internal DNS, which is usually Active Directory integrated. This can lead to every single computer in your company being silently infected with backdoors and rootkits.

In most enterprise networks, Active Directory is the dominant user directory system in place. The internal DNS server is usually integrated into the Active Directory, and it's often hosted directly on the Active Directory Domain Controller. Even when it's not on the Domain Controller, it's a member server that's managed using Domain Administrator credentials. If that DNS server is not hardened against this latest exploit and it gets compromised, the attacker has full control of that computer and can try to obtain the Domain Administrator credentials through various means. Once the attacker is successful, they can transparently assign software to every member server and client computer in the Active Directory to install any kind of software silently. That means malware can be planted into virtually every computer in the company without any user interaction or knowledge of what evil deeds are transpiring. This isn't intended to be alarmist, but it's important to understand the severity of this issue.

Many people may be under the wrong assumption that this is a DNS attack and that it's someone else's problem because they have perimeter firewalls in place. That isn't the case. All it takes is a single computer to be compromised within the perimeter to compromise the internal DNS server through RPC if the hardening measures have not been taken. The workarounds are simple and effective, but you MUST implement one of the following solutions:

• Implement registry modification to block remote DNS management through RPC.  You can download this REG file here to make the necessary changes automatically on your Microsoft DNS servers. This is the quick and sure way of plugging this hole, but it completely disables remote DNS management. You can still Remote Desktop in to the server or walk up to the console to manage the DNS server, though. You will need to reboot the server restart the DNS service using this option, but most DNS servers and Domain Controllers are redundant, which allows you to reboot one at a time without causing service disruption. If it's your only server, you'll have to take the quick outage because of the severity of this flaw.
• Your second option is to implement host-level firewall (perimeter firewall alone is insufficient) policies that block ports 1024-5000. Once you enable the host-based firewall on Windows Server 2003, you'll need to permit UDP and TCP port 53 on the DNS server. Then, allow only incoming ports 1024-5000 from designated management stations that need to manage DNS remotely. You'll also need to open TCP 3389 to your management stations if you want to Remote Desktop into the DNS server, but this isn't required for remote DNS management. Even when the patch does become available, you should keep these hardened firewall settings as least-privilege best practice. Note that if you're using your Active Directory Domain Controller for DNS, you'll need to follow these instructions to open more ports for the Domain Controller to function. Windows 2000 Servers don't have host-level firewalls, but it's possible to create an IPSEC filter to do the equivalent action. It's a bit more work than using the firewall in Windows Server 2003. If you're not comfortable doing any of this, use the registry change method above.  This method does not require a reboot.

To verify your work, you should test to confirm if you're prevented from managing the DNS server from unauthorized IP addresses if you used the second method. Remote management should always fail if you used the first method. Some of this is a rehash of what I wrote last week, but I wanted to clarify and emphasize how important this issue is.