Saturday, August 31, 2019

Detect Null Session Authentication

Introduction

A null session attack is something that has been around since the days of Windows 2000, but amazingly enough it is something that system administrators often neglect to consider when hardening networks. This can lead to disastrous results as enumeration of a null session can divulge just about every bit of useful information an attacker needs to remotely gain access to a system.

A NULL SMB session has a blank user name and a blank password. However, most modern Windows systems by default prohibit enumerating detailed user information across a NULL SMB session (controlled by the HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous, RestrictAnonymousSAM, and EveryoneIncludesAnonymous registry keys).

How Null Sessions Work

A remote session is created when a user logs on to a computer remotely using a username and password that has access to system resources. This is accomplished through the Server Message Block (SMB) protocol and the Windows Server service. These connections are entirely legitimate when proper credentials are supplied.

A null session comes into play when a user makes a connection to a windows system with no username or password. This type of connection can not be made to any typical windows share, but it can be done to the Interprocess Communication (IPC) administrative share. The IPC share, as the name alludes to, is used by Windows processes (via the SYSTEM username) to communicate with other processes across the network. The IPC share is used exclusively by the SMB protocol.
Using the IPC share with no credentials is typically reserved for programs communicating with one another, but there is nothing to say that a user could not connect to a machine via the IPC connection instead. This would not allow for unrestricted access to the machine, but will allow for pretty extensive enumeration that could aide an attacker.
Solution: 

The simplest way to reduce null session vulnerability is to disable NetBios and verify that ports 139 and 445 are closed.

Block Access at the Network Level

If you can not make the registry changes listed above then you can block things with the Windows firewall or network firewall. This can be done by blocking access to the ports associated with NetBIOS and SMB over TCP/IP. These are:
  • TCP Port 135
  • UDP Port 137
  • UDP Port 138
  • TCP Port 139
  • TCP and UDP Port 445
These ports are used for all sorts of Windows networking functions including file sharing, network printing, clustering, and remote administration. That being said, blocking access to these ports should be thoroughly tested before being blindly done to a multitude of hosts.



Restrict Null Sessions in the Registry

However, if your run-time image requires NetBIOS, you can control null session access by editing the following registry key to restrict anonymous access to sensitive data:

Key Name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSAValue Name: RestrictAnonymous
Type: DWORD
Value: 0

The default value of this key is 0. Changing this value to 1 blocks enumeration of SAM and user accounts, and prohibits a null session from seeing user accounts and admin shares. A value of 2 disables null session access without explicit permissions. Changing this value to 2 may conflict with some applications that rely on null sessions.

After you change the registry data, reboot your run-time images and test your applications to verify that they work with restricted null session access.

No comments:

Post a Comment