Difference between revisions of "Certificate Injection"

From Single Sign-On Attacks
Jump to: navigation, search
(Target)
(Description)
Line 18: Line 18:
 
*'''Phase 1 – Preparation.''' The attacker creates his private key '''evilKey''' and a corresponding public key and uses these to create a certificate
 
*'''Phase 1 – Preparation.''' The attacker creates his private key '''evilKey''' and a corresponding public key and uses these to create a certificate
 
'''evilCert'''.
 
'''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
+
*'''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).
 
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
 
*'''Phase 3 – Access to resources.''' The attacker can then generate a token '''t''' for an arbitrary user and sign it with the key belonging
Line 25: Line 25:
 
If the attacker is able to inject his own SSO configuration, the '''SP''' and the according SSO module will trust the attacker
 
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.
 
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=
 
=Mitigation / Countermeasures=

Revision as of 17:38, 2 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

Target

Target Session Managment.jpg

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

The attack uses the Cross-site request forgery(CSRF) technique to enforce the victim to change 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. No-Script) 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).