AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

Hello Paul Bergson back again, and I wanted to bring up another security topic. There has been a lot of work by enterprises to protect their infrastructure with patching and server hardening, but one area that is often overlooked when it comes to credential theft and that is legacy protocol retirement. These legacy protocols were built when there wasn’t the understanding of security requirements that our modern enterprises need today.

To better understand my point, American football is very fast and violent. Professional teams spend a lot of money on their quarterbacks. Quarterbacks are often the highest paid player on the team and the one who guides the offense. There are many legendary offensive linemen who have played the game and during their time of play they dominated the opposing defensive linemen. Over time though, these legends begin to get injured and slow down do to natural aging. Imagine a quarterback at the peak of his career, making over $10 million in salary being protected by a legendary offensive line that was 10 years beyond their prime. If you think of these older protocols like offensive linemen that are protecting the operating system and its data, they need patches (injured) and they get old & slow (weak encryption, etc…). Unfortunately, I see all too often, enterprises running old protocols that have been compromised, with in the wild exploits defined, to attack these weak protocols. No General Manager would ever risk the safety/security of his investment in his key offensive player(s), neither should the teams responsible in protecting the safety and security of their IT enterprise.

Attack Surface Reduction can be achieved by disabling support for insecure legacy protocols.

TLS 1.0 & 1.1 (As well as all versions of SSL)

Server Message Block v1 (SMBv1)

LanMan (LM) / NTLMv1

Digest Authentication

The SSL protocol is broken and can no longer be fixed, threats such as POODLE still exist (see cve-2014-3566) SSL protocol should be retired. TLS 1.0 is no longer considered secure and as of June 30, 2018 the PCI board has set for a deadline for disabling all SSL and TLS 1.0 with the recommendation to use TLS 1.2. *1

The WannaCrypt ransomware attack, worked to infect a first internal endpoint. The initial attack could have started from phishing, drive-by, etc… Once a device was compromised, it used an SMB v1 vulnerability in a worm-like attack to laterally spread internally. *2

A second round of attacks occurred about 1 month later named Petya, it also worked to infect an internal endpoint. Once it had a compromised device, it expanded its capabilities by not only laterally moving via the SMB vulnerability it had automated credential theft and impersonation to expand on the number devices it could compromise. *3 *4

Both WannaCrypt and Petya are just two of many assaults that leverage SMBv1. With LanMan and NTLMv1 there are open source tools readily available to capture and crack credentials. This is why it is becoming so important for enterprises to retire old outdated equipment, even if it still works!

The rest of this document covers details of the protocols and how they can be removed from the enterprise’s environment.

Ned Pyle wrote a great blog on the retirement of SMB1 that I have borrowed from. This is a great article that you will want to read if you haven’t already. The link to his article can be found in the “References” below.

Server Message Block v1 (SMBv1)

With SMB1 you don’t have access to modern security features that SMB 3 provides. *5

Old multi-function printers with old firmware in order to “scan to share”

The above listed services should all be scheduled for retirement since they risk the security integrity of the enterprise. The cost to recover from a malware attack can easily exceed the costs of replacement of old equipment or services.

Retirement

The SMB1 protocol can be removed via Group Policy, PowerShell or Server Manager. *6

LanMan (LM) / NTLM v1

“We are aware of detailed information and tools that might be used for attacks against NT LAN Manager version 1 (NTLMv1) and LAN Manager (LM) network authentication. Improvements in computer hardware and software algorithms have made this protocol vulnerable to published attacks for obtaining user credentials.” *7

LMHash was developed pre-WinNT. It is now considered extremely insecure and we STRONGLY encourage our customers to disable its use. Although NTLM v1 is a newer protocol, it too is considered insecure and we again STRONGLY encourage its retirement as well.

Utilizing a Group Policy applied against clients’ and/or servers’, legacy protocols can be eliminated from use.

Possible values

Send LM & NTLM responses

Send LM & NTLM – use NTLMv2 session security if negotiated

Send NTLM responses only

Send NTLMv2 responses only

Send NTLMv2 responses only. Refuse LM

Send NTLMv2 responses only. Refuse LM & NTLM

Not Defined

Retirement

The recommended settings would be to “Send NTLMv2 responses only. Refuse LM & NTLM“. If NTLMv1 is in use, at a minimum “Send NTLMv2 responses only. Refuse LM” should be configured for your domain environment.

