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 ABAP Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Trusted-RFC Impersonation and Callback Abuse
Edit page

Trusted-RFC Impersonation and Callback Abuse

Description

Two related RFC trust mechanisms let a caller skip normal authentication or borrow another user’s session - both are legitimate SAP features, and both are common misconfiguration targets distinct from the message-server-based 10KBLAZE attack chain (see RFC Gateway / 10KBLAZE):

  • Trusted RFC (configured in SM59/SMT1/SMT2) lets a “trusted” system call a “trusting” system without a password - the trusting side authenticates the connection itself, then authorizes the specific dialog user the trusted side asserts, via authorization object S_RFCACL. S_RFCACL has fields RFC_SYSID, RFC_CLIENT, RFC_USER, RFC_EQUSER, RFC_TCODE, and ACTVT (only 16/execute is valid). The critical field pair is RFC_EQUSER/RFC_USER: if RFC_EQUSER = N (or *) and RFC_USER = *, the trusting system will execute the call as any user the trusted-side caller names - a caller who is only MEIER on the trusted system can assert SCHMIDT (or a SAP_ALL admin ID) on the trusting system with zero further checks.
  • RFC callback lets a function module running on the server side of a synchronous RFC call use the already-open connection to call back into the client, executing a function module there under the identity of the user who initiated the original call. If the client trusts the server (e.g. the server is attacker-controlled or attacker-modified), the callback lets the server-side code run arbitrary RFC-enabled function modules with the client-side caller’s authorizations - including highly privileged administrative sessions.

Enumerate the whole RFC-trust landscape from either side with transaction RSRFCCHK, which lists every configured destination, flags which ones carry a stored password, and shows encryption status in one view (clearer than paging through SM59 connection by connection).

Risk

