The January 2022 security updates for Microsoft Windows include several important updates that will affect Always On VPN deployments. Specifically, CVE-2022-21849 addresses a Remote Code Execution (RCE) vulnerability that should be addressed immediately. The January 2022 security update also includes updates for several IKE Denial-of-Service (DoS) vulnerabilities, in addition to privilege escalation vulnerabilities in the Remote Access Connection Manager.
Update – January 17, 2022: Microsoft has released out-of-band updates to address the issues with IPsec (IKEv2 and L2TP) when using non-Microsoft VPN devices. Updates can be found here.
Update – January 13, 2022: There have been numerous reports of this update breaking VPN functionality when using non-Microsoft VPN devices. If you are using Windows Server and RRAS you can safely update. If you are using a third-party device, you may encounter problems. In addition, there have been reports of issues with domain controllers and Hyper-V servers after installing this update. Please proceed carefully and be sure to have a backup before updating!
Vulnerable Systems
These vulnerabilities are present on both Windows Server and Client operating systems. Essentially, any Windows server or client using IPsec is vulnerable and potentially exploitable.
Vulnerabilities
The following is a list of security updates related to Always On VPN deployments.
Windows IKE Extension Remote Code Execution (RCE) Vulnerability
Another critical flaw affecting Transport Layer Security (TLS) was discovered recently that could put some organizations at risk. The “Logjam” attack exploits a weakness in how the Diffie-Hellman key exchange is used. An attacker, acting as a man-in-the-middle, can potentially force a downgrade of the TLS connection, resulting in the use of weak cryptography. The Qualys SSL Labs SSL Server Test has been updated to identify this vulnerability. When testing a DirectAccess server you will receive the following warning message.
“This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.”
DirectAccess leverages SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, which is used to tunnel IPv6 packets over the IPv4 Internet. These IPv6 packets are encrypted using IPsec. If an attacker were to break the SSL/TLS connection they would gain nothing. Because of this, a dedicated DirectAccess server is unaffected by the Logjam attack. Mitigating it would provide no additional protection, so you can safely ignore the warning about weak DH key exchange parameters being supported.
However, if DirectAccess has been configured to use one-time password (OTP) authentication, the client-based VPN role has been enabled and configured, or the Web Application Proxy (WAP) role has been installed on the DirectAccess server, then the Logjam attack represents a serious risk and should be mitigated. Also, in some cases it may be desirable to make this change on a dedicated DirectAccess server just to prevent an audit finding and avoid having to explain why the DirectAccess workload would be unaffected by this attack.
To mitigate this vulnerability it will be necessary to remove support for cipher suites that use the Diffie-Hellman key exchange protocol on the DirectAccess server. This is accomplished by opening the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and expanding Computer Configuration, Administrative Templates, and Network. Select SSL Configuration Settings and then double-click SSL Cipher Suite Order. Select Enabled and then replace the default list of cipher suites with the following list.
Once complete, restart the DirectAccess server. The Qualys SSL Labs server test should no longer give a warning about the use of weak Diffie-Hellman keys. In addition, this reordering and optimization of cipher suites will also improve the protocol support and key exchange scores, as shown here.
As a reminder, and overall rating of “F” is expected when testing a dedicated DirectAccess server. By design, DirectAccess provides support for null cipher suites to improve scalability and performance for Windows 8.x and later DirectAccess clients. More details here.
Microsoft recently released security advisory 2862152 to address a vulnerability in IPsec that could allow DirectAccess security feature bypass. The associated update addresses an issue with how the DirectAccess client authenticates with a DirectAccess server. Without the update, it is possible for an attacker to launch a man-in-the-middle attack to intercept DirectAccess communication.
The update itself does not resolve the issue directly, however. The update simply allows administrators to configure DirectAccess clients using specific registry settings to enforce more stringent checks during IPsec negotiation after the update is installed. The challenge with this update is that the documentation contained within the knowledge base article is extremely detailed and includes information that pertains to many different remote access scenarios, not just DirectAccess. This has led to much confusion, and many administrators are unclear for which clients and deployment scenarios the registry changes are required.
For DirectAccess deployments, the update needs to be applied to all of your DirectAccess clients. The update does NOT need to be applied to the DirectAccess server. The registry settings required on the client will be dictated based on the configured authentication method for your DirectAccess deployment. If you have configured DirectAccess to use certificate-based authentication by checking selecting the Use computer certificates option as shown below, you’ll only need to make registry settings changes on your Windows 7 clients. Windows 8/8.1 clients DO NOT require any changes be made to the registry when DirectAccess is configured to use certificate-based authentication.
If you are NOT using computer certificates for authentication, then you must make registry changes to all of your Windows 8/8.1 clients. For detailed, prescriptive guidance on implementing the client-side registry changes required to support this update and mitigate this vulnerability, Jason Jones has done a wonderful job documenting those steps specifically, so I’ll refer you to his post here.
You can find the update for KB2862152 for all supported clients here.
