[strongSwan-dev] CERT payload (X.509 certificates) validation issue

[Ravikumar Chennaparapu]

Hi,

We found an issue with strongswan 5.2.2; peer is accepting CERT payload
even though digital signature field in CERT payload is tampered.

As per the below code, there is no validation for the peer's pub key
certificate; peer's public key is added to the cache without any
validation. We do see this as a security vulnerability, could you check
this? Is our understanding correct ?


static void process_x509(cert_payload_t *payload, auth_cfg_t *auth,
cert_encoding_t encoding, bool *first)
{
certificate_t *cert;
char *url;

cert = try_get_cert(payload);
if (cert)
{
if (*first)
{ /* the first is an end entity certificate */
DBG1(DBG_IKE, "received end entity cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received issuer cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_IM_CERT, cert);
}
}
else if (encoding == ENC_X509_HASH_AND_URL)
{
/* we fetch the certificate not yet, but only if
* it is really needed during authentication */
url = payload->get_url(payload);
if (!url)
{
DBG1(DBG_IKE, "received invalid hash-and-url "
"encoded cert, ignore");
return;
}
url = strdup(url);
if (*first)
{ /* first URL is for an end entity certificate */
DBG1(DBG_IKE, "received hash-and-url for end entity cert \"%s\"",
url);
auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received hash-and-url for issuer cert \"%s\"", url);
auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
}
}
}

Thanks and Regards,
Ravi

[Andreas Steffen]

Hi Ravi,

we are not adding received certificates to any trusted cache.
Per default remote certificates are never trusted and are temporarily
added to the auth_cfg object of the IKE_SA. Full X.509 trust chain
verification then happens at a later stage.

Regards

Andreas

Post by Ravikumar Chennaparapu
Hi,
We found an issue with strongswan 5.2.2; peer is accepting CERT payload
even though digital signature field in CERT payload is tampered.
As per the below code, there is no validation for the peer's pub key
certificate; peer's public key is added to the cache without any
validation. We do see this as a security vulnerability, could you check
this? Is our understanding correct ?
static void process_x509(cert_payload_t *payload, auth_cfg_t *auth,
cert_encoding_t encoding, bool *first)
{
certificate_t *cert;
char *url;
cert = try_get_cert(payload);
if (cert)
{
if (*first)
{ /* the first is an end entity certificate */
DBG1(DBG_IKE, "received end entity cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received issuer cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_IM_CERT, cert);
}
}
else if (encoding == ENC_X509_HASH_AND_URL)
{
/* we fetch the certificate not yet, but only if
* it is really needed during authentication */
url = payload->get_url(payload);
if (!url)
{
DBG1(DBG_IKE, "received invalid hash-and-url "
"encoded cert, ignore");
return;
}
url = strdup(url);
if (*first)
{ /* first URL is for an end entity certificate */
DBG1(DBG_IKE, "received hash-and-url for end entity cert \"%s\"",
url);
auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received hash-and-url for issuer cert \"%s\"", url);
auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
}
}
}
Thanks and Regards,
Ravi

[Ravikumar Chennaparapu]

Hi Andreas,

Thanks for the quick reply.

Could you point out the code where peer remote cert validation happens for
CERT payload?

Regards,
Ravi



On Thu, Jan 4, 2018 at 2:18 AM, Andreas Steffen <

Post by Andreas Steffen
Hi Ravi,
we are not adding received certificates to any trusted cache.
Per default remote certificates are never trusted and are temporarily
added to the auth_cfg object of the IKE_SA. Full X.509 trust chain
verification then happens at a later stage.
Regards
Andreas

Post by Ravikumar Chennaparapu
Hi,
We found an issue with strongswan 5.2.2; peer is accepting CERT payload
even though digital signature field in CERT payload is tampered.
As per the below code, there is no validation for the peer's pub key
certificate; peer's public key is added to the cache without any
validation. We do see this as a security vulnerability, could you check
this? Is our understanding correct ?
static void process_x509(cert_payload_t *payload, auth_cfg_t *auth,
cert_encoding_t encoding, bool *first)
{
certificate_t *cert;
char *url;
cert = try_get_cert(payload);
if (cert)
{
if (*first)
{ /* the first is an end entity certificate */
DBG1(DBG_IKE, "received end entity cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received issuer cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_IM_CERT, cert);
}
}
else if (encoding == ENC_X509_HASH_AND_URL)
{
/* we fetch the certificate not yet, but only if
* it is really needed during authentication */
url = payload->get_url(payload);
if (!url)
{
DBG1(DBG_IKE, "received invalid hash-and-url "
"encoded cert, ignore");
return;
}
url = strdup(url);
if (*first)
{ /* first URL is for an end entity certificate */
DBG1(DBG_IKE, "received hash-and-url for end entity cert \"%s\"",
url);
auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received hash-and-url for issuer cert \"%s\"", url);
auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
}
}
}
Thanks and Regards,
Ravi

--
======================================================================
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

[Ravikumar Chennaparapu]

Hi Andreas,

We did some analysis and observed that issue is only seen if we use same
certificates on both sides.

We observed that when verify_trust_chain invokes issued_by, it is always
referencing local certificate instead the peer certificate which is
tampered.

Local certificate is valid one so validation is successful and tunnel got
established with tampered peer certificate.(only certificate signature
content is modified).

