SAP Backdoors: A ghost at the heart of your business (Mariano Nuñez Di Croce)
Abstract (source: Blackhat.com)
In any company, the ERP (Enterprise Resource Planning) is the heart of the business technological platform. These systems handle the key business processes of the organization, such as procurement, invoicing, human resources management, billing, stock management and financial planning. Among all the ERPs, SAP is by far the most widely deployed one, having more than 90.000 customers in more than 120 countries and running in Fortune 100 companies, governmental and defense organizations.
The information stored in these systems is of absolute importance to the company, which unauthorized manipulation would result in big economic losses and loss of reputation.
This talk will present an old concept applied to a new paradigm: SAP Backdoors. We will discuss different novel techniques that can be deployed by malicious intruders in order to create and install backdoors in SAP systems, allowing them to retain access or install malicious components that would result in imperceptible-and-ongoing financial frauds.
After the description of these techniques, we will present the countermeasures that should be applied in order to avoid these attacks and protect the business information, effectively reducing financial fraud risks and enforcing compliance.
Furthermore, we will release a new Onapsis free tool that will help security managers to automatically detect unauthorized modifications to SAP systems.
Is your SAP backdoored? If your answer is “I don’t know,” then you may consider attending to this talk.
Talk Abstract –> SAP Backdoors: A ghost at the heart of your business
Speaker Bio –> Mariano Nuñez Di Croce
Introduction
SAP is the largest provider of business management solutions around the world
- More than 140,000 implementations globally
- More than 90,000 customers in ~120 countries
Used by fortune-500 companies, government, defense agencies
Backdoors
What makes backdoors in SAP so important?
Very little public information on how they can affect SAP platforms. Just because it’s not publicly discussed, doesn’t mean it’s not being used. We need to talk about this to understand the risk.
The biggest mis-conception in SAP security is that SAP security is simply about segregation of duties.
However SAP suffers from vulnerabilities like any other software.
Security is more than just about the user privileges.
After initial compromise –> see previous presentations
After gaining access, the attack can install a backdoor to maintain access.
Due to intrinsic Trust relationships, a high-privileged
takeover of one technological component results in a
complete compromise of the whole platform.
By owning the OS or the Database, an attacker can install a backdoor and use it to maintain control of the system.
A Ghost in the User Master
The User Master is accessed when a user connects to the SAP system using the SAPGUI. The password provided by the user is checked against the password stored in the User Master.
SAP has however used a number of hashing mechanisms. Due to backwards compatibility these older (insecure hashes) are still stored in the User Master. This opens the system up to a number of attacks.
- Initially SAP supported an 8 char password stored as MD5
- Current versions support a 40 char password stored as SHA-1
By default, the User Master stores the older version alongside the newer SHA-1
The system uses a profile parameter – login/password_downwards_compatibility to set the has to be used
- 0 – Downwards compatibility disabled
- 1 – Downwards compatibility enabled (Weak hashes not evaluated)
- 2 – If the hash fails to match, the older hash is checked – Log and Deny access
- 3 – Same as 2, but logon is successful with the older hash (still logs)
- 4 – Same as 3, but no log is created
This parameter can be modified dynamically without a restart
Demo –> Resetting the old hash –> Altering the profile –> attacker logs on with old hash
As the attacker has only changed the old hash, the administrator can still logon without problems (using his password). The attacker however, can still logon using the old hash password he changed. This gives the attacker an almost invisible backdoor, as there is no new account, and logs will not show the logon using the old hash (with profile set to 4).
Protection
- Monitoring the system values and check for changes. If the profile value is altered, there is a problem
- Implement dedicated authentication group for U* tables
Backdoors in SAP Business Modules
Once you are logged in, you interact with the system running transactions. These transactions are run using ABAP Programs/reports.
ABAP programs are divided into 2 types:
- Standard (Shipped by SAP)
- Custom (in-house apps -starts with Z* or Y*)
Standard programs can be modified, but it’s strongly discouraged
ABAP programs are stored in the System’s database
- Table REPOSRC contains compressed sourcecode
- Table REPOLOAD contains ABAP load (bytecode)
Typically SAP prevents changes to the system in PRD systems. All changes are made in DEV.
Unauthorized modifications at the SAP layer are possible, but not trivial
Why go the hard route, when an attacker can go straight to the database. There are no CRC or signature checks on ABAP code stored in the database.
Demo –> Alteration of code in the database that changes payment information for newly added user
PoC attack inserts ABAP bytecode into the database. The SAP system will then compile and use it the next time the functionality is used.
Backdoors in the Authentication Procedure
Certain critical ABAP programs are protected to prevent access to the sourcecode.
The SAP system checks for a magic value (*@#@@[SAP]) in the first line of the code. If it’s present, then the content is not returned. Alongside this check, there is also a hard-coded kernel check to prevent access to the SAPMSYST (User Authentication Procedure) and 2 other key functions. The check is however performed on the ABAP program name. To bypass this, an attacker can create a new program in SAP and copy the code from SAPMSYST to his newly created program. This will then bypass the kernel protection as the name matching no longer triggers the protection.
Demo -> Reading and alteration of the SAPMSYST program to permit a backdoor –> backdoor logs credentials to a logfile
As the SAPMSYST program is core to SAP, a restart of the process is required to force the new bytecode to be created and the new backdoor functionality to take effect.
Protection
- It’s not possible to detect and protect against backdoors from within the SAP system itself.
- External tools are needed.
Onapsis Integrity Analyzer for SAP
Tool due to be released in 2 weeks (after HITB conference)
Why you need it? It’s not feasible to detect backdoors from inside the SAP system itself:
- Backdoors can leave the Program’s “Last modified date”unchanged
- The analysis programs may have also been manipulated to hide a backdoor’s presence
Onapsis Integrity Analyzer connects with the Database and performs “snapshots” of sensitive ABAP report tables — Signature only, no ABAP code stored
Periodically, new snapshots are compared
These checks obviously need to be implemented before your SAP system is backdoored.
Conclusion
- Backdoored systems are not just an SAP problem, they can affect any kind of system
- If an attacker can gain total access to your database system, then it’s very difficult to restrict their access to SAP
- Backdoored applications can be a serious business impact
- It’s all about the money
Best protection is to minimize the chances initial compromise
- Automatic controls
- Regular security checks
- Vulnerability assessments
- Penetration Tests
- Security Audits
- Onapsis’s Integrity Analyzer for SAP can help you to implement more in-depth reactive controls.
Additional Links
For more information please see the Blackhat Europe website
Cатсн²² (in)sесuяitу / ChrisJohnRiley 