Reading
Add Comment
Problem:
Windows Server 2016 VPN server has left the front door wide open for attackers –by default! It authenticates ANY client certificate issued by ANY public CA. This problem occurs when the client certificate trust chain matches a certificate in the server’s trusted root store. For example, an attacker can authenticate with any DigiCert certificate (Figure 1).How vulnerable are these servers? I'm willing to wager that my twelve-year old son can hack it in under five minutes. This is a pants-on-fire security hole that needs to be fixed before the server hits production.
 |
| Figure 1. Win IKEv2 authenticates with ALL root CAs. Yikes! |
Solution:
There are two ways to fix this serious IKEv2 flaw:
- Remove public CAs from the Trusted Root certificate store.
- Use PowerShell so RRAS only authenticates certificates issued from our private CA.
Certificate Store Solution:
Use Windows CA or OpenSSL CA servers, etc. DO NOT use a public CA. Remove ALL public CAs from the server’s trusted root store. Turn off automatic certificate updates. Implement additional authentication safeguards.
Step 1: Only use private certificates (e.g., Windows CA) –do not use public CAs.
We won’t cover the entirety of installing a CA in this article. However, it’s important to understand that the private CA root certificate resides in the Trusted Root certificate store –on both servers and clients.
Step 2: Edit Trusted Root Store:
Start → Type MMC → File → Add → Certificates → Local Computer → OK.
- Backup your system.
• Exporting root certificates before you delete them –just to be safe.
• Take a system checkpoint if applicable. - Certificates to keep:
• Microsoft Root Authority 12/31/2020 -required
• Thawte Timestamping CA 12/31/2020 -required
• Microsoft Root Certificate Authority 5/9/2021 -required
• Private Root CA
- Delete all other certificates in the Trusted Root Store.
Step 3: Create new GPO that prevents certificate updates.
Edit GPO:
→ Computer Configuration
→ Policies
→ Administrative Templates
→ System
→ Internet Communication Management
→Internet Communication Settings
→ Turn Off Automatic Root Certificate Updates: Enabled.
PS Solution:
Is there a better method? Until recently, there was no way to assign specific trust chains for IKEv2 client authentication. The system was simply all or nothing.
Thankfully, Microsoft now provides a solution that fixes this authentication vulnerability. We can finally configure specific root certificates for authentication purposes. N.B., This solutions assumes we’re using a private CA for authentication. Also not, that Microsoft documentation states that this method is only for site-to-site (S2S) VPNs –not true!
Step 1: Confirm existing VPN authentication settings: Get-VPNAuthProtocol (Figure 2):
 |
| Figure 2. Confirm IKEv2 authentication with Get-VPNAuthProtocl. |
Step 2: Configure the VPN server so it only authenticates certificates issued from our private CA:
PS C:\Windows\system32> $cert1 = ( Get-ChildItem -Path cert:LocalMachine\root | Where-Object -FilterScript { $_.Subject-Like "*THWATE*" } )
PS C:\Windows\system32> Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1 -PassThru
WARNING: Configuration parameters will be modified after the Remote Access service is restarted.
The above example uses a variable that assigns a root certificate (i.e., issuer) from our Trusted Root store. It requests a certificate that has “THWATE” in its subject. This is for demonstration purposes only. Do not use THWATE in your configuration.
Successful execution always provides output that specifies the associated root certificate (Figure 3):
Please note, this script does not provide errors if the variable doesn't match a subject a certificate in the Trusted Root store. The Root Certificate field simply remains empty (e.g., Figure 2).
Step 3: Restart the RRAS service.
Alternately, S2S VPNs can serve as a work-around for this public CA free-for-all. We can assign specific client authentication certificates to individual S2S interfaces. The system works but it creates administrative overhead. I’ll write more about this in a future article.
Finally, it’s OK to implement both solutions: Remove all public CAs from the Trusted Root Store; and only authenticate clients from our private CA (i.e., PowerShell).
That’s It!
 |
| Figure 3. Set-VPNAuthProtocol secures our VPN. |
Step 3: Restart the RRAS service.
Additional Thoughts:
Consider additional PowerShell safeguards for certificate authentication:- Define the server certificate sent to clients:
Set-VpnAuthProtocol –CertificateAdvertised - Only accept certificates issued for client authentication:
Set-VpnAuthProtocol –CertificateEKUsToAccept 1.3.6.1.5.5.7.3.2
Alternately, S2S VPNs can serve as a work-around for this public CA free-for-all. We can assign specific client authentication certificates to individual S2S interfaces. The system works but it creates administrative overhead. I’ll write more about this in a future article.
Finally, it’s OK to implement both solutions: Remove all public CAs from the Trusted Root Store; and only authenticate clients from our private CA (i.e., PowerShell).
That’s It!
References:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/52bd49e9-8842-42e2-916a-cbb07eddae33/ikev2-machine-certificate-authentication?forum=winserverNIShttps://support.microsoft.com/en-us/kb/293781
https://social.technet.microsoft.com/Forums/windows/en-US/9c90c7bb-af4a-4668-8ce4-852ce734ae8e/turn-off-automatic-root-certificates-update?forum=winserverDS
0 Comments:
Post a Comment