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. SAP BTP Destinations
  8. /
  9. Destination Service Abuse
Edit page

Destination Service Abuse

Description

The BTP Destination service stores connectivity configuration - target URL, authentication type (NoAuthentication, BasicAuthentication, OAuth2Password, OAuth2ClientCredentials, OAuth2SAMLBearerAssertion, Principal Propagation), proxy type (Internet/OnPremise) - consumed at runtime by apps, CAP services, SAP Integration Suite, and Launchpad. This page complements BTP Destinations with three concrete abuse chains: cleartext credential disclosure via the REST API, SSRF via a user-controlled destination target, and abuse of dynamic destination resolution / OAuth2SAMLBearer-typed destinations.

Risk

Cleartext credential disclosure hands an attacker both the pivot target and the working credential in one API call - bypassing the need to enumerate through Cloud Connector’s topology-hiding at all, since RFC-type destinations resolve directly to an on-prem ashost:sysnr. SSRF via a user-controlled destination target is a direct outbound-request primitive from BTP’s own IP space into on-prem/internal infrastructure.

Options

  • Cleartext credential disclosure (dual-call pattern): the list endpoint returns metadata only; the find endpoint returns User/Password (or clientId/clientSecret) in clear text for any credential-bearing authentication type, once the caller’s token carries destination_configuration.ApiAccess-class scope:
    GET https://<destination-service-host>/destination-configuration/v1/subaccountDestinations
GET https://<destination-service-host>/destination-configuration/v1/destinations/<name>
Authorization: Bearer <token>
    RFC-type destinations without a URL field store credentials/target in JCo-namespaced properties (jco.client.ashost, jco.client.sysnr, jco.client.user, jco.client.passwd) instead - synthesize <ashost>:33<sysnr> to get the same on-prem pivot target the HTTP-destination case gives directly.
  • Token acquisition for the above: any token classifiable as a destination-kind token by its aud/cid claims - most commonly a client_credentials mint from a Destination-service instance’s service key. See Service Key Abuse.
  • SSRF via user-controlled destination target: any feature letting user input influence a destination’s resolved host/URL is a direct outbound-request primitive from BTP’s IP space. Confirmed instance: CVE-2024-29415 (CVSS 9.1) - SAP Build Apps < 4.11.130 shipped a build toolchain depending on the Node ip package, whose isPublic() mis-categorizes alternate-encoding loopback/internal addresses (127.1, 012.1.2.3, 0:0:0:0:0:ffff:127.0.0.1) as public; submit these anywhere a Build Apps flow makes an outbound call based on user input.
  • Dynamic destination resolution (*.dest pattern): any destination flagged HTML5.DynamicDestination=true (plus WebIDEEnabled for Business Application Studio) resolves purely from a client-supplied hostname of the form http://<destinationName>.dest. Test whether destination names in the target subaccount are enumerable/predictable, and whether an app exposes this hostname pattern to client-controlled input - a positive on both could pivot to any dynamically-flagged destination on the subaccount, not just the one the app intends.
  • Technical User Propagation header: SAP-Connectivity-Technical-Authentication (Cloud Connector ≥ 2.15) carries a JWT representing the on-prem technical user, distinct from full interactive Principal Propagation. Check whether a downstream app trusts a client-supplied value of this header rather than generating it server-side, and whether Cloud Connector verifies the JWT actually originates from a legitimate BTP-side component.
  • Hardcoded high-privilege technical user in a destination: table-stakes finding once any destination-read access is obtained - pull the cleartext value per above and check the account’s actual on-prem privilege level.

Mitigation

  • Restrict which principals/service instances hold destination_configuration.ApiAccess/AccessClientSecrets-class scope; treat it as Tier-0 admin-equivalent.
  • Prefer Principal Propagation (X.509 mTLS via Cloud Connector) or short-lived OAuth2SAMLBearerAssertion over static BasicAuthentication/OAuth2Password/OAuth2ClientCredentials - these auth types never expose a reusable static secret through the find API.
  • Never let user input reach a destination’s target host/URL directly; validate against an allow-list before any outbound call.
  • Rebuild all SAP Build Apps applications on ≥ 4.11.130 (SAP Note 3477196).
  • Audit HTML5.DynamicDestination/WebIDEEnabled flags; least-privilege which destinations are reachable via .dest resolution.
  • Rotate any credential stored in a destination after suspected compromise of either the BTP subaccount or the on-prem target - the exposure is symmetric.

Detection and Monitoring

  • Destination-service audit log: a burst of GET /destinations/<name> find calls in rapid succession from a single token/client_id - a harvesting signature versus normal runtime behavior, which typically calls only its own one or two configured destinations.
  • Audit which principals hold ApiAccess/AccessClientSecrets-class scope at all; alert on any new grant, independent of usage.
  • Outbound request logs for alternate-encoding loopback/internal targets (127.1, octal/hex-encoded IPs) reaching internal services.

References