Password Hash Cracking, User Cloning, and User Impersonation: Three Risks Every SAP Customer Should Know

Originally published by Onapsis.

Written by Thomas Fritsch, Onapsis.

The easiest (and a significantly profitable) way for attackers to get into a system is logging in with valid user credentials. According to a recent report, breaches that are caused by stolen or compromised credentials are not only responsible for nearly 20% of breaches1, they are also the most challenging to identify and contain. These types of breaches can take more than 200 days to identify and more than 80 days to contain2. Phishing attacks are the second most common cause of a breach, as well as the costliest.

There are different known types of attack modes to gain user credentials. Some of them, like keyloggers and credential stuffing, do not exploit SAP specific vulnerabilities. Phishing attacks are mostly triggered by emails containing links that direct users to malicious servers.

However, there are some past attempts where attackers could also have used phishing attacks to exploit SAP vulnerabilities. The most recent one was patched with SAP Security Note #3239152 in SAP’s October 2022 Patch Day. The vulnerability is tagged with a CVSS score of 9.6 and allows attackers to direct a user to the original SAP Commerce login page. It does this by using a manipulated URL that injects the redirects to a malicious server in the links provided by the original login form.

However, there are other methods of getting user credentials that exploit SAP NetWeaver architecture specific weaknesses, specifically tailored to hash values.

Password Hash Values in SAP

The passwords of all SAP users are stored encrypted as hash values in transparent tables on the database. These tables are:

• USR02: Contains the current user master record including the hash value(s) of the active password
• USH02: Contains the change documents for the user master records including the hash value(s) of former SAP passwords
• USRPWDHISTORY: Contains the user password history of every user
• USH02_ARC_TMP: Used temporarily during archiving of user change documents

Starting with SAP NetWeaver 7.02, the password hash values are calculated with a standardized hash procedure. This procedure uses a randomly-generated value ("salt"), in addition to the password, to calculate the password hash value. The hash value calculation can also be performed more than once successively, that is, it can be iterated. A list of supported hash algorithms and current limitations for the salt size and the maximum number of iterations can be found in SAP Note #991968.

Cracking Password Hash Values

A salted hash value cannot be decrypted. However, it can be cracked. Tools like hashcat or John the Ripper can be used to find a password. These tools start a brute force attack by applying the hash algorithm that was used by SAP to a dictionary of hundreds of thousands of typically used passwords. If the final hash value matches with the one stored in the SAP table, the password is cracked.

The tools take advantage of the fact that the SAP hash algorithm and the number of iterations are prepended to the final hash value. The same applies to the salt, which can easily be extracted from the end of the hash values after decoding the base64 encoded hash string. Thus, using a random salt does not protect against password cracking, but it prevents mass comparison of the password dictionary against all user passwords at once, as there is a different salt used for each password. This greatly slows down the attack.

In order not to break communication with legacy SAP systems or middleware components, SAP systems on SAP NetWeaver 7.02 or higher, by default, store every password redundantly. This means that every password is additionally stored as a downwards-compatible password (cut after eight characters and converted to uppercase) with two older (and weak) hash algorithms (MD5, SHA-1). These additionally, weaker hash values represent a risk as they can be cracked much faster for all users at once. Since they contain the first eight characters of the full password, this information can be used by the cracking tools to reduce the test candidates in the dictionary significantly and decrease the time to crack a password. A login to the local system with the downwards-compatible, eight character password is usually not possible (except SAP profile parameter login/password_downwards_compatibility is set to 3 which is not recommended).

Protection Measures

1. Don’t generate weak hash values if not needed

The generation of redundant passwords can be avoided by setting SAP profile parameter login/password_downwards_compatibility to 0.

2. Remove existing weak hash values

SAP provides the cleanup program CLEANUP_PASSWORD_HASH_VALUES that can be used after the parameter change to remove all redundant weak hash values. Details about the report can be found in our blog post How Do You Check Old Hashes in Your ABAP System?

3. Restrict the access to the affected tables

It’s not enough to protect table USR02. The password history table USRPWDHISTORY, the change document table USH02, and the archive table USH02_ARC_TMP should also be protected; otherwise, an attacker may be able to use former passwords to make conclusions about the current password.

Restricting access includes:

• Protection against direct database access from outside (using SQL)
  This should be secured in general, e.g. by using firewalls. Otherwise, the SAP authorization concept that controls data access can completely be bypassed
