Last week I spent entirely too much time talking about DNS, so this week as a fresh change of pace, I’ll be talking about… DNS. You’re welcome. Realistically, you should probably go back and listen to that episode or read the blog post, but if you don’t want to: 1) It’s fine really, we’re not disappointed in you. Really it’s fine. We’re fine. How are you? 2) Here’s the tl;dr:
- DNS was established in 1983 because of the need to have a dynamic, distributed solution for resolving names on the various inter-networks
- The original DNS spec was largely unconcerned with security issues around authentication, integrity, and encryption
- Solutions like DNSSEC and DNS over HTTPS were created to solve those issues
- Naturally, this has led to other issues, especially with DoH becoming more popular
This week we’re going to dig into one of the DNS alternatives that sprung up as private networks became a thing. What type of DNS attacks are out there today. And what the Microsoft ZTDNS solution does to try and ameliorate them.
DNS Alternatives
DNS was created to help with name resolution on networks that spanned multiple organizations. Yes we’re talking about the internet, but also other networks like ARPANet, CSNET, and NSFNET.
The main idea was that you would need distributed, hierarchical name resolution because you had all these different nodes on the network and no central repository of all information. We could get into the whole decentralized nature of the internet and how that was a key design choice, but that is a whole other episode/post unto itself.
My point is that DNS was great for larger shared or public networks, but might have seemed like overkill for an internal network. As a result, IBM established their own internal networking software implementation called the NetBIOS software interface. The name comes from the fact that the networking software ran on the network adapter in an IBM PC instead of running on the CPU itself.
The BIOS on the network adapter handled the network, transport, and session layers of the traditional OSI stack. Programs could interface with the network adapter by sending network control block messages and receiving responses. I’m not going to get into NCBs, except to note that they exist.
NetBIOS
Since NetBIOS was handling network communications, it needed a way to assign and resolve names. Each network adapter could have up to 17 names, one permanent and 16 selectable. The names were limited to 16 characters, a fact that will become important later. The permanent name was tied to the adapter’s unique identifier. Think of it as a proto-MAC address. The names of the local adapter and any other discovered nodes were stored in a name table.
But how did a system on the network learn the names of other hosts and their corresponding addresses? By blasting the network with requests constantly. It's super effective!
NetBIOS could create sessions or send datagrams, TCP and UDP respectively. Datagrams could be used for broadcasts to all nodes on the network, and that is how a name was registered. When a system wanted to use a given name, it simply broadcasted that it was going to use that name. If no system objected (meaning that it was already using the name) then all systems on the network would add that name and address to their table.
NetBIOS naming is completely flat with no hierarchy, and there’s no configured name servers that function as an arbiter. It’s just a bunch of nodes yelling out names into the void. And those names were restricted to 16 characters. As you might imagine, NetBIOS did not scale well.
In an attempt to handle the scaling problem, RFC 1001 established the idea of NetBIOS name servers and datagram distribution servers. The former would act as a sort of bulletin board of NetBIOS name entries, giving clients operating in specific modes a place to go and try to resolve a name instead of blasting it out across the wire. It also helped in routed networks where two clients might not be in the same broadcast domain. The datagram distribution servers? Don’t worry about them, they weren’t really important for name resolution.
The NetBIOS standard also introduced the concept of scopes. NetBIOS names could be limited to a scope, and that scope name could be tacked on to the end to create a hierarchy that is compatible with DNS. And here we began the uneasy alliance of NetBIOS and DNS that persisted for far too long thanks in part to Microsoft and their insistence on backwards compatibility.
WINS
While the RFC 1001 standard established the idea of NetBIOS Name Servers, it was up to the vendors to actually implement such a thing. We’re talking about 1987 here, so Microsoft was working with PC-DOS 3.1 and Windows 2.0. They had a tight relationship with IBM, so naturally they supported the NetBIOS stack which implicitly included NetBIOS name resolution.
The implementation of NetBIOS on Windows was called NetBEUI (NetBIOS Extensible User Interface) and it was supported on multiple network protocols, including IPX, token-ring, and TCP/IP.
With the release of Windows Server NT 3.5, Microsoft introduced the WINS service aka (Windows Internet Name Server) to assist with name resolution over NetBEUI by providing their implementation of the NB name server concept. NT 3.5 also included DHCP, so clients could automatically get their IP address and WINS server settings from the network (Options 44-47).
You know what wasn’t included in Windows 3.5 for either the server or client version? DNS. It wasn’t until the Resource Kit for NT 3.5 that the Microsoft implementation of DNS was made available. At this point we’re still in 1995. Internet connectivity is far from a given, and Microsoft is just trying to support the internal networks that are flourishing at all kinds of companies. They embraced the name resolution offered through NetBIOS and NBNS, and didn’t give DNS much more of a thought, right up until Active Directory and Windows 2000.
Active Directory
If you’ve ever been in charge of maintaining Active Directory, you’ll know how absolutely critical DNS is to the functioning of basically everything in AD. Domains and forests themselves are DNS constructs and resolved as such. But since Microsoft absolutely cannot deprecate anything, NetBIOS stuck around and many components of the operating system would default to using it for name resolution. SMB in particular was a major offender. So while DNS was ostensibly the way forward, you still had to deploy WINS servers if you wanted anything approaching efficiency on your network. And don’t even think about disabling NetBUEI if you know what’s good for you.
If fact, when you created a new domain in Active Directory, you had to specify its NetBIOS name. If you didn't give it one, Microsoft would use the first subdomain of your Active Directory domain name, e.g. corp.local would have a NetBIOS name of CORP. I haven't touched AD in anger for something like five years, so I don't know if this is still the case.
Twenty years later, it’s now safe to kick NetBIOS to the curb. Maybe. Assuming you’re running a fairly modern stack. And you aren't running any old applications. And you've checked your network traffic for NetBIOS queiries. And you've made the appropriate sacrifices at the Altar of Baal.
Microsoft knows that a lot of cruft still remains, and that’s why WINS deprecation was finally announced only with the release of Server 2022. That’s right, decisions made in 1994 had a direct impact on operating system features 30 years later. At this point you can’t possibly be surprised.
I was going to get into SRV records and maybe write about the Name Binding Protocol in AppleTalk, but um, we’re already in danger of this becoming a 3 part post series, so I’ll stop there. And now for something completely different!
DNS Based Attacks
The long and short of it is that DNS became the de facto name resolution standard for all network types, OT networks notwithstanding. Due to its complete ubiquity, that means it also became a target for hackers. There have been several interesting uses of DNS for malicious motives over the years. Allow me to regale you with the use of DNS Tunneling, which if you listened to our tech news of the week episode you’d already understand, but we know Renaldo skips those, so here’s the deal Renaldo.
DNS Tunneling
If you think about how DNS is typically used, a request is sent via UDP to an IP address on port 53. Assuming a DNS server is listening on the IP address in question, it may choose to respond to the request. Or it may decide to ignore the request entirely. This is UDP we're talking about after all.
Since DNS queries are so common, they are not usually blocked by the network firewall. Even if you block the client from making a direct DNS request to an external host, chances are your internal DNS servers are forwarding requests in their stead. Otherwise, how the hell would your internal clients even access the internet?
So here’s where the hacking bit comes in. An attacker starts by infecting a system with malware using any of the common attack vectors: phishing, malicious websites, USB drives strewn across the parking lot. Once the malware is installed, it can send DNS requests to a command and control (C2) server. The requests look a lot like normal DNS query, but ciphered into the request could be data that is being exfiltrated or a request for commands to be run.
Essentially, the C2 server is registered as an authoritative name server for one or more domains controlled by the hacker. The infected computer will take some piece of information and base64 encode it, which makes it safe as a hostname string. Then the string is broken up so each segment meets DNS requirements, and a record request is sent to the C2 server using that string and the domain name.
The query could be a simple A record request, or a TXT record request, which can have an arbitrary payload of up to 255 characters. Between the encapsulated string in the request and the TXT payload, a full conversation can be had between the client and C2 server. Efficient? No. Sneaky? Hells yeah.
If you see a ton of DNS requests coming from a client for the same domain with gibberish hostnames, that’s probably an infected host. You might have to be quick though, because hackers know you’re looking for this type of activity, so the DNS tunneling might last only long enough to establish a persistent session over another protocol.
How do you protect against this kind of thing? By applying DNS filtering at the firewall or DNS server level. You can inspect requests for suspicious looking strings in the name of the query or TXT record requests with weird looking strings effectively stop most DNS tunneling. Problem solved right? Um, no.
Last week I wrote about the rise of DNS over HTTPS aka DoH. DoH provides encryption of DNS traffic by establishing a TLS session with the target server before transmitting the request. It’s become the standard for most modern browsers. That’s great for privacy! But it’s less great for traffic inspection.
The client DNS requests are no longer in clear text, meaning that your firewall cannot view the contents and filter them. Which means malware is now free to use that channel instead. Which actually brings us nicely to Microsoft’s ZTDNS solution and me finally landing this plane.
Zero Trust DNS
Zero Trust DNS is a new feature for Windows and its currently in preview. So this is early days. The goal of ZTDNS is to lock down network access to only approved destinations, while reckoning with the modern standards of DNS over HTTPS and DNS over TLS. How do you go about inspecting the traffic without breaking encryption? You don't!
Microsoft’s solution is to perform the inspection before it happens by leveraging the Windows Filtering Platform (WFP) integrated with the Windows DNS client. The WFP allows applications to build network processing rules, including blocking unauthorized traffic to certain destination.
In a ZTDNS scenario, WFP will maintain a list of Protected DNS servers that it trusts. By default, access to all other IP addresses is blocked except for the Protected DNS servers and any exceptions supplied by the administrators. Effectively, your client cannot reach an internet address by default.
When a URL like pickles.cucumbers.com is typed into the browser on a system using ZTDNS, the Windows DNS client will send a DNS resolution request to the Protected DNS servers. If that domain is in a white list of allowed domains, the DNS server will respond with the IP address, which will be added to the allow list in the WFP filter. All other traffic will be blocked by WFP. So even if the client somehow does get the IP address to a malicious domain, the WFP layer will block it.
Protected DNS servers will use certificate based authentication to prove their identity to the ZTDNS client. Connectivity between the client and server is secure using either DoH or DoT, meaning that the server needs to support one of those two protocols. That mean you don't HAVE to use a Windows server to be the Protected DNS server for ZTDNS, but one can imagine that it makes things easier.
You might have caught the fact that this all relies on the use of the Windows DNS client and that browsers tend to use their own DNS client. ZTDNS will absolutely break those browsers, and you’ll need to update the browser to use the Windows DNS client instead. This is also a Windows only solution. Macs and Linux need not apply, at least not yet.
ZTDNS is clearly aimed at managed devices in an enterprise and not your home desktop, but I think it’s an interesting approach and could help combat attacks like DNS tunneling while still making use of DNS protection mechanisms like DNSSEC and DoH.
And that’s it! We did it. Two posts and countless words spilled on DNS to explain a preview feature from Microsoft. Worth it? 100%
You're welcome.
