Having covered the system-wide profile parameters necessary for assigning passwords in SAP in our last blog post, we are now going to “get our hands dirty” and show you, step-by-step, how insecure password hashes can be cracked in SAP.
Where can I find the password hashes in SAP?
As already mentioned in the previous blog post, you can find all the hashed passwords of your SAP users in the table USR02. If you missed out on our discussion of the basics of hash functions, as well as the necessary profile parameters, I recommend reading our previous blog post first:
SAP Cybersecurity: How Secure Are Your Passwords?
The profile parameters will be especially helpful in what follows, which is why I strongly recommend that you read that section carefully before proceeding.
Preparations for cracking password hashes
After conducting some short research, I have decided to use the HashCat for cracking password hashes in SAP. The application, which has to be used from the command line, may seem a little off-putting at first, but once you have played around with the tool a little bit, it is all pretty straightforward. A group of developers has also programmed a GUI, but I haven’t tested it yet. You can download HashCat here.
Once you downloaded the tool, the next thing to do is to take a look at the algorithms supported by HashCat. In the list of supported hash algorithms, we can find the following:
- SAP CODVN B (BCODE)
- SAP CODVN F/G (PASSCODE)
- SAP CODVN H (PWDSALTEDHASH) iSSHA-1
That’s strange. In the last article only the PASSCODE was mentioned and what does CODVN B / F / G / H actually mean anyway? OK, not so fast, let’s take things one step at a time. In table USR02, in addition to the PASSCODE field, there may be other fields in which SAP can store the password, depending on the configuration. This includes the fields BCODE and PWDSALTEDHASH. So far, that is however, only half the truth about the fields BCODE, PASSCODE and PWDSALTEDHASH. In the last blog post, we mentioned the hash algorithms MD5, SHA1 and SHA2. But how do I know which hash algorithm was used? Quite simple: If the field BCODE contains a value, you can be sure that the MD5 algorithm is being used. Compared to SHA1, this is considerably more insecure and consists of a maximum of 8 characters in SAP, whereby all letters are stored as uppercase letters. Why this is a disadvantage from a security point of view is something that we will explain later on when it comes to the settings to be used for cracking.
In contrast to the BCODE field, the password hash in the PASSCODE field is not hashed with the MD5 algorithm, but with SHA1, which means the password can be up to 40 characters long and the letters are case-sensitive.
In the SAP table USR02, there is also a field called “CODVN” (code version of the password hash algorithm (new systems)). You can find a good overview of this on Daniel Berlin’s blog at:
Basically, the field “CODVN” shows again which hash algorithm was used. We will need this information later on to crack the password.
The hash algorithm and the salt
Usually, one or both of these password hashes can already be found in the USR02 table, and the safest variant of the three is the use of the iSSHA-1 algorithm. This can also be up to 40 characters long, but unlike MD5 and SHA1 it contains a random salt. A salt makes it a bit more difficult to crack passwords because it is added to the actual password, so that the same passwords of different users do not have the same hash value. For the MD5 and SHA1 algorithms, SAP uses either the first 1-6 letters of the user name (field USNAM) or the complete user name, which is separated from the password by a “$” sign.
Let’s take a look at a short example to make things clearer:
Hans is new to the company and is supposed to change his initial password when he first logs in to SAP. Because Hans wants to make life easy for himself, he uses the same password everywhere. This is made up of his place of birth “Bremen” and his year of birth 1983. According to the policy, Hans must use at least one number and one capital letter. Luckily it is also between 6 and 8 characters long.
Hans’ password then is:
Bremen83
Hans’ username was set to “Hans” by the admin, so that it is easy to remember.
In this example, the MD5 algorithm is used and SAP calculates the hash value with the following string:
HANS$BREMEN83
The result generated using the MD5 algorithm would be:
ccd1890a8473069a27bb98a16a16a1ca4cb
And that’s about all you need to know about how the generation of hash values works for the purposes of what follows.
Cracking the hash
An attacker doesn’t just want to know the hashed value though, of course, but the password as plain text too. Consequently, a hacker wants to decrypt the hash value. But how do we get to the plain text from the Hans’s MD5 value:
ccd1890a8473069a27bb98a16a1ca4cb
At first glance, this seems more complicated than it actually is. First of all, we collect all the information we already have gathered about passwords. Let’s start with the profile parameters from the previous blog post:
Password minimum length: 6 due to the algorithm used we have a maximum of 8 digits
Minimum number of letters: 1
Minimum number of digits: 1
Minimum number of special characters: 0
This information will already help us a lot. In addition, we know from the field “CODVN – B” that a stored password contains only uppercase letters. The knowledge about this fact already reduces the number of possible passwords by a factor of 26, because we only have to test for capital letters. As the blog of Daniel Berlin shows, only ASCII characters can be used. Means that each digit can take up 128 possible characters. However, since no special characters are required according to the policy, we, as an attacker, make the assumption that no special characters are being used. This reduces the possible characters to the following 36 characters per position (small letters and special characters are not used):
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
This would mean that with a six-digit password, there are 366 = 2,176,782,336 possibilities that the password can accept. Sounds like a lot at first, doesn’t it? Unfortunately, it’s not really that much in this day and age anymore. In a test, my 7-year-old computer managed to try out between 30 and 50 million possibilities per second. In the worst-case scenario, even if the tool has to try out all 2.2 billion possibilities, this means a waiting time of just under 2 minutes until the password becomes visible. This time of course increases if the password has more digits. With 8 digits, there are already 368 = 2,821,109,907,456 possibilities. Of course, we gave this a try too. In the worst case, my old computer needs about 1 day and 6 hours to try out all the possibilities with 8 digits. For a hacker, this is a bearable waiting time if you can imagine what you could do with it all. In my test, it took about 6-7 hours until the password became visible. In addition, there are numerous options for running the cracking process in parallel, which significantly speeds up testing.
Cracking with HashCat
For cracking the passwords, I used HashCat as mentioned above. After unpacking the archive, the process is quite simple. First, run the Windows command prompt (Windows Button – CMD) and navigate to the path where you extracted HashCat to. In my example, HashCat is located in D:\Programs\:
“D:”
“cd Programs\HashCat 3.6.0”
Then enter “hashcat64. exe –help”. All possible settings and options for starting HashCat will then be displayed. We’ll confine ourselves to the essentials and use the following options:
-a 3 “Brute-Force Attack”
-m 7700 “Modus SAP CODVN B (BCODE)”
And, in addition to that, we need to tell it our findings (uppercase letters and numbers) about the password by inputting:
-1 ?u?d
which describes a user-defined character set consisting of uppercase letters (?u) and numbers (?d). In addition, using a user-defined string character set, we must specify a mask that defines how long the password is:
?1?1?1?1?1?1?1?1
Since we know that a password can have a maximum of 8 characters using CODVN B, we set the mask to 8 characters. However, we ignore all passwords with fewer characters in the procedure. Therefore, we also use the parameter:
–increment
This means that all possibilities are being tested from single-digit to eight-digit passwords. In addition, we must of course also include the hash value under the prefixed user name (SALT).
So that HashCat knows where to store the password, we also use the output parameter with a text file that will be located in the same folder as the hashcat64. exe file.
-o plain.txt
The complete input will then look like this:
D:\Programs\HashCat 3.6.0\hashcat64.exe -a 3 -m 7700 -1 ?u?d HANS$ccd1890a8473069a27bb98a16a1ca4cb ?1?1?1?1?1?1?1?1 -o plain.txt –increment
Note: The hash value in the BCODE field from SAP has only 16 characters. In this case, the hash value is for illustrative purposes only and will not work with HashCat because it is too long.
How can SAP hashes be secured?
Basically, the only question you end up asking yourself is how it is possible for such a weakness to have come about at all. Since SAP is an ERP system that has evolved historically and has had to react to weaknesses in the past without losing companies and, at the same time, remaining backwards-compatible, compatibility can be set via the profile parameters. The compatibility can be viewed and changed using the transaction “RZ11” by entering the profile parameter “login/password_downwards_compatibility”. A value of “1” is the standard setting, which means that the old hash values are also calculated (with MD5 and SHA1). If you change the value to “0”, the old hash values will no longer be calculated and only the most secure hash value to date will be calculated using the iSSHA1 algorithm. A small note at this point: The changes only take effect after a restart of the instance.
However, changing the profile parameter to “0” does not mean that you are totally on the safe side yet. The old hash values are still in the SAP system. But we can also remedy this situation. Using transaction “SA38” and the program “CLEANUP_PASSWORD_HASH_VALUES”, all weak hash values are removed from the database across all clients.
It should finally be pointed out that any use that you make of the information in this blog post is at your own risk and we underline once again that the cracking of SAP passwords is something that should only be done after consultation with and with the permission of the relevant persons responsible. We do not assume any liability for any possible damages which may occur, e.g. due to high processor load / graphics card load.
