Overview

Prowler, a popular security auditing tool, recently disclosed a critical vulnerability in its SAML authentication flow. This flaw enables a malicious tenant with a controlled SAML IdP to complete a valid SAML flow for its own configured domain while asserting an email address from another configured domain, potentially leading to cross-tenant account takeover.

Understanding the Vulnerability / Threat

Root Cause Analysis

The confirmed root cause lies in the SAML ACS finish and token issuance flow. The flow selects a SAML configuration through the ACS route but later recalculates the tenant from the asserted user email domain. This is unsafe because the `user.email` is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain. The attack is made possible by several compounding weaknesses: 1. **No domain ownership proof**: `SAMLConfiguration.email_domain` is validated for format and global uniqueness but not for domain ownership. 2. **Global SAML domain index**: Maps each configured domain to its tenant. 3. **Hardcoded auto-connect**: `SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True`. 4. **IdP-initiated SSO enabled**: `reject_idp_initiated_sso: False`. 5. **Token issuance for the wrong tenant**: The vulnerable ACS finish flow could create membership and issue a `SAMLToken` using a tenant derived from the asserted email domain. 6. **Token switch impact**: The token switch endpoint checks that the authenticated user is a member of the target tenant. This vulnerability belongs to the CWE-287 category, Improper Authentication.

Attack Surface & Vector

The vulnerability lives in the SAML authentication flow of Prowler, specifically in the ACS finish logic and token issuance. An attacker needs to have a controlled SAML IdP and a valid SAML configuration for their own domain. The attack vector involves crafting a SAMLResponse that asserts an email address from a victim's configured domain.

Exploitation Mechanics — Scenario Walkthrough

Scenario: Compromising a Corporate Prowler Instance 1. Initial Position: The attacker has a controlled SAML IdP and a valid Prowler account. 2. Triggering the Flaw: The attacker crafts a SAMLResponse asserting a victim's email address and posts it to the Prowler ACS endpoint. 3. What Breaks: The vulnerable ACS finish logic derives the tenant from the asserted email domain instead of the validated SAML configuration, potentially issuing a token for the wrong tenant. 4. Attacker's Prize: The attacker can obtain a JWT token for the victim user, allowing them to access the victim's cloud security audit findings and switch into tenants where the victim is a member.

Real-World Impact

The vulnerability can lead to full read/write access to a victim's cloud security audit findings, enumeration and modification of compliance findings and integration secrets, lateral movement into additional tenants, and possible persistent access.

Detection & Defense

Immediate Mitigations

- Upgrade Prowler to the patched version. - Configure `SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = False`. - Set `reject_idp_initiated_sso: True`.

Detection Strategies

- Monitor for suspicious SAML authentication attempts. - Implement additional logging and SIEM rules to detect potential exploitation.

Long-Term Hardening

- Implement proper domain ownership verification for SAML configurations. - Enhance authentication and authorization controls. - Regularly review and update security configurations.

Key Takeaways

- Understand the criticality of proper authentication and authorization in SAML flows. - Regularly review and update security configurations. - Implement additional security measures to prevent tenant takeover.