Checking SAP password strength – part I (ABAP)

There are reasons why you might want to check the security (strength) of an SAP implementation’s passwords. Maybe during an external SAP security assessment or during an internal review.

If it is an SAP security assessment and the successful exploitation of a vulnerability is able to provide OS command execution in the application server, the command shell might not be sufficient to prove the impact of the vulnerability. Sometimes the most effective way to do it is to retrieve valid credentials (SAP user credentials) in order to prove a real threat. This can evidence the ability to connect to the system, obtain business information and explain to our customer the real problem behind a given vulnerability. The impact is clearer, from the customer’s perspective, when there is a chance to access business data and it’s exposed with valid (SAP) user credentials rather than performing command execution and showing a command shell, although the latter could potentially cause more damage.

Other scenarios where password cracking could be necessary is on complex landscapes with several systems interconnected. If an attacker is able to obtain valid user credentials in low-criticity systems such as sandbox or development systems it is likely that the same user and password will be configured in productive systems as well, being able to “jump” from the initial system (probably much less secured) to the most critical systems.

The basics of SAP password hashing

SAP password hashes are generated using specific algorithms and stored in the database. When it comes to the algorithms there are several that could be configured in the system. Currently the most widely used hash algorithms in the SAP systems are [1]:

  • CODVN B: Based on MD5 algorithm, only supports uppercase up to eight characters. Some characters are not supported. Uses the user name as “fixed” salt.
  • CODVN F: Based on SHA1, supports case sensitive passwords up to forty characters uses the user name as “fixed” salt.
  • CODVN G: CODVN B & CODVN F, both hashes.
  • CODVN H: SHA1 algorithm although in the future the algorithm can be selected through a profile parameter. It supports case sensitive passwords up to forty characters and uses random salt.
  • CODVN I: CODVNB & CODVNF & CODVNH, all three hashes.

The hashes are stored in different fields of the USR02 table depending on the selected hash function:

  • CODVN B hashes will be stored in BCODE field.
  • CODVN F hashes will be stored in PASSCODE field.
  • CODVN G stores the CODVN B hash generated in the BCODE field and the CODVN F hash in the PASSCODE field.
  • CODVN H hashes will be stored in PWDSALTEDHASH field.
  • CODVN I hashes the same as CODVN G and stores the CODVN H in PWDSALTEDHASH field.

It is possible determine the hash algorithm for each user by looking at the value of the “CODVN” field in the USR02 table.

Password strength exposed through cracking

To discover weak passwords, we’ll use a process called “password cracking”. This process focuses on generating different hashes and comparing this hashes with the ones retrieved before. To make this process more efficient, we will focus our efforts into cracking CODVN B and CODVN G hashes, since the first hashing algorithm is weaker and can give us information to make it easier to discover the second hash.

We’ll use John the Ripper community enhanced version (with Jumbo patch) to crack the SAP password hashes [2].

If the system is using CODVN G hashes, then we can first try to crack the CODVN B hash which is easier (remember, only eight uppercase characters) and then use this information to build a possible password. For example, if we have the following log-in information:

Username: test
Password: testTEST1234

CODVN B hash: $5DA86F6F7B0DD7F0
CODVN F hash: $EE593A624E549BB358D22D5879994D4730E44964

If we crack first the CODVN B hash then we will know that the password starts with “testtest”. We don’t know the case, but we know the char set and we can create a password dictionary starting with the prefix “testtest” like “testTest”, “TestTest”, and so on.

Now we need a good word list to start the cracking process. We can use one of the following:

  • rockyou.txt
  • John the Ripper (included with the tool)

You can find several wordlists at skullsecurity.org [3].

Enough theory, let’s see a real example. this file contains the dump of the user hashes, which can be retrieved by reading the USR02 table.

Let’s say we want to crack the password hash for the following user:

Username: CRACKME
Password: Barcelona123
CODVN B hash: 0x77F51F9578932C75
CODVN F hash: 0x68E2A98EE65ECE1EBB3801EE6189721570ACF303

First we need to adapt our CSV file to john’s format. John includes a Perl script called sap_prepare.pl. In order to change the CSV we run:

./sap_prepare.pl <input_file> <output_bcode> <output_gcode>

Where <input_file> must be the CSV file and as output we will obtain 2 files which will serve as input for john cracking CODVN B and CODBN G respectively (remember that the G version of the hash algorithm is nothing else than CODVN B+CODVN F in separate fields)

Now we have two files ready to be fed into john, as we said, it is better to start with CODVN B hash. The command to start the cracking process is:

./john --wordlist=<path_to_dic> <path_to_file_to_crack> --format=sapb

Using the “rockyou.txt” dictionary we obtain the following output:

Loaded 1 password hash (SAP CODVN B (BCODE) [128/128 AVX intrinsics 12x])
BARCELON (CrackMe)

