Net Bios Null Sessions

• 
  
  
  The null session is often refereed to as the Holy Grail of Windows hacking. Null Sessions take advantage of flaws in the CIFS/SMB (Common Internet File System/ Server Messaging Block).
  
  
• 
  
  
  You can establish a Null Session with a Windows (NT/2000/XP) host by logging on with a null user name and password.
  
  
• 
  
  
  Using these null connections allows you to gather the following information from the host:
  • 
    
    
    List of users and groups
    
    
  • 
    
    
    List of machines
    
    
  • 
    
    
    List of shares
    
    
  • 
    
    
    Users and host SIDs (Security Identifiers)
    In the enumeration phase, the attacker gathers information such as network user and group names, routing tables, and Simple Network Management Protocol (SNMP) data
    
    However, in addition to the standard user, the OS also supports a unique type of user called the 'null' user, which is basically a pseudo-account that has no username or password, but is allowed to access certain information on the network.
    
    
    
    The Null user is capable of enumerating account names and shares on domain controllers, member servers, and workstations. This makes the Null user, a user with no credentials, a potential means of attack by crackers to elicit information and compromise the system.
    Let us take a look at a typical LANMAN sessions on Windows NT 4.0
    
    
    
  
  

Remote machines establish a session with the Windows NT server using a challenge response protocol. The security of the information channel is ensured through a sequence of communications as outlined below.

• 
  
  
  The remote machine (or session requestor / client) sends a request to the session server (or session acceptor). This may be within the same domain or across domains.
  
  
• 
  
  
  The session server responds by sending across a random 64-bit challenge question to the client. The client responds to the question with a 24-bit answer which is hashed with the password of the user account that is requesting the session.
  
  
• 
  
  
  The session server accepts the response and verifies with the local security authority regarding the authentication of the user account and password.
  
  
• 
  
  
  The LSA confirms the identity of the requestor by verifying that the response was hashed with the correct password for the user that the requestor purports to be. This confirmation occurs locally if the requestor's account is a local account on the server. However, if the requestor's account is a domain account, the response is forwarded to the concerned domain controller for authentication.
  
  
• 
  
  
  On authenticating the response, an access token is generated by the session server and sent across to the client.
  
  
• 
  
  
  The client then uses this access token to connect to resources on the server till the newly established session is terminated.
  
  
  Windows 2000 provides three groups whose membership is controlled by the administrator: Users, Power Users, and Administrators. The group whose membership is controlled by the operating system or domain is Authenticated Users. It is the same as the Everyone group, except that it does not contain anonymous users or guests. Unlike the Everyone group in Windows NT 4.0, the Authenticated Users group is not used to assign permissions. Only groups controlled by the administrator, primarily Users, Power Users, and members of the Administrators group, are used to assign permissions.
  
  
  
  
  

Now, let us take a look at a typical LANMAN sessions on Windows 2000

• 
  
  
  Here, the client sends a pre-authenticated (hash of user password) request along with a time stamp to the key distribution center (KDC) that resides on the domain controller (DC) of the concerned domain, requesting for a ticket granting ticket (TGT).
  
  
• 
  
  
  The KDC extracts the hash of the user identity from its database and decrypts the request with it, noting the time stamp as well for recentness of request. A valid user account results in successful decryption.
  
  
• 
  
  
  The KDC sends back a TGT, that contains among other information the session key (encrypted with users password) and the security identifiers (SID) identifying the user and the group among other things.
  
  
• 
  
  
  The client uses the ticket to access the required resources.
  
  

  A null session is an insecure (unauthenticated) connection with no proof of identity. No user and password credentials are supplied in the establishment of the session. No session key is exchanged when establishing a null session, and hence it is impossible for the system to send encrypted or even signed messages on behalf of the user under a null session.

  When the LSA is asked to create a token for a remote client communicating via a null session, it produces a token with a user SID of S-1-5-7 (the null logon session), and a user name of anonymous logon. We have seen earlier that Everyone is included in all tokens, and the null session is classified as a network logon. This gives the null user access to file system shares and named pipes.
  
  
  Other areas where null sessions are considered useful is when the LMHOSTS.SAM file uses the "#INCLUDE " tag. The share point that contains the included file must be setup as a null session share. Additionally where a service, running under the local "SYSTEM" account, needs access to some network resource, a null session may be established to access these resources.
  
  
  An interesting part is that Null sessions can also be established at the API level with languages such as C++. Null sessions can be used to establish connections to 'null session pipes', if it is allowed by the server. A 'pipe' is a facility that allows a process on one system to communicate with a process on another system, while a inter process communication share allows communication between two processes on the same system.
  
  
  Null sessions can also be used to establish connections to shares, including such system shares as \\servername\IPC$. The IPC$ is a special hidden share. It may be noted that the IPC$ share is an interface to the 'server' process on the machine, also associated with a pipe so it can be accessed remotely. Null sessions make the enumeration of users, machines, and resources easier for administrative purposes especially across domains. This is the lure for the attacker who intends to use a null session to connect to the machine.
  
  
  During port scanning, the attacker takes note of any response from TCP port 139 and 445. Why would these ports interest an attacker? The answer lies in the SMB protocol.
  The SMB (Server Message Block) protocol is known for its use in file sharing on Windows NT / 2000 series among other things. Attackers can potentially intercept and modify unsigned SMB packets then modify the traffic and forward it so that the server might perform undesirable actions. Alternatively, the attacker could pose as the server or client after a legitimate authentication and gain unauthorized access to data.
  
  
  SMB is the resource sharing protocol supported by many Microsoft operating systems; it is the basis of network basic input/output system (NetBIOS) and many other protocols. SMB signing authenticates both the user and the server hosting the data. In Windows NT it ran on top of NBT (NetBIOS over TCP/IP), making it a bulky protocol with a large header as well as consuming greater time. In Windows NT, it used the ports 137, 138 (UDP) and 139 (TCP). In Windows 2000, SMB was allowed to directly run over TCP/IP, without the extra layer of NBT. Therefore, port 445 started being used for this purpose.
  
  
  Each SMB session consumes server resources. Establishing numerous null sessions will slow or possibly crash the server even in Windows 2003. An attacker could repeatedly establish SMB sessions until the server stops responding. SMB services will become slow or unresponsive.