in June I wrote an article about decompressing ABAP source code, in which I talked about multiple efforts to decode the SAP DIAG protocol. Now I'd like to share my experience with the outcome of those projects. Have fun!
SAP DIAG protocol
The SAP GUI uses a proprietary protocol called DIAG for communication with the application server — which unsurprisingly does not support encryption, only (optional) encryption.
To secure network communication, SNC (Secure Network Communications) comes into play: it adds encryption, single-sign-on capability and support for alternate authentication mechanisms.
Anyway, the following assumes a default SAP setup, i.e. username/password authentication without any encryption mechanism in place.
In the below tests, I'll login to client 000 with user DDIC, password ABCD1234 in English.
The clients have the IP addresses 10.0.0.1 and 10.0.0.100, while the server has 10.1.0.20.
The test procedure is the same for all below tools:
- Start the sniffer,
- log in to an SAP system,
- stop the capture and
- search the captured data for the (plain text) login data.
1st Tool: Cain & Abel v4.9.43
Cain & Abel is a versatile "security tool", which has been actively developed for > 10 years. Wikipedia has a nice overview of its features. The wealth of features might make it's usage a bit unclear — so this is what needs to be done:
- Start the sniffer,
- switch to the "Sniffer" tab,
- select the "Passwords" section,
- choose the "SAP Diag" entry and
- wait for captures to appear.
The captured and decoded communication is fully stored in a plain text file, so you need to find the needle in the haystack:
Cain is a very powerful tool and a perfect choice for security studies!
It has so many impressive features that most AV companies classified it as malware; you'll probably have to deactivate your AV guard before running it. 😯
The only thing that's missing is a parser for the dump, which directly extracts the credentials!
2nd Tool: SapCap v0.1
This one is implemented in Java and you need to struggle through the dependencies before it starts to cooperate…
You'll need: the JRE 6, SapCap itself, Jpcap, WinPcap and the MS Visual C++ runtime (unless already installed).
I managed to get ot going on Windows XP (x32), but had to give up on my Windows 7 (x64) / JRE 7 workstation… but YMMV.
SapCap works, but is a bit rough around the edges; besides the packet analysis didn't work for me.
Not my favorite!
3rd Tool: Wireshark
Wireshark is a powerful and polished network packet analyzer and probably the best open-source tool for this topic.
Unfortunately it doesn't support decoding the SAP DIAG protocol out of the box – but so-called dissection plugins fill this gap:
The CoreLabs plugin has to be compiled along with Wireshark, but I didn't get it to work before I got bored (approx. 10 serious tries). Seems to be a proof-of-concept, nothing more!
➡ Update: Check this article for a review of the CoreLabs plugin!
The Positive Research Center plugin is only available as a Win32 DLL file – no source code, no documentation… take it or leave it… 🙁
Apart from that, this plugin works really fine and since I'm a big fan of Wireshark, it's my first choice on Windows!
- Paper: "Sniffing SAP GUI passwords"
- Dennis Yurichev:
See you next time!
in this article, I'd like to summarize what I found out about SAP's password storage mechanism (for SU01 users, not the SecStore).
The passwords of all users are stored in table USR02 as one (or more) cryptographic hash value(s).
Table USH02 and some others contain the password history (see SAP Note 1484692). This history used to be limited to the last 5 entries per user before NW 7.0; meanwhile the number of entries is customizable via the profile parameter login/password_history_size (see SAP Note 862989).
The hash algorithm has changed several times over time – either due to weaknesses or as a result of the increase in computing performance (see "CODVN H" below).
Per definition, the result of a cryptographic hash function is/should be irreversible, i.e. one cannot/shouldn't be able to retrieve the plain text password from the hash value… but that's the point where the fun starts! 😎
SAP Note 1237762 gives a good overview of hash attacks and has some rather helpful tips on how to prevent them!
The password cracking tool John the Ripper (with the "Jumbo" patch) supports two of SAP's common hash algorithms (CODVN B & F/G). Give it a try, if you're serious about the security of your passwords!
This table summarizes the details of all currently available password hash algorithms (as per Q4/2012):
|Max. Passw. Length||Pw.|
|Charset||Salt||Notes||SAP Note||Hash in|
|Character 1-6 of the username|
|Unsupported characters (probably the same as with CODVN B) in the password and salt are replaced by an apostrophe (»'«).|
Superseded by code version B (automatic migration during logon).
|Unsupported characters (see note) in the password and salt are replaced by »^«||735356||BCODE|
|Superseded by code version E|
(but almost identical)
|Correction of code version D||874738||BCODE|
|G||= Code versions B & F||BCODE &|
(curr. only iSSHA-1)
|40||sensitive||UTF-8||random||Hash algorithm and options can be set via parameter login/password_hash_algorithm||991968||PWDSALTEDHASH|
|I||= Code versions B, F & H||BCODE,|
The MD5- and SHA1-based algorithms consist of two hash iterations with "some Walld0rf magic" in between — for details, have a look at this posting in the john-users mailing list.
Kernel & profile parameters
The following has an impact on the used hash algorithm:
- the SAP kernel version
- the profile parameters:
- login/password_downwards_compatibility — if available
The following tables show the effect of the above on the hash algorithm on some test-systems:
Sources & further reading
Here's where the information in the above "Hash algorithms" table came from – plus additional resources:
- SAP Note 2467: Password rules and preventing incorrect logons
- SAP Note 721119: Logon with (delivered) default user fails
- SAP Note 735356: Special character in passwords; reactivation not possible
- SAP Note 862989: New password rules as of SAP NetWeaver 2004s
- SAP Note 874738: New password hash calculation procedure (code version E)
- SAP Note 991968: Value list for login/password_hash_algorithm
- SAP Note 1023437: Downwardly incompatible passwords since NW2004s
- SAP Note 1237762: Protection against password hash attacks
- SAP Note 1300104: CUA - New password hash procedures - Background information
- SAP Note 1458262: Recommended settings for password hash algorithms
- SAP Note 1484692: Protect read access to password hash value tables
- SAP Note 1488159: SUIM - RSUSR003 - Incorrect results for CODVN = F
- Openwall Wiki: Excerpts from john-users mailing list ← search for "SAP"
- Paper: "Perfect Storm - The Brave New World of SAP Security"
- Paper: "SAP Passwort Sicherheit" (2004) – German
- Onapsis has 2 great articles:
Happy reading — this is really helpful stuff! 😛
if you ever wanted to determine the transaction type (dialog, parameter tcode …) and status (locked …), you probably came across table TSTC (where tcodes are defined) and found that this information is encoded in the CINFO field — which contains an old-school hexadecimal value.
So… wtf do those CINFO values mean? Here we go:
|CINFO (hex)||Binary||Type||Locked ?||Auth. object check ?|
|0x00||0000 0000||Dialog transaction||no||no|
|0x04||0000 0100||Dialog transaction||no||yes|
|0x20||0010 0000||Dialog transaction||yes||no|
|0x24||0010 0100||Dialog transaction||yes||yes|
|0x01||0000 0001||Area menu (obsolete)||no||-|
|0x21||0010 0001||Area menu (obsolete)||yes||-|
|0x02||0000 0010||Parameter / variant transaction||no||-|
|0x22||0010 0010||Parameter / variant transaction||yes||-|
|0x08||0000 1000||Object transaction||no||no|
|0x0C||0000 1100||Object transaction||no||yes|
|0x28||0010 1000||Object transaction||yes||no|
|0x2C||0010 1100||Object transaction||yes||yes|
|0x80||1000 0000||Report transaction||no||no|
|0x84||1000 0100||Report transaction||no||yes|
|0xA0||1010 0000||Report transaction||yes||no|
|0xA4||1010 0100||Report transaction||yes||yes|
|0x90||1001 0000||Report transaction with variant||no||no|
|0x94||1001 0100||Report transaction with variant||no||yes|
|0xB0||1011 0000||Report transaction with variant||yes||no|
|0xB4||1011 0100||Report transaction with variant||yes||yes|
|0x05 (invalid)||0000 0101||Area menu (obsolete)||no||-|
|0x06 (invalid)||0000 0110||Object transaction -or-|
|0x44 (invalid)||0100 0100||Dialog transaction||no||yes|
(The CINFO values marked with "invalid" exist, but make no sense… probably because they're relicts created by SAP a long time ago. 😯 )
According to the above, these are the bitmasks for your own program:
|0x00||0000 0000||Dialog transaction|
|0x01||0000 0001||Area menu|
|0x02||0000 0010||Parameter / variant transaction|
|0x08||0000 1000||Object transaction|
|0x80||1000 0000||Report transaction|
|0x90||1001 0000||Report transaction with variant|
|0x04||0000 0100||Flag: Authorization object check ?|
|0x20||0010 0000||Flag: Locked ?|
To get started, either have a look at the report "RSAUDITC_BCE" or try this:
REPORT. TABLES: tstc. * -- Bitmasks DATA: c_auth TYPE x VALUE '04', c_lock TYPE x VALUE '20'. * -- Find all locked transactions SELECT * FROM tstc. CHECK tstc-cinfo O c_lock. WRITE: / tstc-tcode, 'is locked'. ENDSELECT. * -- Find customer transactions w/o authorization check SELECT * FROM tstc WHERE tcode LIKE 'Y%' OR tcode LIKE 'Z%'. CHECK NOT tstc-cinfo O c_auth. WRITE: / tstc-tcode, 'has no authorization check'. ENDSELECT.
did you ever wonder, what's behind the button "Import from file" in PFCG's Menu tab?
Well, it obviously allows you to upload a menu from a file, but expects a special file format: SAP Note 389675 has the details. You won't find this format anywhere in PFCG or elsewhere in your system, so it has to be created by you…
This usually makes the "Import from file" button hard to use and thus unpreferable!
Let's say, you're trying to revise (and minimize) the authorization in a SAP client ex post, i.e. when the system has been in use for some while and nobody took care of proper roles. Moreover some (key-) users might already have created their own favorites, which – hopefully – reflect their tasks in the system.
Wouldn't it be nice to be able to import those user favorites to a role and build adequate authorizations this way? Still there will be much to analyze and adjust — but it might be a good starting point!
A user's favorites are stored in the table SMEN_BUFFC and SMEN_BUFFI (for the various kinds of link targets). So this is the place we'll get the menu data from.
The file format from the above mentioned SAP Note 389675 only supports a subset of all possible favorite types: folders, transaction codes, URLs, Knowledge Warehouse links and custom types (we won't deal with the last-mentioned one).
So in addition to reading and converting the favorites, we'll have to filter out all unsupported types of favorites.
Here's how to create the program that does the work:
- Create a new report in SE38 and paste this source code (don't forget to set a program authorization group).
- In the selection texts, tick "dictionary reference" for all parameters.
- Activate & execute the program.
The selection screen allows you to select:
- the user from whom to read the favorites and
- an optional file to save the data to.
Once started, the report prints the converted favorites on screen and optionally saves it to the specified file.
You might want to customize the report to download the favorites of several users at once — but be aware that you'll have to either save each user's favorites to its own file or deal with duplicate object IDs (and parent IDs and the sort order …)!
If you're interested in role menus, you might want to check the AGR_HIER* tables.
😀 Have fun!
this week, a colleague pointed me to the possibility to hook your own code into SAP GUI downloads via a user-exit. Since downloads are always a big security - and data protection topic, I took a closer look.
Generic download authorization: S_GUI
When downloading data to the frontend, the authorization object S_GUI is checked (with ACTVT 61). This is a very unspecific check, as it does not take the affected data into account – if you have appropriate authorizations, you can download roles, the SFLIGHT table or your colleagues' salary. It's just a client-wide "switch", which either allows or disallows downloads. Many authorization admins don't pay much attention to S_GUI, but rather focus on data access authorization objects. Anyway this is not sufficient, as downloaded data may be passed to third-parties easily or analyzed inappropriately.
SAP offers 2 user-exits to extend download authorization checks:
- SGRPDL00 — User-exit for "normal" SAP GUI downloads
- HRPC0001 — User-exit for HR-specific downloads; logical databases: PNP (HR master data) and PAP (recruitment data)
The first one is called by the GUI_DOWNLOAD function module – i.e. for each and every frontend download, while the second one is HCM-specific. To get started, I decided to inspect SGRPDL00, as this one has the best coverage.
User-exit SGRPDL00: Creation
First of all, we need to create an add-on project via tcode CMOD to implement the user-exit.
Enter the project name "SGRPDL00", click on "Create", enter the project attributes and then go for "Enhancement assignments". When you're prompted to save, say "Yes" (← hard decision) and choose a package ("Local object" is fine, if you're just playing around).
After that, enter "SGRPDL00" as the enhancement name, click on "Components" and double click on the function exit name:
Since you don't want to modify the SAP standard function module, double click on the include ZXFILU01. SAP tries to baffle you with a warning message:
… nice try, but just press Enter and you'll be prompted, whether you'd like to create the include. After ticking "Yes", you can start to implement the code, which will be called during every frontend download.
User-exit SGRPDL00: Implementation
The function module EXIT_SAPLGRAP_001, in which our code runs, provides 2 input parameters:
- IS_LIST_DOWNLOAD — whether the user is downloading a list (Standard list or ALV)
- NO_AUTH_CHECK — whether the GUI_DOWNLOAD function module was asked to not check S_GUI
and allows throwing the exception "NO_AUTHORITY" – which means that the download is forbidden.
Paste this code to get you started, activate it and don't forget to activate the user-exit itself.
The above code is a documented example… you'll for sure want to add your own code there; anyway it demonstrates a bunch of possibilities. One of the most interesting aspects is that it creates an Application Log entry for every download. Although the Security Audit Log provides similar functionality, it's possible to add additional information – the table name for SE16 in the above example code.
Unfortunately, you don't have access to all variables from the calling program… which makes it a bit difficult to add useful information (have a look at how the include gets the table name for SE16). If anybody has a better idea, please tell me.
The user-exit HRPC0001 is specific to HR/HCM and works a bit different. The implementation in include ZXP04U02 does not perform any check itself, but is rather expected to return a report and form name. This form is responsible for the check and may be located within the calling report's context – thus enabling your code to access any global variable therein. This way you can take the HCM-specific context into account to determine whether the download is okay or not.
When copying data to the clipboard, S_GUI is not triggered – SAP Note 997201 provides a solution at the cost of a modification.
- Uploads are not covered.
- Non-GUI downloads are not covered (BEx, Portal, …)
- If you mainly need reliable logging for each and every client, you might want to check the SAP UI Logging solution.