The world is abuzz with the most recent ransomware attack, dubbed WannaCrypt. While this attack generated a lot of fanfare, the tools needed to mitigate the problem were already in existence months ago.
A month prior to the release of the hacking tool, Microsoft patched the vulnerability it targeted as part of its March Patch Tuesday release. Back in September 2016, Microsoft was already sounding the alarm about the protocol Server Message Block version 1, discouraging its use.
Why then was it still being used? Many of the compromised clients were running Windows 7, which no longer needs SMBv1 to communicate with other clients and servers.
The purpose of this blog post is to summarize the issues with SMBv1, explain the importance of server hardening to reduce risk to environments and to go over some best practices for implementation.
Issues with SMBv1
The original SMB v1 protocol is almost 30 years old. Software designed in the 1980s is obviously very different from the landscape that exists today. The 1980s were a world without malicious actors, advanced persistent threats, ever-increasing volumes of stored data and near-universal computer usage.
Since 2007, when both Windows Vista and Windows 2008 were released, SMB v1 was rendered obsolete. When using SMB v1, you lose the following key protections offered by the later SMB protocol versions:
- Pre-authentication integrity (SMB v3.1.1+), which protects against security downgrade attacks.
- Secure dialect negotiation (SMB v3.0, v3.02), which protects against security downgrade attacks.
- Encryption (SMB v3.0+), which prevents inspection of data on the wire and man-in-the-middle attacks. In SMB v3.1.1 the throughput encryption performance is even better than signing.
- Insecure guest authentication blocking (SMB v3.0+), which protects against man-in-the-middle-attacks.
- Better message signing (SMB v2.02+). HMAC SHA-256 replaces MD5 as the hashing algorithm in SMB v2.02, SMB v2.1 and AES-CMAC replaces that in SMB v3.0+. Signing performance also increases in SMB v2 and SMB v3.
If your clients have SMB v1 enabled on their endpoints, then a man-in-the-middle can tell your client to ignore all the above controls. All they need to do is block their SMB v2+ traffic and answer to your server’s name or IP address. Your client will default to SMB v1 communication and share all the in-transit data on the network — unless you required encryption on that share to prevent SMB v1 in the first place. SMB v1 is no longer needed. It is no longer necessary. It should be, at a minimum, turned off; optimally uninstalled via GPO.
The importance (and challenges) of server hardening
As delivered by manufacturers and resellers, the default configurations for operating systems and applications are typically geared to maximize ease-of-deployment and ease-of-use, not with security in mind. Basic controls, open services and ports, default accounts or passwords, older more vulnerable protocols (like SMB v1), pre-installation of unneeded software; all can be exploitable in their default state.
Developing configuration settings with good security properties is a complex task beyond the ability of individual users. It requires the analysis of potentially hundreds or thousands of options in order to make the optimum choices to reduce the risk of exposure.
Even if a strong, initial configuration is developed and installed, it must be continually managed to avoid security “decay” as software is updated or patched, new security vulnerabilities are reported and configurations are tweaked to allow the installation of new software or support new operational requirements. If this is not done, attackers will find opportunities to exploit both network-accessible services and client software.
Best practices for the implementation of server hardening
Some important things to keep in mind when implementing this control are:
- Establish and ensure the use of standard secure configurations of your operating systems. These standardized images should represent hardened versions of the underlying operating system as well as the applications installed on the system.
- Implement automated patching tools and processes for both operating systems and applications.
- Limit administrative privileges to very few users who have both the knowledge necessary to administer the operating system as well as a business need to modify the configuration of the underlying operating system and/or application.
- Ensure strict configuration management by building a secure image that is used to build all new systems that are deployed in the enterprise. Any existing system that becomes compromised should be reimaged with the secure build.
- Ensure the master images are stored on securely configured servers, validated with integrity-checking tools capable of continuous inspection, and change management to ensure that only authorized changes to the images are possible.
For those organizations looking for server and application hardening templates, a good place to start is the Center for Internet Security, which publishes templates for operating systems as well as application hardening.
For more information about server hardening, reach out to the managed security specialists at Rackspace. And click here to find more about our managed security services and the ways we’re helping organizations combat cyber attacks.