This article discusses the use of hashing for password security in SAP systems, explaining how hashes are stored, methods for cracking them using tools like JohnTheRipper and Hashcat, and emphasizes the importance of addressing weak hashes and deactivating downward compatibility to enhance data protection.
Introduction to Hash Cracking
Hashing is a one-way encryption method used to ensure data integrity, authenticate information, secure passwords, and other sensitive information. Hash functions transform data into a fixed-size string of characters that are uniform and deterministic, making it a great option for maintaining data security.
One of the main features in relation to password storage is that the results are one-way, this means that it is possible to obtain the same result with the same input data, but can’t calculate the input data knowing the result, which allows validating user credentials without knowing the original data.
Sometimes, as security professionals, we need to perform password cracking which is basically “recover” the plaintext value, to identify users with weak passwords, hijack other users accounts to elevate privileges to mention some use cases of this technique.
This blog will provide background on how SAP stores passwords and cracking tools that can be used to perform tests.
Password Storage in SAP Netweaver ABAP
SAP systems produce and store different types and versions of hashes according to its configuration. Furthermore, legacy and insecure values can be kept back to provide retrocompatibility, which is important because depending on the configuration parameters, it’s possible to have weak hashes stored in the SAP system database that can make it easier for a threat actor to obtain highly critical information about the user’s credentials.
Database Tables
SAP Netweaver ABAP stores passwords mainly in the database table USR02, also keeps user historical values in the tables USH02, USH02_ARC_TMP, and last but not least in table USRPWDHISTORY.
Although USR02 contains the active passwords, analyzing all the hashes can provide hints or partial passwords that can lead to mutate input test data or improve an existing dictionary.
Hash Functions and Formats
SAP systems implement several mechanisms to generate hashes and multiple values can be stored based on profile parameters configurations.
The field CODVN (Code Version of Password Hash Algorithm) in table USR02 represents the algorithm that is active for an specific registry, the possible values and hashing methods are:
| CODVN Value | Description |
| B | MD5 based function, limited to 8 uppercased characters ASCII encoded |
| D | MD5 based function, limited to 8 uppercased characters UTF8 encoded |
| F | SHA1 based function with fixed SALT, 40 characters UTF-8 encoded |
| H | SHA1 based function with random SALT, 40 characters UTF-8 encoded |
Each specific hash value has its own column in the aforementioned tables, and multiple hashes can coexist and be validated according to the SAP system configuration.
For each tables CODVN “B”/”D” is stored in the column “BCODE”, CODVN “F” is stored in column “PASSCODE” and CODVN “H” is stored in the column PWDSALTEDHASH.
Two other CODVN values are possible “G” and “I”, which is basically that multiple hashes are going to be generated and stored. CODVN “G” will produce “F” and “B”, and CODVN “I” will produce the hashes “H” “F” and “B”.
The password hashes that are going to be generated, stored and validated when the user logs in is handled by the profile parameter login/password_downwards_compatibility (see https://help.sap.com/doc/saphelp_nw74/7.4.16/en-us/4a/c3f18f8c352470e10000000a42189c/frameset.htm for more information about this parameter).
Password Cracking in SAP Systems
To be able to crack passwords, first we need to obtain password hashes. If we have access directly to the database, this task is straightforward, but in SAP systems we have other options.
Obtaining Hashes in SAP systems
If we don’t have direct access to the database, it’s possible to retrieve the password hashes via specific transactions or remote function calls (RFC).
Some helpful transaction codes to export database records are SE16 and DBACOCKPIT, both transactions permit to explore database tables and extract full values.
If these transactions aren’t available, the RFC function RFC_READ_TABLE can provide partial hashes. This method won’t provide the full hash values, but some tools can use these incomplete values to get some results. It’s also important to highlight that this RFC function is remote enabled, which means that it can be executed remotely.
The image below shows an example of the retrieved partial value of the previous hash.
Password Cracking Tools and Recommendations
Password cracking allows for the recovery of passwords, and due to the inherited properties of hash functions the only way to perform that task is by brute forcing values. This can be achieved by purely testing every length and character which is not the most performant option, using a pre created wordlist or rainbow tables which is basically (and in simplified terms) a pre calculated list of hash values and its corresponding plaintext, but rainbow tables is not a valid choice if random salts are used in the hash calculation process.
A mix of these techniques can be used, combining wordlists with values or mutating the words into new values based on rules.
It’s important to mention that the success of this process depends mainly on the generation of the wordlist and rule sets. Knowing typical passwords or words related to the organization can lead to a more efficient way to achieve this task.
Weak hashes or partial hashes can produce results that are inaccurate or outdated. These results can provide hints about the password domain. To provide a concrete example of this, imagine that a user has the password “Password1234”. If CODVN B hashes are generated, it’ll be a lot quicker to crack, but the result will be “PASSWORD” instead of the real user password. At the very least, this provides a good starting point to start creating the dictionary and rules to test stronger and active hashes.
There are currently two de facto standard tools that allow this password recovery task to be performed and we will exemplify their use below, these tools are JohnTheRipper and Hashcat.
Cracking SAP System Hashes with JohnTheRipper
JohnTheRipper provide several versions and Jumbo version is the best option if we want to crack SAP system generated hashes, because it also provides some scripts to format input files like sap2john.pl which explains how to download as spreadsheet the hashes and converts to the input expected by john binary.
The format required by older versions of JohnTheRipper is $ for CODVN B/D/F and only the hash for CODVN H, but newer versions accept the input file without space padding up to 40.
The commands to be executed in order to start the recovery process are:
| For CODVN Bjohn –format=sapb –wordlist=wordlist_file hashes_file
For CODVN Fjohn –format=sapg –wordlist=wordlist_file hashes_file For CODVN Hjohn –format=saph –wordlist=wordlist_file hashes_file |
Cracking SAP System Hashes with Hashcat
Hashcat allows not only to crack full hashes, but it’s also possible to crack partial hashes obtained via RFC_READ_TABLE.
For CODVN B/D/F the file format required is $, for CODVN H only the hash is required.
It’s possible to execute Hashcat with different attack modes. The simplest way is the Wordlist mode, which basically compares hashes produced from that list with the ones obtained from the database. However, other modes are available, like brute force every character or combining word lists with rules.
For the sake of the example Hashcat can be executed as follows to attempt to recovery passwords based on word lists:
| For CODVN Bhashcat -a 0 -m 7700 hashes_file wordlist_file For CODVN Fhashcat -a 0 -m 7800 hashes_file wordlist_file For CODVN B with partial hash from RFC_READ_TABLEhashcat -a 0 -m 7701 hashes_file wordlist_file For CODVN F with partial hash from RFC_READ_TABLEhashcat -a 0 -m 7801 hashes_file wordlist_file For CODVN Hhashcat -a 0 -m 10300 hashes_file wordlist_file |
Other methods like brute forcing or rule-based can be really slow if they lack some precise definitions or will require generating some rule sets which, without some knowledge of the password context, can be suboptimal and unsuccessful.
Conclusions and Recommendations
SAP systems based on its configuration can produce several hash versions, some of them nowadays considered weak and easy to crack.
Based on profile parameters configuration, these downgraded passwords can be considered valid when a user attempts to log in if downward compatibility is enabled.
If weak hashes aren’t being validated, the results can provide hints about real passwords that could help to improve the wordlists or rules.
Onapsis strongly recommends to deactivate the downward compatibility and remove the weak hashes in all the related tables mentioned above.
Overall, hashing is not only an interesting procedure from an attacker perspective, but it can also help infosec teams identify password reutilization or well known passwords and take actions accordingly.
