It's amazing how many folks think that IPSec VPNs are not susceptible to password cracking. I've run into many folks that just don't think about it -- They get distracted by the strength of DH, 3DES, and SHA1, but forget that the weakest link is the password. As Cisco and David Wagner point out, this is not a vulnerability in IPSec/IKE, but is something that I've seen many engineers gloss over. They think about NTLM or Unix hash cracking, but not IPSec.
That's why I wrote IKECrack in the first place -- how secure is a bazillion bit encrypted link that uses "test" as a PSK? I worked out the details of the crack process on my own a couple years ago, then later discovered the IETF and John Pliam had already discussed and decided that it wasn't a big deal. I still find the tool useful for pentesting, but decided it didn't need a detailed whitepaper :)
I do find it surprising that the IKE PSK attacks have not been published more widely and am very surprised that the IETF didn't modify aggressive IKE to make it a bit more secure. [I think SonOfIKE addresses some of this, but most current implementations are the older IKE] Example areas are ID revelation [I've seen vendors strengthen this by passing a hash of the ID], passive HASH collection/cracking due to PSK being only secret in HASH, and the fact that the gateway gives an active attacker a copy of the HASH before validating the user. Many vendors seem to have made IKE aggressive modifications that make passive attacks impossible [AFIK] by using additional secret info in the HASH calculations. This also has a side effect of making active attacks [or MITM] difficult because these modified HASH calcs are generally proprietary :)
As the Cisco response indicated, PSK cracking is not limited to just aggressive mode IKE. Main mode is also vulnerable, but requires a different technique. IKECrack doesn't currently perform the main-mode attacks, but here's an overview of how the process works:
1 - the attacker needs to be a MITM or an active attacker with one of the IPSec peers DoSed and the other re-initiating IKE
2 - the attacker participates in the DH process and collects Nonce values
3 - even though main mode protects the IDs, IDs are normally the IP addresses of each endpoint. Many IPSec devices [Cisco IOS excluded] don't even give the user the ability to override the IP based ID
4 - we now have everything we need [minus the PSK] to calculate the key material used for de-crypting the 1st encrypted frame [ID packet].
4 - Bruteforce/Dictionary for differing PSKs and try to decrypt to frame. We know most of the encrypted frame's contents, so validation is fairly straightforward.
The bottom line is this: If you use PSK auth with either main-mode or aggressive-mode, make sure you choose strong passwords. Best option is to avoid PSK and use stronger methods if possible. I don't agree that folks should scrap agressive-mode -- just be aware that UserIDs are leaked in the clear and weak passwords are crackable.
Anton Rager
Sr. Security Consultant
Avaya Enterprise Security Practice
arager (at) avaya (dot) com [email concealed]
It's amazing how many folks think that IPSec VPNs are not susceptible to password cracking. I've run into many folks that just don't think about it -- They get distracted by the strength of DH, 3DES, and SHA1, but forget that the weakest link is the password. As Cisco and David Wagner point out, this is not a vulnerability in IPSec/IKE, but is something that I've seen many engineers gloss over. They think about NTLM or Unix hash cracking, but not IPSec.
That's why I wrote IKECrack in the first place -- how secure is a bazillion bit encrypted link that uses "test" as a PSK? I worked out the details of the crack process on my own a couple years ago, then later discovered the IETF and John Pliam had already discussed and decided that it wasn't a big deal. I still find the tool useful for pentesting, but decided it didn't need a detailed whitepaper :)
I do find it surprising that the IKE PSK attacks have not been published more widely and am very surprised that the IETF didn't modify aggressive IKE to make it a bit more secure. [I think SonOfIKE addresses some of this, but most current implementations are the older IKE] Example areas are ID revelation [I've seen vendors strengthen this by passing a hash of the ID], passive HASH collection/cracking due to PSK being only secret in HASH, and the fact that the gateway gives an active attacker a copy of the HASH before validating the user. Many vendors seem to have made IKE aggressive modifications that make passive attacks impossible [AFIK] by using additional secret info in the HASH calculations. This also has a side effect of making active attacks [or MITM] difficult because these modified HASH calcs are generally proprietary :)
As the Cisco response indicated, PSK cracking is not limited to just aggressive mode IKE. Main mode is also vulnerable, but requires a different technique. IKECrack doesn't currently perform the main-mode attacks, but here's an overview of how the process works:
1 - the attacker needs to be a MITM or an active attacker with one of the IPSec peers DoSed and the other re-initiating IKE
2 - the attacker participates in the DH process and collects Nonce values
3 - even though main mode protects the IDs, IDs are normally the IP addresses of each endpoint. Many IPSec devices [Cisco IOS excluded] don't even give the user the ability to override the IP based ID
4 - we now have everything we need [minus the PSK] to calculate the key material used for de-crypting the 1st encrypted frame [ID packet].
4 - Bruteforce/Dictionary for differing PSKs and try to decrypt to frame. We know most of the encrypted frame's contents, so validation is fairly straightforward.
The bottom line is this: If you use PSK auth with either main-mode or aggressive-mode, make sure you choose strong passwords. Best option is to avoid PSK and use stronger methods if possible. I don't agree that folks should scrap agressive-mode -- just be aware that UserIDs are leaked in the clear and weak passwords are crackable.
Anton Rager
Sr. Security Consultant
Avaya Enterprise Security Practice
arager (at) avaya (dot) com [email concealed]
IKECrack author
http://ikecrack.sourceforge.net
[ reply ]