Why you should really get rid of old password hashes *NOW*

This blog is written in an effort to raise more awareness on securing your SAP infrastructure. In this case specifically on the topic of securing your SAP Password hashes. I will try and avoid being too technical…If I fail, sorry in advance

As recently announced there is a new version of OCLHashcat, version 1.20 that now supports password cracking for SAP Codeversion B and F/G. See the release notes.

Say what? And why should I care?

For the less technical people amongst us, OCLHashcat is an advanced password cracking tool that allows you to crack passwords via GPU’s (Graphical cards. This allows you to crack passwords (SAP passwords included) in a relatively fast way.

You should care about this as it is now possible to crack your SAP passwords very fast. Specifically the ones that are hashed in codeversion B or F/G. This may allow intruders to give access to your SAP systems.

So what about this codeversion B and F/G thing?

SAP passwords are stored in the database of your SAP systems in the USR02 table. They are not stored in clear text, but in a hashed format, so it cannot be read by anyone having direct access to the database tables.

This hash can be generated via different algorithms (In sap called codeversions). See for a good overview the weblog of Daniel Berlin. The most recent algorithm used is “I”, older versions are for example H, G, F, E, D, B and A. They all have their characteristics, but in general one can say that the lower the letter in the alphabet, the weaker the algorithm and the more easy (and faster) it is to crack the hash created by that algorithm.

How does this cracking work?

There are many, many ways to crack passwords, but for now we will focus on offline brute forcing passwords. In simple words; Generating password hashes for all possible passwords and compare them to the SAP extracted hashes to see if there is a match. Good to note here is that this is done OUTSIDE the SAP system, so there is no direct connection to an SAP system needed.

As said before, password cracking is an art in itself and there is a whole world to discover. I will not go into detail as there are tons of sources on the internet on password cracking. Some examples here, here or here.

Important to mention is that, with tools supporting GPU’s, the processing power is MUCH higher than it used to be with traditional CPU’s. Therefore the TIME needed to crack passwords is dramatically LOWERED and the RISK your SAP passwords might get compromised in a reasonable short time is HIGHER than it was before.

A practical example:

In my test lab I have set up a simple test environment on a rather standard desktop with a GPU card I had spare (used for bitcoin mining when that was still profitable with GPU’s). This is a rather old card I bought 2 years ago for around 200 Euros, but they can be purchased second hand for much less nowadays.

The installation of OCLHashcat is simple, install the needed GPU drivers, download OCLHashcat and you are ready to go. See for more information the website.

To demonstrate the tooling, I did two runs, one for the Bcode hashes and one for the Gcode hashes. As input I used a download from the USR02 table. The input file needs to have the hashes in the following format:

TEST$234CEE8774C3084D

Where the username in this case is TEST, followed by a $-sign and then the hash itself. In this example I used a file with several users and hashes, each on a single line. To run the tool in brute force mode you can use this command:

# oclHashcat64.exe –m 7700 –a 3 input_bcode.txt

Where “-m 7700” stands for the Bcode algorithm (Gcode=7800), “-a 3” means a brute force attack and “input_bcode.txt” is the file with Bcode hashes. The current processing is displayed on the screen:

   
In the screenshot it can be seen that the tool is currently brute forcing passwords with a length of 7 characters, the ones with passwords of 1-6 characters are already tried. In this example that only took several minutes. Depending on the speed of your GPU the total range of all possible passwords for the Bcode algorithm can be brute forced in less than a week time. Important to notice is that this only brute forces the first 8 characters, so if your passwords are 10 characters you will miss the last 2 characters.

After only 24 hours of brute forcing I managed to retrieve more than 75% of the passwords, many of them were 8 characters long. The remaining part would take several days, but as I already retrieved many passwords this was not necessary.

All retrieved Bcode passwords are converted to upper-case as there is not case-sensitivity in this algorithm. However, with the use of password-rules and the Gcode password hashes you can quite easily brute force the remaining characters and case-sensitive part.

Another thing to mention is the use of parameter login/password_downwards_compatibility. Depending on the value of this parameter you can use the brute forced Bcode password to logon due to backwards compatibility.

After brute forcing the Bcodes hashes, I did a similar attempt on the Gcode hashes from my USR02 table. This is a slower algorithm as can be seen by the  SPEED of ~2100 kH per second (A factor 6 slower than the Bcodes algorithm):

Brute forcing Gcode hashes is slower than the Bcode equivalent, so in case you have access to both hashes, a hybrid attempt would be more efficient where you first brute force the 8 characters via the Bcode and brute force the remaining characters (if any) and the case-sensitive part via the Gcode.

Ok, great stuff, but how do I protect myself against this?

Some counter measures that can be taken are:

• Regularly attempt to brute force the password hashes of your users to test how strong they are (you probably need approval for this!)
• When making use of Single-Sign-On you can probably delete the password hashes. Delete them from tables USR02 and USH02.
• Set parameter login/password_downwards_compatibility = 0 (this might break communication with systems older than 7.0, check carefully)
• Use a recent password hashing algorithm, see parameter login/password_hash_algorithm
• Delete old hashes, see ABAP report CLEANUP_PASSWORD_HASH_VALUES
• Choose strong passwords (enforce them via policies) via the password parameters
• Limit access to tables with password hashes like USR02, USH02

References

For more information see following SAP Notes and other material:

• 1237762 – ABAP systems: Protection against password hash attacks
• 1458262 – ABAP: recommended settings for password hash algorithms
• 1023437 – ABAP syst: Downwardly incompatible passwords (since NW2004s)
• http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0d2445f-509d-2d10-6fa7-9d3608950fee?overridelayout=true