Pentesting SAP

Introduction about SAP

SAP stands for Systems Applications and Products in Data Processing. SAP, by definition, is also the name of the ERP (Enterprise Resource Planning) software as well as the name of the company. SAP system consists of a number of fully integrated modules, which covers virtually every aspect of business management.

Each SAP instance (or SID) is composed of three layers: database, application and presentation), each landscape usually consists of four instances: dev, test, QA and production. Each of the layers can be exploited to some extent, but most effect can be gained by attacking the database.

Each SAP instance is divided into clients. Each one has a user SAP*, the application’s equivalent of “root”. Upon initial creation, this user SAP* gets a default password: “060719992” (more default password below). You’d be surprised if you knew how often these passwords aren’t changed in test or dev environments!

Try to get access to the shell of any server using username <SID>adm. Bruteforcing can help, whoever there can be Account Lockout mechanism.

Discovery

Next section is mostly from https://github.com/shipcod3/mySapAdventures from user shipcod3!

  • Check the Application Scope or Program Brief for testing. Take note of the hostnames or system instances for connecting to SAP GUI.

  • Use OSINT (open source intelligence), Shodan and Google Dorks to check for files, subdomains, and juicy information if the application is Internet-facing or public:

SAP Logon screen

Testing the Thick Client / SAP GUI

Here is the command to connect to SAP GUI sapgui <sap server hostname> <system number>

  • Check for default credentials (In Bugcrowd’s Vulnerability Rating Taxonomy, this is considered as P1 -> Server Security Misconfiguration | Using Default Credentials | Production Server):

  • Run Wireshark then authenticate to the client (SAP GUI) using the credentials you got because some clients transmit credentials without SSL. There are two known plugins for Wireshark that can dissect the main headers used by the SAP DIAG protocol too: SecureAuth Labs SAP dissection plug-in and SAP DIAG plugin by Positive Research Center.

  • Check for privilege escalations like using some SAP Transaction Codes (tcodes) for low-privilege users:

    • SU01 - To create and maintain the users

    • SU01D - To Display Users

    • SU10 - For mass maintenance

    • SU02 - For Manual creation of profiles

    • SM19 - Security audit - configuration

    • SE84 - Information System for SAP R/3 Authorizations

  • Check if you can execute system commands / run scripts in the client.

  • Check if you can do XSS on BAPI Explorer

Testing the web interface

SAP Index Page
  • Look for common web vulnerabilities (Refer to OWASP Top 10) because there are XSS, RCE, XXE, etc. vulnerabilities in some places.

  • Check out Jason Haddix’s “The Bug Hunters Methodology” for testing web vulnerabilities.

  • Auth Bypass via verb Tampering? Maybe :)

  • Open http://SAP:50000/webdynpro/resources/sap.com/XXX/JWFTestAddAssignees# then hit the “Choose” Button and then in the opened window press “Search”. You should be able to see a list of SAP users (Vulnerability Reference: ERPSCAN-16-010 )

  • Are the credentials submitted over HTTP? If it is then it is considered as P3 based on Bugcrowd’s Vulnerability Rating Taxonomy: Broken Authentication and Session Management | Weak Login Function Over HTTP. Hint: Check out http://SAP:50000/startPage too or the logon portals :)

SAP Start Page
  • Try /irj/go/km/navigation/ for possible directory listing or authentication bypass

  • http://SAP/sap/public/info contains some juicy information:

Configuration Parameters

If you have correct login details during the pentest or you have managed to login to SAP GUI using basic credentials, you are able to check the parameter values. Many basic and custom configuration parameter values ​​are considered vulnerabilities.

You can check parameter values ​​both manually and automatically, using scripts (e.g. SAP Parameter Validator).

Manual Parameter Checking

By navigating to Transaction Code RSPFPAR, you can query different parameters and look up their values.

The table below contains the defined parameters and the conditions for which they are distinguished.

For example, if gw/reg_no_conn_info is set to less than 255 (<255), then it should be considered as threat. Similarly, if icm/security_log is equal to two (2), it will also be a possible threat.

Parameter
Constraint
Description

auth/object_disabling_active

Y

Indicates if object disabling is active.

auth/rfc_authority_check

<2

Sets the authority check level for RFCs.

auth/no_check_in_some_cases

Y

Specifies whether checks are bypassed in some cases.

bdc/bdel_auth_check

FALSE

Determines if authorization checks are enforced in BDC.

gw/reg_no_conn_info

<255

Limits the number of characters for registration number connection info.

icm/security_log

2

Defines the security log level for ICM (Internet Communication Manager).

icm/server_port_0

Display

Specifies the server port for ICM (port 0).

icm/server_port_1

Display

Specifies the server port for ICM (port 1).

icm/server_port_2

Display

Specifies the server port for ICM (port 2).

login/password_compliance_to_current_policy

0

Enforces password compliance with the current policy.

login/no_automatic_user_sapstar

0

Disables automatic user SAPSTAR assignment.

login/min_password_specials

0

Minimum number of special characters required in passwords.

login/min_password_lng

<8

Minimum length required for passwords.

login/min_password_lowercase

0

Minimum number of lowercase letters required in passwords.

login/min_password_uppercase

0

Minimum number of uppercase letters required in passwords.

login/min_password_digits

0

Minimum number of digits required in passwords.

login/min_password_letters

1

Minimum number of letters required in passwords.

login/fails_to_user_lock

<5

Number of failed login attempts before locking the user account.

login/password_expiration_time

>90

Password expiration time in days.

login/password_max_idle_initial

<14

Maximum idle time in minutes before requiring password re-entry (initial).

login/password_max_idle_productive

<180

Maximum idle time in minutes before requiring password re-entry (productive).

login/password_downwards_compatibility

0

Specifies if downward compatibility for passwords is enabled.

rfc/reject_expired_passwd

0

Determines if expired passwords are rejected for RFC (Remote Function Calls).

rsau/enable

0

Enables or disables RS AU (Authorization) checks.

rdisp/gui_auto_logout

<5

Specifies the time in minutes before automatic logout of GUI sessions.

service/protectedwebmethods

SDEFAULT

Specifies the default settings for protected web methods.

snc/enable

0

Enables or disables Secure Network Communication (SNC).

ucon/rfc/active

0

Activates or deactivates UCON (Unified Connectivity) RFCs.

Script for Parameter Checking

Due to the number of parameters, it is also possible to export all of them to an .XML file and use the script SAPPV (SAP Parameter Validator), which will check all the above-mentioned parameters and print them values ​​with appropriate distinction.

Attack!

  • Check if it runs on old servers or technologies like Windows 2000.

  • Plan the possible exploits / attacks, there are a lot of Metasploit modules for SAP discovery (auxiliary modules) and exploits:

  • Try to use some known exploits (check out Exploit-DB) or attacks like the old but goodie “SAP ConfigServlet Remote Code Execution” in the SAP Portal:

SAP Config Servlet RCE
  • Before running the start command on the bizploit script at the Discovery phase, you can also add the following for performing vulnerability assessment:

Other Useful Tools for Testing

References

Last updated