IPSEC is an amazing, but not often used technology that allows you to authenticate, allow, deny, protect and/or encrypt network traffic between windows and non-window computers. It has been around since at least Windows 2000 days but it is some time difficult to set up. Â
Recently, Microsoft has released a how to article explaining how you can use it to restrict network connections to your domain controllers so that only your Privileged Access Workstations can make RDP connection to your domain controllers (see https://blogs.technet.microsoft.com/askpfeplat/2017/07/24/securing-rdp-with-ipsec/ ). Itâ€™s a great article that got me to test out the feature myself and I highly recommend that you look at it this article yourself especially if you are setting a dedicated Admin Workstations for your Domain Admins. Â
One of the first things that IPSEC needs to do when negotiating the protocol is to authenticate the users and/or the computer. IPSEC can do this is via many ways (see below):Â
- Kerberos â€“ This is on by default way to authenticate any Windows user and computers and is a relatively easy and reliable way of authenticatio
- NTLM â€“ This is of course the old method of authenticating Windows users and computers and while it is easy to use, it is in no way as strong as Kerberos method.
- Certificate â€“ This is the uses industry standard PKI certificates again for the computers and/or users. It strength is based on the type of certificate you have deployed, but generally it’s considered very strong authentication. It can however take a lot of setting up as you have to deploy a full PKI environment first and issues the computers and users certificates
- Preshared key – This option allows you to select a preshred key that you specify as the authentication for IPSEC. As it clearly says (Below) this is a â€œnot recommendedâ€ way of setting up authentication for IPSEC. Its only described as being â€œless secureâ€ than the other authentication methods. This method is really used if you are not communicated with other non-windows computers via IPSEC and you have no other way to authenticate.
(Yes my super-secure password highlighted below â€˜ABC123â€™)
Â Now is also a good time to explain that a few years ago Microsoft released a patch MS14-025 to address how it stored password in AD. In short, the Group Policy Preferences passwords were saved using a 32 bit AES encrypted value. Previous to this hotfix when you set the value in Group Policy you were warned that the password was being only â€œlightly encryptedâ€. Microsoft went out if its way to warn you in a blog post about this in 2009 (see https://blogs.technet.microsoft.com/grouppolicy/2009/04/22/passwords-in-group-policy-preferences-updated/) and I also did a post in 2013 (see https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/) explaining how bad it was to use these Preferences password option. Â
Then, Metasploit released a module for their toolkit to scan for scanning and decrypting these password value saved in the AD System Volume. So Microsoft released a patch that blocked the UI from being able to make changes to any Group Policy Passwords. Put simply Microsoft drew the line in the sand and prevented anyone from saving Preferences password in the AD SYSVOL.Â
So, with the knowledge and Microsoft deliberate attempts to block any sort of â€œsecretâ€ values in AD. So when I then stumbled across this dialogue box that specifically mentioned a preshared Key. This got me thinking about how this key is stored in AD and how Microsoft addressed the same issues of saving the preshared key for IPSEC.Â
Firstly you can see (image above) that after you set the value you can still clearly see it in the Group Policy UI. This told me at the very least however they key was stored using encryption and not hashsed. This at the very least told be the valued could in theory be reversed engineered and did get me a bit worried.
Â So kept digging into the SYSVOL of the Group Policy Object and almost immediately opened up the â€œRegistry.polâ€ file to see if it gave any clues to the storage of the key.
Â I did a quick â€œfindâ€ in the file for the string â€˜ABC123â€™ but could not find it, so I did a quick visual scan for anything that looked like an obfuscated field and to my surprise the key was there in plain text as â€˜A B C 1 2 3â€™.
Â Thatâ€™s right, the method of storage of the preshared key for IPSEC is to simply add a space between each character and then just save is in the SYSVOL as clear text. So as far as algorithms go, I think this one could be cracked by my 5 year old…
Update: Thanks to the comment from SODER to my article he explains that the spaces are actually just the way the text is displayed in notepad. Other text editors that display unicode will actually not have any spaces at all.
So the warning message is certinly correct, the preshared key is stored â€œless secureâ€. More accurately you could describe it as being not secure at all.
Then, if you have read the blog post by fellow MVP Darren Mar-Elia at https://sdmsoftware.com/group-policy-blog/security-policy/a-new-old-threat-dealing-with-ad-and-group-policy-information-exposure/ you will realise that the System Volume is an open book readable by all computers (and most users) in your Active Directory domain. So, the permission to read the Group Policy Object information that has this preshared key is by default â€œAuthenticated Usersâ€ or maybe only â€œDomain Computersâ€ if you have locked it down. Put simply, assume everyone on your domain can read this value. It must, otherwise how else can your computer read the information required to setup a preshared key authentication in the first place.
Â So, to summaries we have a pre-shared key, saved in a place that is readable by all users and computer in the domain and is saved in clear text unicode.
But why is this an issues? Microsoft is clearly warning people that it is â€œless secureâ€ so let them make the decision about whether to use this option or not. Well, if you remember earlier Microsoft has already gone to the effort of disabling featured that save password values in AD SYSVOL using just light encryption. What I fail to see here in this case why this is really any different.
If I had to guess, this is just a legacy setting that has been around for many years that is used mainly used for testing and/or IPSEC with non-Windows based computers. I am sure the usage rate of such an option if very low. But this does not mean that it is not likely that there are some people out there that are using IPSEC thinking that it gives them some level of protections.Â
So let me be clear, in my opinion IPSEC with preshared key should not be considered secure at all. If you have deployed IPSEC using this method of authentication then you really need to look at moving to PKI, Kerberos or event NTLM. Also, at the very least I think Microsoft should address this issues in a similar way to how it prevented people using Group Policy Preferences Passwords.
But donâ€™t get me wrong I am not saying IPSEC is not secure, itâ€™s just that one of the available method of authentication is not secure. So, if you are going to use IPSEC then for goodness sake NEVER USE PRESHARED KEYS.
8 thoughts on “Why you should never use a Preshared Key with IPSEC”
“obfuscated by adding spaces between each character”
Err..hmm.. not obfuscation at all! Let me explain. That registry.pol file is literally a text file, that contains regkey names and value pairs. And because registry supports full unicode characters, the policy file contains also unicode-encoded text. Unicode by definition supports 65535 different characters. Which is exactly 16 bits, or 2 bytes. So it stores 2x “normal” characters per 1 unicode character. Because the normal english alphabet was high in the list, all ofmthem fit in the first 256 items list (a’la ASCII), so no real need for the 2nd byte to encode them. So the second byte is hex 0 (I may be wrong with the exact value, but its visual representation looks like some space or similar.
Try to use any more proper text editor instead of notepad, and try to choose the decoding format from ASCII into Unicode, and surprise! There will be no more extra spaces, just purely the real readable value of the reg key names, and IPSEC preshared keys 🙂
Hi Soder. Thank you for your detail description as to how the vaule is saved and explaining that the vaule is in fact not obfuscated at all…
Is this the same for Windows 10 machines that are not on the domain?
I am trying to retrieve a PSK from a W10 device that has bMMC IPSEC snap-in but I am having a hard time finding anything that looks like it. ALl the .POL files are clean and a search of the registry has come up with nothing.
If its not on the domain then it would not be stored in SYSVOL, but at best the value would need to be saved as encrypted so its defenitly possible that you could discover the value if you have access to the OS on the computer.