A New version of pysap – an Open Source Tool for SAP Protocols and file formats – Now Available
SecureAuth Innovation Labs, a dedicated research team, sheds light on the tools and mechanisms available to better use and protect credentials in SAP HANA environments. After exploring the network protocol used to connect to HANA databases, we take a deep dive into how the HANA client stores connection information, and more importantly, accesses credentials.
Introduction
One of the (many) challenges of managing large distributed systems is how to secure usage of credentials and cryptographic material. If you are doing things right, you are authenticating and securing all network paths and communications between systems, which requires the use of credentials, keys, tokens, certificates, and other forms of secrets. Protecting all those secrets is not an easy task, especially if applications and systems need to use them unattended and without an administrator’s intervention.
SAP provides a set of different mechanisms and technologies to solve these challenges, ranging from custom and proprietary file formats to encrypted cryptographic keys and certificates, to tools for storing and using credentials.
In this article, we focus on one use case related to the SAP HANA platform, which is how to enable administrators, users, scripts and even applications, to store and use connection credentials to SAP HANA systems.
Enter the SAP HANA Client Secure User Store
SAP HANA Client Secure User Store is a tool integrated with the SAP HANA client, that provides mechanisms to store connection information to SAP HANA systems. The main objective is to allow client applications to connect to SAP HANA without requiring the user to type-in credentials. Scripts can for example rely on this tool to automate processes and launch database queries or similar.
The hdbuserstore tool provides a wide range of commands to manage the stored credentials, where the user can for example add new ones, delete them or change some of the associated information. It also supports specifying a list of hosts for failover support and the client tool will pick the corresponding host to connect to.
The key part is that, for this tool to be useful, it needs to store the user’s credentials in a secure way. To do that, SAP decided to use an encryption mechanism and store the credentials in a particular file format. This is where the Secure Storage in File System (SSFS) comes in. For those readers knowledgeable in general SAP security, this same mechanism is used in the ABAP platform and via the rsecssfx tool. In the context of SAP HANA, it’s also used to store both server-side and client-side encryption keys.
How does the Secure Storage in File System (SSFS) protect data?
As is clear from its own name, SSFS is a file-based solution to store data in a secure way. Encryption of the data is done with an encryption key, which is also stored in the file system. The hdbuserstore tool then governs access to the encrypted data, by providing the required encryption and decryption capabilities to the clients using it.
The secure store makes use of the following main file types:
- Data Files, which have the DAT extension and which the names follow the form SSFS_<SYSTEMNAME>.DAT. The data files contain the actual data in encrypted form and in internal structures called records. Records can contain data in plain text or encrypted, and the content can range from usernames to connection attributes and passwords. Authenticity protection is allegedly provided by means of an HMAC value calculated over the content and the data file headers, and in the case of encrypted data it also includes a SHA-1 hash value to guarantee integrity of the content.
- Key Files, using the KEY extension and with the form SSFS_<SYSTEMNAME>.KEY. Key Files are crucial for securing access as they contain the encryption keys being used to encode the data. Each file contains a unique key and some additional meta data, such as the timestamp, hostname and username associated.
- Lock Files with the LCK extension, and following the same naming convention SSFS_<SYSTEMNAME>.LCK. These files provide the tool with a mechanism to identify if a given data file is being used by another process.
How is the data encrypted? The SSFS solution and its tool uses a variant of the Triple DES (3DES) encryption algorithm. However, the S-Box as well as other constants used by the algorithm are not the ones defined during the standardization process. Instead custom defined ones are used. We suspect that the same or a very similar implementation of 3DES is used in other SAP encryption components, such as the ABAP Secure Store.
What is needed to access the encrypted content? Having access to the Data File and its corresponding Key File should allow anyone with the proper tools to access the content. Note that the encryption key is not derived from nor complemented with any type of user-provided input and instead only the file is used. It’s also worth mentioning that, different to some other SSFS-based implementations, the Client User Store doesn’t feature default hard-coded keys.
Playing with key and data files – An updated version of the pysap Open Source Tool for SAP Protocols and file formats available today
As always, when we engage in this type of exploration to better understand known components of a system, having a way to play with the different structures and values is our desire. We decided to implement the aforementioned file formats in our Open Source tool dedicated to SAP protocols and file formats: pysap. In previous releases of pysap, we added support to parse credential-related structures and file formats, such as the CredV2 and PSE formats. In our new release of pysap, we’ve enabled support for the SSFS layer. While pysap is based on Scapy, a library focused on crafting and exchanging network packets, its declarative nature and the great flexibility provides the basis to easily implement the file formats and be able to express them in a way that’s self-explanatory to almost anyone familiar with Python code.
The new code incorporated to pysap corresponds to classes for the main file formats, as well as the required cryptographic functions, and can be found already published in the tool’s repository. We have added an example script that mimics the behavior of the hdbuserstore tool and in addition allows to output the decrypted content in plain text:
What can go wrong?
The security of SAP’s other secure stores has been the target of some security scrutiny over the years. Dmitry Chastuhin and Vladimir Egorov from ERPScan published a series of blogposts, now unavailable, where they shared some of the inner workings of the ABAP, Java and HANA stores, including the 3DES encryption used in RSEC. The work was also published in Dmitry’s presentation at the Confidence Security Conference 2014 Edition “All your SAP Passwords belong to us”, and resumed in good detail by Yvan Genuer’s article published in Devoteam’s blog post “The security of ‘SAP Secure Storage’”.
We are not going to cover here the security properties of the encryption mechanism in use nor its customized constants. However, it is highly important to mention that the entire security of the solution relies on the access control mechanisms in place to keep the Data and Key Files away from malicious actors. By design, both the encrypted data and the encryption key are kept on the same file system. It is essential then to apply the available Operative System procedures and methods to restrict and audit access to both files as much as possible. Making sure that these files are only accessible to the desired parties is fundamental to securing the underlying data encrypted in the store.
To strengthen the process of securing the SSFS files, newer versions of SAP HANA implemented a mechanism to better segregate access to them, by isolating them in separate operating system users and providing methods to enforce more granular access control lists and check authenticity of the processes accessing them. We left the exercise of exploring this solution, the Local Secure Store (LSS), for a further exercise.
Finally, it is worth noting that as mentioned, the encryption keys are not derived from user-provided inputs but instead directly stored in the Key Files. Cracking encrypted files by means of brute forcing encryption keys is still possible but not practical just yet considering the best-known attacks against 3DES.
Best practices and recommendations
The number one recommendation related to the entire challenge of handling credentials is to try to stay away from passwords as much as possible. In the context of SAP HANA systems, we’ve covered this topic in our blogpost “Exploring the SAP HANA SQL Command Network Protocol – Federated Authentication”. Delegating authentication to a strong Identity Provider, such as SecureAuth’s Identity and Access Management Solutions, that offers not only greater traceability but also multiple and secure authentication factors will make a difference.
However, there are situations where completely replacing password-based authentication is not feasible. Considering the factors discussed, we recommend the following actions when dealing and handling SSFS files:
- Make sure that access control lists for both Data and Key Files are well defined and follow the principle of least privileged. Implementation of Privileged Access Management and secrets management solutions can help with this process when dealing with a large number of systems and servers to secure.
- When working with automated processes, deployment scripts and clients connecting with SAP HANA systems, properly treat SSFS Key Files as sensitive information and minimize its distribution. For example, a code repository with automation deployment artifacts might contain an encrypted Data File committed to it but should avoid storing Key Files. Those should be distributed via other secure methods. Setting up automated notifications by looking for the type of files involved can provide cheap and easy-to-implement detection capabilities to avoid further risks and take immediate actions if needed.
- Under the suspicion of a compromise of a client system, consider the credentials stored locally as compromised as well, and rotate affected credentials. The fact that the hdbuserstore stores credentials encrypted does not prevent an adversary who managed to get access to both the Data and the Key Files from extracting the stored credential, as the encryption process doesn’t take any user-provided information as input.
Conclusion
To conclude, we shared valuable research insights obtained while analyzing the security protections and components provided in SAP HANA systems. The secure storage and handling of credentials in large distributed systems is a big challenge as well a key component of secure practices. By sharing our insights and the details we understand related to the SAP HANA Client User Store and underlying SSFS, we hope to provide you with valuable recommendations and best practices to make your jobjust a little bit easier to help you mitigate risk and effectively protect credentials in SAP Hana.
For any question related to this topics, reach me at @martingalloar or email our SecureAuth Innovation Labs using labs@secureauth.com.
