Dangers in SAP Transport Management: Part 3
Manipulation of the SAP Job Management
This is part three of our blog series on the Dangers in SAP Transport Management. In part one, we give an intro to SAP Transports. In part two, we went over the starting point of this attack, the transaction SU24. In this third installment, we’re focused on the manipulation of job management and its associated risks to SAP Transports.
Job Management in SAP® poses a big attack surface for external manipulation. The possibilities range from abusing the vulnerabilities of certain SAP standard jobs allowing critical job attributes to be changed, to completely defining and scheduling jobs via transport request.
Every SAP Basis administrator knows the job SAP_COLLECTOR_FOR_PERFMONITOR. It collects statistical data from files and inserts them into tables, which can be read and processed by transactions such as ST03 and ST03N. For this, the job uses several reports, which it reads from the table TCOLL. Though there is a check of added reports against the fixed values of the domain COLL_RNAME while manually maintaining this table, impeding abuse, one can add arbitrary reports via transport. In that case, the reports to be executed from the table TCOLL are not checked against the fixed values of the domain when the job is started by SAP_COLLECTOR_FOR_PERFMONITOR. Furthermore, the job SAP_COLLECTOR_FOR_PERFMONITOR is run in the context of the user DDIC or an equivalent user, meaning that attackers will rarely encounter authorization issues. Though the job runs in the client 000, this is no real limitation for an attack.
Starting with SAP S/4HANA, SAP has introduced a new job repository for standard system jobs. The new transaction SJOBREPO has been introduced that allows authorized users to display and customize existing job definitions to a certain degree. It is also possible to completely deactivate the execution of individual jobs.
More interesting is the fact that SAP has also introduced the new transport object R3TR JOBD together with the new job repository. You can now create job definitions via transaction SE80 on the development system and transport them in a “legal” way to production! This means maximum attention is required when approving such a transport request for production. In early S/4HANA versions the jobs run in the context of the fixed standard user SAP_SYSTEM with profile SAP_ALL. In newer versions, it is possible to define a default user per client (the restriction to client 000 no longer exists) that does not necessarily need SAP_ALL. Nevertheless, SAP recommends assigning at least a generic authorization for all SAP Basis and all SAP HR authorization objects (See SAP Note #2731999). Being aware of the special attention that might be paid to the object R3TR JOBD, attackers might camouflage an attack via the job repository by transporting the individual tables that define a JOBD object instead.
But an attacker is not limited by standard system jobs and can also misuse the common background processing architecture for an attack.
In general, as long as an attacker knows the internal job number, any existing job can be used as a Trojan horse for attacks. Examples are:
- Adding/editing/deleting job steps
- Changing the executing user of a job step
- Changing the status of a job
If the job number is unknown, an attacker can define and schedule a completely new job in a production system via transport. For this, the three tables TBTCO, TBTCP and TBTCS are sufficient.
What does this mean for people approving transport requests or change requests for production?
The following objects need careful investigation:
- R3TR TABU TCOLL
- Possible attack attempt
- If it is not a report, which is defined as a set value of the domain COLL_RNAME, an attack attempt is highly probable!
- Transports to the content of the table TCOLL should be prohibited in general
- R3TR JOBD
- Clarify the reasons for extending the list of system standard jobs
- Check if the corresponding report cannot be scheduled as a general job in SM36
- R3TR TABU STJR_JOBD_ROOT, STJR_JOBD_TREP
- Definite attack attempt!
- Someone is aware of the special attention that is paid to new job definition object R3TR JOBD and tries to bypass the security checks by transporting the individual tables
- R3TR TABU TBTC*
- Definite attack attempt!
Someone is trying to circumvent the job management system from the outside in order to manipulate existing jobs or to define and include new jobs
- Definite attack attempt!
In order to further mask an attack, entries of the tables mentioned above can be concealed within a superordinate object. These include:
- View Cluster (R3TR CDAT <random object name>)
- Maintenance View (R3TR VDAT <random object name>)
- Customizing Data (R3TR TDAT <random object name>)
In these cases, an entry also has to be considered to be a definitive attack attempt. Only checking every transport request, as mentioned in our previous blog posts, helps against such an attack.
*This test, and over 100 others, are conducted automatically in The Onapsis Platform for both internal and external transport objects. Read the SAP Transport Inspection Application note (PDF) for additional details on how the technology works and how it can be integrated into your business process with The Onapsis Platform.