Chapter 4

Understanding the Extended Capabilities of the Nessus Environment

Solutions in this chapter:

·         Windows Testing Functionality Provided by the smb_nt.inc Include File

·         Windows Testing Functionality Provided by the smb_hotfixes.inc Include File

·         UNIX Testing Functionality Provided by the Local Testing Include Files

In This Toolbox

Some of the more advanced functions that Nessus’ include files provide allow a user to write more than just banner comparison or service detection tests; they also allow users to very easily utilize Windows’ internal functions to determine whether a certain Windows service pack or hotfix has been installed on a remote machine, or even whether a certain UNIX patch has been installed.

This chapter covers Nessus’ include files implementation of the SMB (Server Message Block) protocol, followed by Nessus’ include files implementation of Windows-related hotfix and service pack verification. This chapter also addresses how a similar kind of hotfix and service pack verification can be done for different UNIX flavors by utilizing the relevant include files.

Windows Testing Functionality Provided by the smb_nt.inc Include File

Nessus can connect to a remote Windows machine by utilizing Microsoft’s SMB protocol. Once SMB connectivity has been established, many types of functionality can be implemented, including the ability to query the remote host’s service list, connect to file shares and open files that reside under it, access the remote host’s registry, and determine user and group lists.

Swiss Army Knife

SMB Protocol Description

SMB (Server Message Block), aka CIFS (Common Internet File System), is an intricate protocol used for sharing files, printers, and general-purpose communications via pipes. Contrary to popular belief, Microsoft did not create SMB; rather, in 1985 IBM published the earliest paper describing the SMB protocol. Back then, the SMB protocol was referred to as the IBM PC Network SMB Protocol. Microsoft adopted the protocol later and extended it to what it looks like today. You can learn more on the SMB protocol and its history at http://samba.anu.edu.au/cifs/docs/what-is-smb.html.

In the following list of all the different functions provided by the smb_nt.inc file, some of the functions replace or provide a wrapper to the functions found in smb_nt.inc:

·         kb_smb_name Returns the SMB hostname stored in the knowledge base; if none is defined, the IP (Internet Protocol) address of the machine is returned.

·         kb_smb_domain Returns the SMB domain name stored in the knowledge base.

·         kb_smb_login Returns the SMB username stored in the knowledge base.

·         kb_smb_password Returns the SMB password stored in the knowledge base.

·         kb_smb_transport Returns the port on the remote host that supports SMB traffic (either 139 or 445).

·         unicode Converts a provided string to its unicode representation by appending for each of the provided characters in the original string a NULL character.

The following functions do not require any kind of initialization before being called. They take care of opening a socket to port 139 or 445 and logging in to the remote server. The registry functions automatically connect to \winreg and open HKLM, whereas smb_file_read() connects to the appropriate share to read the files.

·         registry_key_exists Returns if the provided key is found under the HKEY_LOCAL_MACHINE registry hive. For example: if ( registry_key_exists(key:“SOFTWARE\Microsoft”) ).

·         registry_get_sz Returns the value of the item found under the HKEY_LOCAL_MACHINE registry hive. For example, the following will return the CSDVersion item’s value found under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registyr location:

service_pack = registry_get_sz(key:"SOFTWARE\Microsoft\Windows NT\CurrentVersion", item:"CSDVersion");

·         smb_file_read Returns the n number of bytes found at the specified offset of the provided filename. For example, the following will return the first 4096 bytes of the boot.ini file:

data = smb_file_read(file:"C:\boot.ini", offset:0, count:4096);

To use the following lower-level functions, you need to set up a socket to the appropriate host and log in to the remote host:

·         smb_session_request Returns a session object when it is provided with a socket and a NetBIOS name. The smb_session_request function sends a NetBIOS SESSION REQUEST message to the remote host. The NetBIOS name is stored in the Nessus knowledge base and can be retrieve by issuing a call to the kb_smb_name() function. The function also receives an optional argument called transport, which defines the port that the socket is connected to. If the socket is connected to port 445, then this function does nothing. If it’s connected to port 139, a NetBIOS message is sent and this function returns an unparsed message from the remote host.

