Why Sophos is not supporting IKEv1 Aggressive mode with PSK?

This week we are working on a Security Firewall migration project and suddenly we noticed that some of the VPNs are configured in Aggressive mode with a pre-shared key on the old existing firewall. The Client was not supposed to migrate on IKEv2 or Main mode but after an hour discussion with the concerned person, we got a green signal to go with the main mode. We were shown many documents, articles and finally a GNS3 lab that why are we (Sophos) not supporting Aggressive mode with PSK.

Fig 1.1- Sophos Dashboard
Note: Here you can't select "Testing" policy with PSK option because it is configured with IKEv1 Aggressive mode. 

This is a known vulnerability was found almost 16 years back in 2003. Actually, this is not a bug or issue with any product but IKEv1 aggressive mode designed with this security issue.  I hope those days no one was noticed that someone can creak or will creak this PSK. But this is an IT industry and you can't say that you are 100 safe. In IKEv1 Aggressive mode, the authentication hash based on a preshared key (PSK) is transmitted as a response to the initial packet of a VPN client that wants to establish an IPSec Tunnel (Hash_R). This hash is not encrypted. It's possible to capture these packets using a sniffer.

This attack only works in IKE aggressive mode because in IKE Main Mode the hash is already encrypted. Based on these facts IKE aggressive mode is not very secure. This is not new. Read here Cisco Security Notice details: 

The Sophos is using "StrongSwan" open source IPSec VPN codes in the background on XG firewalls. When I was searching for any security article or notice from the "StrongSwan" website and I found some interesting point as:

Does strongSwan support IKEv1 Aggressive Mode?
A: Since version 5.0.0 the answer is yes. For previous releases, where the IKEv1 protocol was handled by the pluto daemon, the answer is and remains no. 

However, the strongSwan developers still recommend to avoid its use with pre-shared keys. This is due to a known weakness of the protocol. With Aggressive Mode, a hash of the pre-shared key is transmitted in clear-text. An eavesdropper can capture this hash and run an offline brute-force attack against it. Once the pre-shared key is known MITM attacks to gather the XAuth credentials can easily be executed. 

Aggressive Mode is therefore incompatible with the basic principles of the strongSwan project which is to deliver a product that meets high security standards. That's why, in order to use Aggressive Mode with pre-shared keys as responder (i.e. on gateways) it is required to set charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes in strongswan.conf. 

As promised often in numerous public and private talks strongSwan then changes its name to weakSwan. It is not required to set this option for clients as they often have no other choice.

To avoid Aggressive Mode with pre-shared keys (and other short-comings of IKEv1 Main or Aggressive Mode) the best option is to switch to IKEv2. But even for IKEv1 strongSwan 5.0.0 now provides an easy to deploy alternative: hybrid authentication. This mode uses a certificate to authenticate the gateway and only XAuth to authenticate the client, during Phase 1 (Main or Aggressive Mode) the client is not authenticated.

Here, I am sharing how to perform this attack in your lab: CSK LAB

An Article By Deepak Kumar 
Linkedin: https://www.linkedin.com/in/engdeepak/
Twitter: https://twitter.com/Deepakkhw