Hello! Today’s post can be considered as a appendix to our previous post. We will learn how to validate the strength of SAP passwords by trying to crack them. We’ll focus on the password hashes coming from the SAP JAVA Application Server.
The JAVA Application server stores the passwords in the form of hashes encoded in BASE64. The hash algorithm used is salted SHA-1, also known as SSHA1 .
SAP JAVA “stack” password hashes are stored in a database table called UME_STRINGS. The JAVA password hashes can be filtered by the “attr” field (attr = ‘j_password’). We can get the user name along with its corresponding hash by executing the following SQL query:
SELECT pid, val FROM UME_STRINGS WHERE attr = 'j_password'
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.