Direct Access to the Underlying Database (Oracle/MSSQL/DB2/MaxDB)
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.
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.
- Confirm reachability/credentials as
<sid>adm-R3trans -dperforms a silent connectivity test using the sameOPS$/SSFS-resolved credentials the kernel uses; a cleanR3trans 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 SYSDBAsucceeds with no password when run as an OS user in the Oracledbagroup (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 SQLin ABAP (EXEC SQL. ... ENDEXEC.) - executes database-specific SQL directly, bypassing Open SQL’sS_TABU_DIS/S_TABU_NAMchecks, 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).
- 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 toSAP_ALL. - Migrate the
OPS$/SAPUSERpassword mechanism to Secure Storage in File System (SSFS) per SAP Note 1639578; afterwards drop the now-unusedSAPUSERtable andreset 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_nodesinprotocol.ora; equivalent host-based firewalling for MSSQL/DB2/MaxDB). - Eliminate
Native SQLfrom custom code wherever Open SQL suffices; flagEXEC SQLblocks in code review / SAP Code Vulnerability Analysis. - Restrict
DBACOCKPIT/DB02authorizations (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 sysdbagetsORA-01031: insufficient privilegesagainstUSR02.
- OS-level command auditing for
sqlplus,sqlcmd,db2,dbmcli,brconnect -f chpassinvoked 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/DB02usage andS_RZL_ADMgrants - review viaSTAUTHTRACE/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.
- SAP Note 1522952 - Password Complexity Verification Function (Oracle 11.2)
- SAP Note 1639578 - SSFS as password store for primary database connect
- SAP Note 1503634 - FAQ: Oracle Database Vault
- SAP Note 1355140 - Using Oracle Database Vault in an SAP environment
- SAP Note 1597194 - Database Vault 11.2: Installation Guide for SAP
- SAP Note 1502374 - Database Vault Policy Scripts for SAP (11.2)
- SAP Note 1481950 - New authorization check for generic table access (S_TABU_NAM)
- Book: SAP-Systeme schützen (Rheinwerk/SAP PRESS), Chapter 12 “Schutz der Datenbank”, §12.2 (OPS$/SSFS, brconnect, pp.283–287), §12.4 (SAP database interface, Native SQL vs. Open SQL, direct
sqlplus/USR02read, Database Vault, pp.293–308); Chapter 5 §5.6.1 “Oracle-Hack” (connect sapr3/sap@SIDviasvrmgrl, pp.142–143) - Related pages: Secure store decryption
- Credential material taxonomy
- OS command execution
