From older SAP R/3 to the recent SAP Netweaver ABAP system, SAP username and password are stored encrypted directly in database. Fortunately, encryption mechanisms have evolved since 90’s 🙂
But it’s possible to active them all anyway, by misconfigure a simple SAP parameter : login/password_downwards_compatibility.
It could lead to dangerous behaviors, like quick password cracking, bypassing password strength policies, and also to an unconventional user spoofing.
In this article I explain how SAP Netweaver passwords are stored, then what the parameter ‘Password Downwards Compatibility’ means, and finally show a couple of vulnerabilities related to it.
SAP hash type
There are different types of password hashing mechanism possible in SAP system.
Called ‘code version’ (CODVN) in below table :The current CODVN used by default is H : based on iSSHA-1, up to 40 UTF-8 characters, random salt with configurable length (96) and iteration (1024). Refer to SAP Note 991968 for latest supported algorithm and details about code H.
The code B is the worst possible. Dating back to the 90s, it’s MD5 based, 8 ASCII upper-case characters maximum.
As you can see there are couple of specifics CODVN : I and G. They permit to use more than one codvn at the same time.
For example, if CODVN is set to “I”, it’s mean that user’s password will be hashed using H, F and B CODVN. Also, these three hashes will be stored in database.
SAP hash storage
User password and information are stored in several tables.
The USR02 table is known as “Master User Table”, this is the table involved when you modify user through SU01. This table handle a lot of interesting information like :
The USH02 table is known as “User changed document”, this is the history table about user modification. It contents a part of USR02. Passwords recovered from this table could be out of date, but a pattern could also be highlighting.
The USRPWDHISTORY table is known as “Password history information”, this is the table where old password are stored and compared to the new one, when user changes his password. History is managed by parameter login/password_history_size.
Password downwards compatibility
Sometimes, a new or upgraded SAP system must work together with other systems that only support backward compatible password hash value (older SAP system, external component, etc).
Enable SAP Password downward compatibility means something like that :
When downward compatible is active, the system tries to evaluate your password with code-H entry, then code-F and then code-B.
The parameter login/password_downwards_compatibility managed this activity.
Below the parameter description summary :
Value | Description
0 | backward not possible, no hash generated
1 | backward not possible, hash generated
2 | backward not possible, hash generated and syslog entries created during attempt
3 | backward possible, hash generated and syslog entries created during attempt
4 | backward possible, hash generated and no syslog entries created during attempt
5 | use only B-code (like previous centruy !)
Fun fact, I’ve already found this “workaround” on forum to solve password issue related to login, interface, or so…
Issue 1 : Killing the current password policy
The first issue about setting up this parameter to wide (>3) is to make password policy useless.
Indeed, SAP allows administrator to create a very tunable password policy, with bunch of parameters login/min_password_*, login/password_history_size, login/password_charset, etc.
But imagine the following scenario :
_ A good password policy is set on a SAP System : 10 char minimum, 2 digits, 2 specials char, etc
_ Also the parameter login/password_downwards_compatibility is set to 3 (because the previous team have set it, and current team won’t to touch it)
_ Now, a user change his password to : PaSswoRd123!:)kilélongmonmotdepasse^^
The system encrypt this password using code-H, result of “7h5Lx8pLzhen2WsLeOcIiuuOn/G34xZfqbqtn7J7D58=” and store it in USR02, column PWDSALTEDHASH.
Because of downward compatibility, the system also try to encrypt this password using code-B… but code-B is limited to 8 characters, all upper-case remember ?
So the system truncates the 8 first characters, put all in upper case, then encrypt the password using code-B :
PaSswoRd123!:)kilélongmonmotdepasse^^ --> PaSsworRd --> PASSWORD --> code-B --> 8268EEECE2DC6EE0
Finally the system store this hash in USR02, column BCODE.
The second password “PASSWORD” is obviouly more easy to crack, and add a strong password policy rules in this case is useless.
Again, because of downward compatibility, login back into the SAP system with credential YVAN/PASSWORD works…
Issue 2 : Spoofing a user
If you follow me, you understand than a single user could have “multiple” passwords, and most of the time they don’t know about it.
This passwords hashes, are stored in database like other data.
It’s possible to directly access database data.
So it’s possible to modify the content of BCODE column, of any user, by our crafted entry.
update sapsr3.usr02 set BCODE=’2D22DE35F460F464′ where bname=’YVAN’ and mandt=’010′ ;
Where 2D22DE35F460F464 is code-B(‘FOOBAR’).
From now, we are able to login back with credential YVAN / FOOBAR, and use his profile in his personal working environment with all options like menus, reports, shortcuts, privileges, etc. At the same time, the real user could continue using credential YVAN / PaSswoRd123!:)kilélongmonmotdepasse^^ as well without being noticed.
Ok, having the right to tamper database data, means having already high privileges account, but it could be used as backdoor as well as post exploitation activities.
DO NOT CHANGE the parameter login/password_downwards_compatibility without made preliminary study of impact. It could lead to dangerous business issue, by disable important flow between your SAP system and other component.
- First of all, try to understand when and for what this parameters was setting up. (Yeh, unbelievable advise…)
- Check syslog entries about “Password trunctated” pattern… yes with the typo :
It means someone, or something, tries a connection using backward hash. It could provide some hints of which users or background interfaces are involve.
- Restrict the database access
- Restrict as possible access to critical SAP Tables, like USR02, USH02 and USRPWDHISTROY protected against SE16, SE17, SE11, etc.
- Use different passwords in different systems and clients
- If possible, disable downward compatibility
Want to test yourself your system ?
Simple try to login into your SAP system using the first 8 characters upper-case of you regular password… You are in ? Oups :]
Check out our SAP Security offer :
- SAP Audit Assessment
- SAP Penetration Testing
- Remediation Process