-Has more than a thousand of employees
-Is a circus of IT Systems
–Mixture of operating systems, databases, applications and their different versions
-Decision makers care more about their bonus than the interest of the company
-Is a political battlefield
Enterprise Security
Even a medium level of IT security is too expensive to achieve
–Missing asset management (how many Oracle DBs, Windows servers, etc)
–Tons of security scanning, to few remediation chasing
–Many of the vulnerabilities cannot be mitigated
-Obsessed by Cross Site Scripting
-IT security departments cannot influence security decisions of business applications much, because of political reasons.
-Nobody cares about the hacked UNIX machine, SQL DB, or others.
-Defacement and similar security incidents are budget approvers
SAP Systems
-Business specific
-Industry solutions
-Hold the Crown Jewels
-Are usually extensively customized
-Less exposure to typical hackers (ABAP)
SAP Security
-Security mostly focuses on authorizations and segregation of duties
-Intrusion prevention is still a baby
-Risks are underestimated/general IT Security efforts are typically unbalanced at companies
-Unlike e.g Active Directory, SAP systems belong to the business, not the IT
-Security departments usually fail when they are challenged
RFC (Remote Function Call) protocol lets you run functions remotely
–To run; use Java, C, etc. with RFC-SDK or simply execute the test program "startrfc". Following
creates a new user with god rights:
startrfc -3 -h 10.1.5.4 -s 05 -c 010 -u ERTUNGA -p CCC42 -F SUSR_RFC_USER_INTERFACE
-E USER=SATRIANI -E ACTIVITY=01 -E PASSWORD=RUBINA -E USER_TYPE=A -T USER_PROFILES,
12,r=-
There is no exploit involved. Everything is intended functionality.
–Beats "RFC users are not a threat because they cannot login via SAPGUI"
–Time to recheck company’s shared folders and eliminate hardcoded passwords.
RFC (a.k.a communication) users are thus very very important!
–Secure their passwords and make them part of the password change process
–Don’t forget: GUI (dialog) users which have S_RFC rights can also execute remotely
–SAP_ALL FOR COMMUNICATION USERS IS A NO GO!
RFC_READ_TABLE
Reads the contents of any table (Including ones with sensitive data e.g salary information)
Has bugs in converting e.g binary fields
SUSR_RFC_USER_INTERFACE
Can be used for creating/modifying users
RFC_ABAP_INSTALL_AND_RUN
-Takes ABAP source lines and executes them
-Widely known! tighten user authorizations to prevent abuse
-More restricted in latest NetWeaver Systems
RFC can be encapsulated in SOAP messages (SOAP RFC)
-Company’s internal proxy suddenly opens the doors to all SAP systems
-Disable it if not used!
Single Sign-on (SSO2)
-Is a convenient feature, not a security feature
-RTFM: Secure Store and Forward [SSF] documentation
-Personal Security Environment files hold the private key data
-If an attacker obtains it, it can create authentication tickets for the victim system. Accepting these tickets is enabled per default. Attacker can logon as any user.
-The private key container (PSE) can be pin-protected
-Advice: Disable accepting tickets using relevant profile parameters!
SQL Injection-ABAP typically uses parametrized queries (Developers can still specify parts of sql statements dynamically by parentheses)
-Not dynamic: SELECT ColumnA FROM TableA INTO[...]
-Dynamic: SELECT(var_ColumName)FROM(var_TableName) INTO[...]WHERE(var_WhereClause)
-Avoid dynamic statements where possible!
Cross Site Scripting
-Proper sanitization/encoding of the input data is the key for self developed web code such as BSPs.
-If not done, an attacker can do everything related to XSS, plus steal e.g the SSO2 (Authentication) cookies from the clients SSO2 cookies are stateless so client impersonation is a breeze. Avoid using this mechanism without proper controls.
-If you have F5's or similar devices, encrypt cookies based on origin IP.
ABAP Executable Manipulation
-Statement: INSERT REPORT
-Writes custom code to any ABAP program
-It's even possible to call an editor to make it more user friendly
-Very suspicious if found in self-developed code
RS_REPAIR_SOURCE Executable
-Unpatched version does not have authorization checking.
-People with e.g SE38 rights can execute this and manipulate the system and data of it.
-Same as ABAP injection, only more convenient.
-SAP patched it via: SAP Note 1167258: Program RS_REPAIR_SOURCE
ABAP Rootkits
-It is possible to modify system executables (ABAPs)
-An attacker can easily infect important ones executables and install an ABAP rootkit
-SAP has RFC functions that do not require user authentication by default (SRFC Function Group). This could be one candidate.
-Installed rootkit can give anonymous access to the attacker with functionality such as: Installing
SAP_ALL users, Manipulating ABAP reports, Running OS commands, Stealing hashes or PSE files, Deleting Logs.
Triple-Penetration Attacks
Penetration 1: Attacker exploits the weakest system
-Typical enterprise setup: Testing/Development > Quality Assurance > Production
-Among them, most unprotected are test/development systems
Penetration 2: Attacker infects clients which connect to the weakest system
–Starts with modification/infection of the critical areas such as logon screen ABAP code
-When admins/developers successfully login, malicious payload is downloaded and executed on these users computers
Penetration 3: Victim infects all the systems it later connects to
-Modification of critical components of the newly accessed SAP systems (Internal production systems, Partner systems, critical systems)
How to stay secure
-Have proper "check-in" and "leavers process" that take the ABAP developer risks into consideration
-Audit the code against security vulnerabilities before transporting to production systems
-Syncing passwords to development systems means, possibility of developers to capture valid passwords for production systems. Avoid it!
-Get rid of insecure and/or default passwords
-Disable backwards compatiability of passwords
-Install the latest security patches
