Archive

Posts Tagged ‘SMB’

Wireshark: Determining a SMB and NTLM version in a Windows environment

February 3, 2011 4 comments

The last few days I am playing around with wireshark and I must say I enjoy working with this program. It has saved the day for me a couple of times by giving me information that is only retrieved by looking at packet level. In this article I was looking at SMB and NTLM traffic in a windows environment. I noticed that our XP based network was running NTLMv1 that is considered unsecure. Let’s change this fast !

Intro

NTLM over a Server Message Block (SMB) transport is one of the most common uses of NTLM authentication and encryption. Kerberos Protocol Extensions (KILE) is the preferred authentication method of an SMB session in Windows Server operating system and Windows Client operating systems. However, when a client attempts to authenticate to an SMB server using the KILE protocol and fails, it can attempt to authenticate with NTLM.

The NT LAN Manager (NTLM) Authentication Protocol is used in Microsoft Windows Networks for authentication between clients and servers.  NTLM is used by application protocols to authenticate remote users and, optionally, to provide session security when requested by the application. There are two major variants of the NTLM authentication protocol: the connection-oriented variant and the connectionless variant. Each of these variants has three versions: LM, NTLMv1, and NTLMv2.  In addition to authentication, the NTLM protocol optionally provides for session security—specifically message integrity and confidentiality through signing and sealing functions in NTLM. For more in depth information I urge you to read this Microsoft NTLM documentation. The following picture will show a protocol flow of NTLM and Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) authentication of an SMB session.

Step 1 and 2 – The SMB protocol negotiates protocol-specific options using the SMB_COM_NEGOTIATE request and response messages. The client will send its supported dialects and the server will respond with the highest possible dialect. The following dialect values are possible (older dialects are excluded here):

Step 3 – The client sends an SMB_COM_SESSION_SETUP_ANDX request message. Assuming that NTLM authentication is negotiated, within this message an NTLM NEGOTIATE_MESSAGE is embedded.

Step 4 – The server responds with an SMB_COM_SESSION_SETUP_ANDX response message within which an NTLM CHALLENGE_MESSAGE is embedded. The message includes an 8-byte random number, called a “challenge”, that the server generates and sends in the ServerChallenge field of the message.

Step 5 – The client extracts the ServerChallenge field from the NTLM CHALLENGE_MESSAGE and sends an NTLM AUTHENTICATE_MESSAGE to the server (embedded in an SMB_COM_SESSION_SETUP_ANDX request message). If the challenge and the response prove that the client knows the user’s password, the authentication succeeds and the client’s security context is now established on the server.

Step 6 – The server sends a success message embedded in an SMB_COM_SESSION_SETUP_ANDX response message.

Wiresharking

This article will only show how to find out which SMB and NTLM versions are used on your windows servers and windows clients while using Wireshark. This is very useful to know because it has a great impact on your security. There are many documents on the internet that show that LM and NTLMv1 are insecure these days therefore we need to ensure that these authentication methods are not allowed inside the windows network. Thus we need to ensure that NTLMv2 only is allowed. This behavior can be changed on windows servers and clients at the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

REG_DWORD Valuename: lmcompatibilitylevel

The following values can be used:

So you’re actually configuring a minimum security level here. Now let’s take a look which values are used by default per OS type:

We can conclude that if we have an XP client and a windows 2008 R2 server with default settings it will always use NTLMv1. If we use an Windows 7 or Vista client and a windows 2008 R2 server it will use NTLMv2. Lets fire up Wireshark and take a look what’s happening “on the wire”.

Windows XP client and Windows 2008 R2 server (default settings)

In this scenario a Windows XP client (10.0.0.2) tries to connect to a Windows 2008 R2 Server (10.0.0.1) share. Let’s take a look at the SMB negotiate protocol request:

The highest possible dialect that the Windows XP client can speak is NT LM 0.12. Thus SMB v1.0. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of SMB v1.0 (NT LM 0.12) and this is used to access the share. Let’s take a look which version of NTLM it uses by looking at the Session setup andX request: NTLMSSP_AUTH packet.

There is no NTMLv2 section here so it is using NTLMv1. Thus insecure !!

Windows 7 client and Windows 2008 R2 server (default settings)

In this scenario a Windows 7 Client (10.0.0.3) tries to connect to a Windows 2008 R2 Server (10.0.0.1) share. Let’s take a look at the SMB negotiate protocol request:

The highest possible dialect that the Windows 7 client can speak is SMB 2.???. Thus SMB v2.0 Wildcard. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of 0x02ff (hexadecimal value for SMBv2.0 wildcard). You can also see that the protocol column switches from SMB to SMB2. Now the Windows 7 clients needs to know which SMB2 version will be used for communication. . Let’s take a look at the new SMB2 negotiate protocol request:

The highest possible SMB2 dialect that the Windows 7 client can speak is more specific now. It can use 0x0202 or 0x0210. Thus SMB v2.002 or SMB v2.1. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of 0x210 (hexadecimal value for SMBv2.1) and this is used to access the share. Let’s take a look which version of NTLM it uses by looking at the Session setupRequest, NTLMSSP_AUTH packet.

The picture clearly shows that there is an NTLMv2 response.

Is there a quicker way to determine NTLMv1 or NTLMv2 authentication? Yes. We can do this by entering ntlmssp.ntlmv2response into the filter field. Wireshark will filter out ntlmv2 traffic only.

Back to our little problem. We have a network running with XP clients and windows 2008 R2 server with default settings on GPO level. We saw that NTLMv1 will be used for authentication and thus insecure. We need to change this so the XP machines will authenticate by using NTLMv2. We can achieve this by change the Lmcompatibilitylevel value to 5. The best way to achieve this is by placing all Windows XP clients into an OU and configure a computer GPO policy.

Before you change the server side to Lmcompatibilitylevel value 5 you must be absolutely sure that every Windows XP Client uses NTLMv2 or your phone will start ringing very often. You can achieve this by changing the default domain controllers policy or by placing a GPO on an OU with servers. When the server and client side are changed to NTLMv2 you have achieved the highest NTLM authentication possible. Thus the most secure NTLM form possible. This ends my article about Determining a SMB and NTLM version in a windows environment. I hope it’s useful somehow and feel free to comment.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: