prowler-cloud vulnerabilities and threats

Prowler is a cloud security platform. Prior to 5.33.1, an authenticated user with Lighthouse provider configuration access could supply an unvalidated base_url for the openai_compatible provider through POST /api/v1/lighthouse/providers and POST /api/v1/lighthouse/providers/{id}/connection, causing api/src/backend/tasks/jobs/lighthouse_providers.py to send outbound requests, including the API key in the Authorization header, to attacker-controlled or internal endpoints when client.models.list was called. This issue is fixed in version 5.33.1.

Prowler is a cloud security platform. Prior to 5.36.0, the Kubernetes provider connection test accepted kubeconfig_content containing a legacy gcp auth-provider with config.cmd-path and config.cmd-args because kubeconfig_contains_exec_auth in api/src/backend/api/v1/serializers.py checked only exec blocks, and POST /api/v1/providers/{id}/connection loaded it through config.load_kube_config_from_dict in prowler/providers/kubernetes/kubernetes_provider.py, causing kubernetes-python CommandTokenSource.token to run the attacker-supplied command through subprocess.Popen on the shared worker. This issue is fixed in version 5.36.0.

Prowler is a cloud security platform. Prior to 5.37.0, Prowler's HTML output formatter in prowler/lib/outputs/html/html.py inserted finding.resource_tags, assembled by unroll_dict and parse_html_string, into generated reports without HTML escaping, allowing a cloud principal who can modify a scanned resource tag to store HTML or JavaScript that executes when another user opens the report. This issue is fixed in version 5.37.0.

## SAML Tenant Binding Enables Cross-Tenant Account Takeover ### Summary Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain. In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant. The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because `SAMLConfiguration.email_domain` and `SAMLDomainIndex.email_domain` are globally unique. ### Details The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain: ```python email_domain = user.email.split("@")[-1] tenant = ( SAMLConfiguration.objects.using(MainRouter.admin_db) .get(email_domain=email_domain) .tenant ) ``` This is unsafe because `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** (`api/src/backend/api/models.py:2100, 2130-2152`): `SAMLConfiguration.email_domain` is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant. 2. **Global SAML domain index** (`api/src/backend/api/models.py:2200-2201`): `SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant})` maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route. 3. **Hardcoded auto-connect** (`api/src/backend/config/settings/social_login.py:23, 25`): `SOCIALACCOUNT_EMAIL_AUTHENTICATION = True` and `SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True` are hardcoded and cannot be disabled at runtime. 4. **IdP-initiated SSO enabled** (`api/src/backend/config/settings/social_login.py:78`): `reject_idp_initiated_sso: False` allows the attacker to initiate the flow without requiring any action from the victim. 5. **Token issuance for the wrong tenant** (`api/src/backend/api/v1/views.py:853-873`): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a `SAMLToken` using a tenant derived from the asserted email domain instead of the validated SAML configuration. 6. **Token switch impact** (`api/src/backend/api/v1/serializers.py:272`): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member. ### PoC **Environment setup:** ```bash # Build the PoC Docker image (build context = repo root) docker build -t vuln001-poc -f vuln-001/Dockerfile . # Start the stack (PostgreSQL + PoC runner) docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit ``` **Automated test (runs inside the container):** ```bash python -m pytest poc_vuln001.py -v -s --no-header --tb=short ``` **Manual HTTP exploitation chain (against a live Prowler API):** **Step 1 - Attacker configures SAML for their own email domain:** ```bash curl -i -X POST "$API/api/v1/saml-config" \ -H "Authorization: Bearer $ATTACKER_TOKEN" \ -H "Content-Type: application/vnd.api+json" \ --data '{ "data":{"type":"saml-configurations","attributes":{ "email_domain":"attacker.com", "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>" }} }' ``` The attacker does not need to claim `victim.com`. If `victim.com` is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique. **Step 2 - Attacker posts a signed SAMLResponse asserting `user@victim.com`:** ```bash # SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key, # valid for the attacker's configured IdP, but asserting NameID = user@victim.com curl -i -L -c c.jar -b c.jar \ -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \ --data-urlencode "SAMLResponse=$SIGNED_ASSERTION" ``` **Step 3 - Vulnerable ACS finish logic derives