Challenges with Disabling 3Des

With the discovery of the sweet32 vulnerability (more at sweet32.info) in 3Des and 64-bit block ciphers in general, we had to see if it was possible to disable 3Des on our devices. You could be thinking, why have it enabled in the first place? Well, on Windows systems it’s enabled by default if you don’t take necessary steps and 3Des/168 is still a valid cipher in FIPS 140-2, which we must be compliant with. Disabling 3Des however is easy enough, handling the troubles afterwards is not. To disable 3Des add the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168\Enabled (DWORD) = 0

This disabled the following cipher suites:

SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Source: https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols-in-schannel.dll

During our tests on Windows Server 2008 R2 and Windows Server 2012 R2, the outcome was very different. Since we also disabled TLS 1.0 at the same time we ran into a few issues on 2008 R2. Just mind the following:

  • Make sure that you install KB308079, to add support for TLS 1.1 and 1.2 for RDP. HTTP already supports TLS 1.1 & 1.2
    https://support.microsoft.com/en-us/kb/3080079
  • Explicitly enable TLS 1.1 and TLS 1.2 in the registry of Windows Server 2008 R2 otherwise stuff will break. In our case, we couldn’t bind a certificate to a web site.
  • If you disable 3Des and have FIPS 140-2 enabled this will break RDP on Windows 2008 R2. We currently have a support case with Microsoft to see if this can be fixed (more info when it becomes available *).

* June 2017 – A hotfix for Windows Server 2008 R2 will be made available that fixes this specific issue.

*July 2017 – After intensive testing of a private hotfix no negative side effects could be found. A hotfix is scheduled to be released at the end of September 2017.

These are the major challenges we ran into. On Server 2012 R2, these issues didn’t occur. Just because I wanted to know what was going on under the hood I spend a day creating different scenario’s and monitoring results to see which ciphers would be used. I’ve listed the results below. Hopefully someone can make use of this information.

Scenarios

The following scenarios consists out of testing a Windows 7 client making a RDP or HTTP connection to a Windows 2008 R2 or Windows 2012 R2 server. Unless otherwise stated, the Windows client and server are patched with all security updates available. No additional updates have been installed. I would recommend against this setup in production, yet I know many organizations are reluctant to install additional updates in their environment. The conclusion of these tests shows that changes to the OS would have been covered if you install recommended updates as well. Security features, such as TLS, FIPS and 3DES are disabled on the server, not on the client.

Windows 7 & Windows Server 2008 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: No connection
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2

Observation: As you can clearly see in the results above, Windows 2008 R2 with FIPS 140-2 always connects with TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0 even if you have disabled TLS 1.0. Disabling 3DES kills the RDP connection entirely.

Protocol: HTTP

  • Default (No changes to the Operating System): LS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP does a far better job in selecting the correct ciphers, with or without FIPS140-2 enabled it selects the highest suite available. However, without any adjustments it prefers TLS 1.0 over 1.2 even when kb3080079 is installed. Please be aware that on Server 2008 R2 TLS1.1 & 1.2 are explicitly enabled in the registry.

Windows 7 & Windows Server 2012 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: When connecting to Windows Server 2012 R2 over RDP, the protocol still seems to have mind of it’s own. Disabling TLS1.0 on the server side seems to be ignored until you have installed kb3080079 on the Windows 7 box. After installing that update TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2 is the preferred cipher regardless of FIPS140-2 compliancy.

Protocol: HTTP

  • Default (No changes to the Operating System):
    FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP again is very consistent in selecting it’s cipher suite. Selecting FIPS140-2 compliancy has no negative or positive effect on the selection.

 

Windows Update Error 0x80072ee2

For a while now I’ve been getting timeouts when using Windows updates through our proxy servers. Everything else seems to be working just fine, no complaints on browsing the web, it just seems that whenever I’m using Windows update through the proxy it takes a few times before it’s successful. Up until now it wasn’t really a problem because we use internal WSUS servers, however testing the Microsoft Operation Manager Suite and pointing Windows update to the Internet for getting the patches made it clear that connectivity issues were getting in the way of progress. Every time we scheduled an update run, it’s would time out on the proxy with error 0x80072ee2, direct connection went fine on all occasions. To make a long story short it turns out that the underlying mechanism of Windows Updates depends on the Background Intelligent Transfer Service (BITS), which in turn uses a different mechanism to connect to the internet (WINHTTP).

Normally it will use your Internet Explorer proxy to connect to the Internet, yet this seems to be having a few issues where Windows Update is unable to connect. What helped me in fixing the problem is telling WINHTTP to always use a dedicated proxy instead of relying of the automatic detection of a proxy or use the settings from Internet Explorer. Simply use good old netsh or use the powershell cmdlet:

