Security alert regarding default keys in Service Provider Docker image

[Frank Mason]

Unicon, Inc. has recently discovered that a specific Docker image of a
Shibboleth Service Provider contains default encryption and signing keys.
These keys have been found unchanged in some production installations. If
you are running an image from or based on the recently disabled
https://hub.docker.com/r/unicon/shibboleth-sp/ (source code:
https://github.com/Unicon/shibboleth-sp-dockerized) you should immediately
replace it with the latest version found at
https://hub.docker.com/r/i2incommon/shibboleth_sp, which is maintained by
Internet2/InCommon. Further details are contained below. If you have any
questions, please email info at unicon.net or submit our Contact Us form (
https://www.unicon.net/contact-us).

Regards,

Frank Mason

Information Security Officer

Unicon, Inc.


=Synopsis=

Unicon, Inc. Shibboleth Service Provider Docker image contains default
encryption and signing keys.

=Type/Severity=

Moderate

= Summary =

The Shibboleth Service Provider (SP) Docker image defined by the
shibboleth-sp-dockerized project (
https://github.com/Unicon/shibboleth-sp-dockerized,
https://hub.docker.com/r/unicon/shibboleth-sp/ (disabled)) had two
public/private key pairs (X509 certificates) embedded within it. These two
key pairs should be regenerated for any non-demonstration deployment of
that image, but project documentation did not explicitly instruct deployers
to do so. Failing to do so compromises privacy, authenticity, and/or
integrity of a SAMLv2 IdP’s communication with the affected SP.

Affected versions:

   -

   All images pulled from https://hub.docker.com/r/unicon/shibboleth-sp/
   (disabled)


= Details =

The problematic key pairs exist in the following files, all in the
/etc/shibboleth directory:


   -

   sp-encrypt-cert.pem
   -

   sp-encrypt-key.pem
   -

   sp-signing-cert.pem
   -

   sp-signing-key.pem


The Shibboleth SP will, by default, list the encryption public key in its
metadata as being able to be used by a SAML IdP to encrypt its response to
the Shibboleth SP. That same metadata would also indicate to the SAML IdP
that a signing public key could be used to sign the AuthnRequest that the
Shibboleth SP sends to the SAML IdP. If a deployment used the
unicon/shibboleth-sp
from Docker Hub without changing those embedded key pairs, the potential
impact is as follows:


   -

   The SAMLv2 response returned to the Shibboleth SP could be encrypted by
   a SAML IdP using that original embedded encryption public key, and anyone
   who was able to get access of a copy of that SAMLv2 response could decrypt
   it and see its contents, potentially exposing sensitive information. That
   is, a SAMLv2 response intended to only be “decryptable” by that Shibboleth
   SP could be decrypted by others. These SAMLv2 responses typically contain
   user attributes, e.g. email addresses, first name, last name, etc. Other
   information could also be included that could be considered sensitive, such
   as employee ids and group memberships.
   -

   If the Shibboleth SP were to sign the AuthnRequest it sends to a SAML
   IdP, then a SAML IdP could receive a SAMLv2 AuthnRequest that it thinks has
   been verified as coming from that specific Shibboleth SP, whereas an
   unknown system or actor could have sent it. Note, though, that the
   Shibboleth SP only sends a signed AuthnRequest to a SAML IdP if the
   deployer overrides the default settings in the Shibboleth SP Docker image,
   or if the SAML IdP metadata it relies on indicates that the IdP wants to be
   sent a signed request.


= Mitigation =

Deployments based on its DockerHub-hosted images should migrate to images
maintained by Internet2/InCommon (
https://hub.docker.com/r/i2incommon/shibboleth_sp), especially if the
embedded key pairs were not regenerated prior to deployment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230405/3ecb425f/attachment.htm>