• Protection against access via own ABAP programs
  The quality assurance instances should check, automatically or manually, that none of these tables is accessed in customer code
• Protection against access using existing generic tools (SE16/SM30/SM31)
  Authorizations on authorization objects S_TABU_DIS and/or S_TABU_NAM should be assigned extremely restrictively
• Don’t grant debugging authorizations in production
  This should be avoided, especially assigning authorizations to change values in production
• Protection against exports of table contents using transports
  Don’t open the production system for releasing transports, otherwise the table data can very easily extracted from the system

The first three measures also apply for all views that are consuming the four password hash tables. A detailed list with more information can be found in SAP Note #1237762.

4. Enforce Strong Passwords

Strong passwords are the enemy of dictionary attacks. The time to crack a password strongly depends on its length and complexity.

The best practices for creating secure (Dictionary Attack resistant) passwords are:

• A password should be 16 or more characters
• A password should include a combination of letters, numbers, and special characters.
• A password should not include any of the user’s personal information like their address or phone number. It’s also best not to include any information that can be accessed on social media like kids’ or pets’ names.
• A password shouldn’t contain any consecutive letters or numbers.

SAP administrators can enforce choosing secure passwords by an appropriate configuration of the SAP profile parameters:

• login/min_password_lng
• login/min_password_lowercase
• login/min_password_uppercase
• login/min_password_digits
• login/min_password_specials

Special Considerations for Development Systems

The security level for test systems and development systems differs from the security level for production systems. Thus, these systems are a good starting point for insider attacks. On development systems it is almost impossible to restrict the access to the four critical tables. As people intend to use the same user passwords on multiple systems, passwords cracked on a development system might also be usable for the production system. It is strongly recommended to use different passwords in production systems than those used in test systems or development systems.

User Cloning

With developer authorizations in place, users can do everything regardless of their currently assigned authorizations. Creating and releasing transports is daily business for developers. So, extracting the data from the password hash value tables is an easy task for them.

Unfortunately, exporting data of the four critical tables for password cracking is not the worst thing that can happen. The generated password hash values are not system dependent. That means, a hash value generated on system 1 does also work on system 2. A developer can export their own USR02 user record from the development system and can trick an administrator to import the corresponding transport request into production! They are able to login to production with the well-known credentials.

Transporting the user record is not enough as the cloned user needs authorizations on the production system. There are several options to assign authorizations to the cloned user. The two easiest ones are transporting a reference user mapping (table USREFUS) or entries for the authorization buffer (table USRBF2) together with the USR02 record. More advanced attacks could also include role and profile assignments.

It doesn’t even need to trick an administrator into importing the malicious data into production. An attacker can even omit the (risky) step of tricking someone else into importing an extra transport for the attack. Instead, they can hide the manipulated record in a "regular" transport request that will be approved anyway as it transports regular things that were requested by the application department and approved by change management. Our blog post, SAP Security: Change and Transport System, describes two ways, showing how to hide table entries in a regular transport request.

User Impersonation

Single Sign-On: No Passwords, No Problems?

Almost… Transporting USR02 entries into production to clone a user doesn’t make sense in Single Sign-On (SSO) scenarios as there is usually no password stored in the table. However, transports represent a risk here, too. For an SSO solution to work, it needs to map every SAP user to their external ID, provided by the SSO tool. For SAP NetWeaver SSO, this mapping is stored in table USRACL. External solution IDs are mapped in table USREXTID. Both tables can be transported without any restrictions. The two tables can be manipulated resulting in the impersonation of another, more powerful user.

Example: In an SAP NW SSO scenario, an attacker assigns their SNC identity to user SAP. On a development system, this can easily be achieved by updating table USRACL via an own short ABAP program. It doesn’t necessarily need the required permissions to maintain this table:

After transporting this change into production, the attacker can choose between every user having their SNC identity assigned. Thus, this method can be used to impersonate arbitrary users in a production system.

Password hash cracking, user cloning, and user impersonation are realistic attack scenarios in SAP systems. Even SSO solutions are not 100% secure. Protecting the password hash value tables, enforcing strong passwords, and monitoring transport object lists are key measures for minimizing the associated risks.

1,2 Ponemon/IBM Cost of a Data Breach Report 2022