Pre-Announcement from Tobias Brunner <tobias@strongswan.org>
Date: Thu, 5 Nov 2015 14:23:39 +0100
Subject: [security@suse.de] strongSwan security vulnerability: CVE-2015-8023
CRD: 16.11.2015, 12:00 UTC
------------------------------

Dear strongSwan partner,

While looking into a different issue I recently discovered a serious
authentication bypass vulnerability in our eap-mschapv2 plugin.  All
strongSwan versions since 4.2.12 are affected.

CVE-2015-8023 has been assigned for this vulnerability.

Affected are IKEv2 connections that use EAP-MSCHAPv2 to authenticate
clients via our own eap-mschapv2 plugin.  It doesn't matter if it is
used directly (rightauth=eap-mschapv2) or tunneled in EAP-PEAP or
EAP-TTLS (rightauth=eap-peap|ttls and phase2_method = mschapv2) or if
the eap-dynamic plugin is used (rightauth=eap-dynamic) with the
eap-mschapv2 plugin being loaded.
Installations that use RADIUS to provide EAP-MSCHAPv2 authentication to
their clients (rightauth=eap-radius) are not affected (provided the
RADIUS server's EAP-MSCHAPv2 implementation is correct).

The EAP-MSCHAPv2 protocol works roughly as follows:  The server sends a
Challenge message to the client containing a challenge string.  The
client uses that string together with the username and password to
calculate a response that it sends back in a Response message, which
also contains a challenge provided by the client.  The server validates
the response and, in turn, uses the client's challenge string, username
and password to calculate a response that proves it also knows that
shared secret.  This response is sent to the client in a Success Request
message.  The client verifies the server's response and, if valid, sends
an empty Success Response message to the server, which successfully
concludes the EAP method.  If the authentication was successful an EAP
MSK (Master Session Key) is calculated based on the password and the
client's original response.  Please refer to [1] and RFC 2759 for details.

Due to insufficient validation of its local state the server
implementation of the EAP-MSCHAPv2 protocol in the eap-mschapv2 plugin
can be tricked into successfully concluding the authentication without
providing valid credentials.  In fact, the client can simply send the
last message in the process described above (i.e. an empty Success
message) as response to the server's Challenge message to pass the
EAP-MSCHAPv2 authentication successfully.

Since no MSK is established if this happens it's possible to recognize
such attacks by looking at the server logs.  The following log message
would be seen during the client authentication:

  EAP method EAP_MSCHAPV2 succeeded, no MSK established

Please let us know if you noticed such attacks on your servers.

The attached patches fix the vulnerability in the affected strongSwan
versions and should apply with appropriate hunk offsets.

Please prepare updated releases and patch your installations, but do not
yet publicly disclose any information about this vulnerability.  We want
to give you as a partner enough time to prepare new releases and will
publicly disclose the vulnerability with the strongSwan 5.3.4 release on
Mon Nov 16th, 12:00 noon UTC.

The issue I originally looked into (reported by a user at [2]) also
concerns the eap-mschapv2 plugin and mostly affects setups where a
client's EAP-Identity is used for accounting purposes or duplicate
checking.  Because the username used during the EAP-MSCHAPv2 exchange
was not tied to the identity exchanged in an earlier EAP-Identity
exchange (or the IKE identity) a client could choose an arbitrary
EAP-Identity and then authenticate itself using its own username and
passsword (a regular client usually uses the same identity/username for
the two exchanges, but that's quite obviously not a requirement).
Subsequently, the client is identified by its chosen EAP-Identity and
not its actual username.  The upcoming release will also include a fix
for this issue.

Our apologies for the inconvenience.

Kind Regards
Tobias Brunner
strongSwan Developer

[1] https://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2
[2] https://wiki.strongswan.org/issues/1182