A recent incident affecting a small number of entities in the UK federation has alerted us to some issues related to the distribution of default cryptographic keys. The following advice applies to both service providers (SP) and identity providers (IdP).
The risk of using a default key is that someone may impersonate you. As an SP they may obtain information from an IdP, whilst this is hard to pull off, it is not impossible. The risk of an IdP using a default key is that someone may impersonate your IdP almost trivially.
The issues here are to do with how you create/maintain key material and trust one another… Something which R&E federations such as the UK federation exist to provide and to protect, with a trust fabric to enable this material to be shared within the context of SAML authentication.
The supply chain issue of containers
If you are using container images e.g. Docker, Kubernetes to provide parts of the infrastructure for your SAML implementation, then you must understand and review the supply chain related to this, review the container for any weakness or insecurity, and ensure that the container image is being maintained and updated in-line with the versions of software provided by the vendor.
In this case we identified that a widely used publicly available container image contained default cryptographic keys – CWE-1394. The use of that particular image does not itself lead to a vulnerability. However, the use of the default cryptographic keys does lead to a vulnerability, and it’s very easy to do this in the haste of developing a service or solution and leave this in place without realising.
Recommendations
1. If you do not know how the cryptographic keys have been created, go and find out. The best time to rinse and replace keys is before they are deployed and trusted by your customers/peers.
2. Check in-service containers to see how fresh they are, if they are regularly maintained, review the corresponding/upstream code repository e.g. on Github, or the build system e.g. Dockerfile
3. If keys are created during build, then those keys need to be unique and protected. You may need to run your own container build system/Dockerfile and registry image, that must then be secure/protected if you need the keys in the build image. Alternatively, override the keys locally with mounts/secrets in Docker/Kubernetes etc..
4. Check your build systems work; as a result of changes to container image and in some cases withdrawal of images, your container builds may no longer work. It’s better to routinely check, rather than not being able to address a critical vulnerability in a timely fashion.
5. If it’s found that you’re reusing non-unique key material then contact us for further guidance.
The dangers of direct or bi-lateral metadata sharing
Even for the UK federation who manage metadata for multiple participants, there are ways that problems and vulnerabilities can be introduced. We have incorporated scanning for signatures of these insecurities into the UK federation toolchain and, thankfully, we can see none at this time.
For individual identity or service providers who are integrating direct or bi-lateral metadata sharing between a service provider and an identity provider, they may not have the visibility that we have, or the robust controls that enable us to flag and block entities with known insecure keys. In order to protect it’s members, were existing compromised keys are discovered, the UK federation works with participants to rapidly remove and replace these within the federation metadata/trust fabric.
The trust-fabric of the UK federation relies on regular download and ingestion of the metadata coupled with signature checking of the metadata. These methods are frequently not used for bi-lateral metadata between SP and IdP, where metadata is usually shared with many organizations and difficult and slow to revoke/replace, and there is often no signature checking of the metadata taking place. Therefore an adversary could gain control of the metadata endpoint and “trick” IdPs to trusting an SP under their control (and therefore be able to exfiltrate personal data from the target organisation). This situation is not possible where signature checking is used.
An individual Identity provider operator is often working in an environment where the opportunities to peer review are limited, relating to the configuration of the SP, its metadata, or the configuration the SP recommends on the IdP. Identity provider operators may not always know when and where they need to test to ensure the configuration is robust.
Recommendations
1. The more SPs can be encouraged to work through the UK federation, then the less bi-lateral metadata needs to be shared, reducing risks related to metadata and key handling. However, SPs need to comply with our rules and have SAML software that will work in a multi-lateral federation, which can be more challenging for some SaaS based providers, who have designed their systems to work with a single IdP. Sometimes these can integrate directly within the federation, and sometimes they aren’t able.
2. IdP operators who are integrating directly should question SPs on
- How was the key material created?
- What SAML software is being used and from where?
3. IdP operators may find that SAML encryption and key material are not provided by the SP. In such a case they should test that the SP is performing signature checking of the SAML assertion from the IdP. Within the UK federation we require SAML encryption keys to be provided by SPs, so that IdPs can encrypt their assertions.
In a situation where SAML encryption is not used, all data sent between IdP and SP is visible in the web browser and by plugins, and you are 100% reliant on both the SP performing signature checking and TLS/SSL i.e. https. Hence, our recommendation is to use SAML encryption wherever possible, and to challenge SPs who do not.
On a slightly related note, the following “meme” originally shared via social media struck a cord (have re-created using Bart Simpson Chalkboard Generator ) … SAML responses are base64 encoded, but this in itself is not encryption – it’s encoding.
I think finally we should let The Simpsons remind us of the dangers of poor key management – “500 Keys episode”
Please contact us via service@ukfederation.org.uk, if you have any queries related to the UK Access Management Federation.