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. RFC Gateway Unauthenticated OS Command Execution (10KBLAZE / SAPXPG)
Edit page

RFC Gateway Unauthenticated OS Command Execution (10KBLAZE / SAPXPG)

Description

10KBLAZE (OPCDE 2019) is the name given to a class of attacks against an unprotected SAP RFC Gateway port (33XX on an application-server instance, 48XX/33XX on a standalone SAProuter-fronted gateway). It is not a CVE - it exploits the absence or misconfiguration of the gateway’s access-control files, secinfo and reginfo (SAP Notes 1408081, 1421005, 821875). An attacker with only network reachability to the gateway port sends raw SAP NI-framed packets to register a STARTED_PRG conversation with the kernel binary sapxpg, then instructs it to run an arbitrary OS command - with the privileges of <sid>adm, the same account that owns every other SAP kernel process.

The four-packet flow: P1 GW_NORMAL_CLIENT registers a CPI-C client session; P2 F_SAP_INIT opens a STARTED_PRG conversation targeting the sapxpg TP; P3 F_SAP_SEND/SAPXPG_START_XPG_LONG executes the OS command; P4 F_SAP_SEND/SAPXPG_END_XPG retrieves stdout/stderr. If secinfo is missing, empty, or over-permissive (gw/acl_mode not enforced, or a catch-all P TP=* line), the gateway accepts the registration and the command executes. On a correctly hardened gateway (secinfo/reginfo populated, kernel ≥ 745 default), the gateway silently drops P2 - a reliable negative signal distinguishing a hardened target from a transient network issue.

Note
This is a configuration weakness, not a patchable vulnerability - SAP’s guidance (Note 1408081) predates the 2019 public disclosure by years and is opt-in hardening the customer must apply.

Risk

Any network-reachable attacker who can register a STARTED_PRG conversation with sapxpg gains arbitrary OS command execution as <sid>adm with no SAP credential of any kind - full compromise of confidentiality, integrity, and availability of the host and every downstream system it can reach. The follow-on direct-database SQL technique (below) converts this into a persistent, SAP_ALL-equivalent SAP user written directly into the user-master tables, bypassing the ABAP authorization layer entirely.

Options

  • SAPMAP modules/exploitation/sap_gw_xpg_standalone.py - stdlib-only re-implementation of the full P1–P4 wire protocol, with ABAP/Java-gateway and kernel-754-vs-793+ compatibility handling and a built-in hardening diagnostic (F_SAP_INIT timeout = likely protected).
  • Manual equivalent (historical): pysap sap_gw_xpg.py / sap_gw_xpg2.py (Python 2, ABAP gateways only).
  • Manual equivalent: Metasploit sap_gw_rfc_direct and other public 10KBLAZE scripts.
  • Direct-DB SQL user creation follow-on - once OS command execution is available, sap_db_sql_writers.py (+ SQL templates in sapmap_config.py) drives the same sapxpg primitive to invoke the target’s own DB CLI (sqlplus, sqlcmd, hdbsql, sqlcli, db2) and write a pre-computed, valid SAP password hash directly into USR02/UST04/USR04/USRBF2 - creating a service user (USTYP=S) with SAP_ALL-equivalent authorizations, entirely underneath the ABAP kernel and its authorization checks (S_USER_GRP, S_USER_AUT, BAPI_USER_CREATE1). Delivery is per-DB/OS (Oracle/MSSQL on Windows via cmd.exe echo-to-file + CLI; HANA/MaxDB on Linux via a two-step python3 -c write + CLI -i/-I execute), driven by SAPXPG’s tight field-length limits (EXTPROG ≤128 bytes, PARAMS ≤255 bytes).
  • Manual equivalent (DB write): direct OS/DB-CLI access to the database host, or the same sap_gw_xpg_standalone.py-class primitive driven by hand against sqlplus/hdbsql/sqlcli.
  • Reconnaissance prerequisite: unauthenticated RFC_SYSTEM_INFO/gateway-monitor probing to obtain target IP, SID, hostname, instance number, and kernel version.
  • Configuration check: read the running values of gw/acl_mode, gw/sim_mode, gw/reg_no_conn_info, gw/rem_start, and SAPXPG_SEC_CHECK (via RZ11/RSPFPAR, or remotely via PFL_GET_SINGLE_PARAMETER). gw/acl_mode = 0 (no ACL check) or gw/sim_mode = 1 (log-only, never deny) means the gateway is effectively open even when secinfo/reginfo files exist; a gw/reg_no_conn_info below 255 leaves known ACL-bypass paths live. Read the running value, not just the profile - these are dynamic parameters (see Profile Parameter Drift).
  • A single OS-command foothold obtained this way converts directly into an interactive SAP* super-user SAP GUI session - see Hardcoded and Virtual Super-User SAP*.

Mitigation

  • Implement secinfo/reginfo per SAP Note 1408081’s starting configuration (internal,local keyword, kernel ≥ 720 / SAP_BASIS ≥ 700 with the referenced support packages); set gw/acl_mode=1.
  • Store secinfo/reginfo in the global path ($(DIR_GLOBAL)/secinfo) so it’s consistent across every application-server instance.
  • Set gw/reg_no_conn_info = 255 (SAP Note 1444282): this parameter is a bitmask that activates the individual secinfo/reginfo ACL-bypass fixes, and a default of 1 leaves most of them off - meaning a syntactically valid ACL can still be bypassed until the bitmask is complete.
  • Set gw/sim_mode = 0. Simulation mode (1) logs ACL violations but never rejects them, so a gateway left in simulation has ACLs that appear configured yet enforce nothing.
  • Order the secinfo/reginfo entries as specific permits followed by a terminal deny (P lines then D *): evaluation is first-match-wins, so a permissive P TP=* HOST=* USER=* above the deny opens everything.
  • Do not rely on gw/rem_start = DISABLED on its own. When the gateway is co-located with the ABAP server (the normal on-premise layout), a program started via the local-start path can execute regardless of rem_start; pair the setting with a restrictive secinfo and ensure no sapxpg program is registered. Also set SAPXPG_SEC_CHECK so sapxpg performs its own security check.
  • Harden the companion message server per SAP Notes 1421005 / 821875 (rdisp/msserv_internal, ms/acl_info) - closes the related fake-application-server registration path 10KBLAZE variants also use (see Message Server / Gateway Trust Injection).
  • Restrict SM49/SM69 and the S_LOG_COM/S_RZL_ADM authorization objects to users who genuinely need external OS-command capability.
  • Ensure the DB CLI’s OS-trust model (sqlplus / as sysdba, hdbsql -U DEFAULT) is independently gated by restricting who can execute as <sid>adm.
  • Network segmentation: RFC Gateway ports (33XX, 48XX) should never be reachable from outside the trusted SAP network segment.

Detection and Monitoring

  • Gateway logging (gw/logging) - logs every STARTED_PRG/registered-server start attempt including source IP and TP name; alert on any sapxpg start from a non-admin host.
  • Transaction SMGW - review active connections and the loaded secinfo/reginfo ACLs for unexpected entries or an empty/missing file.
  • SM21/dev_rd system log and gateway trace files for STARTED_PRG/sapxpg entries correlated with unfamiliar source IPs.
  • OS-level process monitoring: sqlplus/hdbsql/sqlcli/sqlcmd/db2 spawned as a child of sapxpg/disp+work rather than an interactive admin shell or a scheduled DBA job.
  • Database-side: USR02/UST04/USR04/USRBF2 INSERT/UPDATE statements executed via a CLI connection under <sid>adm’s OS-trusted identity, outside the normal ABAP user-management code path - a strong indicator, since the ABAP layer never sees the write and no Security Audit Log user-creation event is generated.
  • Network-level: any inbound connection to 33XX/48XX from outside the trusted admin/application-server network segment is itself worth alerting on.

References