Administrators are strongly encouraged to prevent the LM hash from being stored in the local SAM database and Directory Services. Implementing the NoLMHash can be configured by setting the “Network security: Do not store LAN Manager hash value on next password change” to enabled. By default this should already be set.

Potential Impact

As with any changes to your environment, it is recommended to test this prior to pushing into production. If there are legacy protocols in use, an enterprise does run the risk of services becoming unavailable. It would be in the best security interests, if insecure legacy protocols are in use, to chart out a plan to retire/migrate the devices that still require these protocols.

TLS/SSL

“Many operating systems have outdated TLS version defaults or support ceilings that need to be accounted for. Usage of Windows 8/Server 2012 or later means that TLS 1.2 will be the default security protocol version.” *8

The default settings for the TLS/SSL are all enabled with the exception of Client SSL 2.0, which is disabled. The registry settings below are ciphers that can be configured. If you want to disable a protocol just create a new entry and configure “Enabled” to equal 0 under the specific sub-key you want to disable.

Note: Disabling TLS 1.0 could prevent clients from connecting to Windows Server 2008 R2 (2008 SP2 is not covered) and Windows 7, unless KB3080079 has been applied on the device you are connecting too, and you are using the latest release of the RDC client. *10

Windows 8 and Server 2012 and later already have this capability built-in.

You will also need to ensure that the destination device has been configured to “Negotiate” its RD session. *11

Digest/WDigest

Digest/WDigest was introduced back with Windows XP/Server 2003 and it has long since been found to be insecure. Microsoft highly recommends that this protocol be disabled. If you have installed KB2871997 Digest/WDigest still needs to be disabled on the device. KB2871997 provides the ability to disable its use, but by itself does not prevent its use. *13

Prior to disabling Digest/WDigest you will want to ensure it isn’t in use. This can be accomplished by inspecting the Event logs and/or ensuring that reversible encryption is not set in Active Directory, Directory Service. For complete details see below.

Checking for the Use of These Legacy Protocols

SMBv1

The PowerShell command above will provide details on whether or not the protocol has been installed on a device. Ralph Kyttle has written a nice Blog on how to detect, in a large scale, devices that have SMBv1 enabled. *9

Once you have found devices with the SMBv1 protocol installed, the device should be monitored to see if it is even being used. There is a PoSh command to Audit the use of SMBv1 to see if the protocol is in use: *5
Set-SmbServerConfiguration –AuditSmb1Access $true

If you are on an operating system LOWER than Windows Server 2008/Vista, or for some reason you cannot enable to necessary security logging, then a network sniffing tool will be required to determine if NTLMv1 is in use. Unfortunately to find which version of NTLM is in use you have to look at the NTLM conversation itself in this case. Ned Pyle wrote a great article on how to capture and differentiate between v1 and v2 that can be found at https://blogs.technet.microsoft.com/askds/2012/02/02/purging-old-nt-security-protocols/.

*13

TLS 1.0

To help determine a specific clients TLS use, Qualys SSL Labs has a nice tool (If the device has internet access). The tool provides client and web server testing. *14

From an enterprise perspective you will have to look at the enabled ciphers on the device via the Registry as shown above.

Digest/WDigest

Digest authentication requires the use of reversibly encrypted copy of the user’s password store in Active Directory, Directory Services (AD DS). To check to see if this is enabled with AD DS, review the setting on your user’s accounts to see if your accounts have the box checked for “Store password using the reversible encryption”. *15

If it is found that it is enabled, prior to disabling, Event Logs should be inspected so as to possibly not impact current applications. Event ID 4776 will appear in the Security Event log for any use of Digest/WDigest. To ensure that you are capturing authentication events ensure that you have this enabled – “Audit Credential Validation” = Enabled. This should be enabled on all of the enterprises DC’s. *16

I think this is a topic many of you hadn’t thought of and hopefully it can make your to do list to research your environment and find out what type of insecure protocols you might have running within your environment. Best of luck in your research and oh by the way “SKOL” Minnesota Vikings.

Join the conversation

Looking at retiring legacy protocols on an RD Gateway server, can see we have some TLS 1.0 hits (Thanks for the Schannel Group Policy BTW)
Trouble is matching those TLS 1.0 hits with RD sessions (usernames, client info, etc) so we can take the appropriate action on the end user side of things first. Any suggestions better than digging through a packet capture?