February 11, 2015 at 15:46How SAP ABAP Secure Storage Works
With this blog entry, we begin a series of posts on passwords in SAP systems: how various passwords are stored in the system, how they are protected and transmitted.
At first glance, everything is simple - you need to store passwords in the database. Of course, in the case of ordinary users, this is the case: passwords are stored as hashes in the database. However, for business users of the SAP-system is not so simple.
Due to the complex architectural features of the ERP system, SAP developers have to use various types of storages for such critical information as system user passwords.
Well, we will discuss how reliably these stores are implemented and whether an attacker can use their shortcomings for their own purposes.
Consider the ABAP stack of SAP systems as the most common among implementations.
In the ABAP stack, critical information such as passwords is usually stored in an entity called ABAP Secure Storage.
There are 2 types of ABAP Secure Storage:
1) ABAP Secure Storage
2) ABAP Secure Storage in the File System
Let's start with ABAP Secure Storage. This type of storage is presented in the form of a RSECTAB table in the database, which stores information about passwords from:
- RFC destinations
- Exchange Infrastructure (XI)
- LDAP system users
- SAPphone
- SAPconnect
- CCMS (Generic Request and Message Generator)
The information in this plate is client-dependent: using the standard SAP transaction SE16, you will not be able to see the records of other clients, moreover, the encrypted data of your client number will not be displayed.
Using the SECSTORE transaction, you can find out which encrypted data of which entities are stored in Secure Storage. The encrypted values themselves will also fail to be seen.
However, if you look directly at the plate using SQL queries, you can see all the information stored in it:
The directly encrypted payload is stored in the DATA column.
The result of the SQL query: select IDENT, rawtohex (DATA) from RSECTAB
Let's see what types of encryption, keys and storage format are used in ABAP Secure Storage.
Two formats are used to store encrypted data: rsec_data_v2 and rsec_data_v3. They differ slightly:
Consider the third version of this structure. As you can see, in addition to the direct payload, it contains information about the system (SID), signatures, and several service fields that are used in the encryption process.
The unencrypted structure looks something like this:
For encryption, 3DES mode: DES-EDE3 is used. In this configuration, a 24-byte key and an encrypt-decrypt-encrypt sequence of operations with 3 different keys based on a 24-byte key are configured. The first key is bytes 1 through 8, the second key is bytes 9 through 16, and the third key is bytes 17 through 24.
Two stages of encryption are applied.
At the first stage, SAP encrypts only part of the data from the rsec_data_v3 structure. The following fields
are encrypted : - char randomPrefix [2];
- char payload [109];
- char payloadLength;
- char magicLocal [4];
- char magicGlobalSalted [4];
- char recordIdenti? ErA7Hash [16];
The key for the first encryption step is generated based on the standard system key. The key for the first stage is calculated as follows:
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 is the key for the first
Hsup encryption step - md5 (sidA7 [3] + insnoA7 [10])
Keydef - a standard system key. Where its value comes from is described below.
So, after the first stage of encryption, our structure began to look something like this:
You may notice that not all of its values are encrypted. Since the values sidA7 and insnoA7 were used to generate the key of the first stage, they remained unprotected so far. It is for their encryption that the second stage is intended.
At the second stage, the whole structure is subjected to encryption. As a key, Keydef is used - a standard system key.
After the second stage of encryption, we get a value that is written in the DATA field of the RSECTAB table:
There is only one unclear moment in the whole mechanism - the value of the standard key, on the basis of which the key is generated for the first stage of encryption and which is used in pure form for the second stage.
It turns out that the standard key value is hardcoded in one of the applications of the SAP system. True, in encrypted form. The encryption algorithm is 3DES-EDE2.
To find out the key for encryption, you must first decrypt it. For this operation, again, you need a key (I hope that you are still reading this text and understand it :)).
Oddly enough, the key for decrypting the standard key is also hardcoded in the code of one of the applications of the SAP system, but in a pure form.
Keyrsec - the key for decrypting the standard key.
Keydef - the standard system key.
Now all the elements of the mechanism are known. The decryption process is performed in reverse order.
What are the disadvantages of such a mechanism? The fact is that the value of the standard encryption key is the same on all SAP installations. Thus, an attacker, once having received a standard key (this is not difficult, because all the data, as you understand, is embedded in the program code), can use it to decrypt data from ABAP Secure Storage. And since most of the data in Secure Storage is passwords from RFC destinations, then, recognizing them, the attacker can gain access to neighboring SAP systems.
An example of a program that allows you to decrypt data from ABAP Secure Storage:
Protection
How to prevent data from being compromised from ABAP Secure Storage?
1) First of all, you need to change the standard encryption key. The current key status can be found in transaction SECSTORE.
In order to change the standard key, it is necessary to execute the SECSTORE transaction and in the corresponding section enter the value of the new key for Secure Storage encryption. You can also select the option where a new key will be randomly generated.
After the key is changed, its value will be stored in the file SecStoreDBKey.pse The
full path to the file will be defined in the SAP parameter rsec / securestorage / keyfile
2) Restrict access to the private key file SecStoreDBKey.pse
Having gained access to this file, the attacker will recognize the encryption key and will be able to decrypt the data from Secure Storage.
3) Install SAP Notes 1902258, 1902611 and 1922423.
Related links:
1) Secure Storage (ABAP)
2) All your SAP P @ $$ w0ЯdZ belong to us
At first glance, everything is simple - you need to store passwords in the database. Of course, in the case of ordinary users, this is the case: passwords are stored as hashes in the database. However, for business users of the SAP-system is not so simple.
Due to the complex architectural features of the ERP system, SAP developers have to use various types of storages for such critical information as system user passwords.
Well, we will discuss how reliably these stores are implemented and whether an attacker can use their shortcomings for their own purposes.
Consider the ABAP stack of SAP systems as the most common among implementations.
In the ABAP stack, critical information such as passwords is usually stored in an entity called ABAP Secure Storage.
There are 2 types of ABAP Secure Storage:
1) ABAP Secure Storage
2) ABAP Secure Storage in the File System
Let's start with ABAP Secure Storage. This type of storage is presented in the form of a RSECTAB table in the database, which stores information about passwords from:
- RFC destinations
- Exchange Infrastructure (XI)
- LDAP system users
- SAPphone
- SAPconnect
- CCMS (Generic Request and Message Generator)
The information in this plate is client-dependent: using the standard SAP transaction SE16, you will not be able to see the records of other clients, moreover, the encrypted data of your client number will not be displayed.
Using the SECSTORE transaction, you can find out which encrypted data of which entities are stored in Secure Storage. The encrypted values themselves will also fail to be seen.
However, if you look directly at the plate using SQL queries, you can see all the information stored in it:
The directly encrypted payload is stored in the DATA column.
The result of the SQL query: select IDENT, rawtohex (DATA) from RSECTAB
Let's see what types of encryption, keys and storage format are used in ABAP Secure Storage.
Two formats are used to store encrypted data: rsec_data_v2 and rsec_data_v3. They differ slightly:
Consider the third version of this structure. As you can see, in addition to the direct payload, it contains information about the system (SID), signatures, and several service fields that are used in the encryption process.
The unencrypted structure looks something like this:
For encryption, 3DES mode: DES-EDE3 is used. In this configuration, a 24-byte key and an encrypt-decrypt-encrypt sequence of operations with 3 different keys based on a 24-byte key are configured. The first key is bytes 1 through 8, the second key is bytes 9 through 16, and the third key is bytes 17 through 24.
Two stages of encryption are applied.
At the first stage, SAP encrypts only part of the data from the rsec_data_v3 structure. The following fields
are encrypted : - char randomPrefix [2];
- char payload [109];
- char payloadLength;
- char magicLocal [4];
- char magicGlobalSalted [4];
- char recordIdenti? ErA7Hash [16];
The key for the first encryption step is generated based on the standard system key. The key for the first stage is calculated as follows:
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 is the key for the first
Hsup encryption step - md5 (sidA7 [3] + insnoA7 [10])
Keydef - a standard system key. Where its value comes from is described below.
So, after the first stage of encryption, our structure began to look something like this:
You may notice that not all of its values are encrypted. Since the values sidA7 and insnoA7 were used to generate the key of the first stage, they remained unprotected so far. It is for their encryption that the second stage is intended.
At the second stage, the whole structure is subjected to encryption. As a key, Keydef is used - a standard system key.
After the second stage of encryption, we get a value that is written in the DATA field of the RSECTAB table:
There is only one unclear moment in the whole mechanism - the value of the standard key, on the basis of which the key is generated for the first stage of encryption and which is used in pure form for the second stage.
It turns out that the standard key value is hardcoded in one of the applications of the SAP system. True, in encrypted form. The encryption algorithm is 3DES-EDE2.
To find out the key for encryption, you must first decrypt it. For this operation, again, you need a key (I hope that you are still reading this text and understand it :)).
Oddly enough, the key for decrypting the standard key is also hardcoded in the code of one of the applications of the SAP system, but in a pure form.
Keyrsec - the key for decrypting the standard key.
Keydef - the standard system key.
Now all the elements of the mechanism are known. The decryption process is performed in reverse order.
What are the disadvantages of such a mechanism? The fact is that the value of the standard encryption key is the same on all SAP installations. Thus, an attacker, once having received a standard key (this is not difficult, because all the data, as you understand, is embedded in the program code), can use it to decrypt data from ABAP Secure Storage. And since most of the data in Secure Storage is passwords from RFC destinations, then, recognizing them, the attacker can gain access to neighboring SAP systems.
An example of a program that allows you to decrypt data from ABAP Secure Storage:
Protection
How to prevent data from being compromised from ABAP Secure Storage?
1) First of all, you need to change the standard encryption key. The current key status can be found in transaction SECSTORE.
In order to change the standard key, it is necessary to execute the SECSTORE transaction and in the corresponding section enter the value of the new key for Secure Storage encryption. You can also select the option where a new key will be randomly generated.
After the key is changed, its value will be stored in the file SecStoreDBKey.pse The
full path to the file will be defined in the SAP parameter rsec / securestorage / keyfile
2) Restrict access to the private key file SecStoreDBKey.pse
Having gained access to this file, the attacker will recognize the encryption key and will be able to decrypt the data from Secure Storage.
3) Install SAP Notes 1902258, 1902611 and 1922423.
Related links:
1) Secure Storage (ABAP)
2) All your SAP P @ $$ w0ЯdZ belong to us