SAP with Oracle – Authentication problem

Yvan Genuer Sécurité SAP

Version Française

dev-light.png

Introduction

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).

dev-logistic.png

OSP$ mechanism

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.

dev-network.png

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 :

dev-calculator.png

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:

Hardcoded salt


The begnining of the key.


The plaintext.


dev-target.png

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.

dev-risk-and-security.png

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 :

http://www.devoteam.fr/en/offers/risk-security/expert-articles/secure-your-sap-against-new-threats

  • SAP Audit Assessment
  • SAP Penetration Testing
  • Remediation Process
  • Training
  • etc.