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:
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
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)
New installations should be incompatible with this, but a real pain is that SOLMAN is mostly the CUA and that only supports 7.02 maximum and if you still have a 7.00 or lower hanging around then you have to live with some risk.
Thinking about the options, downward compatibility = 0 is the only real option against someone with very simple access in those releases.
Thanks for the infos about the report to delete old hashes. USH* tables are dead anyway. Away with them..
Back in 2009 you have proposed to change the default value of this profile parameter (by using the wish list) and so we did.
Yep, I've been happy ever since.. 🙂
Yes, backwards compatibility always bites you in the back... Maybe something to adres in your Security trainings, do you still hold them?
This is included in the SAP Education trainings ADM940, ADM950 and WDESEC. It is also a question in the 7.31 SAP Security Professional Certification exam btw...
Personally I have however retired from giving trainings - I now mostly do development and hang around the internet... 😉
has anyone played with increasing number of iteration for iSHA1 using parameter login/password_hash_algorithm? The default is 1024 iterations which seems reasonable but I would still like to see SAP implementing KDF such as bcrypt or scrypt instead of iterating standard hash function.
well, we actually consider to increase the number of iterations in the default settings.
Your proposal for supporting Key Derivation Functions (in addition to classic hash functions) sounds interesting; you should consider posting it to the "whish list".
Password hashing based on key derivation function - Security and Identity Management - SCN Wiki
Great article and great advice. Thanks for posting this. I note the last countermeasure in "how to protect myself": Limit access to tables USR02 and USH02. From the ABAP level, assuming we aren't giving wide-open SE16 or SE38 style authorizations to those who really don't need it, are there many risks of 'general' users gaining access to these tables? From the database level, no one other than the application service account and DBA should have any access at all, so this definitely highlights the importance of protecting that service account and limiting direct database or OS access.
Kindly also notice the other recommendations provided in note 1237762:
So, even if an attacker manages to copy the password hash values, he'll then have to use brute force attacks (assuming that dictionary attacks will not succeed since primitive passwords are not used), cannot use rainbow-table attacks (due to random salting) and will be slowed down by the high number of iterations required to calculate a reference hash value.
Matt, You're right, most companies do give access to SE16 et al.
I found the only reliable way is to ensure that all roles that users get, contain a restricted S_TABU_DIS authorisation.
Also, standard SOD practices generally dictate that security and security of security is handled by a different set of administrators to those that look after the SAP application system. Meaning, BASIS/DBA guys should not have access to USR02 or USH02, or even un-audited DBA level access (as SYSDBA for example). It is very difficult to police and even harder to enforce. Especially in small companies.
I've got a brief blog entry here: Musings of an IT Implementor: HowTo: Hide SAP tables including USR02 on how to lock down the tables and some other posts (visible here) on how to lock down other aspects (such as remove "replace" in debug).
Nice blog post, Darryl, but isn't USR02 already protected by authorization group SC by default? This same group also protects the various ADR* tables, the HRP* infotype tables, the other USR* tables, and many others, so it's not very exclusive. I can see the motivation to give the USR tables their own separate auth group, but would that hurt any system-internal functionality?
As for SOD practices, you're absolutely right, in a small organization it's often simply not financially feasible to have that many staff to make that many separations. In the US, Sarbanes-Oxley laws mandate such separations for financial and IT security roles in publicly held companies (those traded on the stock exchanges, in other words), but those laws don't apply to non-public companies, nor to public sector organizations.
The original post was based on some work I did on an R/3 4.7 landscape 😥 . I haven't checked, but like you've highlighted, later SAP releases may have included some auth groups with the USR* tables et al.
The idea with using something high in the alphabet range like ZZ, is that it's relatively easy to exclude the auth groups using a range based exclusion. i.e. only include auth groups A*-ZY*. You don't need to mess about including multiple ranges like A*-SD* + SE*-Z*.
Adding new auth groups doesn't hurt any system functionality. They are only effective when you use them to add/exclude them through S_TABU_DIS (and other auth objects) in roles that are assigned to users.
Creating your own auth groups is recommended if you need to customise the standard ones, instead of modifying the standard ones.
You're also not likely to have your custom auth groups changed during an SAP upgrade, but the standard ones might do, maybe excluding additional tables that you thought should be available to the user.
At the end of the day, it's your preference.
I think with regards to SoX; the very recent eBay hacking case only serves to highlight that SoX (and SOD) is good for security, and this is important for safeguarding not only financial, but customer master data too.
I'm under the impression that unless you're using SNC to encrypt your network traffic between SAP GUI and the SAP instance, then the hash is sent in the clear i.e the hash is visible in a packet sniffer because the SAP GUI performs the hash and sends it for validation at the server when logging into SAP.
Would be good if you could confirm this...
Wrong. The password is compressed using a GUI algorithm and sent accross the network to the server, which uncompresses it (so two way...) back to clear text within the login program and then 1 way hashes it and compares the hashes.
The hashing is always on the server side.
As the compression is reversable, SNC makes even more sence than had it really been the hash...
Yes, totally agree on that Julius.
And Darryl, this SAP compression is totally public, tools like wireshark have plugins. Search google for Dennis Yurichev+SAP Diag, and you will find the information.
I'm going through the P_ADMSEC_731 training and I've just thought of a question...
Scenario: You have multiple SAP ABAP landscape, which is managed with CUA.
Let's say that you changed the password for a user account in a CUA child system, from the CUA master.
Does the CUA master transmit the hashed password to the CUA child system?
YES, the hashed password is send via an Idoc to the satellite systems. So make sure to clean them / archive them every now and then and also protect them via authorisations for example.
Good point about the IDoc cleanup!
That also means that to be totally secure, you need SNC to be setup between the CUA child and master systems.
Great. Thanks for the confirmation.
SNC really does make sense. Especially for those companies who insist on encrypting the data at rest.