Whether you conduct penetration testing an automated vulnerability scanning, knowing your target is the very essential first step. This process or technology is called Asset Profiling. In the asset profiling stage, the most important thing is to recognize the operating system (OS) via its fingerprint. When it comes to OS fingerprint recognition, you should first consider the Server Message Block (SMB) protocol. Let’s look at why.
If you use the Shodan search engine, its statistics on port 445 show that via SMB alone, you can determine the OS of 1.1 million hosts around the world. Therefore, SMB is the first choice for OS version detection – especially for Windows.
What is SMB?
The SMB protocol, which used to be called Common Internet File System (CIFS), was borne out of efforts at IBM in 1983, and was used by Intel® and Microsoft® as early adopters. Ultimately over the years, with Microsoft’s pervasive influence, it has grown into one of the two most prevailing network file system protocol today.
However, the SMB1 protocol has many shortcomings. In addition to the severe security vulnerability that caused the WannaCry Ransomware outrage in 2017, the SMB1 protocol is notorious for its vast consumption of network resources and poor performance under extreme communication scenarios.
The basic function of SMB as a network file system was completed between 1983 to 2007, including various file system operations, user authentication, message signatures, client caching, etc. It is even independent of the NetBIOS protocol layer and directly uses port 445 to run on top of TCP/IP.
SMB was once renamed as CIFS in 1996 as Microsoft’s response to its competition from Sun Microsystem who expanded its Network File System (NFS) protocol to Web services (WebNFS). This name change has caused people to sometimes refer to the SMB protocol as CIFS, and the SMB client on the Linux platform has even maintained the CIFS name until now.
With the fast evolution of the Internet, the security concerns and the increasingly inadequate performance of SMB forced Microsoft to drastically revise the SMB 1.0 protocol to SMB 2.0 in 2007. Noticeably, many new features in SMB 2.X and SMB 3.X basically addressed two issues: security enhancement and performance improvement.
You may wonder why SMB3 didn’t have a separate protocol document. One reason is that there is no significant difference between SMB2 and SMB3 in message format to open a separate document; the other reason is, in fact, SMB3.0 was named SMB2.2 during the beta phase of Windows 8. But later Microsoft engineers justified it as a major version on account of it having a large quantity of code changes and features.
How Different Vendors Use SMB for OS Detection
Highlights:
- Force SMB v1 detection: Instead of using the preferred SMB, it is forced to use SMBv1 for detection. Compared to SMBv2, the response of SMBv1 contains the plaintext string of the server operating system.
- SMB v1 OS detection: There are many kinds of SMBv1 requests and not every kind of request can get the OS version information. Here, it refers specifically to the SMB v1 OS detection
- SMB v1 OS detection request type NTLMSSP: If you send a general AndX Request instead of an SMBv1 request containing NTLMSSP AndX Request, you may not be able to detect the operating system of Windows® Server 2012 or later, even if the other party supports SMBv1
- SMB v2 detection result contains ntlmss.version: For servers that do not support SMB v1 but only support v2, although ntlmssp.version cannot be used directly to determine its operating system, it can recognize the specific Windows Name (Windows Edition) when combining with other information (such as ServerDNSDomainName contains WIN- and Desktop- in the response) as long as you rule out the OS as Linux/Unix.
- SMB v2 Response analysis detail level: Whether the SMBv2 response is parsed, and key field values are listed, such as ntlmssp.version and ServerDNSDomainName.
- Scan shared directories: This item is not used as a standard criterion to evaluate SMB OS scanning; it applies to some specific usage scenarios.
In our next blog, we will share more details about these commonly used products.
Stay tuned…