How to Shoot Yourself in the Foot with Security, Part 1

  • Article

Security Management

By Jesper M. Johansson
Enterprise Security Architect
Microsoft Corporation

See other Security Management columns.

A while ago, I took a hiatus from writing these articles. Now I am back and I thought it would be fun to continue the snake-oil theme that we started with the security myths series and to write about some of the well-meaning things that people do for security that instead result in breaking things. Whereas the myths were high-level concepts, this series will be more technical. The objective is to help you better understand some of the things we do to provide security, and how they may break things unless we are really careful in how we use them.

I don't know at this point how many of these articles there will be, so this is part 1 of n. This article addresses something that is generally good but that causes serious problems because people often implement it incorrectly: Server Message Block (SMB) message signing. By default, as we will see later, the only problems that should be caused by SMB message signing are that older systems running Windows 9x cannot connect to a Windows Server 2003 domain controller (DC). (Windows 98 Second Edition and Windows Me support SMB message signing by default, older systems do not.) Even though this should only affect environments that have not yet replaced their machines running Windows 9x, SMB message signing accounts for 25 percent of all support calls to Microsoft product support services (PSS) relating to security policy. Clearly this setting can be confusing to some people, which makes it a good candidate to explain in this series.

Future articles in this series will address various issues that seem logical at the time. If you have any requests for something to address, a funny story you would not mind sharing (anonymously if you would like) about shooting yourself in the foot, or something else you would like to see covered, please click the "Comments" button below and send me a message.

SMB Message Signing
The SMB, or Server Message Block, protocol is what underlies a Microsoft Windowsbased network. SMB is actually the Microsoft version of an Internet standard known as the Common Internet File System (CIFS). Other systems implement the same standard, including, notably, SAMBA and various hardware devices such as network-attached storage systems. SMB is the basis of all Windows networking and is the protocol used for file and print shares, most domain-traffic, and a while host of other indispensable things in Windows networks. SMB was years ago to a threat model that is very different from what we consider today. Therefore it has few security constructs built in. It was therefore no surprise when Hobbit published a 1997 paper called Common Insecurities Fail Scrutiny, highlighting security issues in SMB. Attack tools soon became available that took advantage of these issues, including the now infamous SMB Reflection Attack.

Many of the problems with CIFS/SMB (henceforth, I shall just use SMB to refer to the protocol) were types of man-in-the-middle attacks, where an attacker manages to insert himself into the conversation and either eavesdrop on it or change its content. For instance, an attacker could listen to the SMB session setup between a legitimate client and server, capture the packets, and later replay them against the server to make his own connection to the server. The SMB Reflection Attack is a special kind of man-in-the-middle attack where the attacker and the server are the same machine. In Protect Your Windows Network, we explained the SMB Reflection Attack like this:

  1. Machine A connects to machine B.

  2. Machine B sends a challenge to machine A.

  3. Machine A computes the response to the challenge and sends it to machine B.

  4. Machine B, having performed the same calculation as A using the credentials it has stored, now compares the response to its own calculated value. If the two match, the connection is a success.

Now consider this flow instead. For this to work, the attacker needs to convince the victim to initiate an SMB connection to the attacker. This e-mail may be part of a social engineering attack.

  1. Victim initiates a connection to the attacker.

  2. At this point, the attacker's system is supposed to send a challenge to the victim to allow the victim to authenticate. Instead, the attacker initiates a new connection to the victim.

  3. Victim generates a challenge for the inbound connection from the attacker and sends it to the attacker.

  4. The attacker takes the challenge it received in Step 3 and sends it to the victim as the challenge for the connection the victim initiated in Step 2.

  5. The victim computes the response to the challenge and sends it to the attacker.

  6. The attacker takes the response received in Step 5 and returns it to the victim as the response to the connection it initiated to the victim in Step 2.

For more details on the individual steps and how the attacker uses them, see Protect Your Windows Network, by Johansson and Riley.

In response to Hobbit's paper, Microsoft added some features to SMB. One of the added features designed to limit these man-in-the-middle attacks was SMB Message signing. SMB Message signing signs SMB packets to ensure that they cannot be replayed against a different system. SMB Message signing is actually four different settings. Again, from Protect Your Windows Network:

  • Microsoft network client: Digitally sign communications (if server agrees) - Sets the workstation service to request message signing on outbound request to SMB servers. This is the only setting of the four that is on by default. This setting is stored in the registry at
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters\EnableSecuritySignature. If this setting is turned off, message signing on the client is disabled. If it is turned on, signing is enabled.

  • Microsoft network client: Digitally sign communications (always) - Sets the workstation service to require message signing on outbound requests to SMB servers. This setting is stored in the registry at
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters\RequireSecuritySignature. If this setting is turned on, the client requires all SMB traffic to be signed. If it is turned off, the EnableSecuritySignature setting on the workstation service guides client behavior.

  • Microsoft network server: Digitally sign communications (if client agrees) - Sets the server service to request message signing on inbound requests from SMB clients. This setting is stored in the registry at
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\EnableSecuritySignature. If this setting is turned off, message signing on the server is disabled. If it is turned on, signing is enabled.

  • Microsoft network server: Digitally sign communications (always) - Sets the server service to require message signing on inbound requests from SMB clients. This setting is stored in the registry at
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\RequireSecuritySignature. If this setting is turned on, the server requires all SMB traffic to be signed. If it is turned off, the EnableSecuritySignature setting on the server service guides server behavior.

