Sniffing SAP GUI passwords // Part 1


Hey security folks,

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.

Test setup

In the below tests, I’ll log in 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 tools below:

  • 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 its usage a bit unclear — so this is what needs to be done:

  1. Start the sniffer,
  2. switch to the “Sniffer” tab,
  3. select the “Passwords” section,
  4. choose the “SAP Diag” entry and
  5. 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 it 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!

Further reading

See you next time!

+++ End of article +++
+++ Begin of article +++

SAP password hash algorithms


Hi there,

in this article, I’ll summarize, what I found out about SAP’s password storage mechanism (for SU01 users, not the SecStore).

Basics

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!

Hash algorithms

This table summarizes the details of all currently available password hash algorithms (as per Q4/2012):

USR02-
CODVN
Algo-
rithm
Max. Passw. LengthPw.
Case
CharsetSaltNotesSAP NoteHash in
USR02-...
A?8upperASCII
(limited)
Character 1-6 of the username
(upper-case)
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).
721119BCODE
BMD5-based8upperASCII
(limited)
Username
(upper-case)
Unsupported characters (see note) in the password and salt are replaced by »^«735356BCODE
C-Never implemented-
DMD5-based8upperUTF-8Username
(upper-case)
Superseded by code version E
(but almost identical)
-BCODE
EMD5-based8upperUTF-8Username
(upper-case)
Correction of code version D874738BCODE
FSHA1-based40sensitiveUTF-8Username
(upper-case)
-1488159PASSCODE
G= Code versions B & FBCODE &
PASSCODE
Hgeneric hash
(curr. only iSSHA-1)
40sensitiveUTF-8randomHash algorithm and options can be set via parameter login/password_hash_algorithm991968PWDSALTEDHASH
I= Code versions B, F & HBCODE,
PASSCODE &
PWDSALTEDHASH

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_charset
    • 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

Happy reading — these links contain really helpful hints! 😛

+++ End of article +++
+++ Begin of article +++

Determine transaction type & status from table TSTC (field CINFO)


Hello!

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.

Meaning

So… what do those CINFO values mean? Here we go:

CINFO (hex)BinaryTypeLocked ?Auth. object check ?
0x000000 0000Dialog transactionnono
0x040000 0100Dialog transactionnoyes
0x200010 0000Dialog transactionyesno
0x240010 0100Dialog transactionyesyes
0x010000 0001Area menu (obsolete)no-
0x210010 0001Area menu (obsolete)yes-
0x020000 0010Parameter / variant transactionno-
0x220010 0010Parameter / variant transactionyes-
0x080000 1000Object transactionnono
0x0C0000 1100Object transactionnoyes
0x280010 1000Object transactionyesno
0x2C0010 1100Object transactionyesyes
0x801000 0000Report transactionnono
0x841000 0100Report transactionnoyes
0xA01010 0000Report transactionyesno
0xA41010 0100Report transactionyesyes
0x901001 0000Report transaction with variantnono
0x941001 0100Report transaction with variantnoyes
0xB01011 0000Report transaction with variantyesno
0xB41011 0100Report transaction with variantyesyes
0x05 (invalid)0000 0101Area menu (obsolete)no-
0x06 (invalid)0000 0110Object transaction -or-
Parameter transaction
no
no
yes
n/a
0x44 (invalid)0100 0100Dialog transactionnoyes

(The CINFO values marked with “invalid” exist, but make no sense… probably because they’re relicts created by SAP a long time ago. 😯 )

Bitmasks

According to the above, these are the bitmasks (for use in your own programs):

Bitmask (hex)BinaryMeaning
0x000000 0000Dialog transaction
0x010000 0001Area menu
0x020000 0010Parameter / variant transaction
0x080000 1000Object transaction
0x801000 0000Report transaction
0x901001 0000Report transaction with variant
0x040000 0100Flag: Authorization object check ?
0x200010 0000Flag: Locked ?

Example

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.

See you!

+++ End of article +++