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
  2. /
  3. SAP Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Service Key & Credential Store Abuse
Edit page

Service Key & Credential Store Abuse

Description

A BTP “service key” is a standing JSON credential document bound to a service instance, one of three shapes: an OAuth clientid/clientsecret pair, a database user/password, or hyperscaler credentials (e.g. an S3 access key for Object Store). Any principal holding the Cloud Foundry Space Developer role - the same role required just to deploy an app, and a routine developer/CI-pipeline permission - can run cf create-service-key against any service instance in that space, minting fresh standing credentials for every instance present: Destination service, Credential Store, HANA Cloud, Object Store, XSUAA, and more. The same credential concept exists on Kyma as a ServiceBinding CR whose Secret the BTP Operator writes into the cluster (see Options); this page is CF-first but the abuse chains apply to whichever runtime the target uses.

Risk

  • HANA Cloud service key -> raw SQL access, bypassing whatever authorization logic the application layer (CAP, UI5 backend) implements on top of it.
  • Destination/Connectivity/XSUAA service key -> chains directly into Destination Service Abuse and XSUAA Token Abuse.
  • Object Store service key -> native hyperscaler bucket credentials, inheriting the full classic cloud-storage misconfiguration risk class on top of BTP’s own access controls.
  • Credential Store proxy-plan sharing -> SAP’s own documentation cautions that reused client credentials across subscribers can let one customer access another’s data if the subaccount domain is known.
  • Cloud Management Service key (plan central) -> the BTP Core Service APIs (Accounts, Entitlements, Provisioning, Events): a clientid/clientsecret pair (HTTP Basic) with global-account / subaccount control-plane authority, not tied to a human identity and surviving the creator’s own account being disabled - a portable, standing tenant-admin API credential if it leaks (CI logs, cf env, git).
  • Service keys are not frequently rotated in practice - a leaked key remains valid long-term.
  • cf/btp CLI local config caches store OAuth refresh tokens in plaintext - any filesystem/endpoint compromise on a machine with an active login session yields a live BTP session without needing the password.

Options

  • Enumerate and mint against every service instance reachable as Space Developer, prioritizing names matching destination/connectivity/xsuaa/credstore/hana:
    cf create-service-key <service-instance> <key-name>
cf service-key <service-instance> <key-name>
  • Fast cross-space reconnaissance before minting: cf curl /v3/service_instances, or a Service-Manager-scoped read token - see BTP Cockpit & Platform API Abuse - enumerates every service instance/binding across the whole subaccount in one pass, flagging priority targets before a per-space cf walk.
  • Alternative binding recovery: GET /v3/service_credential_bindings.
  • On Kyma, the same credential surface is a ServiceBinding CR, not a cf service key. The SAP BTP Operator (btp-manager) provisions each ServiceInstance/ServiceBinding and writes the resulting credentials to a Kubernetes Secret; anyone who can create a ServiceBinding (or read the Secret it produces) obtains the identical HANA/Destination/XSUAA/Object-Store credential set that cf create-service-key yields on Cloud Foundry:
    kubectl get servicebindings -A
kubectl get secret <binding-secret> -n <ns> -o jsonpath='{.data}' | jq
    The btp-operator’s own namespace-mapping Secret is itself a standalone Service Manager API credential - see Kyma BTP Operator → Service Manager Escape. Kyma has no VCAP_SERVICES aggregation point, so also search pod filesystems (find / -path '*/secrets/sapcp/*') per Kyma / Kubernetes.
  • Cloud Management Service control-plane key -> Core Service APIs with Basic auth; e.g. enumerate the whole account hierarchy in one call, then pivot to entitlement/provisioning changes:
    curl -u "<clientid>:<clientsecret>" \
  "https://accounts-service.cfapps.<region>.hana.ondemand.com/accounts/v1/subaccounts"
    Prefer short-lived X.509 (mTLS) service bindings over client-secret keys for this service; inventory and rotate every Cloud Management key, and restrict who can instantiate the service to a locked-down space.
  • HANA Cloud service key -> direct SQL: connect with the embedded DB user/password, bypassing CAP/UI5 application-layer authorization entirely.
  • Object Store service key -> native hyperscaler bucket credentials (AWS S3 / Azure Blob / GCS); apply the standard cloud-storage misconfiguration checklist (bucket-policy scope, encryption-at-rest, credential scope beyond the single bucket).
  • Credential Store proxy-plan: if the same client credentials are shared across subscribers and another customer’s subaccount domain is known, the shared credentials plus that domain’s token URL are SAP’s own documented cross-tenant risk pattern - worth probing in multi-tenant SaaS-on-BTP assessments.
  • Local token theft: ~/.cf/config.json and equivalent btp CLI config caches on any developer/CI machine with an active login session.

Mitigation

  • Restrict Space Developer role assignment; use Service Manager API-level restrictions or CF space quotas/policies to limit which service plans can have keys created.
  • Rotate service keys on a schedule; monitor cf create-service-key events in the audit log.
  • Minimize DB-user privilege embedded in HANA Cloud service keys relative to what the calling application actually needs (cross-schema access in particular).
  • Enforce least-privilege bucket policies on Object Store instances; scope credentials to the single bucket in use.
  • Do not share static client credentials across Credential Store proxy-plan subscribers without per-subscriber isolation.
  • Treat .cf/config.json/btp CLI caches as credential material - scrub from CI artifacts, shared images, and developer machine backups.

Detection and Monitoring

  • Audit log: cf create-service-key / service-key-creation events, especially against destination/connectivity/xsuaa/credstore/hana-named instances.
  • CF API access logs: high-volume paginated /v3/organizations//v3/spaces//v3/apps//v3/service_instances enumeration from a token with no corresponding CI/CD or monitoring-tool identity.
  • Any DB logon under a HANA Cloud service-key user with no prior interactive-logon history.

References