Set-BitsTransfer

to accomplish this task.

List the current proxy
netsh winhttp show proxy

Set a proxy server
netsh winhttp set proxy <FQDN:Port> 

Reset the proxy for winhttp
netsh winhttp reset proxy

Reference


Can’t download updates from Windows Update from behind a firewall or proxy server

https://support.microsoft.com/en-us/help/3084568/can-t-download-updates-from-windows-update-from-behind-a-firewall-or-proxy-server

How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site

https://support.microsoft.com/en-us/help/900935/how-the-windows-update-client-determines-which-proxy-server-to-use-to-connect-to-the-windows-update-web-site

Windows Update Error List

https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list

Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)

https://technet.microsoft.com/en-us/library/cc731131(v=ws.10).aspx

Set-BitsTransfer

https://technet.microsoft.com/en-us/library/dd819421.aspx

Best Practices When Using BITS

https://msdn.microsoft.com/en-us/library/windows/desktop/aa362783(v=vs.85).aspx

Windows Activation

At times I need a semi isolated Lab environment that will last for an extended period of time. Using Windows as an operating system I could fall back on using the evaluation version of the OS but wouldn’t it be cool if I could be using our corporate activation services for that? Luckily there’s a very easy way to get your machines activated, even when you run a lab environment. As most of you know Windows activation is accomplished by using the KMS service. It’s a service that uses anonymous RPC at port 1688. Being anonymous by nature is something we can take advantage of. To start using the corporate server you should do an inventory first. On your corporate network use the NSLookup utility to query for KMS entries.

nslookup -type=srv _vlmcs._tcp

If your environment contains KMS servers it will list something like this:

vlmcs._tcp.corp.contoso.com SRV service location
priority=0
weight=0
port=1688
svr hostname=kms01.corp.contoso.com
ms01.corp.contoso.com internet address = 192.168.10.100

Now you have the name and IP address of your corporate kms server, go to your lab setup and create a DNS service record in the _tcp. zone.

  1. Open the DNS management on your DNS server.
  2. Expand the DNS Zone.
  3. Right-click on the “_tcp” folder and select “Other” -> “New Records“.
  4. Select Service Location (SRV) as the new record type.

Fill in the following information for the new DNS record:

Service: _VLMCS
Protocol: _tcp
Port: 1688
Priority: 10
Host offering the service: kms01.corp.contos.com (or the IP address)

Go to your client or server and at an elevated command prompt type:

slmgr /ato

this will activate your machine. Use:

slmgr /dlv

to see the activation status.

32 Bit Processes on 64 Bit Systems

On our systems we apply hardening policies by all kinds of available techniques. Being local policies, PowerShell scripts or classic batch files even. All the settings are eventually applied by a central installer that takes care of the installation, reboots and validation of the settings. Recently on one of our older systems we ran into something that appeared to be magical at first. Simply put we tried to apply a registry setting that was logged as being successfully set, however it never was applied. Although so it seemed to be the case. After a morning of testing we discovered that the registry key was actually applied (as indicated by the logging) but on another location in the registry. The key showed up in a location that’s used for 32 bit processes on 64 bit systems.

Windows has something called redirection for 32 bit processes when running on a 64 bit system. Normally when an application writes content to the registry (Such as a batch file) it’s a 64 bit process, however, as it turns out, our main installer on 64 bit systems is still 32 bit, hence Windows will redirect all writes to “HKLM\Software” to the “HKLM\Software\WOW6432Node” node. If you want to give it a try, open up “cmd.exe” from the “C:\Windows\SysWOW64” folder and add something to “HKLM\Software” using “reg.exe“. The key will be redirected to the “HKLM\Software\WOW6432Node” node.

32bit

Under normal circumstances this is a good thing to separate 32 bit application from native 64 bits application. In our case not so much, because it’s an installer, not an application. The solution to this problem is rather easy. Adding the parameter:

/reg:64

after the command-line tells the redirector to act as if it’s a 64 bit application and ignore the 32 bit status. Easy does it.

Reference


Registry Redirector

https://msdn.microsoft.com/en-us/library/aa384232(VS.85).aspx

The Microsoft Root Certificate Program

A couple of days ago I had to deal with a situation where our vulnerability tool was complaining that the root certificate store wasn’t updated for a while. After doing some research it turned out that the update service for the Microsoft root certificate program was blocked. That in turn triggered me to dig into the more technical part of the Microsoft Root certificate program. In short the Root Certificate Program makes the end user experience browsing experience a better one. When you visit an https enabled website a check is done if you trust the root authority that handed out the certificate (or the intermediate ca for that matter). If that root certificate is not in the “Trusted Root Certification Authorities” container a list of known participants of the root certificate program is checked if that Root CA is listed. If it is, the certificate is automatically downloaded and stored in the “Trusted Root Certification Authorities”.

