File:Target Parser.jpg and Certificate Injection: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
(Anna uploaded a new version of File:Target Parser.jpg)
 
 
Line 1: Line 1:
=Introduction=
The basic idea of ''Certificate Injection (CInj)'' is to inject a malicious certificate and store it in the ''Authorization & Access Management  (AAM)'' module. Since the SSO module uses this certificate for the token verification, tokens signed by the attacker, who possesses the private key to the injected certificate, will be successfully verified. By this means, even a correctly implemented SSO module, which mitigates all attacks directly related to this module, can still be bypassed.


=Attack subtypes=
There are no attack subtypes for this attack.
=Prerequisites=
*The Service Provider provides functionality to upload a custom IdP certificate, that is used by the ''AAM'' to verify tokens.
*The Service Provider has not implemented countermeasures against [https://en.wikipedia.org/wiki/Cross-site_request_forgery ''Cross-site request forgery (CSRF)''].
=Target=
[[File:Target_Session_Managment.jpg|centre|600px]] <br>
The attacked Single Sign-On component is marked in red colour. <br>
The attack uses [https://en.wikipedia.org/wiki/Cross-site_request_forgery Cross-site request forgery]''(CSRF)'' technique to force the victim into changing configuration data without explicit user interaction.
=Description=
An actual exploit for this attack type can be separated into three consecutive phases:
*'''Phase 1 – Preparation.''' The attacker creates his private key '''evilKey''' and a corresponding public key and uses these to create a certificate
'''evilCert'''.
*'''Phase 2 – Configuration Injection.''' The attacker creates a malicious link containing the ''CSRF'' attack vector, i.e., the injection of '''evilCert'''. Luring the victim to click on that link, he will exchange the originally stored certificate in the User Database with the one provided by the attacker. This is possible because the HTTP-request that changes the certificate is sent via the victim’s browser (using the victim’s session
cookies).
*'''Phase 3 – Access to resources.''' The attacker can then generate a token '''t''' for an arbitrary user and sign it with the key belonging
to '''evilCert''' generating '''s'''. Then, he sends '''(t,s)''' to the target service provider for verification. The target service provider will use the certificate stored in the ''AAM'' module and use this for the verification of '''s'''. Since the stored certificate is '''evilCert''', the verification is successful and the attacker can log in with the chosen identity.
If the attacker is able to inject his own SSO configuration, the '''SP''' and the according SSO module will trust the attacker
just as a regular trusted '''IdP'''. By this means, the attacker can generate valid tokens for any user on the SP and log into his account.
=Mitigation / Countermeasures=
Session Management should include a protection against ''CSRF'' (e.g. CSRF tokens, reasonable session timeout) to mitigate the attack.
=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:
SAManage, Shiftplanning, BambooHR, IdeaScale, Howlr and CA Service Management.
[[Category:Attack_Categorisation_By_Attacker_Model:_Web_Attacker]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Session_Managment]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[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).

Latest revision as of 21:55, 9 February 2016

Introduction

The basic idea of Certificate Injection (CInj) is to inject a malicious certificate and store it in the Authorization & Access Management (AAM) module. Since the SSO module uses this certificate for the token verification, tokens signed by the attacker, who possesses the private key to the injected certificate, will be successfully verified. By this means, even a correctly implemented SSO module, which mitigates all attacks directly related to this module, can still be bypassed.

Attack subtypes

There are no attack subtypes for this attack.


Prerequisites

  • The Service Provider provides functionality to upload a custom IdP certificate, that is used by the AAM to verify tokens.
  • The Service Provider has not implemented countermeasures against Cross-site request forgery (CSRF).

Target


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

The attack uses Cross-site request forgery(CSRF) technique to force the victim into changing configuration data without explicit user interaction.

Description

An actual exploit for this attack type can be separated into three consecutive phases:

  • Phase 1 – Preparation. The attacker creates his private key evilKey and a corresponding public key and uses these to create a certificate

evilCert.

  • Phase 2 – Configuration Injection. The attacker creates a malicious link containing the CSRF attack vector, i.e., the injection of evilCert. Luring the victim to click on that link, he will exchange the originally stored certificate in the User Database with the one provided by the attacker. This is possible because the HTTP-request that changes the certificate is sent via the victim’s browser (using the victim’s session

cookies).

  • Phase 3 – Access to resources. The attacker can then generate a token t for an arbitrary user and sign it with the key belonging

to evilCert generating s. Then, he sends (t,s) to the target service provider for verification. The target service provider will use the certificate stored in the AAM module and use this for the verification of s. Since the stored certificate is evilCert, the verification is successful and the attacker can log in with the chosen identity.

If the attacker is able to inject his own SSO configuration, the SP and the according SSO module will trust the attacker just as a regular trusted IdP. By this means, the attacker can generate valid tokens for any user on the SP and log into his account.

Mitigation / Countermeasures

Session Management should include a protection against CSRF (e.g. CSRF tokens, reasonable session timeout) to mitigate the attack.

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: SAManage, Shiftplanning, BambooHR, IdeaScale, Howlr 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).

File history

Click on a date/time to view the file as it appeared at that time.

Date/TimeThumbnailDimensionsUserComment
current15:27, 2 February 2016Thumbnail for version as of 15:27, 2 February 2016988 × 236 (63 KB)Anna (talk | contribs)
15:07, 2 February 2016Thumbnail for version as of 15:07, 2 February 2016988 × 236 (63 KB)Anna (talk | contribs)

The following page uses this file: