Cracking SAP password – How to retrieve hashes from a SAP abap system


How to retrieve hashes from a SAP ABAP System

There are quite some different methods to interact with a database using tools that a SAP ABAP System provide, but first we need to know which tables contain the password hashes, they are:

USH02 all releases
USH02_ARC_TMP only as of release 6.20 (and subsequent)
USR02 all releases
USRPWDHISTORY only as of release 7.00 (and subsequent)
VUSER001 only as of release 4.5B (and subsequent)
VUSR02_PWD only as of release 7.10 (and subsequent)

With the most important being USR02, where current users password are saved. The other tables listed here are useful to conduct an analysis on the history of the passwords used by SAP users, Dialog type users (users that can interact with a SAP System, also the vast majority of users in a SAP system) but also for Communication type users (for dialog-free communication between systems) and System type users (those who can use internal system processes, for example background processing) and finally for Service type user (a dialog user that is available to an anonymous).

The USRPWDHISTORY table store the users password history so we can rather reconstruct the “psychology” of a user and with this information, we can conduct a better attack on his actual password. The USH02 table contains information about change history for logon data, like the USH02_ARC_TMP table (Last Entries from Archive). VUSER001 and VUSR02_PWD instead contain the BCODE and PASSCODE fields.

Now that we know which tables to inspect, we can proceed with the extraction of the fields we need in order to crack the passwords.

The first method we will describe is based on a query being executed by sqlplus that extracts the bname (user name), mandt (reference client used by the user in the authentication phase), bcode (the CODVN B type hash) and passcode (CODVN G type hash) fields. It is preferable to retrieve the mandt field too because it is possible to find the same name on a different client and they can have a different password, this way we can distinguish between them and we can avoid a failed login attempt which is rather important because, after some unsuccessful attempts (depending on the SAP system configuration), the user will be locked out.

Once we logged into the SAP server as ora<sid> user, we can proceed with the following steps:

sapsrm:oraqla 51> sqlplus / as sysdba

SQL*Plus: Release Production on Sun May 11 08:43:55 2014

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select bname || ':' || mandt || ':' || bcode || ':' || passcode from SAPSR3.USR02;


In scenario where we do not have access to the operating system that hosts the SAP system, or if we don’t have the ora<sid> user’s password, we can still execute the query by accessing the SAP Application. Once we’re in, we can execute the ST04 transaction, then switch to the “Enter SQL Statement” tab on the “SQL Command Editor” window, enter the SQL query (as in Figure 1) then click on the clock with a green flag icon (this is a rather common icon in a SAP environment) or, via keyboard, by pressing the F8 key. In the Result tab we can extract the values we need for next steps (Figure 2)

Figure 1 – ST04 Query
Figure 2 – ST04 Result

By using the ST04 transaction on the contrary to the query as we are going to see soon, we can also extract the MANDT field, otherwise we would be restricted on the client used to execute the transaction. We are going the same restriction by using the SE16 and SE17 transactions. By using one of these transaction, we can extract the table contents (Figure 3) and we can filter the data (Settings -> Format List -> Choose Fields, Figure 4 and Figure 5) based on the fields we flagged as selected. The result is shown in Figure 6. As you can see even if we selected the MANDT field, the result shows only the client 001 data (that is the one from which we executed the transaction). This can be seen as a limitation, however, once we successfully crack some user passwords, we can try those users against other clients, just remember the lockout issue we already discussed before. Please note that locking out a SAP user means a disruption in the workflow, maybe a scheduled job that isn’t executed or something like this that would cause a severe damage to the financial or system processes.

Figure 3 – SE16 – Table Name
Figure 4 – SE16 – Choose Fields
Figure 5 – SE16 – Select Fields
Figure 6 – SE16 – Hits

We now need to save on a local file the data extracted. To do this, select the data using the common SAP GUI shortcuts. Use CTRL-Y to select, then CTRL-C to copy or, even simpler, use the SAP export function on System -> List -> Save -> Local File. A window will pop-up and we are asked the format in which the data will be saved. Even though the “Spreadsheet” format would look like the simpler, we prefer to copy the data “In the clipboard” to paste them in a simple text editor such as notepad (Figure 7). I prefer this way because sometimes, using the excel file, there are chances to have some spurred data due to the implicit conversion on the cell numeric data type. Once we have saved the file in notepad, we make a backup copy of the file (because two are the most important thing in life: backup and health) then we format them in the format (pardon the pun) we have already seen (that is: bname:mandt:bcode:passcode) by using two regular expressions. We will name this file as sap_qla_all_hash.txt (QLA being the SAP test instance).

Figure 7 – SE16 – Copy to Notepad

Before we log out from the SAP ABAP Application Server, we retrieve the list of Administrators type users of the SAP system so we can identify them once we crack their password. To do this just execute the SE38 transaction, then choose the RSUR002 report (or, alternatively, use the SUIM transaction: SUIM -> User Information System -> Users by Complex Selection Criteria -> Users by Complex Selection Criteria) then insert SAP_ALL on the “Profile name” form (Figure 8). By performing this search, we get a list of administrative users of the SAP system. The SAP_ALL profile gives the users the higher privileges.

Figure 8 – SUIM – Profile Name SAP_ALL

Now, before we get to the real cracking phase, we split the file that contains the hashes in two files, one with the bcode, the other with the passcode, in a format understandable by John the Ripper, we do this by inserting 40 characters as a padding between the username and the hash, like this:

user:salt<------- 40 - salt padding -------->$<---- hash ---->

Here’s the awk-fu to achieve this result:

# cat sap_qla_all_hash.txt | awk -F":" '{printf "%s:%-40s%s\n", $1, $1, "$"$3}' OFS=":" > sap_qla_bcode.hash
# cat sap_qla_all_hash.txt | awk -F":" '{printf "%s:%-40s%s\n", $1, $1, "$"$4}' OFS=":" > sap_qla_passcode.hash

We check that everything went fine by counting the rows of the resulting file with both the password and hashes loaded by john using the --single option and to perform a simple and fast cracking:

# wc -l sap_qla_all_hash.txt
636 sap_qla_all_hash.txt

# john --pot=sap_qla_bcode.pot --session=sap_qla_bcode --single --format=sapb sap_qla_bcode.hash
Loaded 636 password hashes with 636 different salts (SAP CODVN B (BCODE) [128/128 SSE2 intrinsics 12x])

# john --pot=sap_qla_passcode.pot --session=sap_qla_passcode --single --format=sapg --encoding=utf8 sap_qla_passcode.hash
Loaded 636 password hashes with 622 different salts (SAP CODVN F/G (PASSCODE) [128/128 SSE2 intrinsics 4x])

Cracking SAP password saga

1. Introduction
2. ABAP Algorithms – BCODE and PASSCODE
3. How to retrieve hashes from a SAP ABAP System
4. The Wordlist
5. Cracking BCODE
6. Cracking PASSCODE
7. How to retrieve hashes from SAP Portal JAVA Application
8. Conclusions

Co-Author: Panfilo Salutari

L'hai trovato interessante?