Windows Insider

Hollow Man

Knowing how and when to use null sessions, those invisible connections, can get you out of—or into—trouble.

This is my first article as the new columnist for “Windows Insider.” I hope to continue the great work of Michael Chacon in making this a forum for demonstrating the practical implementation of Windows features. I want this to be a place where you can see how other certified professionals use their knowledge to solve real-world problems.

Systems administration is a fiendishly complex business. There are lots of gizmos that interact with each other in unexpected ways. For instance, a colleague recently encountered a situation that shows how a small glitch in the implementation of a group policy can lead to one of the most infamous security vulnerabilities in Windows.

MSIng in Action
My associate was configuring software deployment using Windows 2000 group policies. A software deployment policy consists of a small binary file, called a group policy template, and a pointer in Active Directory that links the template to a container such as an OU, domain or site. The deployment template specifies a UNC path to a shared folder that holds a Microsoft Installer (.MSI) file that holds the script for installing an application and, possibly, all the installation files, as well. If a User or Computer object is in a container linked to the group policy with a software deployment policy, a client-side extension downloads the template and uses it to configure the application for local installation. This is classic client/server technology, and it typically works without a hitch.

The most common way to configure a deployment policy is to use the Assign option. This installs shortcuts in the Start menu but doesn’t actually install the application until the user launches it, thus avoiding a huge logjam during the morning logon. It sometimes happens that the engineer who designs an .MSI package will decide not to download all the features in the application during the initial installation. For example, the engineer might flag the Help file so that it installs only if and when the user opens Help. This just-in-time feature delivery saves hard drive space but causes headaches for laptop users who might first touch a feature while in an airplane, or worse, when connected to the office via a dial-up line, resulting in a long delay while the files are copied over the slow modem connection.

Fortunately, there’s a simple way to resolve this. A group policy has settings for both Computers and Users. If you configure a software deployment policy to apply to Computer objects rather than User objects, the client computers will install the application during restart before any users log on. A happy side-benefit of this approach is that all features in the .MSI package are installed regardless of any delayed delivery settings in the .MSI.

My colleague verified this solution using a test server in the production AD domain, and it worked well. The applications fully installed and the laptops were ready to take on the road within a few minutes of the initial boot following imaging. Situation resolved? Not quite, which leads us to the second part of the story.

Refusing Orders
This particular system contained a two-node Win2K Advanced Server cluster used for critical file-and-print services. Application deployment is a significant item, so it made sense to put the .MSI files into a shared resource on the cluster. Interestingly enough, in this configuration, the client computers refused to install the policy-based applications. The laptop would display a message that the deployment packages were installing, but there was no sign of them once the user logged on.

There were other symptoms. Deployment packages configured to deploy directly to User objects rather than Computer objects installed just fine. When the MSI files were moved to a drive on either node of the cluster, the applications installed flawlessly. By the same token, if the deployment policy specified a UNC path containing the actual server name of a node in the cluster rather than the virtual cluster name, the applications installed without a problem. A cluster presents itself to the network as a virtual entity distinct from the individual nodes. “We are the Borg,” says a cluster. Unlike the Borg, each node in the cluster can stand on its own and present shared resources in its own name. This yields three possible UNC paths to the same folder on a two-node cluster:




As it turns out, the explanation for this odd behavior doesn’t involve any magic cluster features but rather an engineering decision related to something we use every day—authentication.

Win2K uses Kerberos by default for validating a user’s identity. When a Win2K user touches a file share on a Win2K server, the server looks for a Kerberos session ticket in the initial connection request. The client obtains this ticket from a domain controller. You can see the contents of the tickets at a client by running a Resource Kit utility called Kerbtray. This utility installs an icon in the System Tray that you can double-click to show the tickets and ticket-granting-tickets issued to the current user.

Local System Account—D'oh!
Individual services running on a Win2K machine must be coded to use and accept Kerberos credentials. Such a service is said to be Kerberized. Only a handful of services in Win2K are Kerberized. The list includes the two services that use the Common Internet File System (CIFS)—LanManServer and LanManWorkstation—but doesn’t include the Cluster service. This is because the discrete nodes of the cluster must log onto each other using local accounts, not AD accounts. For this purpose, the Cluster service uses the same NTLM authentication protocol used by pre-SP3 Windows NT 4.0. (An upcoming fix will upgrade the Cluster service to NTLMv2.)

This lack of Kerberos support in a cluster sets the stage for the software deployment problem experienced by my colleague. Recall that the deployment policy was applied to Computer objects. This means the computer must access the deployment server hosting the .MSI files. This happens before a user logs on, so the Local System account must do the connection. But the Local System account is like Homer Simpson: It’s completely autocratic at home and a total marshmallow anywhere else, because it has no network security credentials. To make a network connection, the Local System account has two choices. It can pretend to be somebody else or it can pretend to be nobody at all.

In Win2K and XP, Local System can pretend to be somebody else—the computer account of the local desktop. Computers have accounts in AD and can obtain network security credentials in the form of Kerberos session tickets. The Local System account can use Kerberos tickets obtained by the computer account to make connections to Win2K servers and other XP desktops.

This is why the software deployment policies worked when the .MSI files were on the test server and the individual nodes of the cluster. Computer accounts are treated like ordinary users in AD, so they can connect to any share that permits access to the Authenticated Users group.

