How to Hack SAP®

How to Hack SAP®

moshe panzerThis article deals with application security level only, providing explanations and examples pertaining to reducing business risk, protecting your enterprise's SAP applications and identifying hackers. The article is brought to you by Moshe Panzer, CEO of Xpandion, and is based on the company's vast experience in revealing, alerting and protecting global enterprises and businesses from fraud and data leakage.

All scenarios and methods described in this article are not merely theoretical ideas, but have been applied successfully in many cases; hence the importance of thoroughly reading this guide and verifying the effectiveness and reliability of solutions implemented in your organization.

General

The term SAP hacking is used by two different groups. The first group is comprised of system administrators and technically-oriented security consultants, who refer to hacking as breaking into an organization's underlying database (e.g., SQL Server, Oracle, DB2) and obtaining raw data from it.
The second group consists of application-oriented security consultants, CISOs, risk managers, GRC (Governance, Risk & Compliance) managers and auditors, who refer to hacking as manipulating SAP in order to transfer money to different bank accounts, download restricted information such as fully detailed customer/employee lists, change employee salaries, etc. Hacking in this case may begin in merely manipulating the SAP system; however this often ends up turning into actual fraud, particularly as a hacker can easily pretend to be a legitimate user in the organization – and then it becomes almost impossible to trace such manipulations.
The main differences between the two groups of hackers and the outcome are summarized below:

   

Hacking SAP Database

 

Manipulate SAP System

Orientation

 

 

Classic hacking, breaking into database Legitimate actions that evolve into fraud, or manipulations of SAP to gain personal benefits unlawfully

Method

 

 

 

Breaking into SAP underlying database Pretending to be a legitimate user (or actually being a legitimate user) and performing activities inside the SAP system

Direction

 

 

From outside the system into the system (database) From outside the system into the system (Remote Function Call), From inside the system (using GUI), from the system outside the organization (transfer money, send invoices)

Required
Knowledge

 

 

Network, Operating System Applicative SAP knowledge (Financial, HCM) combined with technical ABAP and infrastructure

Examples

 

 

Transferring raw table data Transferring money to different accounts, creating fake vendors, obtaining sensitive data of customers/employees

Security
Awareness

 

 

Very high, performed with regular database tools Low, requires high level of expertise (applicative and technical)

Clarifications

  • This research is based on de-facto experience, nevertheless methods which can potentially put a company at risk, will not be discussed under the code of honor we hold by at Xpandion.
  • Organizations may hold several versions of SAP systems; in some cases two different SAP versions of the same product (e.g., SAP ERP) are installed in the same organization. Each version includes many support packages (fixes and enhancements), which need to be installed to solve certain issues, and the functionality of them is different in each organization.
  • Each organization develops additional functionality over their SAP machines, with or without proper security standards, which makes fraud possibilities almost infinite.

Assumptions

  • We assume standard security policies are implemented in your organization, therefore we will not advise on issues like verifying that the number of incorrect logins is set correctly, forcing complicated passwords and checking them via known passwords, and so on.
  • Common risks will be described in detail alongside strong possible solutions. However, for obvious precautions against reading hackers, we will describe how to perform the risk in a general manner only.

Flaws Call for Fraud

Sophisticated, complicated and highly complex, the SAP system – if not well maintained, controlled and comprehended – can conveniently turn into an environment that permits wrongful manipulations. We have witnessed several cases where manipulations of SAP begin at the level of "legitimate" business actions, and slowly but surely turn into various forms of fraud. We strongly recommend enterprises to take the following flaws into account and apply automatic actions to control them in order to achieve a highly secure and controlled SAP environment:

Complexity

Due to the complexity of the SAP authorization model, granting the right authorizations to users and maintaining it, is a highly complicated task in most companies. Furthermore, as more unique authorization roles are added, more maintenance efforts are required, complicating things even more. Therefore most organizations settle for a standard schema of authorizations and roles, which can be maintained with basic resources only.
Even if assumed that when "going live" authorizations were defined correctly and optimally, things inevitably change, such as when an employee switches a position in the company and is granted new authorizations without earlier ones being removed. The reason enterprises avoid removing old authorizations is due to the complexity and the concerning outcome that their removal entails. An escalation of the situation is almost certain, as organizations tend to create new user accounts by copying other existing accounts, which include the copied user's unused authorizations as well.
In addition, top-users, system administrators and various senior consultants are all granted with a huge number of authorizations (sometimes even with SAP_ALL and SAP_NEW authorization profiles), which literally allows performing any action in the system. The bottom line is that many employees have authorizations which they do not use in practice.
Our experience shows that users apply only 7%-13% of their granted authorizations. This means that for each user 87%-93% of their granted authorizations are unused altogether! These unused authorizations include many sensitive ones, such as the ability to transfer money, open G/L accounts, change vendor's bank account number or view another employee's salary.
Unused authorizations are more than enough to attract any hacker.