Although it sounds like a good plan, it can be a bit confusing. In our case we work in a disconnected environment. Read, not being able to connect to Windows update. In that case you can tell Windows to use an internal web of file server to host the certificate list. The process is exactly the same in that case, it just uses a different repository. The confusing part was when I noticed that the location wasn’t reachable however the root certificates where installed regardless. What kind of magic was at play her? Turns out that it isn’t magic after all. Already with the introduction of Windows Vista, long long time ago Microsoft embedded the current list of Root certificates in the crypt32.dll. So if the automatic root certificate process can’t reach Windows update, an internal web or file server, it extracts the certificate from crypt32.dll. It took a while before I figured that one.

Quick steps to manage your internal certificate list

Use the following steps on your Server:

  • Create a local folder and share it.
  • Use:Certutil -syncWithWU
    This will get all the appropriate data from Windows update site. Being:

    • authrootstl.cab, contains a non-Microsoft Certificate trust List (STL)
    • disallowedcertstl.cab, contains a STL with untrusted certificates
    • disallowedcert.sst, contains a serialized certificate store (SST) for untrusted certificates
    • Pinrulesstl.cab, contains a STL of certificate pining rules (Windows 10 and higher)
    • Pinrulesstl.sst, contains a serialized certificate store (SST) for Certificate pining.
    • *.crt, all individual root certificate files.

Set the following registry key on your Client/Target point to your share:

HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\RootDirURL=file://\\server\share (REG_SZ)

These setting are effective immediately.

Tips

Enable AutoUpdate of the trusted Certificate Trust List

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate=0 (REG_DWORD)

Setting this to 1 turns off the whole auto update mechanism for both trusted and untrusted certificates

Enable AutoUpdate of the untrusted Certificate Trust List (Default is trusted and untrusted certificates)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\EnableDisallowedCertAutoUpdate=1 (REG_DWORD)

Create a custom serialized certificate store

  • Certutil -generateSSTFromWU <path\file.sst>
  • start explorer.exe <path\file.sst>
  • Select the certificates that you want and export the file to a new sst.
  • Import the file in your group policy

Clean the local downloaded cache (Only with the Windows update download)

locate the “CryptnetUrlCache” folder and delete the content. Usually in your user profile. (“%userprofile%\AppData\LocalLow\Microsoft\CryptnetUrlCache“)

Enable CryptoAPI 2.0 Diagnostics

Enable the Capi2 event log (located in the “Applications and Services Logs”) to get crypto operations logging.

Start a cryptographic operation

To initiate a crypto operation and see the automatic root certificate at work, browse to a HTTPS enabled website or open one of the certificates from the download mentioned above. Removing the certificate from the store and starting a crypto operation will reinitiate the process.

Dump the content of a Certificate Trust List

certutil.exe -dump <path\file.stl>

Reference


An automatic updater of untrusted certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2

https://support.microsoft.com/en-us/help/2677070/an-automatic-updater-of-untrusted-certificates-is-available-for-windows-vista,-windows-server-2008,-windows-7,-and-windows-server-2008-r2

Configure Trusted Roots and Disallowed Certificates

https://technet.microsoft.com/en-us/library/dn265983%28v=ws.11%29.aspx

Root update download location

http://www.download.windowsupdate.com/msdownload/update/v3 /static/trustedr/en/authrootstl.cab

 

Manually setting Windows Firewall Profiles

What has always bugged me to some extend is that Microsoft removed the possibility to set the Windows firewall profile to my own liking. Not just let Windows decide what’s best. It normally does a pretty good job, but there are occasions where you want to change it manually. Unfortunately, in the network center, there’s no option to just change it. You could always mess around and change the specific network with a policy, but there’s an easier way. PowerShell to the rescue.

Set all firewall Profiles

Use this command to change all the network interfaces to the private profile:
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

Or apply the public profile
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Public

In case you would like the individual connections to have a different profile assigned you need to use a reference point. Use the Get-NetConnectionProfile first to get all the information about the locally installed network adapters.

In this case we use the “InterfaceIndex” number, but you could also use the adapter name, as long as it’s unique. Now that we have the reference (or entry) point we can use the Set-NetConnectionProfile cmdlet to set the correct state.

The command above sets the firewall profile for that specific adapter to the private profile. The options that are available are:

  • Public
  • Private
  • DomainAuthenticated

To validate the execution use the Get-NetConnectionProfile again.

Reference


Understanding Firewall Profiles

https://technet.microsoft.com/nl-nl/library/getting-started-wfas-firewall-profiles-ipsec(v=ws.10).aspx