Securing Your SAP and Securing the Security of Your SAP

In June 2019, just one month after the advisory from US-CERT regarding 10KBlaze, CSO published an interview with Juan Perez-Etchegoyen, CTO of Onapsis, Jonathan Haun, senior director at Enowa LLC and Gert Schroeter, vice president of security communications at SAP Global Security. In this interview, they described eight of the top most common configuration errors and security failures within enterprise SAP environments. The full article can be found here.

Optimists might assume that these errors and failures are always caused by missing sensitivity regarding system security, a lack of knowledge or missing resources, but realists must face the facts—all of these situations can also be created intentionally by an attacker in order to exploit them at a later point in time. In my webcast There’s a Ghost in your SAP, I explain how any table data can be transported hidden and unnoticed into production.

Considering the fact that most security attacks and data breaches are initiated by insiders, the transport of critical configuration data should be considered to be one easy way of opening the SAP system for malicious activities. Therefore, I want to delve deeper and analyze each of the eight configuration errors and security failures with regard to the involved tables. The transport of these tables must definitely be monitored intensively—no matter if they are transported directly, via a maintenance view or view cluster or even hidden.

1. Misconfigured ACL’s

Most of the important access control lists are stored in files on the operating system level. Nevertheless, some critical ACLs are stored in database tables. The same applies to general whitelists. Examples are:

Securing your SAP and securing the Security of your SAP

2. Weak User Access Controls

Hard to believe, but it is possible to transport a complete user record into a production system. Just insert the appropriate USR02 record into a transport request. Authorizations are needed? OK, then how about mapping the new user to a reference user via table USREF? Do you have an external user identity management product in place? Just map the external ID to the SAP user, you want to impersonate (give SAP* a try). Here is an extract of the most critical tables:

Securing your SAP and securing the Security of your SAP

3. Insecure Custom Code

There are types of code that can be changed very easily through table manipulation. E.g. global macros are stored in transparent table TRMAC, SQL Scripts for SAP on MS SQL are managed by transparent table MSSSOURCE. Especially with the later one, it is very easy to inject code into production that leads to a complete deletion of the database.

4. Sloppy Patch Management

The information about a patch being supplied or not can also be manipulated. An attacker could change this sensitive data in order to pretend that specific security threats are already solved in the system while they aren’t. There are 44 CWB* tables (SAP NW 7.50) that contain status and content information about notes and corrections applied.

5. Unprotected Data

Sensitive data not only has to be encrypted in transit and at rest—proper authorization for reading and/or changing data is also important. Unfortunately, there are some tables that can be manipulated to control if authorization checks on certain authorization objects in ABAP code are really processed by the system or not:

Securing Your Sap and Securing the Security of Your Sap

6. Poor password management

SAP users often use the same password in all systems. If passwords are weak or if the user record contains old hash values that were created based on already broken hash algorithms (because they are needed for communication with legacy systems or they were simply forgotten to be deleted), all tables containing password hash values represent a potential security issue as they can be exported from the system and afterward be used for password hash attacks. These tables are:

Securing your SAP and securing the Security of your SAP

7. Failure to Have an Emergency Response Plan

One step of a response plan is the forensic analysis of the cause and the initiator of a system outage, data manipulation or data breach. The reliability of logged data depends on how well it is protected against manipulation. Most of the logged events are stored in tables:

Failure to have an emergency response plan

8. Inadequate logging and auditing

Ensuring the stability and integrity of the log configuration data is as important as securing the already logged data. Only if serious events are continuously identified and tracked, they can be properly analyzed in case of an attack scenario. Involved tables are:

inadequate

Conclusion

ERP systems contain the crown jewels of an enterprise. Proper system configuration in SAP is key for not becoming a victim of cyberattacks and data breaches. While it’s already a challenge to always stay up-to-date with all security settings and patches, a secure system configuration could always be a subject of a malicious manipulation in order to prepare a future attack. Another aspect is the deletion of security-relevant log data that could make forensic analysis impossible after an attack. As most of the affected configuration and log data is stored in tables, it can easily be manipulated through transports. This outlines the importance of monitoring all transports very carefully. Given the high number of transport requests and objects that are moved through the SAP landscapes, an automatic scan and analysis of all transport requests is highly recommended. Last but not least, transports can also be misused to execute any type of ABAP and SQL Code as well as a wide range of operating system commands on a production system.

For further information, have a look into my webcast, There’s a Ghost in your SAP.