Defense tips:

  • Alert when a sensitive authorization is granted.
  • Reduce authorizations on an ongoing basis according to actual consumption.
  • Implement a workflow process for authorization requests.
  • Conduct authorization reviews regularly to identify unused authorizations.

Power Users

Any "respected" fraud attempt includes covering up tracks as well. In SAP however it is much easier to take control of a user account rather than cover up one's tracks. The reason for this is the extensive amount of logs that need to be cleared (application logs, technical activities, change documents, and more). Clearing such an amount of log records is done by hacking into the database (which is relatively difficult) or by running ABAP commands (which is quite a hassle as it requires transferring codes into the production system and running them).
Top user accounts, system administrators and inactive user accounts with vast authorizations are all excellent candidates for a hacker. The hacker can easily take over such legitimate user accounts and manipulate SAP for personal benefits; this is also much simpler and "more rewarding" than trying to actually hack into the excessively secured databases.

Defense tips:

  • Try to minimize the amount of Power Users in your organization.
  • Avoid granting powerful authorization roles and/or profiles (in fact, manual authorization profiles are not recommended by SAP at all).
  • Track users' login IP and inspect any change in their regular IPs.
  • Eliminate or invalidate dormant user accounts.
  • Perform behavioral-based usage inspection analysis to track deviations from normal behavior.

 ABAP Debugger

One of the major risks in SAP is its powerful debugging environment with the ability to stop each program and enter debugging mode while the program continues running (including the ability to change values at run time). This allows a hacker to either change an account number while running a payment program or change a report selection value. Furthermore, the debugger allows bypassing certain commands (like authorization checks) and changing the system return-code (SY-SUBRC) for authorizations checks from Failed (4) to Succeeded (0).

Defense tips:

  • Remove debugging authorizations from all users while granting privileged access to users that really have to enter the debugging environment.
  • Define debugging as a sensitive authorization and receive an alert for when someone is granted such authorization.
  • Monitor users and their activities in the debugging environment.
  • Eliminate authorization to change values in the debugger, and instead permit only display options.

Remote Access

SAP's own-developed communication protocol for accessing the SAP system remotely is called RFC (Remote Function Call) or RFM (Remote Function Module). Basically, it is very easy to remotely activate a function marked with the RFC Enabled flag. All that is needed to remotely access a SAP system is the host address of the SAP machine (and the system's number which is usually 00), username, password and the appropriate permissions for the function's group (Family).
How to obtain the username and password is a different story, yet not so complicated when dealing with usernames for remote access; in any event, we have witnessed many cases where usernames for remote connections are non-dialog and include numerous authorizations (i.e. SAP_ALL profile). The reason this happens is due to the false perception that a non-dialog user cannot perform application tasks. Moreover, the lack of SAP knowledge regarding SAP authorizations, in addition to the RFC-Enabled option and BAPI (Business APIs) functions, results in the erroneous assumption that non-dialog users are perfectly safe and can be granted sensitive authorizations.
From our experience, the most hacked remote usernames are for handheld PCs in warehouses and usernames for external business applications (in some cases usernames were created for testing purposes but have not been in use for a long time). Using remote functions, the hacker can perform various manipulations on SAP, such as obtaining data from SAP tables, changing vendor details, adding/deleting stock, changing employees' social benefits, and more.

Defense tips:

  • Carefully inspect the creation of usernames for remote connection and define alerts when granting sensitive or wide authorizations to them.
  • Lock inactive remote usernames after 30 days of inactivity.
  • Apply behavior-based analysis on misuse and irregular behavior of usernames for remote access.
  • Pay close attention to any change in the function modules which remote usernames are calling; each new function module should be approved and the purpose of calling it should be perfectly clear to you.

Scenarios of SAP Manipulation

Common Reasons for SAP Manipulation

  • To gain personal profit – this can be performed individually or by a few people together.
  • Obtain databases with detailed information – this can serve B2C companies such as insurance companies, as they get access to a vast amount of names and personal information of potential clients.
  • Competitors – we have witnessed very few instances where competitors find value in the outcome of various SAP manipulations.

Scenario #1 – Obtaining Data from Tables

There are basically two common ways to obtain data from SAP tables using SAP standard tools: via Data Browser (T-Code SE16 and its similarities) or SAP Query. Although the data between the application level (SAP) and database level seems identical, there are still some differences to take into account:
In SAP the data stored in different tables/databases can be viewed regardless of the database type and specific format. Looking at the data that is stored in the database table using SAP tools, whether encrypted or manipulated in the database, the hacker can see the data unencrypted clearly, as well as the description of fields. In short, it is quite convenient to use the SAP standard tools to get data from SAP tables instead of attempting to hack into the database.
Using Data Browser, the hacker simply calls T-Code SE16 (or SE16N or just N), chooses the table to question and the criteria, and voila, the data is shown on the screen ready to be downloaded. For example, presenting Table LFA1 will display all vendor details. If the object is a complex view of an object, all the fields from the underlying table will be presented, allowing a complete view of the full object's scope.

If SE16 is not open to the hacker, the tool QuickViewer (T-Code SQVI) can be used or SAP Query can be created using T-Code SQ01. SAP Queries are powerful generated objects, created by top users for themselves or for other users (no programmer is required!), and intended to show data from tables, views, combination of tables, etc. SAP Queries can be created in the production environment directly and thus do not need to be transported and inspected by technical teams. In many organizations the SAP Query tool is granted very easily to users, as it is perceived as an end-user specific tool intended to enable them to generate the data by themselves without wasting developers' time. Most organizations do not realize the risk entailed in misuse of SAP Queries.

To summarize, there are underlying SAP tables, some of which include sensitive data, alongside tools (standard SAP T-Codes) to examine this data. Organizations should carefully monitor users that are authorized to view data via such SAP tools, particularly sensitive data.

Tables that include sensitive data should be carefully monitored, specifically to inspect who is allowed to see the data and who actually sees it; who is able to use the table in QuickViewer and who actually did; in which views the table is being used and who viewed the data; and finally in which queries the table is used and who performed these queries.

Defense tips:

  • Alert when a user:
    • Directly accesses a table via SE16, especially a table which is defined as sensitive.
    • Performs a sensitive query.
    • Is granted a sensitive authorization.
  • Prevent users from being granted sensitive authorizations unless they genuinely need it for performing business tasks

Scenario #2 – Obtaining Sensitive Information from SAP Spool

One of the overlooked backdoors for getting valuable and sensitive data is the SAP spool. When a user/job prints in SAP, the output is first collected in the SAP spool (called Spool Request) and only then sent to the physical printer. Many times the spool request is not deleted from the spool (for a very long time), even after the content is printed. Clearly, this turns the SAP spool into an excellent source for hackers to find information about money transfer slips, monthly pay-slips, check printouts, purchase orders and more.
Furthermore, most users have access to the SAP spool (directly via T-Code SP01 or indirectly via
T-Code SM37), and most organizations enable unlimited access to the spool items, including the options to view, download and re-print the content.

Defense tips:

  • Inspect which users access SAP spool items, especially those that were not created by them.
  • Define sensitive spool items by criteria and alert when they are accessed.

Scenario #3 – Manipulations via Application Tasks

There are endless examples for manipulations that employees can perform via application tasks. Our experience shows that even though the financial module is the most popular for fraud, the more sophisticated hackers also manipulate the Human Resources (or HCM) and Logistics (mainly inventory) modules. Below are some of the many examples:

  • Changing a vendor bank account and waiting until the vendor receives payment (which will of course be falsely transferred into the wrong account).
  • Changing the social benefits of an employee; changing an employee's salary is easily noticeable, however changes in social benefits almost always goes unnoticed.

Note that changing information (such as a vendor's bank account number) can be done using the SAP GUI (in T-Code XK02) or directly by changing the value in the SAP table (in this case LFBK). The latter is performed by manipulating T-Code SE16 together with debugging mode.

Defense tips:

  • Inspect changes in user behavior, especially when an activity is performed by an employee who has never used it before. For example, when a warehouse manager (who has logistics-oriented behavior profile according to usual activities performed) accesses employee details (via T-Code PA30), which is in a different module (Human Resources or HCM) than Logistics, and is marked as a sensitive activity.

Summary

The complexity of SAP inevitably entails a manipulative-enabled environment. To effectively achieve maximum security over SAP systems enterprises should implement the following:

  • Ongoing monitoring of user behavior and actual system consumption.
  • Behavioral-based alerting system that notifies when a sensitive authorization is granted and/or in case of irregular usage behavior.
  • Periodical review of authorizations across the organization.

From our experience, conducting the above actions and processes on a regular basis maximizes the security level across all functions and departments, achieving a better controlled enterprise environment. When an organization reaches and maintains this level of SAP security, it is no longer easily manipulated and therefore not attractive to hackers anymore.

Source: http://hakin9.org/a-guide-to-sap-exploit-in-hakin9-exploiting-software-012013/

 


Get on our list:

Receive all our latest information including eBooks,

blog posts and free tools. You can opt-out anytime.

Headquarters

+972-3-624-4245

157 Yigal Alon Street, Tel Aviv 67443, Israel

info@xpandion.com

US Office

+1-800-707-5144

33 West 19th Street, New York, NY 10011, USA

info.us@xpandion.com