Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

SAP BTP Cockpit & Platform API Abuse

Description

SAP BTP Cockpit is the control-plane UI, but every action it performs is a call to a platform API that is equally reachable programmatically:

  • Cloud Management Service (CIS) Core Service APIs (Accounts, Entitlements, Provisioning, Events)
  • Service Manager (OSB) API (service instances/bindings)
  • per-subaccount XSUAA/trust APIs.

Role Collections, Trust Configuration, and every service instance across a subaccount are enumerable and mutable through both surfaces. An attacker who reaches subaccount-admin-equivalent access via any vector uses the API for fast, UI-review-invisible enumeration and durable configuration change - and where UI access is blocked but an API token is reachable (a leaked Cloud Management service key, a btp CLI session), the API is the only surface needed.

Risk

  • Role Collection tampering enables self-granting of broad scopes (for example XSUAA Token Abuse)
  • Trust Configuration tampering (adding a rogue IdP) is a durable SSO backdoor often overlooked in a standard role-collection/user-list audit (for example Identity Persistence)
  • Service Manager read access broader than a single CF space lets an attacker map every service instance/binding across the whole subaccount in one pass, ahead of targeted service-key minting (for example Service Key Abuse)
  • A leaked Cloud Management service key (plan central) is a standing, human-identity-independent control-plane credential - it survives the creator’s account being disabled and grants global-account/subaccount authority over accounts, entitlements, and provisioning.

Options

btp CLI - account hierarchy enumeration

The API-level equivalent of browsing Cockpit; works wherever a btp login session or Cloud Management credential is reachable:

btp login                                      # or reuse ~/.btp/config.json (cached, plaintext)
btp list accounts/global-account
btp list accounts/subaccount                   # every subaccount in the global account
btp list accounts/directory
btp --format json list security/role-collection --subaccount <SUBACCOUNT-ID>
btp list security/trust --subaccount <SUBACCOUNT-ID>
btp list services/instance --subaccount <SUBACCOUNT-ID>

Cloud Management (CIS) Core Service API - direct

With a Cloud Management service key (clientid/clientsecret, HTTP Basic), enumerate the whole hierarchy in one call, then pivot to entitlement/provisioning changes:

# mint a token from the service key's uaa.url, or Basic-auth directly:
curl -u "<clientid>:<clientsecret>" "https://accounts-service.cfapps.<region>.hana.ondemand.com/accounts/v1/subaccounts"
curl -H "Authorization: Bearer <token>" "https://entitlements-service.cfapps.<region>.hana.ondemand.com/entitlements/v1/subaccountServicePlans?subaccountGUID=<GUID>"

Minting the key itself is a Space-Developer-class action against a Cloud Management service instance - for example: Service Key Abuse.

Service Manager (OSB) API - cross-space instance/binding map

The platform API underlying all service-instance/binding management across a subaccount. A Service-Manager-scoped read token surfaces every instance across the whole subaccount in one call - faster reconnaissance than a per-space cf walk, and it sees instances in spaces the tester’s CF role does not:

curl -H "Authorization: Bearer <sm-token>" "https://service-manager.cfapps.<region>.hana.ondemand.com/v1/service_instances"
curl -H "Authorization: Bearer <sm-token>" "https://service-manager.cfapps.<region>.hana.ondemand.com/v1/service_bindings"

Role Collection review and self-escalation

Goto Security -> Role Collections per subaccount (or btp list security/role-collection); each collection aggregates roles built from role_template_app_id+role_template_name pairs (e.g. cis-local!b2 = Subaccount Admin) that can span multiple subscribed applications. Any principal able to write here can self-escalate - test whether the current identity can assign a Tier-0 collection to itself:

btp assign security/role-collection "Subaccount Administrator" \
  --to-user <you> --subaccount <SUBACCOUNT-ID>

Trust Configuration review

Goto Security -> Trust Configuration per subaccount (or btp list security/trust); enumerate every IdP entry and flag any non-default/unexpected addition - the rogue-IdP persistence primitive in Identity Persistence. Include this explicitly in every cockpit review; it is routinely skipped in favor of role-collection and user-list checks.

Mitigation

  • Apply least privilege to subaccount-admin and Role-Collection-write assignment. Log and alert on Role Collection and Trust Configuration changes.
  • Explicitly include Trust Configuration review in every cockpit-focused assessment, not just role collections and user lists.
  • Scope Service Manager-level read access narrowly. Prefer per-space Space Developer grants over subaccount-wide Service Manager access where the workflow allows it.
  • Prefer short-lived X.509 (mTLS) bindings over client-secret keys for Cloud Management inventory and rotate every Cloud Management key and restrict who can instantiate the service - treat a leaked one as tenant-admin-equivalent.
  • Scrub ~/.btp/config.json and ~/.cf/config.json caches from CI artifacts and shared machines - they hold reusable session tokens.

Detection and Monitoring

  • Audit Log: Role Collection assignment changes and Trust Configuration additions/modifications - see BTP Audit Log Blind Spots for the 90-day default-retention caveat that governs how long this evidence survives.
  • Cloud Management / Service Manager API access logs: high-volume cross-space instance/binding or account-hierarchy enumeration from a single principal with no corresponding legitimate automation identity.
  • Any Cloud Management (central plan) token use from an unexpected source IP or outside a known automation window.

References