Now we have the first eight characters of the password for user CrackMe. Using the john mangling rules (for more information about this topic, refer to JtR’s documentation) we can generate possible CODVN G passwords. To do this we created a new rule based on the NT rule in the “john.conf” file, this appends one letter and three numbers to our CODVN B password, for example:

[List.Rules:SAP]
:
...
-c T7QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]$[a-zA-Z]$[0-9]$[0-9]$[0-9]
-c T8QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]$[a-zA-Z]$[0-9]$[0-9]$[0-9]

Note: I’m sure we could have written this rule better, but so far it is working and is sufficient for the purpose of cracking.

With this rule we can generate a new dictionary to try to crack the CODVN G hash. We need to use our cracked CONDVN B password as “word list” and use the power of mangling rules:

./john --wordlist=<path_to_codvnB_cracked_password> --rules=SAP –stdout >> sap_rule.txt

This will generate passwords like:

“barcelonZ997 ”, “BARCELOnD928 ”, “BARceLonE170 ”

With our freshly created word list we can try to crack the CONVN G hash:

./john --wordlist=<path_to_sap_rule_txt> <path_to_file_to_crack> --format=sapg

Now the output will be:

Loaded 1 password hash (SAP CODVN F/G (PASSCODE) [128/128 AVX intrinsics 8x])
Barcelona123 (CRACKME)
guesses: 1 time: 0:00:00:01 DONE (Fri Feb 15 12:46:08 2013) c/s: 2873K trying: Barcelona120 – Barcelona127

We finally cracked a twelve-character password using the weak hash information. It is possible to try different mangling rules and options. For more info you can check the john-users mail list [5] and the Korelogic’s John the Ripper Rules [6]

Conclusions

There is no magic when it comes to password strength. The solution is to have strong passwords in one hand (which should be enforced by applying strong password policies) and in the other hand and to use secure (ideally the strongest) password hashing algorithms.

Additionally, access to the password hashes information should be secured, to reduce the chances of off-line password cracking. This should be enforces by securing the access to the Database and to the operating system of the SAP application server.

As final remarks we’ll go through some countermeasures aimed to make harder the cracking process:

  1. First of all, prevent unauthorized access to the OS and database. Limit the access to tables USR02, USH02, USH02_ARC_TMP and USRPWDHISTORY. [7]
  2. Properly configure password policies by setting the profile parameters:
    • login/min_password_lng
    • login/min_password_letters
    • login/min_password_digits
    • login/min_password_lowercase
    • login/min_password_uppercase
    • login/min_password_specials
    • login/password_max_idle_productive
    • login/password_max_idle_initial
    • login/password_history_size
    • login/password_expiration_time
  3. The password policy must establish a minimum length for the passwords of 8 characters (if using CODVN B) or higher if available. Use special characters, numbers, and a combination of uppercase and lowercase. Note that the password restrictions should match your internal policies, but the harder requirements the stronger passwords hashes are.
  4. Use the strongest hashing algorithm available in your system (according to the version).
  5. Passwords have to be only one more barrier in your security layer, not the ONLY one. Protect all the SAP services and the application server holistically.
  6. Read the SAP note 1237762 – ABAP Systems: Protection against password hash attacks. [8]

References

[1] http://www.daniel-berlin.de/security/sap-sec/password-hash-algorithms/
[2] http://www.openwall.com/john/
[3] http://www.skullsecurity.org/wiki/index.php/Passwords
[4] example_crack-ABAP.
[5] http://www.openwall.com/lists/john-users/
[6] http://contest-2010.korelogic.com/rules.html
[7] https://service.sap.com/sap/support/notes/1484692
[8] https://service.sap.com/sap/support/notes/1237762

Further reading about password security here.

Share Button

3 thoughts on “Checking SAP password strength – part I (ABAP)

  1. Password length rulez!
    Instead of forcing your employees or customers to choose complex passwords containing different character classes – which they will note and stick onto the keyboard – let them choose long passwords. If you increase min_password_length you can omit min_password_special etc.

    Use login/password_downwards_compatibility and the corresponding programs to get rid of old password hashes and login/password_compliance_to_current_policy to enforce new password rules.

    Finally, go for Single Sign-On which enables you to deactivate any user password in the system.

    Kind regards
    Frank Buchholz, SAP

  2. Hi Frank,
    Thanks for contributing with the information and the additional recommendations as it’s going to be very useful for all SAP customers to catch-up with stronger and more secure passwords.
    It’s great that you mentioned the login/password_downwards_compatibility profile parameter, as Onapsis released a SAP Security In-Depth publication named “The risks of downwards compatibility” that anyone can freely download from the Onapsis web site (http://www.onapsis.com/get.php?resid=ssid01).
    Kind regards
    Juan Perez-Etchegoyen

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>