Risks of not changing SAP default settings
Not everybody working with SAP systems knows this, but every SAP system has its own vault to store sensitive data. In the SAP world, this is called the secure store and it’s a mechanism to store sensitive data like e.g. passwords. Keep in mind though, that the data you store in the secure store cannot be displayed by normal users once it is stored. Only the SAP system kernel can access it. A typical use case example is the passwords used in RFC connections. Once you type a password In SM59 and save it, the password is stored in the secure storage and is only retrieved by the SAP system itself when the connection is being used, typical SAP users cannot see it anymore.
This mechanism prevents regular users to obtain access to sensitive data while the system itself can work with it just fine. However, in 2014 researchers from ERPScan found out how to decrypt the entries of the secure store and that it was for many years encrypted with a default key. This means that if you had access to the encrypted data (stored for example in the RSECTAB table in an ABAP system) you could decrypt the data. This in turn often leads to access to other remote systems in the SAP landscape too, as typically RFC users and passwords give access to not the local, but to remote systems. Making this a vulnerability that goes beyond the scope of one single SAP system. Also, keep in mind that SAP customers often provide the SAP_ALL profile to RFC users making things even worse. An example of a publicly released exploit for the JAVA secure store can be found here.
To come up with stronger security options, already years ago SAP released patches and functionality to re-encrypt the secure store with a customs value. Also when you install a new system nowadays the installer urges you to use your own unique encryption key. While this helps, after having conducted many SAP security assessments over the past years, we still often encounter secure stores encrypted with the default key.
To exploit this vulnerability, one must already have access to the SAP table where the encrypted data is stored in the database or on OS level. This typically makes this vulnerability part of a post-exploitation scenario. Still, to prevent lateral movement, it is extremely important to prevent exploitation since the secure store contains not only local passwords but also passwords providing access to remote SAP systems as mentioned.
To prevent abuse, several measures can be taken:
- Make sure to change the default encryption key. In the ABAP system, the transaction SECSTORE has a wizard that will provide help in doing so
- Prevent/restrict access to the OS files in the global/security directory as they contain the encrypted data and key to decrypt the secure store
- Monitor your SAP system for access to the RSECTAB table from unusual sources
- Run your SAP systems on recent versions and implement SAP Security patches frequently
Below, movie shows how you can decrypt the content in the secure storage of an ABAP system if it is encrypted with the default key.
To detect the above-mentioned misconfigurations and vulnerabilities and many more, we developed Protect4S. An easy-to-deploy solution (no agents needed) providing customers with deep insight into the security status of their SAP systems, without the need for additional manpower, that helps raise the level of SAP Security when embedded in a structural SAP Vulnerability Management process. This is to get, and stay, in control of the security of your business-critical SAP systems while preventing Fraud, Sabotage or Espionage.