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

Mehr hier.