pfSense

From CERT. There may not be much we can do here but wait for an update to strongSwan if it's even viable (see conclusion below). If nothing else, we can strengthen the wording of our recommendations for using Pre-Shared Keys as mentioned in https://gitlab.netgate.com/docs/pfsense-wiki-builder/issues/1 but also in the GUI in addition to the documentation.

Assigning to me so I can handle the docs until we hear more from upstream.

CERT/CC has received a report of a vulnerability in the IKEv1 protocol in the authentication mode with pre-shared keys in the main mode of operation. CERT/CC has reserved CVE-2018-5389 for this vulnerability.

Details from the original report have been included below. We have also attached the PoC source code from the researchers. Please note that the researchers plan to publish their work on August 13th. CERT/CC currently plans to also publish at the same time.

Due to the nature of this vulnerability (please see the Conclusion from the researchers), this notification is primarily for awareness. If you do plan on taking action regarding this report, please let us know.

CERT/CC is tracking this report as VU#857035. Please retain VU#857035 in the subject of any email sent to CERT/CC regarding this report.

Regards,

Vulnerability Analysis Team
======================================================================
CERT Coordination Center
www.cert.org / cert@cert.org
======================================================================

----- BEGIN ORIGINAL VULNERABILITY REPORT -----

Background:
Internet Key Exchange v1 is specified in RFC 2409 and used to negotiate keys between two parties for an IPsec connection. One of the specified modes of authentication (we believe it to be the most used mode) uses pre-shared keys (PSKs), i.e. passwords.
There are two protocol modes, the "main mode" and the "aggressive mode". It is well known, that the aggressive mode of IKEv1 PSK is vulnerable to offline dictionary or brute force attacks by simply eavesdropping all 3 messages of the IKEv1 PSK handshake. For the main mode however, only an online attack against PSK authentication was thought to be feasible. We found out that this is not the case.
-------------------------------------------------------------------
Details:
Our attacker model is an active network attacker. The attacker waits for the victim to initiate an IKE handshake with a responder. If victim and responder already have an active connection, the attacker may enforce a new handshake by dropping all packets of the already established connection, which will eventually lead to a new handshake.
The following diagram shows the message flow:
Initiator Responder
---------- -----------
1. HDR, SA --> (plain)
<-- 2. HDR, SA (plain)
3. HDR, KEi, Ni --> (plain)
<-- 4. HDR, KEr, Nr (plain)
5. HDR*, IDii, HASH_I --> (partially encrypted)
<-- 6. HDR*, IDir, HASH_R (partially encrypted)
Now an explenation of the messages:
1. Contains a header and security association set
header:
contains an initiator cookie
additional data (like version, length, etc)
security association:
contains security options, supported by the initator
it also specifies the prefered authentication methods
2. The responder answers with a packet containing an updated header and its security assocication
header:
contains the responder cookie used later
additional data (like version, length, etc)
security association:
contains security options, supported by the responder
it also specifies the prefered authentication methods
3. The initator sends a message that contains his generated Diffie-Hellman public share KEi and his nonce Ni
4. The responder sends a message that contains his generated Diffie-Hellman public share KEr and his nonce Nr
5. The initiator does the following computations:
generates the shared Diffie-Hellman secret
uses his pre-shared key (password), (initiator and responder) nonces and (initiator and responder) cookies in order to generate 4 keys
see below how these keys are generated
the last generated key is used to encrypt the ID of the initator (IDii) and a hash (HASH_I) value
the hash is not relevant for the attack
the encryption is denoted as the * in the diagram (as explained in the RFC)
The attack works as follows:
In order to generate the correct encryption key the attacker needs to know the following values:
1. Both cookies (retrieved from the header of message 2)
2. Both nonces (retrieved from message 3 and 4)
3. Initiator's Diffie-Hellman public share KEi (retrieved from message 3)
4. Responder's Diffie-Hellman private share (generated by attacker since the attacker plays the responder role)
5. Shared Diffie-Hellman secret (computed from KEi and the private Diffie-Hellman share of the responder) 
6. The pre-shared-key (unknown to the attacker)
The keys are generated as follows (Python code):
k = computeKey(psk, initNonce, respNonce)
k_0 = computeKeyK0(k, dhSecret, initCookie, respCookie)
k_1 = computeKeyK1(k, k_0, dhSecret, initCookie, respCookie)
k_2 = computeKeyK2(k, k_1, dhSecret, initCookie, respCookie)
There are also some constant strings needed, but we removed them for clarity
It is clear that the only unknown value is the pre-shared-key psk.
If the pre-shared-key is weak, an attacker may use a dictionary or brute force attack to guess the psk and compute key candidates
These candidates can be used to try a decryption of the encrypted IDii and HASH_I from message 5
The attacker knows to have found the correct psk if the known values of IDii are found in the first bytes of the decrypted message
the IDii looks like the following when using the well-known IPsec implementation strongSWAN
ID_init fields: ID_Type || Protoco_ID || PORT || ID_DATA (IP address)
ID_init values: 01 || 00 || 00 00 || c0 a8 00 64
Note that the Port and IP address are known to the attacker, as well as the IDType and ProtocolID
-------------------------------------------------------------------
Proof-of-Concept:
We tested the attack on strongSwan 5.5.1, Linux 4.9.0-4-amd64
We furthermore used scapy3 and python 3.6
We attached the source code of our proof-of-concept for verification
-------------------------------------------------------------------
Vulnerable Implementations (as far as we know):
strongSWAN 5.5.1 PSK main mode
all IKEv1 RFC 2409 compliant implementations which allow the authentication mode PSK and main mode of operation, e.g.
Hardware: Cisco, Huawei, MikroTik, Netgear, Juniper, Checkpoint, Palo Alto Networks, Ubiquiti, TP-Link, AVM Fritzbox, etc.
Software: strongSwan, OpenSwan, LibreSwan, OpenBSD, IBM IPsec, Microsoft IPsec, Apple IPsec, KAME, Unicoi Systems
-------------------------------------------------------------------
IKEv2:
In our opinion this attack is also possible against IKEv2 although the protocol flow is different
The reason is that an attacker acting as responder would get all required values to mount the dictionary/brute force attack
Due to time constraints we did not implement the attack against IKEv2
-------------------------------------------------------------------
Conclusion:
This is not an implementation bug and can most probably not be fixed in code without violating the RFC.
A direct countermeasure with existing implementations is to use cryptographically secure PSK values that resist brute force or dictionary attacks.
You may ask, why we are sending such a lenghty report just to say "use good passwords". The problem is that implementations and users dont expect this combination of modes to be weak.
For example, PSK authentication together with the aggressive mode of operation is known to be vulnerable. For that reason StrongSwan requires a configuration flag to be set in order to use this combination: "i_dont_care_about_security_and_use_aggressive_mode_psk = yes" (https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Aggressive-Mode)
Such a flag (or any other precautionary measure) does not exist for the main mode of operation.