Cloud Foundry

Description

SAP BTP Cloud Foundry (CF) is one of BTP’s application runtimes (alongside Kyma, ABAP Environment, and legacy Neo) - a managed, multi-tenant CF deployment whose authorization model differs from vanilla CF in ways that shape the whole engagement. This section index covers that platform and authorization surface - what roles exist, what a Space Developer can actually do, and which platform APIs and features are reachable. Container access is its own page in this section, and the concrete credential-use chains that follow from landing here live on their own pages, linked throughout:

Cloud Foundry Container Access - cf ssh, VCAP_SERVICES harvest, cf env, DB tunnels (the page in this section)
Service-key minting and Credential Store → Service Key & Credential Store Abuse
XSUAA token minting from harvested credentials → XSUAA Token & Authorization Abuse
Destination-service credential chain and on-prem pivot → Destination Service Abuse

Customers never hold CF platform admin. BTP customers get org/space roles only - never the platform admin/admin_read_only scope that vanilla CF operators use to change deployment-wide feature flags or application security groups. Several hardening levers a normal CF operator would reach for therefore do not exist for a BTP customer, which changes both what a tester can rely on and what a defender can fix.

Identity zone equals the subaccount. Each subaccount gets its own XSUAA tenant / identity zone (https://<subdomain>.authentication.<region>.hana.ondemand.com), and that boundary is the tenant-isolation boundary. A credential or token harvested in one subaccount does not cross into a sibling subaccount’s zone unless an explicit trust relationship extends it - assessment of lateral movement between subaccounts should focus on those trust extensions, not on the CF layer.

Risk

Space Developer is, in practice, the master key on SAP BTP CF. It is a routine developer/CI permission - the same role required just to deploy an app - yet it can:

Push, restage, and cf ssh into apps, and read every app’s environment regardless of SSH state
Bind and create services, and mint service keys against any instance in the space, including ones it did not provision
Register a space-scoped service broker
Read staged droplets via the Cloud Controller API

A tester who lands Space Developer in any space effectively owns every service credential reachable from that space. Because HANA Cloud exposes a direct DB connection over port 443 on the public internet by default, a single harvested service key is often enough for a working SQL session with no VPN or Cloud Connector involved.

Options

Space Developer capability enumeration

Confirm the role and map the space before touching credentials:

cf target                                     # org/space context
cf apps                                        # apps in the space
cf services                                    # service instances (mint targets)
cf curl /v3/apps                               # API-level app enumeration
cf curl /v3/service_instances                  # API-level instance enumeration
cf curl /v3/roles?user_guids=$(cf curl /v3/users | jq -r '.resources[0].guid')

VCAP_APPLICATION (from any container or cf env) yields the org/space GUIDs needed to drive /v3 API enumeration directly.

Reading app environments and credentials

The richest harvest - VCAP_SERVICES via cf ssh or, without SSH, via cf env / GET /v3/apps/:guid/env - is covered in full on Cloud Foundry Container Access. The key platform fact: the space_developer_env_var_visibility feature flag (default enabled) exposes this over the API independent of SSH, and customers cannot disable it.

Service-key minting across the space

Any Space Developer can mint a new service key against any existing instance in the space, including ones they did not provision - communal credentials by design:

cf create-service-key <INSTANCE-NAME> pentest-key
cf service-key <INSTANCE-NAME> pentest-key    # retrieve the credential set

This is the entry point to the whole credential-abuse surface; see Service Key & Credential Store Abuse for what each key type (HANA, Destination, XSUAA, Object Store, Cloud Management) unlocks.

`cf download-droplet` - offline secret-mining without a live session

cf download-droplet <APP-NAME> --path ./droplet.tgz
tar -xzf droplet.tgz -C ./droplet
grep -rE "(secret|key|password|clientsecret)" ./droplet

Pulls the staged filesystem that actually runs in the container - including anything baked in at build time (.profile.d scripts, vendored dependencies, accidentally-committed keys). This is a Cloud Controller API operation, not SSH - Space Developer is sufficient and no container access is needed.

Space-scoped custom service broker as a trust-abuse trap

A Space Developer can register a space-scoped custom service broker without CF-admin rights (unscoped broker registration does require admin and fails for a plain Space Developer):

cf create-service-broker <NAME> <USER> <PASS> <BROKER-URL> --space-scoped

This publishes arbitrary “services” into the space’s Marketplace; other developers who bind to them feed credentials and data through the malicious broker’s provisioning/binding callbacks.

Docker-image deploys

cf push --docker-image is supported on SAP BTP CF - a deviation from vanilla CF’s docker-off-by-default posture. It cannot combine with buildpacks, so automatic XSUAA/logging/monitoring instrumentation is lost and must be re-implemented manually. Relevant offensively as a way to run an attacker-controlled image inside the space, and defensively as an app that silently lacks the platform’s standard security wiring.

The `apps.internal` / C2C dead end

Native CF Container-to-Container (C2C) networking and internal-route (apps.internal) network policies are not supported on SAP BTP CF (community-reported 502s/permission errors on attempt; SAP KB 3200585). This saves tester time: do not chase internal-route-based SSRF or sibling-container lateral movement on BTP CF - it is a platform-level dead end by design, not a target-specific hardening. The realistic “internal network” boundary to attack is instead Cloud Connector, and the realistic attack against it is credential-based (the Destination-service chain), not network-scanning based.

Generic CF techniques - pointers only

Not shown to be meaningfully different on SAP BTP; consult directly if an engagement needs them:

runC container-escape CVEs (2025) - CVE-2025-31133, CVE-2025-52565, CVE-2025-52881 (procfs / /dev/console / LSM-bypass bind-mount tricks in the OCI runtime underlying garden-runC). See Sysdig writeup, opencontainers/runc advisory GHSA-qw9x-cqr3-wc7r. SAP as platform operator owns Diego-cell patch responsibility.
General CF container/network security model - garden-runC container security, App Security Groups, cell isolation: CF container security docs, App Security Groups docs (staging ASGs are typically more permissive than running ASGs and should explicitly exclude IaaS metadata endpoints 169.254.169.254).
UAA/OAuth session (cf login --sso) cookie/token-theft - generic SSO session-hijacking techniques, no BTP/XSUAA-specific twist beyond what the linked pages cover.
Kubernetes/pod-escape techniques relevant to BTP’s Kyma runtime - out of CF scope; see Kyma / Kubernetes: Customer-Reproducible Attack Surface.

Mitigation

Restrict Space Developer assignment and segregate sensitive service instances (HANA Cloud, Credential Store) into dedicated, narrow-membership spaces so create-service-key and broker-registration reach is contained.
Do not rely on disabling SSH as a credential control - space_developer_env_var_visibility exposes the same data over the API and customers cannot disable it. Minimize what is in VCAP instead (cert-based bindings, short-lived credentials).
Never bake secrets into build artifacts - this defeats cf download-droplet mining.
Review the space Marketplace for unexpected space-scoped brokers.
For docker-image apps, manually re-implement the XSUAA/logging/monitoring instrumentation buildpacks would have provided.
Don’t rely on internal routing / C2C assumptions either offensively or defensively on BTP CF - it isn’t there; the boundary to harden is Cloud Connector.

Detection and Monitoring

BTP Audit Log: cf create-service-key events, service-broker registration, and cf download-droplet events (if logged) - but see the platform blind spots below.
Audit-log blind spots specific to this platform:
- Direct HANA/PostgreSQL SQL access via a harvested service key is captured only by the database’s own audit mechanism - the BTP platform Audit Log shows nothing for data-plane traffic.
- Subaccount-level logs do not automatically roll up to a global-account-level central instance - an attacker operating entirely within one subaccount’s org/space generates evidence a global-account SOC view will not see without explicitly pulling that subaccount’s logs (SAP KB 3720222).
Monitor XSUAA token-issuance volume/source IPs for anomalies after any suspected VCAP leak.
See BTP Audit Log Blind Spots for the full retention and coverage picture; container- and DB-plane detection detail lives on Cloud Foundry Container Access.