Certificate Injection: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
=Introduction= | =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= | =Attack subtypes= | ||
Line 14: | Line 15: | ||
=Description= | =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= | =Mitigation / Countermeasures= | ||
Session Management | Session Management should include a protection against CSRF (e.g. No-Script) to mitigate the attack. | ||
=Practical Examples= | =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: | 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. | 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= | =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). | 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 17:27, 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
The attacked Single Sign-On component is marked in red colour.
The attack uses the 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).
- Attack Categorisation By Attacker Model: Web Attacker
- Attack Categorisation By Violated Security Objective Access Control
- Attack Categorisation By Attack on IdP/ SP: Attack on SP
- Attack Categorisation By Attacked Single Sign-On Component: Session Managment
- Attack Categorisation By Attack Spreading:Application Specific Flaws
- Attack Categorisation By Attack on SAML