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. SAP Cloud Connector Admin Access & Keystore/SSFS Extraction
Edit page

SAP Cloud Connector Admin Access & Keystore/SSFS Extraction

Description

The SAP Cloud Connector (SCC) is the on-prem <> SAP BTP bridge: it holds a persistent reverse-invoke TLS tunnel to a subaccount and forwards cloud requests to internal back-end systems. Its own configuration is therefore crown-jewels material - compromising an SCC yields the client certificate/private key BTP uses to authenticate the connector, the full back-end reachability map, local admin user hashes, and (when Principal Propagation is configured) the CA private key that mints forwarded on-prem identities.

The admin UI (Tomcat, default port 8443) is form-authenticated: GET a protected URL to seed a JSESSIONID, then POST /j_security_check with j_username/j_password. Once authenticated, /api/* returns JSON, including a config-backup endpoint that packages every keystore SCC uses plus its own Secure Storage in the File System (SSFS) - the same obfuscation-only mechanism ABAP systems use for RSECTAB, reused here to protect CLOUD_CONN/JAVA_KEYSTORE_PASSWORD and other .p12 unlock secrets.

Risk

An attacker who obtains SCC admin access (default credentials, credential reuse, or a captured session) can pull a full configuration backup and recover: the per-subaccount tunnel client certificate/private key (impersonate the connector to BTP), the system-identity keystore, the Principal Propagation CA private key when PP is configured (forge forwarded on-prem identities - see Principal Propagation Abuse), local SCC user password hashes, and the full Cloud-To-On-Premise mapping table (every internal back-end the connector is configured to expose). All of this uses SCC’s own documented, legitimate admin API - the attack is authenticated abuse of intended functionality, not an exploit. Reproducible end-to-end against a customer-operated SCC; no SAP-managed infrastructure involved.

Options

  • Authenticate - POST /j_security_check (j_username/j_password) after seeding a session with a GET to a protected URL. Default credential Administrator / manage is worth one check (the 2.15+ installer forces a change on first login, so live defaults are increasingly rare but still found on un-hardened/older installs).
  • Enumerate topology - authenticated read APIs return versions, configured subaccounts, and the Cloud-To-On-Premise mapping list before any backup is pulled.
  • Pull the config backup:
    POST /api/v1/configuration/backup
    with a caller-supplied passphrase, returning a zip containing:
    • config/ks.p12 - admin UI keystore
    • scc_config/scc.p12 - system-identity keystore
    • scc_config/<region>/<subaccount>/scc.p12 - per-subaccount tunnel client cert + private key (authenticates the SCC to BTP)
    • SSFS_SCC.KEY / SSFS_SCC.DAT - SAP Secure Storage (holds CLOUD_CONN/JAVA_KEYSTORE_PASSWORD, and the Principal Propagation CA private key when PP is configured)
    • config/users.xml - local SCC users + hashed passwords
  • Decrypt SSFS (redrays-io/SAP_Cloud_Connector_SSFS_Decryption): calls the exported getRecord() symbol inside SAP’s own libsapscc20jni.{so,dll,dylib} - decrypts without reversing the cipher, using SAP’s genuine vendor code:
    make                                        # builds decrypt-ssfs.jar once
export SAPSYSTEMNAME=SCC
export RSEC_SSFS_DATAPATH=/path/to/dir/holding/SSFS_SCC.{KEY,DAT}
java -Dscc.jni.lib=/opt/sap/scc/lib/libsapscc20jni.so -jar decrypt-ssfs.jar
    yields single-line JSON: {"CLOUD_CONN/JAVA_KEYSTORE_PASSWORD": "...", "SYSTEM_CERTIFICATE": "...", "PROXY_PASSWORD": "...", ...}.
  • Pure-Python fallback (no JDK/native library needed) - reuses the same RSECCipher primitive documented for ABAP RSECTAB/SSFS (see Secure Store Decryption): unwrap the 57-byte DEK at offset 0x82 of SSFS_SCC.KEY, then decrypt each RSecSSFsData-prefixed record in SSFS_SCC.DAT starting at offset 0xB0. Works entirely offline once the two files are exfiltrated - via the REST backup or via direct OS-level filesystem read of a co-located SCC install’s scc_config/ directory.
  • Unlock the .p12 keystores with the recovered JAVA_KEYSTORE_PASSWORD: openssl pkcs12 -in scc.p12 or any standard PKCS12 parser.
Warning
SCC’s own POST /api/v1/configuration/backup endpoint applies a second, SAP-proprietary wrapping layer over every .p12 in the produced zip, sealed with the backup password from the POST call - not JAVA_KEYSTORE_PASSWORD. A standard PKCS12 parser will reject these blobs (non-0x30 DER header) regardless of how correct the recovered keystore password is. To get genuine, unwrappable .p12 files, obtain filesystem access to the SCC install directory itself (scc_config/scc.p12, config/ks.p12, per-subaccount scc.p12) rather than the REST backup.
  • Post-RCE co-located discovery - from an already-pwned ABAP/Java node, OS-command bundles locate SCC presence on the same host, neighbouring SCCs, SSH keys, and known_hosts entries - a route into an SCC’s install directory that bypasses the admin API and its double-wrapping entirely.

Mitigation

  • Change the default Administrator/manage password (2.15+ enforces this on first login); restrict admin UI (8443) to a dedicated management network/VPN; enforce MFA where available.
  • Treat the config-backup function as a high-sensitivity action: protect and monitor it, require a strong unique passphrase per export, and store backups securely - they contain private keys.
  • Restrict OS-level filesystem access to the SCC install directory to the SCC service account only.
  • Keep SCC patched (see Known CVEs); rotate the tunnel key, PP CA key, and CLOUD_CONN/JAVA_KEYSTORE_PASSWORD after any suspected exposure of an SCC configuration backup or host.

Detection and Monitoring

  • SCC’s own audit/access logging: config-backup events, admin logons (especially Administrator from unusual sources), and default-credential logon success.
  • Network: POST /api/v1/configuration/backup from a non-admin workstation; repeated /j_security_check failures (credential spray).
  • Host: OS-level file access to scc_config//SSFS_SCC.{KEY,DAT}/.p12 files by any account other than the SCC service account - host-level file-access auditing/EDR.
  • Once SSFS/backup files are exfiltrated, both decrypt paths run entirely offline on the attacker’s own host - there is no further target-side telemetry at that point; detection must happen at acquisition time.

References