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. Message Server Trust Injection into Gateway ACL (10KBLAZE "betrusted")
Edit page

Message Server Trust Injection into Gateway ACL (10KBLAZE "betrusted")

Description

This is the “betrusted” variant of 10KBLAZE: instead of relying on a permissive secinfo/reginfo reachable from anywhere, an attacker whose IP is not yet trusted first injects itself into the RFC Gateway’s internal/trusted-host list by abusing the SAP Message Server’s client-registration protocol, then uses that newly granted trust to fire the SAPXPG unauthenticated OS-command primitive.

The chain is two-phase:

  • Phase 1 - Message Server IP injection. An attacker registers a fake ABAP dispatcher with the Message Server’s internal port (39XX) via LOGIN_2, completes MOD_STATE START->ACTIVE registration carrying a DP-info blob with the attacker’s IP embedded (dp_addr_from), and optionally reinforces propagation via MS_CHANGE_IP/MS_SET_LOGON and by directly answering the Message Server’s periodic AD_GET_NILIST_PORT/NILIST requests with the attacker IP - accelerating propagation instead of waiting for the Message Server’s normal 15–20 minute automatic cycle. The registration’s TCP connection is held open indefinitely (never LOGOUT), because the injected trust only persists while the fake dispatcher stays “registered.”
  • Phase 2 - Gateway SAPXPG exploit. Once the Message Server has propagated the attacker’s IP into the Gateway’s internal-hosts list, the default secinfo rule USER-HOST=internal trusts that IP to start SAPXPG unauthenticated - the same OS-command-execution primitive documented on RFC Gateway Unauthenticated OS Command Execution, from which the direct-DB privileged-user-creation follow-on also applies.
Note
Naming caveats. Despite the “betrusted”/“trusted” terminology in public tooling, this technique does not touch SAP’s RFC trusted-system feature (SM59/SMT1, authorization object S_RFCACL) - it exploits an entirely different, network-level trust concept: the Message Server’s belief that any TCP client registering as a legitimate application-server dispatcher is one. Separately, 10KBLAZE has no assigned CVE - some public tooling and documentation mislabel this technique “CVE-2020-6207”; that number does not correspond to a real, current CVE for this issue and should not be cited. The fix is entirely configuration-based (SAP Notes 1421005/821875/1408081/1444282).

Risk

An attacker with no SAP credential and no pre-existing gateway trust achieves the same outcome as a direct 10KBLAZE attack - full unauthenticated OS command execution as <sid>adm, and from there a persistent SAP_ALL-equivalent SAP user created directly at the database layer - purely from network position against two independently-hardenable services (Message Server internal port, Gateway secinfo). Compromises confidentiality, integrity, and availability of the target system and every landscape system it can reach.

Options

  • SAPMAP modules/exploitation/sap_ms_betrusted.py::betrusted - full raw-protocol fake-dispatcher registration (LOGIN_2, MOD_STATE, kernel-version-appropriate DP-info blob) + NILIST-request response, holding the injected trust open.
  • Pre-check: check_ms_acl() - single LOGIN_2 round trip against 39XX; a non-zero errorno in the reply means the port is ACL-protected and betrusted is not possible from that source.
  • SAPMAP modules/exploitation/sap_betrusted_chain.py::create_user_betrusted_chain - orchestrates the full chain: Phase 1 (MS IP-injection) in a background thread while polling check_gw_vulnerable() every 10s for up to 25 minutes, then Phase 2 (create_user_gw_exploit - the SAPXPG -> direct-DB user-creation technique from RFC Gateway Unauthenticated OS Command Execution).
  • Manual equivalent: gelim/sap_ms (original public 10KBLAZE “betrusted” PoC) + hand-crafted SAPXPG P1–P4 packets.
  • Defender-side check: SMMS/msmon “Security Settings” review for unexpected registered application servers.

Mitigation

  • Apply SAP Notes 1421005 and 821875 - set rdisp/msserv_internal to a distinct port and configure ms/acl_info to an ACL file listing only real application-server hosts/subnet.
  • Apply SAP Note 1408081 - configure secinfo/reginfo using the internal/local keywords rather than open wildcard rules; either control alone breaks the chain, but both should be applied.
  • Set gw/reg_no_conn_info to 255 per SAP Note 1444282 to activate the cumulative set of Gateway ACL-bypass fixes.
  • Restrict network reachability to 39XX (Message Server internal port) and 33XX (Gateway) to the application-server subnet only; never expose either across a DMZ/SAProuter boundary.
  • Enable gw/logging and monitor Message Server (dev_ms) and Gateway traces as part of routine Basis security monitoring.

Detection and Monitoring

  • Message Server trace (dev_ms) - the string "is EXTERNAL, access denied" is the direct signal per SAP Note 821875’s documented trace format; its absence for a source that should have triggered it means that source was accepted as an internal application server.
  • SMMS/msmon - unexpected registered application servers with unfamiliar names/IPs.
  • Repeated LOGIN_2 attempts against 39XX from hosts outside the known application-server set.
  • Gateway logging (gw/logging/dev_rd) - SAPXPG invocations from IPs that are not legitimate application servers.
  • Network-level: any inbound connection to 39XX from outside the application-server subnet is inherently suspicious in a correctly segmented landscape.
  • Unexplained new highly-privileged database users appearing outside change-controlled provisioning (see RFC Gateway Unauthenticated OS Command Execution detection notes).

References