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
Edit page

Direct Access to the Underlying Database (Oracle/MSSQL/DB2/MaxDB)

Description

Every AS ABAP authorization check - S_TCODE, S_TABU_DIS/S_TABU_NAM, Open SQL buffering and change logging - is enforced by the application server, not the database underneath it. The SAP system connects to the RDBMS (classically Oracle, MSSQL, DB2, or MaxDB - the pre-S/4HANA majority install base, distinct from the dedicated SAP HANA and SAP ASE dossiers) as a single, generic, all-privileged schema user (SAPSR3/sap<sid>). Any path that reaches the database directly - OS access to <sid>adm/ora<dbsid>, a database-CLI session, or an ABAP Native SQL statement - sees the entire SAP data model with zero SAP-layer authorization checks and zero SAP-layer logging.

The classic trust chain an attacker rides is the OS->DB password-less connect (OPS$) mechanism: the OS user <sid>adm (Oracle: ops$<sid>adm) authenticates to the database with no password at all, because the OS has already authenticated it. From there the SAP kernel reads the actual schema-user password out of table SAPUSER and completes the real connection. Anyone who reaches an OS shell as <sid>adm - or the equivalent Oracle/DB group member - inherits this same password-less path.

Risk

Direct DB access collapses the entire SAP authorization concept: S_TABU_DIS/S_TABU_NAM table-access restrictions, S_DEVELOP code-change gates, and the Security Audit Log all live at the application-server layer and see nothing. An attacker with <sid>adm-equivalent OS access or a leaked DB connect password can read every table (USR02 password hashes, RSECTAB secure storage, REPOSRC ABAP source code) or write to REPOSRC to inject/modify ABAP code, bypassing every transport control. Native SQL in custom ABAP code is the same primitive reachable from inside the application without any OS foothold at all. Impact spans full confidentiality, integrity, and availability of the SAP system and, via REPOSRC tampering, persistence that survives normal transport-based remediation.

Options

  • Confirm reachability/credentials as <sid>adm - R3trans -d performs a silent connectivity test using the same OPS$/SSFS-resolved credentials the kernel uses; a clean R3trans finished (0000) confirms working DB access without needing to know the schema password.
  • Oracle - read via sqlplus:
    sqlplus / nolog
    SQL> CONNECT / AS SYSDBA
    SQL> SELECT * FROM SAP<SID>.USR02;
    
    CONNECT / AS SYSDBA succeeds with no password when run as an OS user in the Oracle dba group (ora<dbsid>) - this is OS-authenticated, not password-authenticated.
  • Steal/rotate the schema password non-interactively - brconnect -u / -f chpass -o sapsr3 -p <new password> changes the ABAP DB-connect user’s password using the same OS trust, without ever supplying the old one; watch shell history for prior invocations leaking the plaintext.
  • MSSQL / DB2 / MaxDB equivalents - sqlcmd -S <host> -E (Windows trusted/integrated auth as the SAP service account), db2 connect to <SID> user db2<dbsid>, dbmcli -d <dbname> -u <user>,<pwd> - same pattern: an OS-trusted or harvested DB-CLI credential reaches the raw data model.
  • Native SQL in ABAP (EXEC SQL. ... ENDEXEC.) - executes database-specific SQL directly, bypassing Open SQL’s S_TABU_DIS/S_TABU_NAM checks, buffering, and change logging entirely; a frequent finding in ABAP custom code and flagged by SAP Code Vulnerability Analysis.
  • DBACOCKPIT/DB02 - the SAP-GUI front end to DB administration; a user with sufficient authorization (S_RZL_ADM, S_ADMI_FCD) can run native diagnostic SQL statements against the database from inside the ABAP session, with no OS access needed.
  • High-value targets once inside: USR02 (password hashes - see secure store decryption and credential material taxonomy), RSECTAB (encrypted RFC/DB destination secrets), REPOSRC (ABAP source - direct write is code injection that bypasses the transport system, see transport/XPRA abuse).

Mitigation

  • Restrict OS-level access to <sid>adm/ora<dbsid>/db2<dbsid> and DB-admin group membership to the minimal required population; treat it as equivalent to SAP_ALL.
  • Migrate the OPS$/SAPUSER password mechanism to Secure Storage in File System (SSFS) per SAP Note 1639578; afterwards drop the now-unused SAPUSER table and reset remote_os_authent.
  • Deploy the SAP-provided Oracle password-complexity verify function (SAP Note 1522952) on profile SAPUPROF.
  • Restrict database network reachability to application-server and authorized admin-console hosts only (Oracle: tcp.validnode_checking/tcp.invited_nodes in protocol.ora; equivalent host-based firewalling for MSSQL/DB2/MaxDB).
  • Eliminate Native SQL from custom code wherever Open SQL suffices; flag EXEC SQL blocks in code review / SAP Code Vulnerability Analysis.
  • Restrict DBACOCKPIT/DB02 authorizations (S_RZL_ADM, S_ADMI_FCD) to Basis/DBA accounts only.
  • For the strongest control, deploy Oracle Database Vault (Realms/Command Rules/Rule Sets) per SAP Notes 1503634, 1355140, 1597194, 1502374 - it separates DBA privilege from access to SAP application data, so that even sqlplus / as sysdba gets ORA-01031: insufficient privileges against USR02.

Detection and Monitoring

  • OS-level command auditing for sqlplus, sqlcmd, db2, dbmcli, brconnect -f chpass invoked by <sid>adm-equivalent accounts outside scheduled maintenance windows.
  • Oracle listener log entries TNS-01190/TNS-01189 - unauthorized remote listener administration attempts.
  • Native SQL (EXEC SQL) blocks surfaced by SAP Code Vulnerability Analysis / ABAP Test Cockpit during code review.
  • DBACOCKPIT/DB02 usage and S_RZL_ADM grants - review via STAUTHTRACE/SUIM.
  • Once Database Vault is deployed: Realm/Command Rule violation entries (ORA-01031, ORA-47400) in the database alert log - any occurrence against SAP schema objects is a strong signal of an attempted bypass.

References