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. Other SAP Solutions
  4. /
  5. SAP Cloud Connector
  6. /
  7. Cloud Connector: Fail-Open Config, Wildcard ACLs & Audit Blind Spots
Edit page

Cloud Connector: Fail-Open Config, Wildcard ACLs & Audit Blind Spots

Description

The SAP Cloud Connector (SCC) is the on-prem agent that bridges a BTP subaccount to backend systems. Its security model is a set of allowlists - which backends it trusts, which resources (URL paths / RFC function modules) it exposes, and which BTP applications may use the tunnel. The recurring problem is that several of these controls default open or fail open, and its default audit level does not record successful access. This page covers SCC’s configuration and ACL weaknesses; identity-side abuse of the tunnel is covered in Principal Propagation Abuse, and its keystore/credential exposure in Admin & Keystore Extraction.

Because a compromised or over-permissive SCC turns any reachable BTP app into a path onto the internal network, its configuration is a high-value audit target.

Risk

An SCC with a fail-open trust store, a wildcard resource ACL, or an empty application allowlist exposes the internal network far beyond what the operator intends - at the extreme, the entire ICF surface of an S/4HANA system to any application in the subaccount, with no audit trail of the successful accesses. Whoever controls the SCC admin UI can add backends and resources at will, reaching every mapped on-prem system. The impact is unauthorized internal-network reach, credential/data exposure at the backend, and - chained with a gateway or message-server weakness - remote code execution on-prem.

Options

Most of the following are configuration/architecture findings a tester assesses with SCC admin/read access or an exported configuration; where a live pivot is possible it is noted.

  • Backend trust store fail-open: for HTTPS backends, SCC validates the backend certificate against a Backend Trust Store allowlist only if “Determining Trust Through Allowlist” is set to ON. If it is off, all backend systems are automatically trusted - SCC will establish TLS to any backend presenting any certificate, with no pinning, enabling a rogue/MITM or repointed virtual host to be trusted silently. Check the toggle.
  • Wildcard resource ACL - “Path and all sub-paths” on /, RFC “Prefix”: SCC’s core control is per-backend resource allowlisting, but the “Path and all sub-paths” access policy behaves as a wildcard: a URL path of / with sub-paths enabled lets the Cloud Connector reach every ICF path on the backend. The RFC “Prefix” naming policy is likewise a wildcard over function-module names. One such entry exposes the whole ICF tree (/sap/bc/soap/rfc, admin services) or a whole RFC namespace. Enumerate each backend’s resources and flag any /+sub-paths or short-prefix RFC entry; where a destination routes through such a mapping, reachability beyond the intended app is testable.
  • Empty application allowlist = every app tunnels; HTML5 is all-or-nothing: the per-subaccount trusted-applications list is empty by default, which means every application and service in the subaccount is allowed to use the Cloud Connector; allowlisting only activates after the first entry is added. HTML5 apps cannot be whitelisted individually - allowlisting services:dispatcher grants every HTML5 application in the subaccount access to the Cloud Connector. Any deployed or compromised app / HTML5 module in a subaccount with an empty or dispatcher-based allowlist inherits on-prem reachability. Check the allowlist state per connected subaccount.
  • Audit level “Security” (default) does not log allowed requests: SCC has three audit levels - Security (default) logs configuration changes and denied runtime requests only; All additionally logs every allowed backend request; Off logs nothing. At the default, a valid-but-malicious access through an over-broad ACL produces no audit entry. The live traffic monitor is also capped at the 50 most-recent requests and is resettable. Demonstrate that a successful tunnel call leaves no trace at the Security level.
  • Admin UI defaults: initial SCC logon is Administrator / manage (must be changed on first login, but often the only barrier), default SSL port 8443, shipped with a self-signed certificate. Default “password” authentication mode uses one shared admin credential regardless of how many admins; switching to LDAP mode gives each admin a unique identity for audit. SCC should never be reachable from the internet. Verify: 8443 exposure/network zone, CA-signed UI cert, LDAP auth mode, that the default password was changed. Whoever controls the UI can add backends/resources and reach all mapped systems.
  • HA “No shadow host restrictions” default: enabling high availability defaults to no shadow-host restriction; when paired, the master instance supplies the shadow with the complete configuration (backend maps, trust, resources) and the shadow can take over on master failure. A rogue shadow that reaches the master’s HA port and pairs receives the entire configuration. Separately, a cockpit admin can Force Disconnect a connector (disrupt, or make room for a rogue one). Check whether an explicit shadow-host restriction is set. The rogue-shadow attack itself requires network reach to the HA port.
  • Monitoring APIs behind Basic auth; subaccount logon data on disk: SCC’s monitoring APIs (/api/v1/configuration/) authenticate via HTTP Basic / form auth (roles sccmonitoring / sccadmin) - weak if reachable with weak/shared passwords. SCC uses no backing database - it stores its configuration, including subaccount logon data, on the local filesystem; encrypting that filesystem prevents misuse of the stored logon data for authenticating to the BTP subaccount. Host compromise or backup theft therefore yields the subaccount credentials, which can re-pair a connector or access the subaccount. Audit: filesystem encryption, monitoring-API credential strength/scope, whether sccmonitoring/sccadmin accounts are shared.

Mitigation

  • Set “Determining Trust Through Allowlist” = ON and populate the Backend Trust Store with only the intended backend certificates.
  • Replace /+sub-paths and RFC prefixes with least-privilege exact paths / exact function-module names; review every backend’s resource list.
  • Populate the per-subaccount application allowlist; treat multi-tenant subaccounts as high-risk because HTML5 scoping is all-or-nothing (via services:dispatcher).
  • Raise the audit level to All for sensitive backends (accepting the volume) and export SCC audit + traffic logs to a SIEM.
  • Change the default admin password immediately; import a CA-signed UI certificate; switch to LDAP authentication mode (named admins); restrict port 8443 to admin networks; run SCC in a controlled zone, never internet-reachable.
  • Set an explicit shadow-host restriction; segment the HA replication path; protect cockpit admin roles (the Force-Disconnect capability).
  • Encrypt the SCC host filesystem and secure backups; give the monitoring APIs strong, scoped, non-shared credentials and keep the endpoint off untrusted networks.

Detection and Monitoring

  • SCC Security Status view: backend allowlist flag, resource-policy breadth, application allowlist state, UI certificate, authentication mode.
  • SCC audit log for configuration-change entries; alert on new backend/resource additions and on trust-toggle changes.
  • Network scanning for exposed port 8443; alert on any internet reachability.
  • Watch the HA view for unexpected shadow connections; alert on cockpit Force Disconnect events.
  • Because the default audit level misses allowed requests, raise it to All on sensitive backends so successful tunnel access is actually recorded - see also BTP Audit Blind Spots.

References