How does ABAP Secure Storage work in SAP?
With this blog entry, we start a cycle of posts about passwords in SAP systems: how different 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, it is: passwords are stored as hashes in the database. However, for service users of the SAP-system is not so simple.
Due to the complex architectural features of the ERP system, developers from SAP have to use various types of repositories for such critical information as system user passwords.
Well, let's discuss how these storages are reliably implemented and whether the attacker can use their flaws for their own purposes.
')
Consider the ABAP stack of SAP systems as the most common among implementations.
In an ABAP stack, sensitive information such as passwords is usually stored in an entity called ABAP Secure Storage.
ABAP Secure Storage is of 2 types:
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 tablet is customer-dependent: using the standard SAP transaction SE16, you will not be able to see the records of other customers, moreover, the encrypted data of your customer number will not be displayed.
Using the transaction SECSTORE, you can find out the encrypted data of which entities are stored in Secure Storage. The encrypted values themselves cannot be seen either.
However, if you look at the table directly 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 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, besides the payload itself, it contains system information (SID), signatures, and several service fields that are used in the encryption process.
The unencrypted structure looks like this:
3DES mode is used for encryption: DES-EDE3. In this configuration, a 24-byte key is configured and an encrypt-decrypt-encrypt workflow with 3 different keys based on a 24-byte key. The first key is bytes from 1 to 8, the second key is bytes from 9 to 16, the third key is bytes from 17 to 24.
Apply 2 stages of encryption.
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 - key for the first stage of encryption
Hsup - md5 (sidA7 [3] + insnoA7 [10])
Keydef - standard system key. Where does its value, described below
So, after the first stage of encryption, our structure began to look like this:
You may notice that not all of its values are encrypted. Since the sidA7 and insnoA7 values were used to generate the key of the first stage, they remained unprotected. The second stage is intended for encryption.
At the second stage, the entire structure is encrypted. The key is used Keydef - standard system key.
After the second encryption stage, we get the value, which is recorded in the DATA field of the RSECTAB table:
Throughout the mechanism, there is only one unclear point - the value of the standard key on the basis of which the key is generated for the first encryption stage and which is used in its pure form for the second stage.
It turns out that the value of the standard key is hard-coded in one of the applications of the SAP system. True, in encrypted form. The encryption algorithm is 3DES-EDE2.
To find the key for encryption, you must first decrypt it. For this operation, again, a key is needed (I hope that you are still reading this text and understand it :)).
Strangely 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 its pure form.
Keyrsec - key to decrypt the standard key
Keydef - 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 point 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 easy, 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 the Secure Storage are passwords from RFC destinations, then, recognizing them, the attacker can also access 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) The first step is to change the standard encryption key. The current status of the key can be found in the 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 the Secure Storage encryption. You can also choose the option where the new key will be generated randomly.
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 individual key file SecStoreDBKey.pse
By accessing this file, the attacker will know the encryption key and will be able to decrypt data from the Secure Storage.
3) Install SAP Notes 1902258, 1902611 and 1922423.
Related Links:
1) Secure Storage (ABAP)
2) All your SAP P @ $$ w0dZ 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, it is: passwords are stored as hashes in the database. However, for service users of the SAP-system is not so simple.
Due to the complex architectural features of the ERP system, developers from SAP have to use various types of repositories for such critical information as system user passwords.
Well, let's discuss how these storages are reliably implemented and whether the attacker can use their flaws for their own purposes.
')
Consider the ABAP stack of SAP systems as the most common among implementations.
In an ABAP stack, sensitive information such as passwords is usually stored in an entity called ABAP Secure Storage.
ABAP Secure Storage is of 2 types:
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 tablet is customer-dependent: using the standard SAP transaction SE16, you will not be able to see the records of other customers, moreover, the encrypted data of your customer number will not be displayed.
Using the transaction SECSTORE, you can find out the encrypted data of which entities are stored in Secure Storage. The encrypted values themselves cannot be seen either.
However, if you look at the table directly 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 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, besides the payload itself, it contains system information (SID), signatures, and several service fields that are used in the encryption process.
The unencrypted structure looks like this:
3DES mode is used for encryption: DES-EDE3. In this configuration, a 24-byte key is configured and an encrypt-decrypt-encrypt workflow with 3 different keys based on a 24-byte key. The first key is bytes from 1 to 8, the second key is bytes from 9 to 16, the third key is bytes from 17 to 24.
Apply 2 stages of encryption.
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 - key for the first stage of encryption
Hsup - md5 (sidA7 [3] + insnoA7 [10])
Keydef - standard system key. Where does its value, described below
So, after the first stage of encryption, our structure began to look like this:
You may notice that not all of its values are encrypted. Since the sidA7 and insnoA7 values were used to generate the key of the first stage, they remained unprotected. The second stage is intended for encryption.
At the second stage, the entire structure is encrypted. The key is used Keydef - standard system key.
After the second encryption stage, we get the value, which is recorded in the DATA field of the RSECTAB table:
Throughout the mechanism, there is only one unclear point - the value of the standard key on the basis of which the key is generated for the first encryption stage and which is used in its pure form for the second stage.
It turns out that the value of the standard key is hard-coded in one of the applications of the SAP system. True, in encrypted form. The encryption algorithm is 3DES-EDE2.
To find the key for encryption, you must first decrypt it. For this operation, again, a key is needed (I hope that you are still reading this text and understand it :)).
Strangely 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 its pure form.
Keyrsec - key to decrypt the standard key
Keydef - 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 point 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 easy, 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 the Secure Storage are passwords from RFC destinations, then, recognizing them, the attacker can also access 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) The first step is to change the standard encryption key. The current status of the key can be found in the 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 the Secure Storage encryption. You can also choose the option where the new key will be generated randomly.
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 individual key file SecStoreDBKey.pse
By accessing this file, the attacker will know the encryption key and will be able to decrypt data from the Secure Storage.
3) Install SAP Notes 1902258, 1902611 and 1922423.
Related Links:
1) Secure Storage (ABAP)
2) All your SAP P @ $$ w0dZ belong to us
Source: https://habr.com/ru/post/250335/
All Articles