In SAP version prior SAP Netweaver 7.40, for communication between Oracle and SAP purpose, the Oracle database is installed with the remote_os_authent parameter enable. This configuration could creates a signifiant breach in the SAP system, because it enables remote anonymous connection to the database, where all SAP data is stored.
Although this parameter is deprecated by Oracle in 2011, and is no longer supported from Oracle 12c, there are still many SAP systems with this vulnerability.
This attack could be splitted in two steps : the remote database connection without authentication, and then a privilege escalation from OPS$ user to SAPSR3 user (owner of SAP tables).
To fully understand the issue, it’s important to understand the OPS$ mechanism.
To allow OS SAP administration user, <sid>adm, to perform database tasks, SAP uses something called the OPS$ mechanism : SAP first logs to Oracle using an OPS$ user ID and then logs back on with the retrieved credentials for the SAPSR3 / SAP<SID> user. The only table owned by OPS$<SID>ADM is a table named : ‘SAPUSER’, with two columns: USERID and PASSWD. This table contains the user and the password of SAP Oracle Schema.
Here is example to clarify OPS$ mechanism. Let’s show how SAP tools, R3trans, are able to check if connection between SAP and database are enable.
The R3trans tool :
saptest:bobadm 56> R3trans This is R3trans version 6.19 (release 720 - 24.08.10 - 14:38:42). unicode enabled version usage: R3trans [<options>] <control_file> The control_file describes what R3trans has to do. The following options are possible: -c f1 f2 : Copy file f1 to f2 with character set conversion. -d : DB connect. Test if SAP database is available. -i file : Import from file without using a control file. -l file : List the contents of file to the log file. -m file : List the contents of file to allow tp to create a cofile. -t : Test. All database changes are rolled back. -t4 : Trace level 4. Switch on developer trace. -u <int> : Unconditional modes. See below. -v : Verbose. Write more details to the log file. -w file : Log file. The default log file is 'trans.log'. -x : DB connect without access on any SAP table. R3trans finished (0012).
SAP Admin issues command : R3trans –d
- The binary R3trans tries to connect to the database using OSP$ account
4 ETW000 [dev trc ,00000] charset='', chset='UTF8', UNI_ASC=FALSE/FALSE 12 0.009255 4 ETW000 [dev trc ,00000] Logon as OPS$-user to get SAPSR3's password 14 0.009269 4 ETW000 [dev trc ,00000] Connecting as /@BOB on connection 0 (nls_hdl 0) ... (dbsl 720 140910)
- The tool reads table SAPUSER and retrieves the SAP schema credential
4 ETW000 [dev trc ,00000] -->oci_prepare_stmt(con=0, len=59, stp=2ff0818); AI=,0,, 115 0.061000 4 ETW000 [dev trc ,00000] SELECT USERID,PASSWD FROM SAPUSER WHERE USERID IN (:A0,:A1) 4 ETW000 21 0.061021
- Then it use this credential to connect again to the database
4 ETW000 [dev trc ,00000] <--oci_execute_stmt(rc=0, iters-errors = 1-0) [dur. 0,001s] 42 0.061780 4 ETW000 [dev trc ,00000] Got SAPSR3's password from OPS$-user 216 0.061996 4 ETW000 [dev trc ,00000] Disconnecting from connection 0 ... 65 0.062061 4 ETW000 [dev trc ,00000] Rolling back transaction ... 18 0.062079 4 ETW000 [dev trc ,00000] Closing user session (con=0, svc=2fdb6b8, usr=300e0e0) 190 0.062269 4 ETW000 [dev trc ,00000] Now I'm disconnected from ORACLE 460 0.062729 4 ETW000 [dev trc ,00000] Connect as 'SAPSR3' with found password from table SAPUSER 21 0.062750 4 ETW000 [dev trc ,00000] Connecting as SAPSR3/<pwd>@BOB on connection 0 (nls_hdl 0) ... (dbsl 720 140910) 4 ETW000 17 0.062767
- Then checks some tables entries, etc. If all statements are successful, the connection is OK
So if we are able to reproduce this flow, we are able to do anything on database, and compromise the SAP system also.
Remote connection without authentication
To make a connection on Oracle database set up as above, simply create a username <sid>adm locally on attacker system, then use Oracle client (sqlplus) to perform the remote connection. Oracle « trust » the operating authentication, and it works…
But the user OPS$<SID>ADM haven’t wide privileges. It can’t do anything on SAP tables :
However it can access to table “SAPUSER”, where the hash of SAPSR3 password is stored :
Quick look on SAPSR3 hash
This hash, generated by SAP, doesn’t look random as first impression :
plain : < mot de passe fourni > hash : < contenu de la table sapuser > hexa : < base64 -d | xxd –p > plain : A hash : V01/0020ZctvSB67Wv2dyQ== hexa : 574d7fd34db465cb6f481ebb5afd9dc9 plain : B hash : V01/0020ZctvSB67Wv2dyg== hexa : 574d7fd34db465cb6f481ebb5afd9dca plain : AA hash : V01/0020ZctvSB67Wv2dyfy+ hexa : 574d7fd34db465cb6f481ebb5afd9dc9fcbe plain : BB hash : V01/0020ZctvSB67Wv2dyvy9 hexa : 574d7fd34db465cb6f481ebb5afd9dcafcbd plain : AAA hash : V01/0028ZctvSB67Wv2dyfy+7hc= hexa : 574d7fd34dbc65cb6f481ebb5afd9dc9fcbeee17 plain : AAAA hash : V01/0030ZctvSB67Wv2oVYRzDVDk8A== hexa : 574d7fd34df465cb6f481ebb5afda85584730d50e4f0 plain : AAAAA hash : V01/0030ZctvSB67Wv2oVYRzDVDk8FZh hexa : 574d7fd34df465cb6f481ebb5afda85584730d50e4f05661
After some research it is easy to understand why this mechanism is no longer supported. In fact the encryption is reversible, although based on 3DES, the salt and key are static and the same for all SAP systems:
The begnining of the key.
Privilege escalation to SAPSR3 Oracle user
It possible to reverse the hash extracted from SAPUSER table, then connect again with this credentials :
Now attacker could read, modify and delete all SAP data stored in this database.
By example, attacker is able to create a SAP user with administive rights (SAP_ALL), and use it with the SAPGui to get full access on SAP System.
Remediation and Conclusion
To avoid this issue, SAP has provided a new mechanism available since SAP Kernel 7.20, and setting up it as default since SAP Netweaver 7.40.
Below useful notes about it :
1622837 - Secure connection of AS ABAP to Oracle via SSFS 1860519 - SAP fails to connect to the database 1905775 - SSFS connection is not working 1639578 - SSFS as password storage for primary database connect 1764716 - Memory leak when using the secure storage in the file system 1764043 - Support for secure storage in BR*Tools 1638280 - Data records in table DBCON
This new mechanism doesn’t impact the business workflow a lot, it’s not an upgrade, and can be done relatively quickly without risk. You should consider using it as soon as possible.
Check out our SAP Security offer :
- SAP Audit Assessment
- SAP Penetration Testing
- Remediation Process