You might be faced with the task to create a really comprehensive user listing for a SAP system with several productive clients – even including 000 and 066.
This is usually a boring task, as you have to log in to every client… gather the list… proceed to the next client… and so on…
Apart from dying of boredom you might run into the problem of not having access to all clients (e.g. 066). 😕
Write a report like this:
REPORT. TABLES: usr02. SELECT * FROM usr02 CLIENT SPECIFIED ORDER BY mandt. WRITE: / usr02-mandt, usr02-bname. ENDSELECT.
Pro: Easy, simple, fast.
Con: Has to be transported, protected… and using "CLIENT SPECIFIED" is considered bad code by many companies!
Use the report RSUVM005, which is intended for system measurement: it gives you a list of (almost!) all users on the clients you specify on the selection screen.
Still the list is missing a few users, because SAP quite rightly considers them irrelevant for licensing — they are automatically filtered out by the report (or more specifically: by the function module SLIM_EXCLUDE_USER):
|SAP client||Excluded user|
|( all other clients )||ALEREMOTE|
To get the comprehensive user listing, we just need a cross-client selection for those excluded user names in addition.
Fortunately you can simply achieve this via tcode SM21 and (mis-)use the "User" field to check for the existence of the missing users on other clients.
Now you can compile the cross-client user listing from within one client…
let's have a look at a very handy system parameter, which is nevertheless not checked as frequently as others in audits — the tp parameter VERS_AT_IMP.
In a default installation this parameter is set to »NEVER«, which means that no new version is created when transporting a program to a target system; the code is simply overwritten there.
If the parameter is set to »ALWAYS« (which is the only other valid option), a version history is maintained analogous to the development system.
Btw.: not only reports are affected by this, but actually all workbench objects that support versioning.
Why does that matter?
The legal codes of many (all?) countries prescribe a duty to preserve records, which is also relevant for program code – the German HGB (Handelsgesetzbuch) for instance. Therefore it is a risk to allow old program versions to be deleted (due to a lack of knowledge – or on purpose).
Developers are usually allowed to execute all reports on a development system, which also includes RSVCAD03 and RSVCAD04. These reports allow the deletion of a program's version history (they're NOT assigned to any program authorization group
and the program code does NOT contain any AUTHORITY-CHECKs ← read comments below).
Update: Meanwhile SAP has added an authorization check for S_CTS_ADMI with value TABL to both programs. Anyway, this authorization is checked in many places and chances are high that a number of users have (and need) this authorization for other purposes. So this does not change the general recommendation of this article…
So your options are:
- if you want to keep the version history on the development system: do whatever it takes to secure RSVCAD03 and RSVCAD04 (just removing S_CTS_ADMI from all roles will not work, especially on non-productive systems) and be careful when restoring the system; you might lose versions (think of reinstallations)
- set VERS_AT_IMP to »ALWAYS« on the productive system and keep your version history there (of course the above reports have to be secured as well)
As you probably guessed, the second option is favorable, because:
- authorizations on production are much more limited, so protecting the reports RSVCAD03/04 is much easier there
- the continuity of a productive system can be ensured, while this is not true for a development system
Where to check it?
Start report RSTMSTPP, enter the productive system's SID and go for it.
Where to set it?
Go to STMS → System Overview. Then double-click in your productive system and switch to the "Transport Tool" tab.
If the parameter does not appear there, it is set to the default value »NEVER«!
Update: Effect on installation of support packages
Switching the parameter to ALWAYS has no automatic effect on transaction SPAM. In other words: installing support packages does not lead numerous (useless) versions of SAP standard objects.
The simple reason is that SPAM allows you to choose whether to create versions of the objects in support packages or not (→ disabled per default).
To enable it, setting VERS_AT_IMP to ALWAYS is a prerequisite — check out SPAM → Extras → Setting → Import queue → Create object versions during import — but be aware that this might have an impact on performance and database size.
Hi authorization admins,
from time to time I get in the mood to clean up one or two SAP systems – and lately I was looking for obsolete roles, which weren't assigned to anybody for ages (e.g. used at least 365 days ago).
While looking around in SUIM and change documents, the developer inside me became more and more delighted – because there is no SAP standard solution for this → time for some R&D. 😛
Here we go:
- Create a new report in SE38 and paste this source code (don't forget to set a program authorization group *cough*).
- There's no need to edit any of the selection texts, as they're defined inside the report…
- Activate & execute the program.
The report allows you to select:
- the role names (all SAP standard roles excluded per default),
- the user who created the role (default exclusion: "SAP") and
- the days since the role's last assignment to any user (default: 180).
The result consists of the following columns:
- Role: … well… the role name
- Creation date: the role's creation date
- Change date: the date of the role's last change
- Removal date: the date of the last removal from a user
- Removed by: the user, who performed the removal
- Role name: the role description
- 3 status indicator fields:
The role type shows, whether it is a single or composite role (using the standard SAP icons).
This icon equals to the traffic light icons on PFCG's "Authorizations" tab (→ green: generated, yellow: action required, red: not generated).
For composite roles this field stays empty (since they have no profile).
SR used in CR:
For single roles, this icon indicates if the role is assigned to a composite role (glowing bulb) or not (dark bulb).
Of course this makes no sense for composite roles – so the field is empty then.
Obsolete / superfluous / unused roles on productive systems should be removed before they get moldy!
😀 Happy Xmas 😀
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! 😛