{"id":3532,"date":"2022-11-16T16:26:35","date_gmt":"2022-11-16T16:26:35","guid":{"rendered":"https:\/\/geekmungus.co.uk\/?p=3532"},"modified":"2023-01-03T16:59:32","modified_gmt":"2023-01-03T16:59:32","slug":"netapp-running-smb-version-1-impacted-by-microsoft-windows-kb5019964-for-cve-2022-37967","status":"publish","type":"post","link":"https:\/\/geekmungus.co.uk\/?p=3532","title":{"rendered":"NetApp Running SMB version 1 Impacted by Microsoft Windows (KB5019964) for CVE-2022-37967"},"content":{"rendered":"\n

NOTE: See https:\/\/geekmungus.co.uk\/?p=3619<\/a> for the most up to date article!<\/strong><\/p>\n\n\n\n

We’ve had an issue with the recent “Security Update for Microsoft Windows (KB5019964)<\/a>” update, as by the looks of it a load of other people.<\/p>\n\n\n\n

In our case we are running Microsoft Windows 2016 domain controllers, the NetApp filers are pretty old we’re readying to migrate off them; they only support SMB version 1.<\/p>\n\n\n\n

We suddenly got reports that accessing the shares via a UNC with the hostname did not work from Microsoft Windows machines giving an error along the lines of name not found. Using the IP address within the UNC path worked fine from a Microsoft Windows machine. Additionally using the UNC with the hostname from Apple Mac workstations and Linux clients (Samba client) worked fine.<\/p>\n\n\n\n

Symptoms<\/h2>\n\n\n\n

We first started with the name resolution, DNS was resolving fine. NETBIOS also appeared to be fine. Essentially:<\/p>\n\n\n\n

\\\\server1 – Does not work, name is not resolved, even though DNS works fine.
\\\\172.16.10.10 – Does work fine.<\/p>\n\n\n\n

Diagnosis<\/h2>\n\n\n\n

After much checking we found that the Kerberos authentication tickets were not working. Essentially when using the IP address we think that NTLM authentication is being used rather than Kerberos, hence why using the IP works while the hostname does not; that is the same for the Apple Mac and Linux clients.<\/p>\n\n\n\n

Running a “klist” from affected clients we saw this:<\/p>\n\n\n\n

Current LogonId is 0:0x4b7cb6d6\n\nCached Tickets: (2)\n\n#0>     Client: USER123 @ DOMAIN.COM\n        Server: krbtgt\/DOMAIN.COM @ DOMAIN.COM\n        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96\n        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize\n        Start Time: 11\/16\/2022 10:59:20 (local)\n        End Time:   11\/16\/2022 20:59:20 (local)\n        Renew Time: 11\/23\/2022 10:59:20 (local)\n        Session Key Type: AES-256-CTS-HMAC-SHA1-96\n        Cache Flags: 0x1 -> PRIMARY\n        Kdc Called: DC1.DOMAIN.COM\n\n#1>     Client: USER123 @ DOMAIN.COM\n        Server: cifs\/server1.domain.com @ DOMAIN.COM\n        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)\n        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize\n        Start Time: 11\/16\/2022 10:59:20 (local)\n        End Time:   11\/16\/2022 20:59:20 (local)\n        Renew Time: 11\/23\/2022 10:59:20 (local)\n        Session Key Type: AES-256-CTS-HMAC-SHA1-96\n        Cache Flags: 0\n        Kdc Called: DC1.DOMAIN.COM<\/code><\/pre>\n\n\n\n
Notice the “Session Key Type: AES-256-CTS-HMAC-SHA1-96” on the #1 key. It is AES-256-CTS-HMAC-SHA1-96 not RSADSI RC4-HMAC(NT), The NetApp is on a software version that can’t work with the later cipher type. Hence the issues across two other NetApp arrays running the same version.<\/p>\n\n\n\n
This was confirmed on the NetApp logs saying an “unsupported cipher” was being used.<\/p>\n\n\n\n
Resolution<\/h2>\n\n\n\n
It turned out the issue was down to a recent Microsoft Windows update to our domain controllers. The following patch which was applied overnight 15th november 2022 to 16th November 2022 was the cause of the issue:<\/p>\n\n\n\n
November 8, 2022\u2014KB5019964<\/strong><\/p>\n\n\n\n
Security Update for Microsoft Windows (KB5019964) – Installed 15\/11\/2022
CVE-2022-37967<\/strong><\/p>\n\n\n\n
So we removed the patch from all domain controllers which had been installed overnight and this resolved the issue.<\/p>\n\n\n\n
The difference in behavior was visible through the tickets issues, we first ran a “klist purge” to clear the client of the TGS ticket with the incorrect cipher type and then attempting the connection to the NetApp via the UNC path with the hostname which was now successful. <\/p>\n\n\n\n
The klist output of the TGS ticket for the NetApp before and after the patch was removed is given below. Firstly before (patch was removed)<\/p>\n\n\n\n
\n\n#2>     Client: USER123 @ DOMAIN.COM\n        Server: cifs\/server1.domain.com @ DOMAIN.COM\n        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)\n        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize\n        Start Time: 11\/16\/2022 13:29:45 (local)\n        End Time:   11\/16\/2022 23:29:45 (local)\n        Renew Time: 11\/23\/2022 13:29:45 (local)\n        Session Key Type: AES-256-CTS-HMAC-SHA1-96\n        Cache Flags: 0\n        Kdc Called: DC1.DOMAIN.COM\n<\/code><\/pre>\n\n\n\n
Then the TGS klist output after the patch has been removed:<\/p>\n\n\n\n
After (patch is removed)\n\n#1>     Client: USER123 @ DOMAIN.COM\n        Server: cifs\/server1.domain.com  @ DOMAIN.COM\n        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)\n        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize\n        Start Time: 11\/16\/2022 14:12:26 (local)\n        End Time:   11\/16\/2022 23:47:44 (local)\n        Renew Time: 11\/23\/2022 13:47:44 (local)\n        Session Key Type: RSADSI RC4-HMAC(NT)\n        Cache Flags: 0\n        Kdc Called: DC1.DOMAIN.COM<\/code><\/pre>\n\n\n\n
Once the Session Key Type: RSADSI RC4-HMAC(NT) was being shown for the TGS Tickets from the NetApps the issue was resolved.<\/p>\n\n\n\n
Any remaining issues should be able to be resolved by a reboot of the machine or a “klist purge” run from the command prompt to flush the incorrect cipher TGS and use a working one.<\/p>\n\n\n\n
We’re then aiming to move off the NetApps posthaste to allow us to put this patch back in place in the long term to remediate the Kerberos vulnerabilities it has. This particular patch however has been known to cause other problems even with those who have AES-128 and above enabled and don’t use legacy ciphers, so waiting on Microsoft for updates on that one.<\/p>\n\n\n\n
\n
Updates for Windows (Nov. 2022): Changes in Netlogon and Kerberos protocol – causing issues<\/a><\/blockquote>