NULL Session is by far the most notorious Windows vulnerability around. What NULL session basically means is that it is possible to connect to your IPC$ administrative share with no username and no password and gain some juicy data. To demonstrate this, simply run cmd and type:
net use \\host /user:"" ""
Where host is the IP/name of any machine on the network. If you get ‘The command completed successfully.’ you’re connected to a machine without providing any credentials.
NULL sessions are more than just information leakage. At least one worm has been known to spread by exploiting both NULL sessions and a vulnerability in RPC.
NULL session is so bad that SANS has been constantly including it in their SANS Top 20.
The discussion if this is a security vulnerability or a feature has been going on forever. Instead of arguing, let’s see how we can solve it for the people that actually wants it solved!
Well… It ain’t that simple… Take a deep breath, this is going to be long.
Windows NT 4.0 / Windows 2000:
The problem is known from the days of NT4. In the good ol’ days all that was needed is some spit and nails to solve the problem, or in other words:
Under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA change the item: RestrictAnonymous from 0 to 1
Problem solved! Not exactly. This only restricts the information gained from NULL session, and does not actually block the connection. Specifically, if you set this to 1, the unauthenticated user can’t enumerate SAM accounts, but it’s still possible to learn a lot about the users on the machine and the network structure.
So, in Windows 2000 Microsoft added another level to RestrictAnonymous. If you set RestrictAnonymous to 2 you actually block ALL unauthenticated access to the IPC$ share. And peace came to the land.
Well… This is swell, if you don’t count some pesky bits of software that actually MUST access the IPC$ with no username and password. I know of at least one accounting program that was written 10 years ago, and no one actually plans to patch it. Even worse, this also blocks anonymous connections from localhost! So if a poor programmer wants to run NetGroupAddUser for example from a local program, it must be done with a username and password!
But, the security freaks were once again calm, they have no NULL session in their machines once and for all. Well, until Windows XP that is.
Windows XP / 2003:
After customer complaints that RestrictAnonymous = 2 made them work hard, Microsoft decided to make life intolerable, er, simpler. In windows XP we now have 3 different keys controlling the NULL session ‘feature’. Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA :
1. Good old RestrictAnonymous is still there, but setting it to 1 or 2 yields the same result, NULL connections can still be created, less information leaks.
2. RestrictAnonymousSam controls anonymous access to SAM accounts (in the past that what RestrictAnonymous = 1 did).
3. EveryoneIncludesAnonymous When set to 0 (default factory setting), this little piggy prevents anonymous connections to be in the ‘Everyone’ group and access resources allowed to everyone.
So what do we get from all these changes? NULL connections can’t get SAM accounts, are not in any group, and generally are unwelcome. But! Cries the purist, they can still make an anonymous connection!
That’s right, in Windows XP, no setting allows the poor administrator to completely block those dreaded NULL connections!
So what can the poor administrator do? First thought comes to mind is of course: Use a firewall!
Disable File and Printer Sharing / Filter traffic and IPSec:
1. So why can’t we just disable all access to the IPC$, who needs it anyway?
The simplest way to solve this, is just uncheck ‘File and Printer Sharing for Microsoft Windows’ on every network interface on the machine! Yup. That works. If you don’t need shared directory, shared printers, remote registry or anything of the sort…
Not a very valid solution in many cases.
2. OK, let’s firewall the damn thing. Just block all incoming traffic on 445/139. Nice try. Microsoft puts so many services on these two poor ports that it can make your eyes bleed. Just as an example: Computer Browser, Workstation, Server, Remote Registry, File / Printer Sharing, DCOM and so on…
OK, I’ll just allow authenticated connection, reject all unauthenticated. I’m sure my firewall can do that!
Not exactly, at least not the firewall built-in 2000 / XP / 2003 (IPSec or the Windows XP Service Pack2 firewall). These guys only talk in source and target ports. No way to tell an authenticated connection from anonymous one. What now?
3. IPSec policy. You heard right, enforce Kerberos (or any equivalent) authentication on all SMB connections. Make everyone authenticate with the Active Directory server before even accessing the port!
That’s actually a very nice solution, the only problem is that it’s a bit awkward. You need an Active Directory server, have all workstations and servers authenticate via that server, and don’t forget to manage and harden your brand new Active Directory server, otherwise you’re back in square 1.
Not to mention that this kind of system takes time to build, check and finally maintain. But, this solves NULL session on XP, 2003 and probably on any new Microsoft Windows system.
If you understand the implications if NULL session in your organization, I strongly recommend you to start thinking about how to solve, or at least minimize the problem. IPSec is by far the ‘comlpete’ solution, but it requires configuration and investment in a working authentication server. In the meantime, harden the registry where possible, and enforce good network separation between subnets.