The first two settings, those denoted with Microsoft network client, affect the workstation service; the Windows file sharing client service. The latter two, denoted with Microsoft network server affect the server service; the Windows file sharing server service. This is a critically important point: The settings have nothing to do with whether the system is primarily acting as a server or a client in the network. All systems have both a workstation and a server service. That means that both settings affect all Windows-based systems and you need to carefully consider how they interact. Therefore, we will henceforth use the term "server" to refer to the machine that is acting as a server in an SMB transaction, and the term "client" to refer to the machine that is acting as a client in the same transaction.

The default settings for each of these are relatively straightforward:

  • The workstation service is set to enable signing on all Windows 2000 and higher systems.

  • The server service is set to disable signing on all Windows 2000 and higher systems.

  • Windows 2000 DCs are set to enable signing on the server service.

  • Windows Server 2003 DCs are set to require signing on the server service.

  • Windows 9x does not support SMB message signing out of the box, nor do many third-party SMB clients and servers.

The interaction between these settings is quite tricky. If the server service on the server, for instance, is set to require signing ("Microsoft network server: Digitally sign communications (always)" turned on), the workstation service must have signing enabled or the communication will fail. The following table shows the interaction between the settings on the server and on the client:

How to Shoot Yourself in the Foot
It is clear already that we have a problem. Windows Server 2003 DCs require message signing, while Windows 9x does not support it, so one way to shoot yourself in the foot is to use Windows 9x. But we knew that already.

If you simple leave the defaults as they are you should not have any problems (except the aforementioned issue with Windows 9x). In spite of that, a lot of folks seem to have a problem with SMB message signing. Clearly, people are changing the defaults. One very easy way to shoot yourself in the foot is to follow all the available security guidance that tells you that you must require SMB message signing on the workstation service. This is actually general goodness. It blocks the SMB Reflection Attack. Unfortunately, unless you enable SMB message signing on all servers at the same time, it also puts you in the Workstation/Required–Server/Disabled box above, where all connections fail. Many people fail to realize that if they simply require signing on the client, it can no longer speak to any servers configured with their default settings. This is the first way people shoot themselves in the foot with this setting.

The second way people shoot themselves in the foot seems to occur once they realize they cannot connect to their servers. Since there is no easy way to revert to the default settings, it appears many people turn off message signing on the workstation service. This restores connectivity to servers, but breaks connectivity to Windows Server 2003 DCs, since those require signing. In fact, it makes a modern client act like a Windows 9x system, which does not support signing either by default and therefore cannot speak to a Windows Server 2003 DC. In order to work properly with a Windows Server 2003 DC, all clients must support and have SMB message signing enabled. In other words, they have to have at least the "Microsoft network client: Digitally sign communications (if server agrees)" setting turned on.

Third, a really easy way to shoot yourself in the foot is to disable SMB message signing. SMB message signing does mitigate serious security issues by validating all packets in an SMB exchange. True, you may use Internet Protocol security (IPsec on top of SMB to achieve a similar effect, but unlike SMB message signing, IPsec does not stop attacks. It simply ensures that you only get attacked by people you know. SMB message signing actually stops the attacks. Thus, we highly recommend that you turn on SMB message signing for critical traffic like DC traffic.

Turning on message signing actually leads us to the final way to shoot yourself in the foot, and to the reason it is disabled on servers by default. There is a performance overhead associated with message signing. Turning on message signing actually modifies how data is transmitted. This means that the overhead is probably going to be negligible for small transactions like transferring small files. However, for very large file transfers the overhead could get extremely high—up to 40 percent in some situations. Therefore, you need to think about where you turn it on.

Clearly, SMB message signing provides significant security value. However, as we discussed in the first article in the security management series, this value comes at a cost; in this case, primarily in terms of performance but also in compatibility. Nobody can tell you that "you must require SMB message signing everywhere" without first doing a detailed risk analysis. The cost can be significant, but the risk is that user credentials get stolen or replayed against a server at a later time. If the risk is deemed to outweigh the cost, you should require SMB message signing everywhere. I cannot tell you that you must do that, nor can anyone else unless they do the analysis. The aim of this article is to give you the information you need to make an intelligent decision, and to help you avoid shooting yourself in the foot by configuring the setting incorrectly.

Learning More
There are numerous resources available on SMB message signing, including the following:

As always, this column is for you. Let us know if there is something you want to discuss, or if there is a better way we can help you secure your systems. Just click the “Comments” button below and send us a note.