First published on TechNet on Feb 12, 2018
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.
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.
With SMB1 you don't have access to modern security features that SMB 3 provides. *5
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.
The SMB1 protocol can be removed via Group Policy, PowerShell or Server Manager. *6
"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.
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.
"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:
Windows OS |
SSLv2 |
SSLv3 |
TLS 1.0 |
TLS 1.1 |
TLS 1.2 |
Windows Vista |
Enabled |
Enabled |
Default |
Not Supported |
Not Supported |
Windows Server 2008 |
Enabled |
Enabled |
Default |
||
Windows 7 (WS2008 R2) |
Enabled |
Enabled |
Default |
||
Windows 8 (WS2012) |
Disabled |
Enabled |
Enabled |
Enabled |
Default |
Windows 8.1 (WS2012 R2) |
Disabled |
Enabled |
Enabled |
Enabled |
Default |
Windows 10 |
Disabled |
Enabled |
Enabled |
Enabled |
Default |
Windows Server 2016 |
Not Supported |
Disabled |
Enabled |
Enabled |
Default |
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_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] 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 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.
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
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-quest... and https://blogs.msdn.microsoft.com/openspecification/2010/05/03/ntlm-v1-no-excuse-me-ntlm-v2-oh-no-yo... 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
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 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.