In computer networking, Server Message Block (SMB), the modern dialect of which is known as Common Internet File System (CIFS), operates as an application-layer network protocol mainly used for providing shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it was known as "Microsoft Windows Network" before the subsequent introduction of Active Directory. Corresponding Windows services are LanmanServer (for the server component) and LanmanWorkstation (for the client component).
The Server Message Block protocol can run on top of the Session (and lower) network layers in several ways:
- directly over TCP, port 445.
- via the NetBIOS API, which in turn can run on several transports
- on UDP ports 137, 138 & TCP ports 137, 139 – see NetBIOS over TCP/IP
- on several legacy protocols such as NBF (incorrectly referred to as NetBEUI).
Microsoft introduced SMB2 with Windows Vista in 2006, and later improved on it in Windows 7, with subsequent major revisions of 2.1 and 3.0 as of 2012.
NetBIOS
The use of the SMB protocol has often correlated with a significant increase in broadcast traffic on a network. However the SMB itself does not use broadcasts—the broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol.
By default, a Microsoft Windows NT 4.0 server used NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with a smaller number of hosts, increased broadcast traffic can cause problems as the number of hosts on the network increases. The implementation of name resolution infrastructure in the form ofWindows Internet Naming Service (WINS) or Domain Name System (DNS) resolves this problem.
WINS was a proprietary implementation used with Windows NT 4.0 networks, but brought about its own issues and complexities in the design and maintenance of a Microsoft network.
Since the release of Windows 2000, the use of WINS for name resolution has been deprecated by Microsoft, with hierarchical Dynamic DNS now configured as the default name resolution protocol for all Windows operating systems.
Resolution of (short) NETBIOS names by DNS requires that a DNS client expand short names, usually by appending a connection-specific DNS suffix to its DNS lookup queries. WINS can still be configured on clients as a secondary name resolution protocol for interoperability with legacy Windows environments and applications. Further, Microsoft DNS servers can forward name resolution requests to legacy WINS servers in order to support name resolution integration with legacy (pre-Windows 2000) environments that do not support DNS.
Microsoft's modifications
Microsoft added several extensions to its own SMB implementation. For example, it added NTLM, then NTLMv2 authentication protocols in order to address security weakness in the original LanMan authentication. LanMan authentication derived from the original legacy SMB specification's requirement to use IBM "LanManager" passwords, but implemented DES in a flawed manner that allowed passwords to be cracked. Later, Kerberos authentication was also added. The NT 4.0 Domain logon protocols initially used 40-bit encryption outside of the United States of America, because of export restrictions on stronger 128-bit encryption (subsequently lifted in 1996 when President Bill Clinton signed Executive Order 13026). Opportunistic locking support has changed with each server release.
SMB 2.1
SMB 2.1, introduced with Windows 7 and Server 2008 R2, introduced minor performance enhancements with a new opportunistic locking mechanism.
SMB 3.0
SMB 3.0 (previously named SMB 2.2) was introduced with Windows 8 and Windows Server 2012. It brought several significant changes, such as the SMB Direct Protocol (SMB over RDMA) and SMB Multichannel (multiple connections per SMB session), that are intended to add functionality and improve SMB2 performance, notably in virtualised data centers. It also introduces several security enhancements, such as end-to-end encryption and a new AES based signing algorithm.
The SMB "Inter-Process Communication" (IPC) system provides named pipes and was one of the first inter-process mechanisms commonly available to programmers that provides a means for services to inherit the authentication carried out when a client first connected to an SMB server.
Features
The SMB "Inter-Process Communication" (IPC) system provides named pipes and was one of the first inter-process mechanisms commonly available to programmers that provides a means for services to inherit the authentication carried out when a client first connected to an SMB server.
Some services that operate over named pipes, such as those which use Microsoft's own implementation of DCE/RPC over SMB, known as MSRPC over SMB, also allow MSRPC client programs to perform authentication, which over-rides the authorisation provided by the SMB server, but only in the context of the MSRPC client program that successfully makes the additional authentication.
SMB signing: Windows NT 4.0 Service Pack 3 and upwards have the capability to use cryptography to digitally sign SMB connections. The most common official term is "SMB signing". Other terms that have been used officially are "[SMB] Security Signatures", "SMB sequence numbers" and "SMB Message Signing".SMB signing may be configured individually for incoming SMB connections (handled by the "LanManServer" service) and outgoing SMB connections (handled by the "LanManWorkstation" service).
The default setting from Windows 98 and upwards is to opportunistically sign outgoing connections whenever the server also supports this. And to fall back to unsigned SMB if both partners allow this. The default setting for Windows domain controllers from Server 2003 and upwards is to not allow fall back for incoming connections. The feature can also be turned on for any server running Windows NT 4.0 Service Pack 3 or later. This protects from man-in-the-middle attacks against the Clients retrieving their policies from domain controllers at login.
SMB Users
The efficiency of password guessing is greatly increased by information gathered using the enumeration techniques. Assuming that user account names and features can be obtained by these techniques, they should be reviewed with an eye toward identifying the following information extracted over null sessions by tools such as enum, nete, userdump/userinfo, and DumpSec.
This information can be used in manual password-guessing attacks, or it can be salted liberally in username lists and password dictionaries fed into automated password-guessing tools.
Local vs. Domain Accounts: For each account enumerated, it is good practice to check which are domain accounts and which are for local use only. Membership can also be seen from the group memberships. Domain accounts can provide footholds from one system to another—getting system access to one box can provide access to that box only, but using that account to spawn processes with logged-on domain users allows an intruder to take over the entire domain or forest, depending on the account.
Lab or Test Accounts: How many lab or test accounts exist in your environment? How many of these accounts are in the local Administrators group? Care to guess what the password for such accounts might be? It could be test, or, on systems with no password policy enforcement, it could even be NULL. To make matters worse, these accounts— even admin accounts—can set passwords that never expire. It is not uncommon to find systems with passwords set months or even years ago—even brute-forcing can be valuable for cracking stronger passwords within such an environment.
User Accounts with Juicy Info in the Comment Field: We’ve actually seen passwords written in the Comment field in plaintext, ripe for the plucking via enumeration. Sometimes hints to the password can be found in the Comment field to aid those hapless users who just can’t seem to remember their own passwords.
Administrators or Domain Admins Groups: These accounts are often targeted because of their all-encompassing power over local systems or domains. Also, the local Administrator account cannot be locked out using default tools from Microsoft, and they make ripe targets for perpetual password guessing. The account has been renamed or disabled on later versions of Microsoft Windows.
Local administrator accounts: might also use the same password for multiple systems, especially if the systems have been installed from one (and the same) golden image. This gives the advantage to the attacker who can use the same local account to compromise all the accounts on the network.
Privileged Backup Application Service Accounts: Many commercial backup software applications create user accounts that are granted a high degree of privilege on a system, or that at least can read almost all of the files to provide a comprehensive backup of the system.
Shared Group Accounts: Organisations large and small have a propensity to reuse account credentials that grant access to a high percentage of the systems in a given environment. Account names such as backup or admin are examples.
User Accounts Haven’t Changed Passwords Recently: This is typically a sign of noneffective account maintenance practices on the part of the user and system administrator, indicating a potentially easy mark. These accounts may also use default passwords specified at account creation time that are easily guessed. For example, the use of the organisation name, username, or welcome for this initial password value is rampant.
User Accounts Haven’t Logged on Recently: Once again, infrequently used accounts are signs of neglectful practices such as infrequently monitored password strength, or rather account management housekeeping.
Windows SIDs
In Windows, security principals generally have friendly names, such as Administrator or Domain Admins. However, the NT family manipulates these objects internally using a globally unique 48-bit number called a security identifier, or SID. This prevents the system from confusing the local Administrator account from Computer A with the identically named local Administrator account from Computer B, for example.
The SID comprises several parts:
S-1-5-21-1527495281-1310999511-3141325392-500
A SID is prefixed with an S, and its various components are separated with hyphens. The first value (in this example, 1) is the revision number, and the second is the identifier authority value. Then four subauthority values (21 and the three long strings of numbers, in this example) and a relative identifier (RID—in this example, 500) make up the remainder of the SID. SIDs may appear complicated, but the important concept for you to understand is that one part of the SID is unique to the installation or domain and another part is shared across all installations and domains (the RID). When Windows is installed, the local computer generates a random SID. Similarly, when a Windows domain is created, it is assigned a unique SID (we’ll define domains later in this chapter). Thus, for any Windows computer or domain, the subauthority values will always be unique (unless purposely tampered with or duplicated, as in the case of some low-level disk-duplication techniques).
However, the RID is a consistent value across all computers or domains. For example, a SID with RID 500 is always the true Administrator account on a local machine. RID 501 is the Guest account. On a domain, RIDs starting with 1001 indicate user accounts. (For example, RID 1015 would be the fifteenth user account created in the domain.) Suffice to say that renaming an account’s friendly name does nothing to its SID, so the account can always be identified, no matter what. Renaming the true Administrator account changes only the friendly name—the account is always identified by Windows (or a malicious hacker with appropriate tools) as the account with RID 500.
Users
Quite simply, an account is a reference context in which the operating system executes code. Put another way, all user mode code executes in the context of a user account. Even some code that runs automatically before anyone logs on (such as services) runs in the context of an account (often as the special and all-powerful SYSTEM, or LocalSystem, account). All commands invoked by the user who successfully authenticates using the account credentials are run with the privileges of that user. Thus, the actions performed by executing code are limited only by the privileges granted to the account that executes it.
Built-in Users
Windows comes out of the box with built-in accounts that have predefined privileges. These default accounts include the local Administrator account, which is the most powerful user account in Windows. (Actually, the SYSTEM account is technically the most privileged, but Administrator can execute commands as SYSTEM quite readily using the Scheduler Service to launch a command shell, for example.)
Service Accounts
Service account is an unofficial term used to describe a Windows user account that launches and runs a service non-interactively (a more traditional computing term is batch accounts). Service accounts are typically not used by human beings for interactive logon, but are used to start up and run automated routines that provide certain functionality to the operating system on a continuous basis. For example, the Indexing service, which indexes contents and properties of files on local and remote computers, and is located in %systemroot%\System32\cisvc.exe, can be configured to start up at boot time using the Services control panel. For this executable to run, it must authenticate to the operating system. For example, the Indexing service authenticates and runs as the LocalSystem account on Windows Server 2003 in its out-of-the-box configuration.
Service accounts are a necessary evil in Windows. Because all code must execute in the context of an account, they can’t be avoided. Unfortunately, because they are designed to authenticate in an automated fashion, the passwords for these accounts must be provided to the system without human interaction. In fact, Microsoft designed the Windows NT family to cache passwords for service accounts on the local system. This was done for the simple convenience that many services need to start up before the network is available (at boot time), and thus could not be authenticated to domain controllers. By caching the passwords locally, this situation is avoided.
Computers (Machine Accounts)
When a Windows system joins a domain, a computer account is created. Computer accounts are essentially user accounts that are used by machines to log on and access resources (thus, computers are also called machine accounts). This account name appends a dollar sign ($) to the name of the machine (machinename$).
Identity SID Comment
Anonymous Logon S-1-5-7 Special hidden group that includes all users who have authenticated with null credentials.
Authenticated Users S-1-5-11 Special hidden group that includes all currently logged-on users.
INTERACTIVE S-1-5-4 All users logged on to the local system via the physical console or Terminal Services.
Everyone S-1-1-0 All current network users, including guests and users from other domains
Network S-1-5-2 All users logged on through a network connection; access tokens for interactive users do not contain the Network SID
Service S-1-5-6 All security principals that have logged on as a service; membership is controlled by the operating system
This Organization S-1-5-15 New to Windows Server 2003, added by the authentication server to the authentication data of a user, provided the Other Organization SID is not already present
Other Organization S-1-5-1000 New to Windows Server 2003, causes a check to ensure that a user from another forest or domain is allowed to authenticate to a particular service
The SAM and Active Directory
Now that we’ve provided an overview of security principals and capabilities, let’s explore in more detail how objects such as accounts and passwords are managed in Windows. On all Windows computers, the SAM contains user account name and password information. The password information is kept in a scrambled format such that it cannot be unscrambled using known techniques (although the scrambled value can still be guessed). The scrambling procedure is called a one-way function (OWF), or hashing algorithm, and it results in a hash value that cannot be decrypted. We will refer to the password hashes a great deal in this book. The SAM makes up one of the five Registry hives and is implemented in the file %systemroot%\ system32\config\sam.
On Windows Server 2000 and later domain controllers, user account/hash data for the domain is kept in the Active Directory (%systemroot%\ntds\ntds.dit, by default). The hashes are kept in the same format, but they must be accessed via different means.
Windows Password Representation in the SAM
In the SAM database, Windows can store passwords in two forms:
- LANMAN
- NT Hash
By default, both are stored in NT , 2000, XP and 2003. LANMAN hashes are not stored in Vista, Windows 8 and Windows 2008 by default. Active Directory (AD) store account information including LANMAN and NT hashes in %systemroot%\ntds\ntds.dit.
LANMAN Hash Algorithm
The LM hash of a password is computed using a six-step process:
- The user’s password is converted into all uppercase letters
- The password has null characters added to it until it equals 14 characters
- The new password is split into two 7 character halves
- These values are used to create two DES encryption keys, one from each half with a parity bit added to each to create 64 bit keys.
- Each DES key is used to encrypt a preset ASCII string (KGS!@#$%), resulting in two 8-byte ciphertext values
- The two 8-byte ciphertext values are combined to form a 16-byte value, which is the completed LM hash
In practice, the password “PassWord123” would be converted as follows:
- PASSWORD123
- PASSWORD123000
- PASSWOR and D123000
- PASSWOR1 and D1230001
- E52CAC67419A9A22 and 664345140A852F61
- E52CAC67419A9A22664345140A852F61
NTLM Password Hashes
NT LAN Manager (NTLM) is the Microsoft authentication protocol that was created to be the successor of LM. NTLM was accepted as the new authentication method of choice and implemented with Windows NT 4.
The creation of an NTLM hash (henceforth referred to as the NT hash) is actually a much simpler process in terms of what the operating system actually does, and relies on the MD4 hashing algorithm to create the hash based upon a series of mathematical calculations. After converting the password to Unicode, the MD4 algorithm is used to produce the NT hash. In practice, the password “PassWord123”, once converted, would be represented as “67A54E1C9058FCA16498061B96863248”.
MD4 is considered to be significantly stronger than DES as it allows for longer password lengths, it allows for distinction between uppercase and lowercase letters and it does not split the password into smaller, easier to crack chunks.
Note: The biggest complaint with NTLM created hashes is that Windows does not utilize a technique called salting. With this being the case, it is possible for a user to generate what are called rainbow tables. Rainbow tables are actually tables containing every single hash value for every possible password possibility up to a certain number of characters.
LANMAN Challenge/Response
Reference
