Always On VPN Security Updates August 2024

Today is the second Tuesday of the month, so Windows Server administrators everywhere know what that means – it’s Update Tuesday! For Always On VPN administrators in particular there are a few security updates that affect Windows Server Routing and Remote Access (RRAS), which is a popular VPN server used to support Always On VPN implementations. While many of these updates address Remote Code Execution vulnerabilities, non are considered critical.

RRAS Updates

This month there are six vulnerabilities disclosed affecting Windows Server RRAS.

CVE-2024-38120 – Windows RRAS Remote Code Execution Vulnerability (Important)

CVE-2024-38121 – Windows RRAS Remote Code Execution Vulnerability (Important)

CVE-2024-38128 – Windows RRAS Remote Code Execution Vulnerability (Important)

CVE-2024-38130 – Windows RRAS Remote Code Execution Vulnerability (Important)

CVE-2024-38154 – Windows RRAS Remote Code Execution Vulnerability (Important)

CVE-2024-38214 – Windows RRAS Remote Code Execution Vulnerability (Important)

Additional Updates

In addition to the updates addressing vulnerabilities in Windows Server RRAS, there are also updates available for the Windows Network Address Translation (NAT), Windows Transport Layer Security (TLS), and Windows IP Routing Management snapin that could potentially impact Always On VPN deployments.

Recommendations

None of the security vulnerabilities disclosed this month are critical. Although the RRAS vulnerabilities are remote code execution, exploitation is unlikely. However, administrators are encouraged to update their systems as soon as possible.

Additional Information

Microsoft August 2024 Security Updates

Always On VPN and Blast-RADIUS

Microsoft released an update for the Windows Server Network Policy Server (NPS) to address recently disclosed vulnerabilities in the Remote Access Dial-In User Service (RADIUS) protocol in the July 2024 security updates. RADIUS is an industry-standard authentication protocol widely used for remote access, including Always On VPN. The RADIUS protocol was first introduced in the early 1990s and, unfortunately, still relies on the deprecated MD5 cryptographic hash function. The good news is that this vulnerability does not affect Always On VPN. Read on to learn more.

Blast-RADIUS

Blast-RADIUS is an attack on the RADIUS protocol that allows an attacker to alter network authentication packets to gain access to a service relying on RADIUS for authentication by exploiting the weakness of MD5 integrity checks in RADIUS. In the absence other controls, an attacker could alter an authentication response and change the reply from Access-Reject to Access-Accept.

Considerations

It’s important to note that leveraging this attack is not trivial. It requires local network access, so the attacker must have a presence on the target network to carry out this attack. However, cloud-hosted RADIUS services are inherently more vulnerable. In addition, the attack is mostly academic today because the default timeout for authentication requests is typically short, usually between 5 and 30 seconds. This is not enough time (today) for an attacker to mount the attack. However, this attack could become more feasible if authentication timeouts are increased (sometimes required to support MFA) or if an attacker has access to vast computing resources.

Affected Protocols

Although Blast-RADIUS is a vulnerability in the RADIUS protocol itself, not all authentication protocols are affected. Specifically, this vulnerability affects services leveraging PAP, CHAP, MS-CHAP, and MS-CHAPv2. Extensible Authentication Protocol (EAP) and Protected Extensible Authentication Protocol (PEAP) are not vulnerable to this attack. Since Always On VPN requires EAP authentication, it is not susceptible to this attack.

Mitigation

Microsoft has published guidance in KB5040268 for mitigating Blast-RADIUS attacks on Windows NPS servers. Specifically, administrators are encouraged to enable the Message-Authenticator attribute in Access-Request packets sent by the network access server and to ensure the NPS server requires the Message-Authenticator attribute in any Access-Request messages it receives.

Note: The following changes are not required for Always On VPN or any other workload using EAP-TLS or Protected EAP, as these protocols use TLS natively to protect the authentication exchange.

NPS

To configure this setting in the UI, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand RADIUS Clients and Servers.
  2. Highlight RADIUS Clients.
  3. Right-click the RADIUS client to configure and choose Properties.
  4. Select the Advanced tab.
  5. Check the box next to Access-Request messages must contain the Message-Authenticator attribute.

PowerShell

To configure this setting using PowerShell, open an elevated PowerShell command window and run the following command.

Set-NpsRadiusClient -Name <RADIUS client name> -AuthAttributeRequired $True

Additional NPS Settings

Administrators should also run the following commands on their NPS servers to further protect their infrastructure from Blast-RADIUS attacks.

netsh.exe nps set limitproxystate all = enable

netsh.exe nps set requiremsgauth all = enable

RRAS

When using Windows Server Routing and Remote Access (RRAS) without EAP, ensure the RADIUS server configuration always includes the Message-Authenticator. To configure this setting, open the Routing and Remote Access console (rrasmgmt.msc) on the RRAS server and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Click the Configure button next to the Authentication provider drop-down list.
  4. Highlight the RADIUS server and choose Edit.
  5. Check the box next to Always use message authenticator.

