English | Deutsch | Español

How you can Hack any SAP® System through Transports unnoticed

July 5, 2018 | From Lars Kehrel

Cardboard boxes on white backgroundAt this year's ASUG Conference in the USA, SAP’s CSO presented 10 topics that are highly relevant for the security of SAP® systems. These include areas such as network and database security, authorizations and code security. However, two very important areas were missing in this overview: the safeguarding of interfaces and the security of transports. In our opinion, the lack of these areas in many lists is a major omission.  

Why transport entail a great risk

Productive systems are generally well protected, and security is a top priority. However, the situation is different with the upstream systems, i.e. the quality systems and especially the development systems. Users usually have extensive authorizations here and can also make major changes. SAP Transport Management allows you to transport changes from these systems to the production system. With the right know-how, these changes are disguised in a way that will not be detected by regular control instances or manual samples. Since transport requests are imported into the system landscape both from within the company and from third parties, insider and outsider attacks are possible.

Did you know that...

- ... any table data can be transported into production completely unnoticed?

- ... you can assume any identity by transporting a single object entry?

- ... a production system can be completely deleted by transporting a single object entry?

- ... one, several or all authorization checks can be deactivated by transport?

Practical Example 1: Double your salary

In HR table PA0008, column ANSAL contains the annual salary of the corresponding master data record. This entry could be changed quite easily in the development system. But you wouldn't get more money out of it just yet. This table entry must first be inserted into the production system without being noticed. For this purpose, we are looking for a transport requests into which we can slip the change. A logical customizing object should exist on this transport. Roles are well suited for this purpose, for example. The desired change of P0008 can now be entered here. When you call up the logical object in detail, a dynamically generated simulation is displayed, not the data that actually exists in the transport request. This makes the built-in changes very easy to hide.  If this transport request is exported and imported elsewhere, the required field is overwritten in the target system. Afterwards the tracks can easily be covered again. Now this manipulation can hardly be detected. In our webinar on this topic, our expert Thomas Fritsch shows how this can look in detail.

Practical Example 2: Taking over a foreign identity

Single Sign-On makes working with SAP systems faster and more convenient for the user, because you do not have to enter the user name and password every time you log on to an SAP system. For an attacker, however, this also offers new possibilities to penetrate SAP systems with foreign identities and, for example, to obtain far-reaching authorizations and gain access to protected data.

Technically, the identity of the user in the SSO solution is mapped to the corresponding SAP user for single sign-on. This is done in table USRACL. Obtaining the identity of a user with extensive authorizations in the production system is therefore comparatively easy. You can simply assign your own user in the SSO solution to an SAP standard user - such as SAP*. You may not have the authorization to doo so in the production system, but with the help of the logical customizing objects, see the previous example, it is also quite easy to conceal it here.

Practical Example 3: Completely deleting a system with only one transport

The most frightening example of an attack is the possibility of completely deleting an SAP system with just one entry. This is also made possible by the content obfuscation described above, using logical customizing objects.

To perform this attack, a specific database object is required. This contains a short command for deleting the database in the target system. Normally, the system should not execute such a command. However, the selected database object contains an "after-import method" - which says nothing more than that a specific function module is being executed automatically after the transport has been imported. If the command for deleting the database is now added to this function module, the deletion of the system is pre-programmed in the truest sense of the word.

These examples show that with sufficient know-how it is not only possible, but even relatively easy to successfully attack SAP systems. Possible defense strategies fail, however, primarily because it is technically almost impossible to check a transport for such security problems before importing it into an SAP System. With Virtual Forge's TransportProfiler, it is possible to examine transports before they are imported into a target system not only for security risks, but also for possible stability problems and data damage. Supported by the CodeProfiler for ABAP, which is also integrated into the release process, transports can be comprehensively checked in advance.

The Virtual Forge Security Suite as a Service even goes one step further and enables the checking of transports from a third-party provider, to name one example, without even having to bring them into the system landscape. The web-based approach identifies potential risks in advance and presents them in a clear report.

More information about Virtual Forge Security Suite as a Service is available here.


Update: Please find more information from SAP here (SAP Note 2671160).

Topics: UnderstandYourRisk, Transport Security