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. Cloud Foundry SSH Access
Edit page

Cloud Foundry SSH Access

Description

Cloud Foundry provides SSH access to application containers through the Diego SSH subsystem. This feature allows authenticated users to establish an interactive shell session or execute single commands inside a running application instance using the Cloud Foundry CLI (cf ssh) or the ssh command (a one time token would have to be generated).

An SSH session connects the user to a single application instance container, running with the same privileges as the application itself. The session does not provide host-level or root access, but it exposes the full runtime context of the application.

In SAP BTP Cloud Foundry environments, applications are frequently bound to platform services such as SAP HANA, XSUAA, destinations, or the Connectivity service. Credentials and tokens for these services are exposed to the application via environment variables and are therefore accessible during an SSH session.

Risk

By default, SSH access is enabled down to space level. If Cloud Foundry SSH access is enabled for an application, any user with write-level access to the space (for example, Space Developer) can SSH into that application. If such an user is compromised SSH access can be abused to:

  • Read application environment variables, including service credentials and secrets (VCAP_SERVICES)
  • Extract OAuth tokens, client secrets, or certificates from bound services
  • Inspect application source code and runtime configuration
  • Execute arbitrary commands as the application runtime user
  • Interact with internal-only network endpoints reachable by the application
  • Abuse destinations and the Connectivity service to pivot to on-premise or private backend systems

Because Cloud Foundry treats the space as the primary trust boundary, SSH access effectively grants full runtime visibility into all applications in that space where SSH is enabled. This can result in breaches of confidentiality and integrity of SAP and non-SAP backend systems.

Options

  • SSH must be explicitly enabled per application (cf enable-ssh <app> / cf disable-ssh <app>)
  • Space Developer permissions are required to enable SSH on an app
  • SSH access is enabled by default on space level (space-ssh-allowed to validate)

Mitigation

  • Disable SSH access on space level in production environments (cf disallow-space-ssh)
  • Disable SSH access for production applications unless explicitly required
  • Separate development, testing, and production into distinct spaces and subaccounts
  • Rotate service credentials and secrets if unauthorized SSH access is suspected
  • Avoid long-lived secrets in environment variables where possible
  • Monitor SSH enablement, disablement, and usage via SAP BTP audit logs and Cloud Foundry events

References