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.
There are no attack subtypes for this attack.
- 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).
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.
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
- 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 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.
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.
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).