A misconfigured S_RFCACL (RFC_EQUSER=N/* + RFC_USER=*) turns any authenticated foothold on a trusted system into full impersonation of any user - commonly an admin ID - on every system that trusts it, with no password required and no additional exploit. Because trusted-RFC relationships frequently connect systems of different sensitivity (a lightly-secured development or Solution Manager system trusted by production), this is a textbook pivoting primitive. RFC callback abuse similarly lets a compromised or attacker-operated RFC server reach back into every client that calls it, executing code under the calling user’s privileges - a serious risk whenever the client cannot fully control or trust the server side of the connection. Both attacks require no vulnerability, only the (common) absence of the specific hardening described below.

Options

  • Recon - enumerate all configured destinations and their trust/credential posture with RSRFCCHK; in SM59, check the Logon & Security tab of each ABAP connection for Trusted System = Yes, and cross-check SMT1 (trusted-system definitions) / SMT2 (trusting-system view) for which systems trust which.
  • Trusted-RFC impersonation - from an authenticated session on the trusted system, call any RFC-enabled function module against the trusting destination while asserting a target user (e.g. via a custom RFC client using pyrfc/pysap, or SE37 test-call using a trusted connection). If the trusting system’s S_RFCACL grants RFC_EQUSER=N/* with RFC_USER=* to the calling system/client, the call executes as the asserted user with no password - check for SAP_ALL/admin IDs as easy high-value targets to assert.
  • RFC callback abuse - stand up an RFC server (SDK/pyrfc) that, when called by a victim client, issues a synchronous callback (CALL FUNCTION <func> DESTINATION 'BACK') to execute an attacker-chosen RFC-enabled function module on the calling client, inheriting the calling user’s session and S_RFC authorizations. Works whenever rfc/callback_security_method is at its pre-hardening default (1, compatibility mode - permits all callbacks not explicitly blocked) rather than 3 (allowlist enforced).
  • Passwordless trusted-destination creation - a trusted RFC destination can be created without SM59 or S_RFC_ADM: RFC_MODIFY_R3_DESTINATION (reachable via RS_TESTFRAME_CALL, no SE37 required) with a blank AUTHORITY_CHECK, TRUSTED_SYSTEM = X, and a blank password builds a password-less trusted connection to any system that already trusts the current one (enumerate candidates via SMT1/RFCTRUST). This turns a foothold on a trusted system into an on-demand trusted pivot without touching the destination-maintenance authorizations that are normally watched.
  • Trusted-ticket replay (shared key) - on unpatched kernels, the trusted-system identification key (extkey) is identical across all of a system’s trust relationships and is stored in RFCSYSACL, and the trusted ticket is sent on every outbound conversation regardless of trust; a captured ticket/key can be replayed against other systems that trust the same source (CVE-2023-0014, capture-replay; the related CVE-2021-27610 forges the internal-communication ticket for an internal-state auth bypass). Both stem from the server being unable to distinguish internal/trusted from external/untrusted partners when initiating a connection. Check kernel patch level for these before assuming trusted RFC is sound.
  • Anonymous recon primitives - a handful of RFC-enabled function modules answer without any authorization check and are useful for landscape mapping before attempting the above: RFC_PING, RFC_SYSTEM_INFO, RFC_GET_DOCU, RFC_TRUSTED_SYSTEM_SECURITY, RFC_SET_REG_SERVER_PROPERTY, RFC_START_GUI, SYSTEM_CREATE_INSTANCE, RFC_START_PROGRAM.
  • Combine with Critical RFC-enabled function modules once impersonation succeeds - the newly-asserted identity’s S_RFC scope determines what’s reachable next.

Mitigation

  • Treat S_RFCACL as critical: never grant RFC_USER = * together with RFC_EQUSER = N/*; where possible leave RFC_USER blank so the trusted connection can only be used by the specific system RFC user it was created for.
  • Only establish Trusted RFC between systems of the same or higher security classification as the trusting side; never trust a development/QA/Solution Manager system from a production system.
  • Set rfc/selftrust = 0 - self-trust is enabled by default (1), letting a system trust itself across clients without explicit SMT1 setup; create explicit trust only where required.
  • Patch the trusted-ticket capture-replay family (SAP Notes 3007182 for CVE-2021-27610 and 3089413 for CVE-2023-0014, applied on both trusting and trusted systems), migrate the trust relationships per SAP Note 3157268, and set rfc/allowoldticket4tt = no once the whole landscape is migrated so legacy (insecure) trusted tickets are no longer accepted on either side. = client is the interim value while only a single system has been migrated.
  • Protect RFCSYSACL with authorization group TTRL (SAP Note 1562697) so the stored trust/key data is not broadly table-readable.
  • Prefer conventional (password-authenticated) RFC connections over Trusted RFC wherever the operational requirement doesn’t specifically demand password-less trust.
  • Configure RFC callback allowlists: enable Security Audit Log class RFC function call for message ID DUK (SM19), set rfc/callback_security_method = 2 (simulation/logging mode) for a representative period (at least three months, to capture periodic jobs), populate the per-destination positive lists in SM59 from the logged callbacks (manually or via the automatic-population menu action), then raise rfc/callback_security_method to 3 (allowlist enforced) per SAP Note 1686632.
  • Restrict S_RFC_ADM (RFC destination maintenance via SM59) to Basis administrators; assign ownership/documentation responsibility to every RFC destination and remove unused ones.
  • Ensure auth/rfc_authority_check is set to enforce S_RFC checking on every system (value 0 or negative disables the check entirely - a critical misconfiguration).

Detection and Monitoring

  • Security Audit Log (SM20/RSAU_READ_LOG): message ID DUK (callback rejected/would-be-rejected in simulation mode) and DUJ/DUI once allowlist enforcement (rfc/callback_security_method=3) is active - any DUJ (rejected) entry outside a known change is a strong signal of attempted callback abuse.
  • Trusted-RFC logons - correlate the calling system ID/client (RFC_SYSID/RFC_CLIENT) against the expected trusted-system inventory from SMT2; any trusted logon from an unexpected source, or asserting a user other than the RFC system user itself, warrants investigation.
  • RSRFCCHK output drift - periodically snapshot and diff the destination/trust inventory; new Trusted System destinations or newly-stored passwords are configuration-change events.
  • Anonymous RFC calls (RFC_SYSTEM_INFO, RFC_TRUSTED_SYSTEM_SECURITY, etc.) from unexpected source IPs in gateway/RFC traces (STRFCTRACE) - a common precursor to a trust-abuse attempt.

References