He’s a Real Nullwhere Man
The Local System on the desktop can’t use the computer account to do an NTLM authentication, so it falls back on the second alternative, to pretend to be nobody at all. It’s possible to connect to a Windows NT or 2000 server without presenting any credentials whatsoever. This is called a null session connection. A null session is the Hollow Man of Windows networking. You can’t see it directly, but you can sense its effect all around you. For example, when you browse My Network Places from a standalone desktop, you make a null session connection to the Browse Master. When you create a trust relationship to an external domain, the system uses a null session to initiate the transaction. If you share a connection to a network printer on another server, users printing through your machine use null sessions to connect to the host printer server.

Null sessions appear useful, but unless properly handled, they constitute a nasty and heavily exploited vulnerability. If you search for “null session” with your favorite search engine, you’ll find site after site with hacking tools that take advantage of null sessions. (Be sure to download utilities only from respected sources. You don’t want to take the chance of introducing a Trojan or some other nasty piece of code into your system.)

You don’t need any fancy utilities to see how null sessions and Kerberos transactions work. Here’s a simple way to fool a desktop into giving you access to the Local System account so you can use it to make network connections. At a Win2K member desktop in an AD domain, log on with administrator privileges then open a command prompt. Check the time in the system tray then, from the command prompt, enter AT

When a second command console appears, use the WHOAMI utility from the Support Tools to verify that you’re running as NT AUTHORITY\SYSTEM, another name for the Local System account. Then enter NET VIEW \\server_name to enumerate the non-hidden shares on a Win2K server where you have public shares. These are shares with the Everyone group on the share permissions and the folder permissions.

Now do a directory of the public share using the syntax DIR \\server_name \share_name. The files in the share will be listed. Open one text file in the public share using the syntax Notepad \\server_name\share_name\file_name. The file opens. Verify that you can modify the file then close it. You can also map a drive to the share point using the NET USE command.

At this point, you haven’t yet made use of a null session because you connected from a Win2K member desktop to a Win2K member server. If you put a packet sniffer on this transaction, you’d see that the desktop obtained a Kerberos ticket to the target server, then presented the ticket in a security blob as part of the initial Connect & X SMB (Server Message Block) command presented to the target server.

Now do a NET VIEW of an NT 4.0 server or a cluster server, if you have one. You can experiment with a cluster server by installing Win2K Advanced Server on a machine that has both an AT/IDE or SCSI boot drive and a second SCSI drive. Install the Cluster service from the Add/Remove Programs applet in Control Panel and specify the second SCSI drive as a cluster resource. At this point, you have a one-node cluster. The second node is essentially offline. You don’t need it for these experiments.

You’ll find that you can do a NET VIEW of the shares on an NT 4.0 server or cluster from the Local System console. A packet sniffer would show a failure of the initial Kerberos connection attempt followed by a null session connection to the IPC$ share, the inter-process communication interface used for handling null session connections to shares and named pipes.

If you attempt to enumerate the files behind the share using DIR or NET USE to the public share, you’ll get an Access Denied error. Clusters and NT 4.0 servers permit enumerating their shares via a null session; but, by default, they don’t permit connection to the shares themselves. This brings us to the source of the software deployment problem. When deploying software to the Computer object, the Local System account can’t use either Kerberos or null sessions to connect to a clustered resource. An NT 4.0 server hosting the .MSI files would also reject the connection.

The Fix is In
Well, we’ve reached the end of our mystery but we still need to fix the problem. There are two potential workarounds. The first is to create a domain-based Dfs (Distributed File System) with a multi-targeted link pointing at the share using the server name rather than the cluster name. If you don’t want to fuss with Dfs, you can enable a null session connection for the specific clustered resource or NT 4.0 share you want to use for software deployment. This is an acceptable solution only so long as you limit the permissions of the Everyone group on the shared folder to Read. There’s no need to give Execute permissions. The clients merely need to read the .MSI files.

To enable null session connections to a specific share, you must first configure the server to accept null session connections. This is the default configuration of Win2K and NT. You can modify the Registry or use a group policy for Win2K servers. The Registry entry is HKLM | System | CurrentControlSet | Control | LSA | RestrictAnonymous. This is set to 0 by default, which accepts null session connections. A 1 will block null sessions for a selected set of circumstances, and a 2 will block them in all circumstances.

The group policy is called Additional Restrictions for Anonymous Connections and is set under Computer Configuration | Windows Settings | Security Settings | Security Options. The policy isn’t enabled by default. Many administrators enable the policy to increase security. This is a good idea, so you’ll need to target the degraded configuration specifically at your cluster server.

By enabling null session connections, you increase the vulnerability of the server to many sophisticated exploits. Never do this on a machine exposed to the Internet or it might become a jump-off point for an internal or Trojan attack. Document the degraded condition so that future administrators don’t inadvertently make configuration changes that expose the machine to exploits.

Once null session connections are enabled, you must then include the share containing the MSI in a list of null session shares for the LanManServer service. The Registry entry is HKLM | System | CurrentControlSet | Services | LanManServer | Parameters | NullSessionShares. Open the REG_MULTI_SZ value and add your share name to the bottom of the list. As soon as you save this change, you’ll be able to enumerate the files behind the share using your Local System console at the member desktop.

I welcome your feedback on this article and any suggestions you might have for future topics. If you’ve had the opportunity to put your certification to work when sleuthing a problem, let me know about it.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.


comments powered by Disqus

Hot Resources

Subscribe on YouTube