This article presents the key risks with DirectAccess and how to audit them.
Let’s begin by first understanding the DirectAccess technology
Introduction of DirectAccess
From the Wikipedia definition
DirectAccess, also known as Unified Remote Access, is a VPN-like technology that provides intranet connectivity to client computers when they are connected to the Internet.
Direct Access overcomes the limitations of VPNs by automatically establishing a bi-directional connection from client computers to the corporate network so users never have to think about connecting to the enterprise network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.
When a DirectAccess client is outside of the corporate network and has an active Internet connection, the client will attempt to establish connectivity with the DirectAccess gateway by creating IPsec tunnels defined by the connection security rules in the Windows Firewall on the client.
How does the DirectAccess Server work?
- The DirectAccess client connects to a publicly exposed Active Directory, which then checks for DirectAccess policy and then allows the client to connect to the DirectAccess server.
- The DirectAccess server checks whether the Windows firewall is enabled or not. If not it will not allow the client to connect.
- After connecting, the DirectAccess server will allow the user to connect to Intranet servers like Application server, Mail Server, etc.
Limitation In terms of Direct Access Implementation
- IP-HTTPS Encryption is used for transmitting data from client to server, vice versa.
- The DirectAccess client must be a part of the DirectAccess policy in Active Directory.
- Only clients who support IPv6 can communicate with DirectAccess Server.
- If a One-Time Password (OTP) is configured it will not allow the user to use force tunneling.
Phases of the Assessment
The following phases constitute a comprehensive assessment of the DirectAccess implementation:
- External Vulnerability Assessment
- External Vulnerability Assessment with a valid DirectAccess Client
- External Vulnerability Assessment without DirectAccess Client
- Internal Vulnerability Assessment
- Direct Access Architecture and Configuration Review
Below are the checks which cover all above three phases
- Intercepting Traffic between DirectAccess Client and Server
With DirectAccess the client and server have to negotiate and use IPsec encryption and then also have to negotiate and encrypt the HTTPS (SSL) session.
As a result, intercepting the traffic between DirectAccess server and client will fail due to the IP-HTTPS encryption. So this test is not likely to reveal anything.
- Testing One Time Password (OTP) Configuration Direct Access:
DirectAccess can be configured with OTP Authentication. We can check if OTP is configured or not before connecting to the DirectAccess Server.
- Multiple Connections from the Same User
In a number of setups, allowing simultaneous logins by the same user might be considered as a policy violation. By default DirectAccess allows such connections. This issue can be resolved by disabling concurrent connection user policy on the Active Directory.
- Testing for Split Tunnelling
DirectAccess can be configured with split tunnelling or force tunnelling. Before going in to the details let’s understand what we mean by force tunnelling and split tunnelling
- Split Tunnelling: DirectAccess split tunnelling defines sending all corporate (Intranet) traffic to the corporate (Intranet) network, and sending all “other” internet traffic directly to the internet.
- Force Tunnelling: DirectAccess force tunnelling defines sending all corporate traffic (Intranet) and internet traffic to the corporate network (Intranet) only.
Disadvantage of split tunnelling
As infrastructure security point all the traffic after connecting to intranet must be tunnel via intranet proxy so that all the traffic can be monitored for the security threat.
If the direct access was implemented to perform split tunnelling the direct access client traffic doesn’t get any web filtration.
If the direct access was implemented to perform split tunneling the victim (Direct Access Client) traffic doesn’t get any web filtration.
Advantage of Having Web Filtering
Web Filtering provides an essential layer of protection from outside threats such as malware, phishing and other online scams.
Restricting internal user web traffic to the outside world will prevent user from most of the client side attacks.
Disadvantages of Force tunnelling
Below are some disadvantages of Implementation of Force Tunnelling
- More Bandwidth required for the Internet connection while DirectAccess client connected intranet infrastructure or DirectAccess server.
- Slower Internet Connection: As all the internet traffic is routed from the intranet the DirectAccess client user might face the slower internet connectivity issues. This factor depends upon the number of DirectAccess Client connected.
- Windows Firewall for Policies Required by DirectAccess Server
DirectAccess server checks that the Windows firewall is enabled at the client level before connecting to the infrastructure.
We tried to disable this firewall but this test case failed as we were not able to connect to the DirectAccess server after disabling firewall on the client system.
- Testing SSL Certificate Issues
DirectAccess requires an SSL certificate to be installed for IP-HTTPS communication. We can perform the following test cases for this:
- Certificate used by DirectAccess Server is authorized by known Certification Authority
- Testing for SSL weak Ciphers
- Restricting access to internal systems
This test validates:
- Whether only the required services are accessible on the DirectAccess server itself
- Whether only the required services are accessible on the servers that have been made available via DirectAccess – such as the file server, email server, or any specific application server
- Whether other IP addresses are accessible and if so what services can be reached on those systems
This can easily be done using Nmap by discovering the IP addresses the client connects to and then scanning entire range within the same subnet.
- DirectAccess Network Location Server
The NLS is a vitally important piece of the DirectAccess architecture
- It is used by DirectAccess clients to determine if they are inside or outside of the corporate network. If a DirectAccess client can connect to the NLS, it must be inside the corporate network. If it cannot, it must be outside of the corporate network. It is for this reason that the NLS must not be reachable from the public Internet.
- If the NLS is offline for any reason, remote DirectAccess clients will be unaffected (outside). However, DirectAccess clients on the internal network will mistakenly believe they are outside of the corporate network and attempt to establish a DirectAccess connection.
- Production deployment should have the NLS configured on a server dedicated to this role.
- If the NLS is located on the DirectAccess server and the server is offline for any reason, DirectAccess clients on the internal network will be unable to access local resources by name until the DirectAccess server is back online
Security checks performed on NLS:
- Disaster Recovery for NLS Server: NLS Server needs to be placed in the Intranet with redundancy. Server redundancy means creating a replica of the server known as DR Server. If anything goes down with the Primary server then DR Server will become active.
- NLS Vulnerability Assessment: As this is part of DirectAccess infrastructure, the NLS server needs to be hardened properly. A dedicated server needs to be configured for the NLS. Do not use NLS Server for other purposes.
- Connecting to the DirectAccess server from the Internet via RDP
It might be the case that the DirectAccess server is configured with Remote Desktop Protocol (RDP) access enabled. This means that port 3389 is opened to the outside world as well as the inside. Considering the external threat for RDP, an attacker can brute force the credentials which could lead to unauthorized access to DirectAccess Server or the attacker might exploit an unpatched vulnerability in the Microsoft RDP service to compromise the server.
- Port Scanning of the other client systems: As DirectAccess server provides access to multiple clients and those clients are in same network, we can try and access the other clients by scanning the same IP address range as the one to which the client we have connected belongs.
- Checking Direct Access Client Security (Windows 7 & 8):
As of now DirectAccess supports Windows 7 and Windows 8 Operating Systems.
For Window 7: The DirectAccess client uses the executable located at “C:\Program Files\DirectAccess Connectivity Assistant\DcaSvc.exe” which will connect to DirectAccess server and run with system level privileges.
Here, we need to make sure that the BIOS administration option on the Direct Access Client machine is password protected. Otherwise, an attacker can perform boot via an alternate media such as a USB-loaded Kali distro and can replace the DirectAccess Client located in “C:\Program Files\DirectAccess Connectivity Assistant\DcaSvc.exe” with malware or malicious file. This would allow an attacker to elevate the privileges of a normal user to system level and take control of the client system.
- DirectAccess Server Security Hardening:
This is the check for standard hardening of the underlying Windows Server Operating System on which DirectAccess is installed. One might simply use a standardized Windows Server security checklist or those available from CIS Benchmark.
Conclusion:
To conclude, the list below highlights some of the key security risks with the DirectAccess server:
- DirectAccess client security
- DirectAccess Server Security from Direct Access Client and the Internet
- Network Segregation of DirectAccess server and client from the rest of the network
- Security of the servers which will be accessible after a successful connection.
- Disaster recovery implementation for Name location Server (NLS)
Reference:
http://directaccess.richardhicks.com/
http://niiconsulting.com/checkmate/2015/06/security-review-of-microsoft-directaccess-implementation/
Special Thanks For Providing Input to My Article:
Richard Hicks <[email protected]>
Leave a Reply
Your email is safe with us.