Close

HAVE QUESTIONS?

A partner account manager can help. Contact us today.

Subscribe me to your mailing list

SAP Passwords. Part 1: ABAP Secure Storage. How it works

This is the first entry in our blog series dedicated to passwords in SAP systems. We will discuss how different passwords are stored in systems, how they are protected and transmitted. It seems easy at first glance: passwords should be stored in a database. Of course this is true for regular users: their passwords are stored in databases as hashes. But it's not that simple for the service users of SAP systems.

Complex architectural features of ERP systems and other enterprise business applications force SAP developers to use different storage types for service user passwords, as critical as they are.

Well, let's see how securely these storages are implemented. Are there any flaws attackers can use to their own benefit?

We will use the ABAP stack as the example because it is the most widely implemented one. The ABAP stack usually stores such critical data as passwords in an entity called ABAP Secure Storage.

There are two types of ABAP Secure Storage:

  • ABAP Secure Storage
  • ABAP Secure Storage in the File System

First, ABAP Secure Storage. This storage type is introduced as the database table called RSECTAB, which stores information about passwords from:

  • RFC destinations
  • Exchange Infrastructure (XI)
  • LDAP system users
  • SAPphone
  • SAPconnect
  • CCMS (Generic Request and Message Generator)

The data presented in this table is client-dependent, so using the standard SAP transaction SE16 will not yield any entries for other clients. Even your own encrypted client number data will not be displayed.

RSECTAB table of ABAP Secure Storage

You can use the transaction SECSTORE to find out for which entities Secure Storage stores encrypted data. You will not be able to see the encrypted values themselves, either.

However, referring to the table directly by SQL queries will show all data stored there.

Encrypted payload per se is stored in the DATA column.

SQL query result: select IDENT,rawtohex(DATA) from RSECTAB

Let's find out which encryption type, keys, and storage structure are used in ABAP Secure Storage.

Two structures are used to store encrypted data: rsec_data_v2 and rsec_data_v3. They are not very different:

There is a third version of this structure. As you can see, it contains not only payload but also system information (SID), signatures, and several service fields which are used during encryption.

The unencrypted structure looks similar to this:

The cipher is a 3DES mode: DES-EDE3. In this configuration, the encryption features a 24 bytes long key and the operation sequence "encrypt-decrypt-encrypt" with 3 different keys based on the 24-byte key. The first key gets the 1-8 bytes, the second one gets the 9-16 bytes, and the third key uses the 17-24 bytes.
There are two stages of encryption.

At the first stage, SAP only encrypts a portion of the data from the rsec_data_v3 structure. These fields are encrypted:

  • char randomPrefix[2];
  • char payload[109];
  • char payloadLength;
  • char magicLocal[4];
  • char magicGlobalSalted[4];
  • char recordIdentifierA7Hash[16];

The key for the first encryption stage is generated on the basis of the standard system key. The first stage key is calculated using this formula:

Key'def[1] = Keydef[1] ^ (Hsup[0] & 0xF0)
Key'def[6] = Keydef[6] ^ (Hsup[0] & 0x0F)
Key'def[7] = Keydef[7] ^ (Hsup[3] & 0xF0)
Key'def[10] = Keydef[10] ^ (Hsup[1] & 0xF0)
Key'def[13] = Keydef[13] ^ (Hsup[1] & 0x0F)
Key'def[16] = Keydef[16] ^ (Hsup[4] & 0x0F)
Key'def[19] = Keydef[19] ^ (Hsup[2] & 0xF0)
Key'def[20] = Keydef[20] ^ (Hsup[2] & 0x0F)

where:

Key'def – first encryption stage key
Hsup - md5(sidA7[3]+insnoA7[10])
Keydef – default system key. We will get back to its value later.

After the first stage of encryption, our structure looks like this:

You may notice not all values are encrypted. The values sidA7 and insnoA7 stayed unprotected because they were used to generate the first stage key. This is what the second stage is for: to encrypt these values. At the second stage, the entire structure as a whole is encrypted. Keydef, the default system key, is used as the encryption key.

After the second encryption stage, we get the value which goes into the DATA field of the RSECTAB table:

Only one part of the scheme is left unclear: the value of the default key used to generate the first encryption stage key and to encrypt the entire structure at the second stage.

Actually, the default key value is hardcoded in an SAP application. It is hardcoded in an encrypted form, though. The encryption algorithm is 3DES-EDE2.
So to learn the encryption key, one has to decrypt it first. This, again, requires a relevant key (I hope you're still with me ☺).
Strangely enough, the default key encryption key is also hardcoded in one of SAP applications, and this time, it is in clear text.

Keyrsec – default key encryption key
Keydef – default system key

Now we know the whole story. To decrypt everything, do the steps backwards.

What are the disadvantages of this mechanism? You see, the default key value is the same for all SAP implementations. So if an attacker learns the default key once (it is easy enough, considering that all data is hardcoded), they can use it to decrypt data in ABAP Secure Storage. Most of this data is RFC destination passwords, and an attacker who knows them will be able to access adjacent SAP systems, too.

Example of a program which can decrypt data in ABAP Security Storage:

Defense

How do you prevent your ABAP Secure Storage data from compromise?

1) First of all, change the default encryption key. The SECSTORE transaction shows the current key status.

To change the default key, execute SECSTORE and enter the new Secure Storage encryption key value in the relevant section. You can also choose to generate the new key randomly.

After the key is changed, its value will be stored in the file SecStoreDBKey.pse The complete file path is defined in the SAP parameter rsec/securestorage/keyfile

2) Restrict access to the individual key file SecStoreDBKey.pse. Once an attacker has access to this file, they will know the encryption key and decrypt Secure Storage data.

3) Install SAP Security Notes 1902258, 1902611, and 1922423.

4) Monitor your SAP system regularly for various vulnerabilities and misconfigurations to prevent attackers from accessing your database.

.

Links

[1] Secure Storage (ABAP)
[2] All your SAP P@$$w0ЯdZ belong to us