Could you check this from your side. If needed more info regarding this
issue, please let me know.

Thanks and Regards,
Ravi





On Thu, Jan 4, 2018 at 5:49 PM, Ravikumar Chennaparapu <

Post by Ravikumar Chennaparapu
Hi Andreas,
Thanks for the quick reply.
Could you point out the code where peer remote cert validation happens for
CERT payload?
Regards,
Ravi
On Thu, Jan 4, 2018 at 2:18 AM, Andreas Steffen <

Post by Andreas Steffen
Hi Ravi,
we are not adding received certificates to any trusted cache.
Per default remote certificates are never trusted and are temporarily
added to the auth_cfg object of the IKE_SA. Full X.509 trust chain
verification then happens at a later stage.
Regards
Andreas

Post by Ravikumar Chennaparapu
Hi,
We found an issue with strongswan 5.2.2; peer is accepting CERT payload
even though digital signature field in CERT payload is tampered.
As per the below code, there is no validation for the peer's pub key
certificate; peer's public key is added to the cache without any
validation. We do see this as a security vulnerability, could you check
this? Is our understanding correct ?
static void process_x509(cert_payload_t *payload, auth_cfg_t *auth,
cert_encoding_t encoding, bool *first)
{
certificate_t *cert;
char *url;
cert = try_get_cert(payload);
if (cert)
{
if (*first)
{ /* the first is an end entity certificate */
DBG1(DBG_IKE, "received end entity cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received issuer cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_IM_CERT, cert);
}
}
else if (encoding == ENC_X509_HASH_AND_URL)
{
/* we fetch the certificate not yet, but only if
* it is really needed during authentication */
url = payload->get_url(payload);
if (!url)
{
DBG1(DBG_IKE, "received invalid hash-and-url "
"encoded cert, ignore");
return;
}
url = strdup(url);
if (*first)
{ /* first URL is for an end entity certificate */
DBG1(DBG_IKE, "received hash-and-url for end entity cert \"%s\"",
url);
auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received hash-and-url for issuer cert \"%s\"", url);
auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
}
}
}
Thanks and Regards,
Ravi

--
======================================================================
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

[Andreas Steffen]

Hi Ravi,

locally loaded certificate are always trusted even if the X.509
trustchain is not complete. This also allows the use of self-signed
certificates.

Regards

Andreas

Post by Ravikumar Chennaparapu
Hi Andreas,
We did some analysis and observed that issue is only seen if we use same
certificates on both sides. 
We observed that when verify_trust_chain invokes issued_by, it is always
referencing local certificate instead the peer certificate which is
tampered. 
Local certificate is valid one so validation is successful and tunnel
got established with tampered peer certificate.(only certificate
signature content is modified).
Could you check this from your side. If needed more info regarding this
issue, please let me know. 
Thanks and Regards,
Ravi
On Thu, Jan 4, 2018 at 5:49 PM, Ravikumar Chennaparapu
Hi Andreas,
Thanks for the quick reply.
Could you point out the code where peer remote cert validation
happens for CERT payload?
Regards,
Ravi
On Thu, Jan 4, 2018 at 2:18 AM, Andreas Steffen
Hi Ravi,
we are not adding received certificates to any trusted cache.
Per default remote certificates are never trusted and are temporarily
added to the auth_cfg object of the IKE_SA. Full X.509 trust chain
verification then happens at a later stage.
Regards
Andreas
Hi,
We found an issue with strongswan 5.2.2; peer is accepting
CERT payload
even though  digital signature field in CERT payload is
tampered.
As per the below code, there is no validation for the peer's
pub key
certificate; peer's public key is added to the cache without any
validation. We do see this as a security vulnerability,
could you check
this? Is our understanding correct ?
static void process_x509(cert_payload_t *payload, auth_cfg_t *auth,
cert_encoding_t encoding, bool *first)
{
certificate_t *cert;
char *url;
cert = try_get_cert(payload);
if (cert)
{
if (*first)
{ /* the first is an end entity certificate */
DBG1(DBG_IKE, "received end entity cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_SUBJECT_CERT, cert);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received issuer cert \"%Y\"",
cert->get_subject(cert));
auth->add(auth, AUTH_HELPER_IM_CERT, cert);
}
}
else if (encoding == ENC_X509_HASH_AND_URL)
{
/* we fetch the certificate not yet, but only if
* it is really needed during authentication */
url = payload->get_url(payload);
if (!url)
{
DBG1(DBG_IKE, "received invalid hash-and-url "
"encoded cert, ignore");
return;
}
url = strdup(url);
if (*first)
{ /* first URL is for an end entity certificate */
DBG1(DBG_IKE, "received hash-and-url for end entity cert \"%s\"",
url);
auth->add(auth, AUTH_HELPER_SUBJECT_HASH_URL, url);
*first = FALSE;
}
else
{
DBG1(DBG_IKE, "received hash-and-url for issuer cert \"%s\"", url);
auth->add(auth, AUTH_HELPER_IM_HASH_URL, url);
}
}
}
Thanks and Regards,
Ravi
--
======================================================================
Andreas Steffen                       
strongSwan - the Open Source VPN Solution!         
www.strongswan.org <http://www.strongswan.org>
Institute for Networked Solutions
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==