Friday, March 18, 2016

Windows Advanced Firewall - Bugs in Canned Rules for Domain Controllers

So, in what I consider to be a significant advance in the security of our Domain Controllers, we decided to switch on the Windows Advanced Firewall. Not for the feint of heart, the obvious challenge is to ensure all the rules are in place to allow the DCs to continue to function correctly. The good news is that since the Windows Firewall service runs by default (regardless of whether the firewall is switched on), it 'learns' rules as software is installed and also, when the server is promoted to a DC. This results in the firewall being preconfigured for you with a set of 'canned' exceptions.

However

After I noticed that the canned exceptions for our backup system (EMC Networker) had been applied to only the 'Public' profile and not the 'Domain' profile (because our build process installed Networker before the domain join), I decided to go through the canned Domain Controller exceptions with a fine tooth comb, and actually recreate them in the requisite GPO by hand. I found errors:

Bug #1 Windows Time
As Microsoft themselves explain, if you create an exception to allow access to

%systemroot%\system32\svchost.exe

then you must further qualify that exception by specifying the service you require access to. This is because svchost.exe is the executable that runs all Windows services. There also seems to be a drastic shortage of commas (Oxford and otherwise) within the Microsoft documentation team.

"Adding a service container or a program that host services, such as Svchost.exe, Dllhost.exe, and Inetinfo.exe, to the rules list without further restrictions in the rule might expose the computer to security threats. Adding these containers might also conflict with service hardening policies on computers running this version of Windows."

https://technet.microsoft.com/en-us/library/dd448559(v=ws.10).aspx

An example would be their canned exception for DCOM, it specifies

%systemroot%\system32\svchost.exe

but further qualifies that exception to the service 'Remote Procedure Call (RPC)' which is shortened in the GUI to RPCSS. It also specifies the protocol to TCP and the ports to RPC Endpoint Mapper. However, in the canned exception for the Windows Time system specifies

%systemroot%\system32\svchost.exe (Protocol UDP 123)

but does not specify the Windows Time Service as the qualifying service, contrary to their own advice. Since this bug basically provides unfettered access to any Windows service through UDP 123 (which, by the way, NTP is the oldest surviving protocol in the world) I consider this to be a significant vulnerability.

Bug #2 Fileserver/Printspooler (Spooler Service RPC Endpoint Mapper)
In a similar, but opposite vein, the bug with this canned exception is that the service RPCSS *is* called out as a service ('TCP RPC Endpoint Mapper'), but the executable is defined as 'Any' instead of

%systemroot%\system32\svchost.exe

Which means any that TCP RPC Endpoint traffic is allowed to that service, regardless of which listening executable is addressed.

Update #1 I found some more, WTF Microsoft...

Bug #3 RDP Shadowing
Really Microsoft? RDP Shadows TCP on *'Any'* port? Should be set to TCP 3389

Bug #4 and #5 WMI and WMI (ASync-In)
Instead of TCP on *'Any'* port, how about implementing the following and using port 24158.

https://msdn.microsoft.com/en-us/library/bb219447(v=VS.85).aspx

Bug #6 Routing and Remote Access
Agree with the canned exception for Protocol 47 (GRE) but what about the following missing rules:
PPTP needs TCP 1743
L2TP needs UDP 500 and 4500 as well as Protocol 50 (ESP)
SSTP needs TCP 443 (SSL)

The good news - I learned a lot during this exercise.

Cheers!




No comments:

Post a Comment