Certificate Faking and Replay Attack: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Introduction=
=Introduction=
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.
Every [https://en.wikipedia.org/wiki/Single_sign-on SSO] protocol provides freshness parameters ''N'' to limit the reuse and lifetime of the authentication tokens. Taking into account that the reuse of tokens is optional, the validation of the attributes providing freshness is not considered as critical. On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time.


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).
The attack specifically targets the SSO Verificator.


=Attack subtypes=
=Attack subtypes=
Line 8: Line 8:


=Prerequisites=
=Prerequisites=
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.
The attacker needs access to a valid token. More specifically, the token in question is required to be valid for the ''Software-as-a-Service Cloud Provider (SaaS-CP)'' at any time in the past. This can be achieved if the attacker had legitimate access (for a limited period of time) to the ''SaaS-CP'' via ''SSO'' and used this access to generate and store a token for himself. Alternatively, searching for published tokens in forums or in technical documentations could also provide valid, though most possibly outdated, tokens.


=Target=
=Target=
Line 15: Line 15:


=Description=
=Description=
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.
The attacker sends an expired authentication token to the target ''SaaS-CP''. In case, that the unlimited reuse of authentication tokens is applicable and the token is successfully verified, the attack is classified as successful.
The attack’s impact is average since the attacker has limited attack surface – he can only spend authentication tokens he possesses. However, the potential impact drastically rises in case the attacker gains hold of an authentication token granting him extended access rights (e.g., as an administrator of the system).
 
[[File:Replay_Attack.jpg]]
<br>
SAML token with expired timestamps is sent to the ''SaaS-CP''.


[[File:Certificate_Faking.jpg|center]]
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=
=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.
This component should validate attributes providing the corresponding restrictions, i.e., the freshness parameter ''N''. In the SAML context relevant to this study, this parameter is represented by ''NotOnOrAfter'' and ''NotBefore''. Failing to
properly verify these parameters will enable this attack type. Another possibility to enable this attack type would be via additional freshness attributes, which are not part of the digital signature ''s''.


=Practical Examples=
=Practical Examples=
This attack can be realized using SAMLRaider:
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Clarizen, Instructure, AppDynamics, TimeOffManager, LiveHive and CA Service Management.
[http://blog.csnc.ch/2015/09/saml-sp-authentication-bypass-vulnerability-in-nevisauth/]
[http://www.csnc.ch/misc/files/advisories/CVE-2015-5372_AdNovum_nevisAuth_Authentication_Bypass.txt]


[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]


=References=
=References=
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk
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).
(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 18:25, 25 January 2016

Introduction

Every SSO protocol provides freshness parameters N to limit the reuse and lifetime of the authentication tokens. Taking into account that the reuse of tokens is optional, the validation of the attributes providing freshness is not considered as critical. On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time.

The attack specifically targets the SSO Verificator.

Attack subtypes

There are no attack subtypes for this attack.

Prerequisites

The attacker needs access to a valid token. More specifically, the token in question is required to be valid for the Software-as-a-Service Cloud Provider (SaaS-CP) at any time in the past. This can be achieved if the attacker had legitimate access (for a limited period of time) to the SaaS-CP via SSO and used this access to generate and store a token for himself. Alternatively, searching for published tokens in forums or in technical documentations could also provide valid, though most possibly outdated, tokens.

Target

File:Target Signature Verification.jpg


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

Description

The attacker sends an expired authentication token to the target SaaS-CP. In case, that the unlimited reuse of authentication tokens is applicable and the token is successfully verified, the attack is classified as successful. The attack’s impact is average since the attacker has limited attack surface – he can only spend authentication tokens he possesses. However, the potential impact drastically rises in case the attacker gains hold of an authentication token granting him extended access rights (e.g., as an administrator of the system).


SAML token with expired timestamps is sent to the SaaS-CP.


Mitigation / Countermeasures

This component should validate attributes providing the corresponding restrictions, i.e., the freshness parameter N. In the SAML context relevant to this study, this parameter is represented by NotOnOrAfter and NotBefore. Failing to properly verify these parameters will enable this attack type. Another possibility to enable this attack type would be via additional freshness attributes, which are not part of the digital signature s.

Practical Examples

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Clarizen, Instructure, AppDynamics, TimeOffManager, LiveHive and CA Service Management.

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

Retrieved from "http://www.ws-attacker.de/index.php?title=Certificate_Faking&oldid=243"