Greetings to everybody!
In this post, we’ll examine a way to doctor transport requests, which can be used with malicious intent, but potentially also as a “quick fix” by admins. The goal is to identify the involved tools and related authorizations to secure your SAP systems against such manipulations… as far as possible!
Report RDDIT076
Let’s start with the offender itself:
Report RDDIT076 allows you to select an existing transport request (or transport task) and edit many of its attributes.
As an example, we assume an unreleased workbench request (type “K”). That request contains a single task, which in turn consists of a repair… e.g. a changed report.
To make it interesting, we assume that the modified report copies the profile SAP_ALL to our user’s authorization buffer once we start it (that gives us all authorizations without any traces). As the assumed code checks for SY-UNAME, it only works for one user (in the example that’s me: DBERLIN). There’s only a very shallow code-check during transport… so the chance of being caught is small! 🥳
But wait… we absolutely don’t want to be caught. Really not! So just in case our malicious code change is detected, let’s blame someone else!
Let’s see what RDDIT076 can do for us:
Okay – the title of the transport request is a bit too honest and we could easily have chosen a better one. The problem is: my user DBERLIN is the owner of both the request and the task and will be blamed for its contents. Fortunately, we can simply edit both entries:
We adjust the description and set a new owner: our estimated colleague Frank Grimes (FGRIMES).
Save and repeat for the task!
The scenarios
In our example we assumed a malicious, internal developer… but that’s not the only situation, in which the report might be (mis-)used. We have to differentiate between three scenarios:
- justified usage (e.g. by a developer, who needs to cope with a particular situation)
- sloppy usage (e.g. an admin, who favors “shortcuts” instead of the longer standard process)
- malicious usage (e.g. to hide the origin of manipulative code in a transport request)
The first case is generally acceptable, but it must be ensured that the possibility to use RDDIT076 is not misused. That will turn out to be challenging and I doubt that such cases exist.
The second “sloppy” case is not easy to prove for an auditor, because there’s always a “good” reason, why a change had to be fast and the usual process would’ve been too slow… so people might try to sell the second case for the first one.
Lastly, the third case is what our example is based on – an intentional attempt to maliciously exploit the SAP system. That’s the most obvious case, but when cleaning up your system, always keep in mind that the other two cases exist as well (and are probably more likely 🤔).
How to prevent it
Access
RDDIT076 is a report without an assigned authorization group and there is no associated transaction code – so to block access, you should take care of program execution rights, for example:
- SA38: only S_PROGRAM is checked with P_ACTION = SUBMIT
- SE38: first, S_DEVELOP with ACTVT = 03 and 16, OBJNAME = RDDIT076 and OBJTYPE = PROG is checked, then additionally S_PROGRAM (see above)
- START_REPORT: only S_TCODE with START_REPORT is checked… nothing else 🙄
Program execution rights should generally only be granted to few, carefully chosen users – especially because there is no way to do it in a granular way (i.e. without a program authorization group).
Authorizations
There are some, but not many authorizations necessary to run RDDIT076:
- S_TRANSPRT with ACTVT = 03 to select the transport request and read its contents
- S_CTS_ADMI with CTS_ADMFCT = TABL as a “general” protection
- and S_DATASET with ACTVT = 34 (write), PROGRAM = SAPLSTRF and FILENAME = <DIR_TRANS>/actlog/<LOGFILE>
The first two authorizations are administrative rights that can be used to limit the usage of the report and which should only be granted to few users! The third authorization is checked, when a log file is written – so in case this right is not granted, no log would be written… which is counterproductive!
The hard truth
In the end, you’ll probably end up with a few users that have the necessary rights to use the report and can thus manipulate transport requests. The reason is that only a few generic authorizations are checked in RDDIT076 and all those rights are needed in other places as well… at least by SAP basis (on DEV and maybe also PROD) and developers (on DEV).
From an audit perspective, a residual risk remains after the first cleanup. You could further reduce it by additional measures… for example, you could assign the report to an authorization group (so that the S_PROGRAM check is more specific) and make sure that other ways to execute it, e.g. START_REPORT, are removed from all roles. That’s feasible, but difficult for a rather small gain in security… and most people will probably not want to change the attributes of an SAP standard report.
Another option would be an ex-post control – but then we’d need a good log of the actions performed in RDDIT076. In the next chapter “How to detect it” we’ll see that logging exists, but is far from being detailed enough. Other ways to trace such administrative activities, such as SAP UI Logging, are usually complex and expensive.
So, the hard truth is that RDDIT076 is a candidate for risk acceptance…
How to detect it
As stated above, changes performed in RDDIT076 lead to log files being written to <DIR_TRANS>/actlog/<LOGFILE>, if the S_DATASET authorizations allow it. One log file is used per transport request/task number.
Such a file, unfortunately, contains only minimal information… the example from the beginning of this article leads to two log files. One for the transport request and one for the contained task. Both files contain one line similar to the following:
1 ETR018 "05.04.2020 16:15:30" request/task "NSPK900042" was changed by user "DBERLIN"
No information about what was changed…
That’s not enough data for a sensible ex-post control!
The bottom line
I’d suggest removing the involved authorizations from all users that don’t need it – the remaining users should be administrative ones only.
Admins should have separate users (and rights) for “employee tasks”, e.g. time management, day-to-day administration and extended admin-tasks. At least the latter user should be logged extensively. Logs should be monitored for the usage of RDDIT076 and – in case of matches – the logfiles should be inspected.
That’s not bulletproof, but the best approach possible without disproportionate effort… at least IMHO…
Bye and see you soon!
