This 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.
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|
|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)|
|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|
|Very high, performed with regular database tools||Low, requires high level of expertise (applicative and technical)|
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:
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.
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.
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).
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.
Scenarios of SAP Manipulation
Common Reasons for SAP Manipulation
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.
Alert when a user:
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.
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:
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.
The complexity of SAP inevitably entails a manipulative-enabled environment. To effectively achieve maximum security over SAP systems enterprises should implement the following:
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.