·         smb_neg_prot Returns the negotiated response when it is provided with a socket. This function negotiates an authentication protocol with the remote host and returns a blob to be used with smb_session_setup() or NULL upon failure.

·         smb_session_setup Returns a session object when it is provided with a socket, login name, login password, and the object returned by the smb_neg_prot. This function logs to the remote host and returns NULL upon failure (could not log in) or a blob to be used with session_extract_uid().

·         session_extract_uid Returns the UID (user identifier) from the session object response. This function extracts the UID sent by the remote server after a successful login. The UID is needed in all the subsequent SMB functions.

·         smb_tconx Returns a session context when it is provided with a socket, NetBIOS name, unique identifier, and a share name. This function can be used to connect to IPC$ (Inter Process Connection) or to any physical share on the remote host. It returns a blob to use with smb_tconx_extract_tid() upon success or NULL if it’s not possible to connect to the remote share. For example, the following line will try to connect to the remote host’s IPC$:

if ( smb_tconx(soc:socket, name:kb_smb_name(), uid:my_uid, share:"IPC$") == NULL ) exit(0);

·         smb_tconx_extract_tid Returns the TID (tree id) from the session context reply.

·         smbntcreatex Returns the session context when it is provided with a socket, user id, tree id, and name. This function connects to a named pipe (such as \winreg). It returns NULL on failure or a blob suitable to be used by smbntcreatex_extract_pipe().

·         smbntcreatex_extract_pipe Returns the pipe id from the session context returned by smbntcreatex().

·         pipe_accessible_registry Returns either NULL if it has failed or non-NULL if it has succeeded in connecting to the pipe when it is provided with a socket, user id, tree id, and pipe name. This function binds to the winreg MSRPC service and returns NULL if binding failed, or non-null if you could connect to the service successfully.

·         registry_open_hklm, registry_open_hkcu, registry_open_hkcr Returns the equivalent to the MSDN’s RegConnectRegistry() when its provided with a socket, user id, tree id, and a pipe name. The return value is suitable to be used by registry_get_key().

·         registry_get_key Returns the MSDN’s RegOpenKey() when it is provided with a socket, user id, tree id, pipe name, key name, and the response returned by one of the registry_open_hk* functions. The return value is suitable to be used by registry_get_key_item*() functions.

·         registry_get_item_sz Returns the string object found under the provided registry key when it is provided with a socket, user id, tree id, pipe name, item name, and the response returned by the registry_get_key function. The return value needs to be processed by the registry_decode_sz() function.

·         registry_decode_sz Returns the string content when it is provided with the reply returned by the registry_get_item_sz function.

The following functions are not used in any script, but could be useful to clean up a computer filled with spyware:

·         registry_delete_key Deletes the specified registry key when it is provided with a socket, user id, pipe name, key name, and the response returned by the registry_open_hk* functions.

·         registry_delete_value Deletes the specified registry key value when it is provided with a socket, user id, pipe name, key name, the response returned by the registry_open_hk* functions, and the name of the value to delete.

·         registry_shutdown This function will cause the remote computer to shutdown or restart after the specified timeout. Before the actual shutdown process starts, a message will be displayed, when it is provided with a socket, user id, tree id, pipe name, message to display, timeout in seconds, whether to reboot or shutdown, and whether to close all the applications properly.

The following example shows how to determine whether the remote host’s Norton Antivirus service is installed and whether it is running. If Norton Antivirus is not running, the example shows how to start it by utilizing the Microsoft Windows service control manager.

To determine whether the remote host has Norton AntiVirus or Symantec AntiVirus installed, first run the smb_enum_services.nasl test, which will return a list of all the services available on the remote host. Next, accommodate the required dependencies for smb_enum_services.nasl (netbios_name_get.nasl, smb_login.nasl, cifs445.nasl, find_service.nes, and logins.nasl). Next, get the value stored in the knowledge base item called SMB/svcs; this knowledge base item holds a list of all the services that are present on the remote host. You do this by using the following code:

service_present = 0;

services = get_kb_item("SMB/svcs");

if(services)

{

if("[Norton AntiVirus Server]" >!< services || “[Symantec AntiVirus Server]” >!< services)

{

service_present = 1;

}

}