Certificate Faking

From Single Sign-On Attacks
Revision as of 20:04, 26 January 2016 by Anna (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


The cryptographic verification of the digital signature guarantees the integrity of the token. Additionally, it is essential to verify the token’s authenticity, too. In other words, the Software-as-a-Service Cloud Provider (SaaS-CP) should check whether the token was signed by a trusted Identity Provider (IdP). The Certificate Faking (CF) attack utilizes possible flaws in the selection logic of the key used for the verification of tokens, by providing an attacker generated token signed by an attacker generated key.

Attack subtypes

There are no attack subtypes for this attack.


In order to run the attack, the attacker must be able to create SAML tokens and sign them with his own self-created key.


Target Verificator.jpg

The attacked Single Sign-On component is marked in red colour.

The attack targets the SSO Verificator, which should verify that the authentication token is signed by a trusted third party instead of accepting any key provided with the token (although the XML Signature standard allows to include certificates, it is essential to verify whether it is a trusted certificate).


The SAML token is signed with an untrusted key. If the key stored in the token is used for the verification without validating the trust relationship to it, CF is applicable.

Certificate Faking.jpg

The attacker creates a token t = (I, N, D), where I - Identity, N - Freshness and D - Destination. Then, he creates a secret key evilKey and a corresponding public key. The secret key is used to compute the digital signature s = SIG_evilKey(t). The attacker then uses his key pair to create a certificate evilCert containing the corresponding public key to verify s. SAML uses the XML Signature standard that allows to store evilCert directly within the XML Signature. If the target SaaS-CP uses evilCert to verify the signature s (without prior check of the trust relationship for the corresponding key), the token will be accepted as valid.

Mitigation / Countermeasures

This attack can be mitigated by manually deploying the trusted certificates to the corresponding SaaS-CP and not using any certificates provided with the token.

Practical Examples

This attack can be realized using SAMLRaider: [1] [2]


C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).