Repeat these steps for any additional configured RADIUS servers.

CLI

Administrators can implement this change at the command line by opening an elevated command window and entering the following command.

netsh.exe ras aaaa set authserver name = <name of RADIUS server> signature = enabled

For example:

netsh.exe ras aaaa set authserver name = nps.lab.richardhicks.net signature = enabled

New NPS Events

After installing the KB5040268 update on NPS servers, the NPS server will record event ID 4421 from the NPS source after a service start if the RequireMsgAuth or LimitProxyState settings are not configured.

“RequireMsgAuth and/or limitProxyState configuration is in Disable mode. These settings should be configured in Enable mode for security purposes.”

Optional Mitigation

If administrators cannot configure the above settings, consider using IPsec to secure network traffic at the transport layer. IPsec will protect all RADIUS traffic at the network layer to mitigate Blast-RADIUS attacks. Unfortunately, Windows Server NPS does not support TLS or DTLS, so IPsec is your only option.

Summary

Always On VPN is not vulnerable to the Blast-RADIUS attack. However, NPS is commonly a shared service in many organizations, and other workloads may use older, vulnerable protocols. Consider implementing the changes detailed in KB5040268 as outlined in above to ensure the integrity of your environment and mitigate these potential attacks.

More Information

Microsoft KB5040268: how to manage Access-Request packets attack vulnerability associated with CVE-2024-3596

RADIUS Protocol Vulnerability Exposes Networks to MitM Attacks

New Blast-RADIUS attack breaks 30-year-old protocol used in networks everywhere

Overview of Microsoft Protected Extensible Authentication Protocol (PEAP)

Always On VPN NPS Auditing and Logging

Always On VPN Trusted Network Detection and Native Azure AD Join

Administrators deploying Microsoft Always On VPN are quickly learning that the native Azure Active Directory join (AADJ) model has significant advantages over the more traditional Hybrid Azure AD join (HAADJ) scenario. Native AADJ is much simpler to deploy and manage than HAADJ while still allowing full single sign-on (SSO) to on-premises resources for remote users. Intune even allows for the import of custom ADMX and ADML administrative templates, further reducing the dependency on on-premises Active Directory for device management.

Remote Management

Although devices aren’t joined to the domain, administrators may still wish to access those clients connected to their network for device discovery or to perform administrative tasks. However, when native AADJ clients connect via Always On VPN, the Public Windows firewall profile is assigned to the VPN tunnel adapter. The Public profile is, of course, more restrictive and blocks most management protocols by default.

Firewall Rules

While adding firewall rules to the Public profile to allow management protocols is possible, this isn’t recommended for security reasons. The Public profile is typically loaded when the device is on an untrusted network. Exposing management protocols on an insecure network is asking for trouble.

Domain Profile

Domain-joined or Hybrid AADJ endpoints will use the Domain Windows firewall profile. This profile is more permissive, allowing many standard management protocols by default. Also, administrators can add rules to allow additional access as required without increasing the risk for devices on untrusted networks.

Trusted Network Detection

So, the trick is to get a native AADJ endpoint to load the Domain profile for the VPN tunnel adapter when connected via Always On VPN. Trusted Network Detection is accomplished by using settings configured on the endpoint using the NetworkListManager Configuration Service Provider (CSP).

Intune and XML

There are two settings administrators can enable AADJ devices to detect a trusted network and load the Domain Windows firewall profile. Unfortunately, these settings can only be applied using Intune and the Custom XML template. Administrators will use the following OMA-URI settings.

AllowedTlsAuthenticationEndpoints

The AllowedTlsAuthenticationEndpoints policy setting defines the URL the device uses to validate a trusted network. The target must be an on-premises web server with a valid TLS certificate using HTTPS. The target must be a highly available internal resource inaccessible from the Internet. DirectAccess administrators will be quite familiar with this concept; it’s the Network Location Server (NLS)!

Use the following OMA-URI to configure the TLS authentication endpoint.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/AllowedTlsAuthenticationEndpoints

String: <![CDATA[https://nls.corp.example.net]]>

ConfiguredTlsAuthenticationNetworkName

The ConfiguredTlsAuthenticationNetworkName policy setting is optional. Administrators can use this setting to provide a friendly name for the authenticated trusted network. The FQDN of the target resource (NLS) is used by default. However, using this setting overrides the default with something more meaningful.

Use the following OMA-URI to configure the TLS authentication network name.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/ConfiguredTlsAuthenticationNetworkName

String: <Friendly network name>

Results

Once configured, you’ll find the Always On VPN tunnel adapter uses the Domain Windows firewall profile and an optional friendly network name.

Additional Information

Deploying Always On VPN with Intune using Custom XML and CSP

Always On VPN CSP Updates

Always On VPN and VpnStrategy with CSP