Security Assessment of Microsoft DirectAccess

A talk about DirectAccess (an IPv6-only VPN solution) was given by our colleague Ali Hardudi during IPv6 summit. Ali has recently finished his master thesis on this topic.

The DirectAccess VPN technology was introduced by Microsoft starting from Windows server 2008. It allows users remotely, seamlessly and securely connect to their internal network resources without a need to provide user credentials, which is done using different technologies such as Windows domain group policies.

As everything, this technology has advantages and disadvantages. It is using pure IPv6 and can work over IPv4 infrastructure, provides bidirectional access and allows for remote management and administration while implementing enhanced security features, but not all Windows OS’s are supported, the force tunneling and end-to-end encryption are not always possible, and there is a performance degradation when using IP-HTTPS tunneling.

The DirectAccess solution is relying on a wide range of technologies, such as:

• Active Directory Domain Controller (AD DC)
• IPSEC
• Public Key Infrastructure (PKI)
• HTTPS server as Network Location Service (NLS)
• Name Resolution Policy Table (NRPT)
• IPv6 tunneling technologies
• NAT64/DNS64, and others.

Ali has built a lab and developed two scenarios for assessment: IP-HTTPS default configuration case, and authenticated IP-HTTPS case. In these scenarios an attacker is considered to have the following position:

• He knows URL/IP of the DirectAccess server
• He has compromised or a trusted certificate
• Position of attacker is remotely settled or within the local subnet of the client.

First scenario was the unauthenticated IP-HTTPS case with the following considerations: packets with multicast/unicast addresses are not forwarded, and a server replies on behalf of clients, if a client wants to configure an address that is already configure.
For this scenario the following attacks were performed:

• Scan alive hosts using Ping scan (attacker position is local or remote)
• Scan for alive DA clients using Duplicate Address (local or remote)
• Send packets with spoofed IPv6 addresses (local or remote)
• Denial of Service against IP-HTTPS tunnel (local or remote)
• Neighbor Cache exhaustion (local or remote)
• MITM using a trusted certificate (local or remote)
• MITM by relaying IPSEC packets via attacker’s computer (local only)

The second scenario was the authenticated IP-HTTPS case with the following features: almost all types of packets are accepted by the DirectAccess, null cipher suites can not be used any more, all the authenticated IP-HTTPS connections are trusted, and the only packets that are not forwarded are those which have unspecified IPv6 source address “::”
The following attacks were performed:

• Scan for alive DirectAccess clients using Ping scan (attacker position is local or remote)
• Scan DirectAccess clients for open ports (local or remote)
• DoS against DirectAccess clients by sending fake Router Advertisement (RA) with randomized prefixes (local or remote)
• Hijacking IPSEC packets that are sent to the client and cause a DoS (local or remote)
• DoS DirectAccess client, by sending unsolicited Neighbor Solicitation (NS) with the IPv6 of the DirectAccess server as a source address (local or remote)

This assessment has shown that IP-HTTPS is a very critical component, which could be utilized by attackers to perform many IPv6 attacks on both DirectAccess client and server.

You can have a look at the slides here or watch the video recording on our channel.

Cheers,
Olga