JASBUG: Cutting Through the Fear Uncertainty and Doubt (FUD)

Posted by Jeff Schmidt, CEO and Founder of JAS Global Advisors (11 February 2015)

Wow. Given the rather odd nature of the JASBUG (and the story behind it), there has been a lot of discussion. As can be expected, some of the discussion gets things right, and some not so much.

To clear through the Fear Uncertainty and Doubt (FUD) and focus on a few points that really matter, I’ve written some additional clarifications below. And – most importantly – I provide practical, actionable recommendations for IT professionals.

There is a lot going on here.  Let’s jump-in.

Issue #1: The headline technical issue is an improper use of the Internet’s Domain Name System (DNS) for authentication.

The DNS is a directory, not an authentication tool. It’s a phone book, not a driver license. This is why we focus so much on the infamous lock icon (and green bar) in the web browser – the TLS/X.509 certificate mechanisms provide the cryptographic authentication layer on top of the DNS lookups and subsequent traffic. Without the lock icon, you have no guarantee that you’re actually talking to www.bank.com.

Many – if not most – information security problems have roots in identification and authentication subtleties. When software designers, implementers, and/or users don’t get identification and authentication right, things usually go awry.

The web browser is designed to convey identification and authentication information to the human behind the keyboard, but what if it’s machine-to-machine communication? For example, when your Windows machine is talking to a remote file server? Or when your domain-joined Windows machine (i.e. a member of a corporate Active Directory) talks to the Active Directory Controllers?

When you browse remote file systems in Windows (e.g. \\fileserver\homedirectory), where is the lock icon and reassuring green text? When your Windows machine connects to the corporate Active Directory Controller and downloads really important things like Group Policy Objects to manage your machine, where is the cute little lock? There isn’t one. That doesn’t mean all is lost, it just means that the computers do all of this hard cryptographic authentication work in the background without making a fuss.

Or so we thought it worked like that. In the case of Windows clients, it doesn’t always happen correctly, leaving a situation where browsing to \\fileserver\homedirectory – or more interestingly \\fully.qualified.domain.name.com\homedirectory or \\1.2.3.4\homedirectory (all supported syntaxes) – your computer simply “trusts” that the remote host is who they claim without performing a cryptographic authentication. This leaves the machine vulnerable to Man In The Middle (MITM) attacks.

Not only are Windows clients too trusting of the responses they get back from DNS, they can also be fairly easily tricked into downgrading to unauthenticated and unencrypted transit protocols (like WebDav over http).

Microsoft’s response to both of these problems was to add a new feature called UNC Hardened Access. UNC Hardened Access ensures that the proper level of authentication (and/or in-transit encryption) is in place based on the sensitivity of the communication. Instead of being subject to the OS “trying too hard” to make communication work, the UNC infrastructure within Windows now allows the higher layer resource requestor to specify whether Mutual Authentication, Integrity, and/or Privacy are required for the communication. This is the right, general-purpose solution to this problem.

As an IT system administrator, unless you have strong physical control of your entire network from end-to-end, are sure devices never physically leave your network or connect to other networks, and can assure that only trusted devices are on your network, you’ll want to enable this feature – after carefully reviewing the material from Microsoft of course.

As developers and architects, we should be ever vigilant to improper use of the DNS for authentication. Every secure interaction that starts with a DNS resolution requires a subsequent authentication step.

Issue #2: Active Directory relies on the DNS and interacts with the DNS in unanticipated ways.

One can think of Active Directory is a hierarchical database layered on top of DNS technology and protocols. The interactions between Active Directory and the global Internet DNS are opaque and not universally understood by Microsoft administrators.

Active Directory clients locate resources in a Microsoft network largely through special DNS requests for A and SRV records. Bits of the Active Directory structure like the name of the Active Directory forest, Organizational Units (OUs), and the Active Directory Root wind-up in DNS queries when clients try to find resources. The DNS queries are then mutated by DNS Search Path Processing, which is also, unfortunately, opaque and sloppy.

The resulting exploration of the DNS namespace when a Windows client is looking for resources is surprising: while a simple Windows client is looking for a resource called, say, printer.myou.myad, that may actually result in Internet DNS queries for printer.myou.myad.com, printer.myou.myad, printer.myou, printer.myou.com, and so-on. If the machine is connected to the public Internet – and/or the network is configured in such a way that those queries “leak” out of the enterprise – the Internet DNS infrastructure will attempt to resolve those queries and provide pointers to these resources. Which is almost certainly not what is desired; a result from the local Active Directory controller for your domain is expected.

This is a perverse issue.  Over the course of our research, over 200,000 distinct Active Directories reached-out to us over the Internet via DNS registrations we contrived in various ways.  Think Robert Stucke’s fantastic DEFCON21 talk.

See SAC064 for more information about DNS search list processing.

Microsoft did not address “query leakage” or Active Directory naming problems as related to the global Internet DNS in this round of patches. However, if UNC Hardened Access is enabled, at least in theory even leaked queries would not result in an exploitable situation because the strong authentication step is still required providing cryptographic proof that the client is talking to the server it thinks it is. So even if these queries make it out to the Internet, no harm done.

As an IT system administrator, you should have mechanisms in place to monitor DNS query leakage. Internal DNS queries associated with Active Directory should not be permitted to leave the enterprise boundaries. Additionally, your Active Directory should be named within a global Internet DNS namespace you control to further reduce your risk. For example, if you own company.com, your Active Directory should be rooted in corp.company.com or something similar, so any queries that do leak onto the global Internet DNS go back to you and not to someone else.