Skip to content

Microsoft Single Sign-on Updates

Among the patches published by Microsoft in its November 2022 security update, kerberos protocol changes described in KB5021131 affected a small number of SurfProtect customers, who were initially unable to authenticate users when using our Windows SSO service.

This change was linked to the as-yet undisclosed vulnerability CVE-2022-37966, which is mitigated by setting the default encryption type as AES on accounts that are not already marked with a default value. We have historically required Kerberos tokens to be encrypted using the RC4 cipher due to support across all of our customer installations and this change resulted in our servers refusing to serve web content since we were unable to verify user identity.

To restore service for the affected customers, our engineers deployed an update across the SurfProtect proxy servers to enable support for AES. This change ensures that the Microsoft patches can be applied with no need for any intervention by local administrators in order for SurfProtect SSO to continue to fuction as normal.

Update

Our engineers recently undertook work to add support for AES in the SurfProtect web proxy. This change addresses concerns about the security of RC4-HMAC, as detailed below, and also provides a migration path in anticipation of client support being withdrawn for the deprecated encryption mechanism.

Before the release of Microsoft's November 2022 security update, AES support was rolled out to a limited number of customers and verified to be functional. After a small number of sites experienced errors when attempting to access the SurfProtect Active Directory service, the decision was made to expedite deployment of the feature and emergency maintenance was performed to push the feature to all of our SurfProtect clusters.

Due to the ongoing phased rollout of the new SurfProtect software stack, some servers in both London and Manchester were not able to accept the update without additional changes and work is scheduled for this weekend, beginning 2022-11-12, to migrate them to the new software. This older version of the service responds differently to the new default when encountering errors decoding Kerberos tokens and fails open so that users are filtered with a default profile. We are actively monitoring for this behaviour and will migrate affected customers directly to the new platform in order to avoid unexpected filtering behaviour.

Most customers on the new platform are still providing proof of identity encrypted with RC4 but instructions for manually switching to AES are provided at the end of this article. Details of the upcoming service migration are available on our status page and we recommend waiting for confirmation that the work was carried out before making any changes.

Background

The initial release of SurfProtect Quantum focused on supporting as wide a userbase as possible in as consistent a manner as possible, and the lack of ubiquitous support for AES from client devices at the time meant that defaulting to RC4 for Windows integration was considered to be the best option.

Even at the time, the use of RC4 was considered to be insecure and there were known vulnerabilities that allow for an attacker to determine the password of a service account on the target AD server. While the RC4 cipher itself is considered broken, this isn't an issue in practice since the RC4-HMAC-MD5 scheme used by Kerberos guards against cryptanalysis by essentially ensuring that every ticket issued by an AD server is encrypted with a unique key. Rather, the weaknesses associated with its use are due to the historical need to derive as user's encryption key from their own password hash.

When Windows 2000 replaced the NT LAN Manager (NTLM) authentication protocols in favour of Kerberos, it was necessary to provide a transparent migration path for existing user accounts. Conveniently, RFC-3961 defines that Kerberos encryption mechanisms must implement the operation string-to-key.

RFC-4757 (The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows) declares that: 

   On upgrade from existing Windows NT domains, the user accounts would
   not have a DES-based key available to enable the use of DES base
   encryption types specified in [RFC4120] and [RFC3961].  The key used
   for RC4-HMAC is the same as the existing Windows NT key (NT Password
   Hash) for compatibility reasons.

So, effectively, the string-to-key function used by RC4-HMAC returns the NTLM hash of a user's password.

NTLM password hashes are constucted from a single pass of the MD4 algorithm over the user's password in UTF-16LE format, producing a 16-byte key that wouldn't be practical to brute force. They had the undeniable benefit of being available from data migrated from existing NT domains but unfortunately don't themselves provide protection against brute force attacks: in particular, they lack salts and require only a single iteration of the MD4 algorithm so an attacker can feasibly search in a practical amount of time through all the possible keys that can be generated from weak passwords.

Fortunately, this isn't actually useful for compromising normal user accounts thanks to preauthentication, where a client is required to prove that it already knows the user's password hash before the server will respond to authentication requests. In the case of services such as SurfProtect where Kerberos is used to prove user identity for Single Sign-on, however, any domain-authenticated user with rights to access the service will on request be provided with a Service Ticket. This ticket is encrypted with a key derived from the corresponding service-user password and can therefore be used to potentially identify that service user's password with no need for any further interaction with the AD server or remote service.

Typically it's expected that service accounts may require elevated privilages so the attacker, who already has local user access to the domain, has now gained administrator rights. Since the SurfProtect account is created with no elevated privileges, the impact of a local user gaining access is significantly reduced.

Mitigation

Customers wishing to precipitate the switch to using AES can do so through the Active Directory Users and Computers (ADUC) tool on their AD Domain Controller.

Right-click on the surfprotect user and select properties to open the properties window, then navigate to the tab labelled Account. Scroll through the Account Options and check one or both of: - This account supports Kerberos AES 128 bit encryption - This account supports Kerberos AES 256 bit encryption

Click on Apply and users will immediately begin to receive AES-encrypted service tickets the next time the log in and start to use the SurfProtect service.