DirectAccess IP-HTTPS Preauthentication


Introduction

DirectAccess IP-HTTPS PreauthenticationRecently Iā€™ve written about the security challenges with DirectAccess, specifically around the use of theĀ IP-HTTPS IPv6 transition technology. In its default configuration, the DirectAccess server does not authenticate the client when an IP-HTTPS transition tunnel is established. This opens up the possibility of an unauthorized user launching Denial-of-Service (DoS) attacks and potentially performing network reconnaissance using ICMPv6. More details on this can be found here.

Mitigation

The best way to mitigate these security risks is to implement an Application Delivery Controller (ADC) such as the F5 BIG-IP Local Traffic Manager or the Citrix NetScaler. Iā€™ve documented how to configure those platforms here and here.

No ADC?

For those organizations that do not have a capable ADC deployed, it is possible to configure the IP-HTTPS listener on the Windows Server 2012 R2 server itself to perform preauthentication.

Important Note: Making the following changes on the DirectAccess server is not formally supported. Also, thisĀ change isĀ incompatible with one-time passwords (OTP)Ā  and should not be performed if strong user authentication is enabled.Ā In addition, null cipher suites will be disabled, resulting in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients. Making this change should only be done if a suitable ADC is not available.

Configure IP-HTTPS Preauthentication

To configure the DirectAccess server to perform preauthentication for IP-HTTPS connections, open an elevated PowerShell command window and enter the following command.

ls Cert:\LocalMachine\My

DirectAccess IP-HTTPS Preauthentication

Copy the thumbprint that belongs to the SSL certificate assigned to the IP-HTTPS listener. Open an elevated command prompt window (not a PowerShell window!) and enter the following commands.

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=[thumbprint]
appid={5d8e2743-ef20-4d38-8751-7e400f200e65}
dsmapperusage=enable clientcertnegotiation=enable

DirectAccess IP-HTTPS Preauthentication

For load-balanced clusters and multisite deployments, repeat these steps on each DirectAccess server in the cluster and/or enterprise.

Summary

Once these changes have been made, only DirectAccess clients that have a computer certificate with a subject name that matches the name of its computer account in Active Directory will be allowed to establish an IP-HTTPS transition tunnel connection.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Note: For information about configuringĀ the Citrix NetScalerĀ to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKIā€™s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Note: For information about configuringĀ the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.Ā For information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerIP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.

When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.

IP-HTTPS Connection

Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.

ICMP and IPsec

By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).

Security Risk

This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.

Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time withĀ the default configuration.

IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerTo mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.

Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.

Citrix NetScaler Configuration

To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the clientĀ before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.

Important Considerations

Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.

Summary

The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.

References

Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/

Security Assessment of Microsoft DirectAccess [Full Document] –Ā https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html

Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w

Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx

Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication –Ā https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

Configure Windows Server 2012 R2 Ā and Windows Server 2016 to Perform IP-HTTPS Preauthentication –Ā https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

DirectAccess and the TLS Logjam Attack

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 and the Logjam Attack

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.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA

DirectAccess and the Logjam Attack

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.

DirectAccess and the Logjam Attack

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.

%d bloggers like this: