In this post I’ll cover some properties of the Windows Server 2019 IPv6 stack. It is an update of a similar post I wrote on the IPv6 properties of Server 2016 a while ago.
For this reason I will mostly look at the same properties I did at the time (read: at times without providing too much technical background information; that can be found in the other post) and I’ve hence performed the same types of practical tests.
Version
This is the Windows version I looked at:
Microsoft Windows [Version 10.0.17763.529]
As of this article this equates to Windows 10 release 1809 but I tested an installation of “Windows Server 2019 Standard”. Being a “server OS” might result in some specific settings (like the creation of temporary addresses being disabled by default) but I expect the majority of the network stack’s IPv6 attributes to be the same.
Tunnel Adapters
All of them are disabled by default now, as was introduced in Windows 10 1803.
mDNS
To my surprise mDNS was enabled and active, as can be observed from the system’s actual network traffic. Not sure when Microsoft introduced this as part of their IPv6 stack – this article talks about “new mDNS functionality” and describes a registry key to, maybe, control the behavior (wasn’t tested by myself) and this post seems to indicate it was actually introduced in Win 10 1809 (also there’s a mention of another registry key called EnableMulticast which, afaik, is the one managed by GPOs for controlling LLMNR) – but in any case I’m not sure I like this one. H.D. Moore just tweeted how mDNS can be used for recon purposes on the local link and Antonios Atlasis had released an mDNS attack tool called Pholus in 2017 (after this Troopers #TR17 talk on “An Attack-in-Depth Analysis of multicast DNS and DNS Service Discovery”).
Suffice to say that I don’t really see a need why Windows 2019 Server has mDNS enabled by default.
DHCPv6
The DHCPv6 DUID is generated as an LLT type (see the old post for more details). Furthermore at the first glance the system seems to expose the same type of DHCPv6 behavior I laid out in the other post (sending out DHCPv6 SOLICIT messages without being “advised” to do so by means of router advertisements with an M flag, and doing so even being a “server”), but there’s a major difference now. When receiving an RA with the O-flag set it sends out a DHCPv6 message type 11 (Information-request, in this case asking for options vendor-specific [17], DNS recursive name server [23], domain search list [24], lifetime [32]) which I’d consider a much more correct behavior than the one Server 2016 exposed. The expected (and in my lab: observed) response to this is a DHCPv6 message type 7 (Reply) containing the DNS resolver(s).
RA Option 25 / RDNSS
Chris had already laid out (in this post) that support of RFC 8106 (IPv6 Router Advertisement Options for DNS Configuration) was introduced with Windows 10 Creators Update (public release in April 2017). Hence this shows as an additional property of the IPv6 stack as depicted below:
C:\Windows\System32>netsh int ipv6 sh int 15 [...] Force ARPND Wake up patterns : disabled Directed MAC Wake up patterns : disabled ECN capability : application RA Based DNS Config (RFC 6106) : enabled DHCP/Static IP coexistence : enabled
Here’s some interesting additional facts, though. When receiving different DNS resolvers via stateless DHCPv6 and RAs now both show up (in ipconfig):
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-2D-54-F5-8D-16-45-03-CD-9E
DNS Servers . . . . . . . . . . . : 2620:fe::fe
2620:fe::9
NetBIOS over Tcpip. . . . . . . . : Enabled
However then only the one obtained from DHCPv6 is actually used for name resolution, as section 5.3.1 from RFC 8106 indicates. For those interested: we had also discussed the behavior of different operating systems in case of conflicting parameters obtained from different sources in this whitepaper.
Looking at the above command output you may further note there’s another new property called “DHCP/Static IP coexistence”. I’ve no idea what it actually does (Chris later provided some background in this tweet), but I noted that it only exists in the setting “enabled” (I didn’t find a way to modify it).
RFC 6939 Support
Roberto Taccon had asked if I could evaluate the support of RFC 6939 (“Client Link-Layer Address Option in DHCPv6”). For some background on RFC 6939 you might read this post which Antonios and I wrote a while ago. Here it should be kept in mind that this RFC 6939 is mainly about a DHCPv6 relay’s capacity to forward a (DHCPv6) client’s MAC address to a DHCPv6 server (which would otherwise only know the client’s DUID). This in turn would allow the DHCP server to perform specific options based on that address, like reservations.
For our purposes/scope this means that “support of RFC 6939” equates to “support on the relay and on the DHCPv6 server”. To test this I built a simple test network with two subnets, a client, a DHCPv6 server (our system in question with the built-in DHCP service) and a Cisco-based router running IOS-XE which, afaik, supports RFC 6939 out of the box. For the protocol here’s the exact image:
Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version Denali 16.2.1, RELEASE SOFTWARE (fc1)
The interface facing the client was configured like this:
ipv6 nd managed-config-flag ipv6 dhcp relay destination 2001:DB8:2:2::20
So the client’s DHCPv6 message gets relayed by the router and it actually contains the option in question:
Point is that the server doesn’t offer any possibility to act on this option. This is what the DHCP server’s GUI looks like, in the context of reservations:
As we can see there’s no field to refer to the client’s MAC address (and I didn’t find any documentation on RFC 6939 on Windows either). So, alas, simply the answer to is: no, apparently Windows Server 2019 does not support RFC 6939.
RFC 6980
I pretty much performed the tests laid out in this post. It turned out that the same methods worked against a system running Server 2019 (and being “protected” by a switch with RA Guard enabled on the attacker’s port). So nothing new here. For the record I also applied the port-based ACL laid out in the slides of our “IPv6 Security in Enterprise Organisations” tutorial (slide #70), with the following results:
– this actually blocked all of the above evasion techniques.
– however, once sending the packets to the to global unicast destination but with a target MAC 33:33:00:00:00:01 (all-nodes) the ACL could be avoided and the attacked system (the one running Server 2019) subsequently accepted the RA and added a second default gateway (with a better metric).
We had described this variant in the ERNW Whitepaper 62 “RA Guard Evasion Revisited”.
For those interested this is done by means of the following command line switches of Chiron:
-tm 33:33:00:00:00:01 -d 2001:db8:1:1:8264:e773:73cc:f999
The full command line of a successful attack could hence look like this:
chiron_local_link.py enp1s0 -ra -s fe80::1 -nf 4 -lfE 60,60 -tm 33:33:00:00:00:01 -d 2001:db8:1:1:8264:e773:73cc:f999
Finally, before you ask: the Windows Firewall (default settings) does not prevent this.
Misc
Fernando Gont had asked if I could check for support of the following RFCs:
- RFC 7112 “Implications of Oversized IPv6 Header Chains”
- RFC 7739 “Security Implications of Predictable Fragment Identification Values”
- RFC 8021 “Generation of IPv6 Atomic Fragments Considered Harmful”
I did not perform any specific testing on the latter two but looking at the results in the above section on RFC 6980 I think the answer re: “support” of RFC 7112 is somewhat clear ;-).
So overall there’s some, as I’d say, progress of the IPv6 maturity of Windows Server 2019, but from a security perspective some things could still be improved (namely the default behavior of DHCPv6 and mDNS).
Happy to receive feedback of any type and/or comments & corrections.
Cheers, Enno