Retire Those Old Legacy Protocols

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

Updated security features are found below

• Pre-authentication Integrity (SMB 3.1.1+)
  • Protects against security downgrade attacks
• Secure Dialect Negotiation (SMB 3.0, 3.02)
  • Protects against security downgrade attacks
• Encryption (SMB 3.0+). Prevents inspection of data on the wire, MiTM attacks
  • In SMB 3.1.1 encryption performance is even better than signing
• Insecure guest auth blocking (SMB 3.0+ on Windows 10+)
  • Protects against MiTM attacks
• Better message signing (SMB 2.02+)
  • HMAC SHA-256 replaces MD5 as the hashing algorithm in SMB 2.02, SMB 2.1 and AES-CMAC replaces that in SMB 3.0+
  • Signing performance increases in SMB2 and 3

SMB1 is Very Inefficient When Compared to SMB 3.0 *5

• Larger reads and writes (2.02+)
  • More efficient use of faster networks or higher latency WANs
  • Large MTU support.
• Peer caching of folder and file properties (2.02+)
  • Clients keep local copies of folders and files via BranchCache
• Durable handles (2.02, 2.1)
  • Allow for connection to transparently reconnect to the server if there is a temporary disconnection
• Client oplock leasing model (2.02+)
  • Limits the data transferred between the client and server, improving performance on high-latency networks and increasing SMB server scalability
• Multichannel & SMB Direct (3.0+)
  • Aggregation of network bandwidth and fault tolerance if multiple paths are available between client and server, plus usage of modern ultra-high throughout RDMA infrastructure
• Directory Leasing (3.0+)
  • Improves application response times in branch offices through caching

Use Cases Where SMB1 is Still Required

• Still running XP or WS2003 (Or older)
  • Out of support (Unless there is a custom support agreement in place)
• Old management software that demands admins browse the ‘network neighborhood’ master browser list
• Old network storage device
• 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

Security Protocol Support by OS Version:

To disable the use of security protocols on a device, changes need to be made within the registry. Once the changes have been made a reboot is necessary for the changes to take effect.
https://technet.microsoft.com/en-us/library/dn786418.aspx

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.

In the settings below, both TLS 1.0 and TLS 1.1 are disabled.

Open up the registry (RegEdit) and browse to:
Computer > HKLM > System > CurrentControlSet > Control > SecurityProviders > SCHANNEL > Protocols

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsPCT 1.0]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsPCT 1.0Client]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsPCT 1.0Server]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client]

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server]

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client]

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server]

“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]

Building a migration plan to move to TLS 1.2. *8

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

From an elevated command prompt:
Get-WindowsFeature FS-SMB1

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

Open up Event Viewer and review any events that might be listed.
Applications and Services Logs > Microsoft > Windows > SMB Server > Audit

LM/NTLMv1

To find the use of LM there are 3 choices NetLogon logging, network sniffing, or if you are on Windows Vista/Server 2008 or above, you can also use the event viewer. Rather than touch on everything here, it may be easier to take a look at https://blogs.technet.microsoft.com/ken_brumfield/2008/08/08/ntlmv2-or-not-ntlmv2-that-is-the-question/ and https://blogs.msdn.microsoft.com/openspecification/2010/05/03/ntlm-v1-no-excuse-me-ntlm-v2-oh-no-you-were-right-its-v1/ for a little more information on how to do this.

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

Get-ADUSer -filter ‘userAccountControl -band 128’ -properties userAccountControl

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.

References

1. https://www.ssllabs.com/
2. https://docs.microsoft.com/en-us/msrc/customer-guidance-for-wannacrypt-attacks
3. https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Ransom:Win32/Petya
4. https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
5. https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
6. https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
7. https://support.microsoft.com/en-us/help/2793313/security-guidance-for-ntlmv1-and-lm-network-authentication
8. https://www.microsoft.com/en-us/download/details.aspx?id=55266
9. https://blogs.technet.microsoft.com/ralphkyttle/2017/04/07/discover-smb1-in-your-environment-with-dscea/
   
10. https://support.microsoft.com/en-us/help/3080079/update-to-add-rds-support-for-tls-1-1-and-tls-1-2-in-windows-7-or-wind
    
11. https://technet.microsoft.com/en-us/library/ff458357.aspx
    
12. https://blogs.technet.microsoft.com/askpfeplat/2016/04/18/the-importance-of-kb2871997-and-kb2928120-for-credential-protection/
13. https://blogs.technet.microsoft.com/askds/2012/02/02/purging-old-nt-security-protocols/
    
14. https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
15. https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/22e38464-acb3-48cd-87e5-c554ef6e3ccd.mspx?mfr=true
16. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772679(v=ws.10)