Certificate Faking and Signature Exclusion Attack: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Attack description=
=Attack description=
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.
The integrity of all authentication tokens should be protected. In case of [http://www.sso-attacks.org/SAML ''SAML''], this is realized by a digital signature ''s = SIG_IdP(t)''. ''Signature Exclusion'' (0Sig) exploits a vulnerability in the verification logic allowing the usage of unsigned tokens. If SAML token does not contain any signature, no protection of integrity or authenticity is provided. Since no digital signature for the token is required, an attacker can generate tokens containing arbitrary identities ''(I)'' of other users.
 
The attack targets the [https://en.wikipedia.org/wiki/Single_sign-on 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).


=Attack subtypes=
=Attack subtypes=
Line 9: Line 7:


=Prerequisites for attack=
=Prerequisites for attack=
In order to run the attack, the attacker must be able to create [http://www.sso-attacks.org/SAML SAML] tokens and sign them with his own self-created key.
In order for this attack to work the attacker has to have knowledge about the following things:
#'''Attacker knows endpoint of the web service.''' otherwise, he is not able to reach the web service.  
#'''Attacker knows that the web service processes the security header and the ''"signature"'' element.''' If the web service does not '''"expect"''' an signed part, it just discards the signature and the attack does not work.
 


=Graphical representation of attack=
=Graphical representation of attack=
The [http://www.sso-attacks.org/SAML 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.
 
[[File:Certificate_Faking.jpg|center]]
[[File:Signature_Exclusion_Attack.jpg|center]]
 


=Attack example=
=Attack example=
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.
The attacker creates authentication tokens containing statements about other users ''t = (..., I_Alice/I_Bob/I_Admin,...)''. He then sends the token to an ''Software-as-a-Service Cloud Provider (SaaS-CP)'' (Starget) and is logged in with the corresponding identity. Finally, the attacker gains access to arbitrary accounts and their resources. The attack is targeted at the ''Single Sign-On (SSO)'' Verificator, which should require that the authentication token is signed and verify the applied signature. By this means, the integrity of the authentication token is guaranteed.
 


=Attack mitigation / countermeasures=
=Attack 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.
[http://www.sso-attacks.org/SAML ''SAML''] messages without signature must not be accepted.


=Practical Attack Examples=
=Practical Attack Examples=
At this point no practical attack examples are known.
In 2012, Somorovsky et al. applied the Signature Exclusion attack on three [http://www.sso-attacks.org/SAML ''SAML''] frameworks: Apache Axis2, JOSSO and OpenAthens.
 
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Clarizen.
 


[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
Line 31: Line 37:
[[Category:Attack_Categorisation_By_Attack_on_SAML]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]


=References=
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).


=References=
[https://www.nds.rub.de/research/publications/BreakingSAML/ J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann, M. Jensen: On Breaking SAML: Be Whoever You Want to Be. In Pro­cee­dings of the 21st USE­NIX Se­cu­ri­ty Sym­po­si­um, 2012.]
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).

Revision as of 21:35, 29 November 2015

Attack description

The integrity of all authentication tokens should be protected. In case of SAML, this is realized by a digital signature s = SIG_IdP(t). Signature Exclusion (0Sig) exploits a vulnerability in the verification logic allowing the usage of unsigned tokens. If SAML token does not contain any signature, no protection of integrity or authenticity is provided. Since no digital signature for the token is required, an attacker can generate tokens containing arbitrary identities (I) of other users.

Attack subtypes

There are no attack subtypes for this attack.


Prerequisites for attack

In order for this attack to work the attacker has to have knowledge about the following things:

  1. Attacker knows endpoint of the web service. otherwise, he is not able to reach the web service.
  2. Attacker knows that the web service processes the security header and the "signature" element. If the web service does not "expect" an signed part, it just discards the signature and the attack does not work.


Graphical representation of attack


Attack example

The attacker creates authentication tokens containing statements about other users t = (..., I_Alice/I_Bob/I_Admin,...). He then sends the token to an Software-as-a-Service Cloud Provider (SaaS-CP) (Starget) and is logged in with the corresponding identity. Finally, the attacker gains access to arbitrary accounts and their resources. The attack is targeted at the Single Sign-On (SSO) Verificator, which should require that the authentication token is signed and verify the applied signature. By this means, the integrity of the authentication token is guaranteed.


Attack mitigation / countermeasures

SAML messages without signature must not be accepted.

Practical Attack Examples

In 2012, Somorovsky et al. applied the Signature Exclusion attack on three SAML frameworks: Apache Axis2, JOSSO and OpenAthens.

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Clarizen.

References

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).

J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann, M. Jensen: On Breaking SAML: Be Whoever You Want to Be. In Pro­cee­dings of the 21st USE­NIX Se­cu­ri­ty Sym­po­si­um, 2012.