SAP Security Assessment Methodology Part 3 – Credential Centric Attack Vectors

Before proceeding with this methodology some SAP terminologies are to be understood:

Client – A client is a 3-digit number that could be understood as a specific customer. This means that all business data within a client is protected from other clients. Each client has its own customer data, which can be considered as the exclusive property of this client. Clients enable SAP SAS providers to install a small number of SAP Systems but still cater to many customers. Thus, sharing hardware and software resources. Every standard SAP component is shipped with 3 default clients – 000, 001 & 066.

Transaction – A task successfully completed in SAP is referred to as a transaction. Transaction codes or T-codes are the shortcuts to reach the feature in the SAP interface where the task is located. It is entered in the command field. By entering a transaction code instead of using the menu, you go to a task and start the function in a single step.

1. Brute Forcing

Focussing on making efforts to obtain valid user credentials of a particular SAP component, one must first look for registered clients on it. Below MSF module comes to the rescue:

  • auxiliary/scanner/sap/sap_rfc_client_enum

 After the clients are enumerated, below module extracts SAP users for each client:

  • auxiliary/scanner/sap/sap_mgmt_con_extractusers

With a list of existing SAP users, one can proceed with brute forcing. MSF provides below listed modules for the pupose:

  • auxiliary/scanner/sap/sap_web_gui_brute_login
  • auxiliary/scanner/sap/sap_mgmt_con_brute_login
  • auxiliary/scanner/sap/sap_soap_rfc_brute_login

 

Below is a list of default SAP credentials for all its components. Note to set the clients as 000,066,100 & 001 along with any other Client ID being used at the server.

Username Password
admin axis2
Administrator manage
CONTENTSRV init1234
CTB_ADMIN sap123
DDIC 19920706
DDIC Change
DDIC SAP4ALL
Developer isdev
EARLYWATCH support
EARLYWATCH SUPPORT
IDEADM admin
itsadmin init
Replicator iscopy
SAP* 06071992
sap123 Administrator
SAP* 6071992
SAPCPIC admin
SAPCPIC ADMIN
SAP* PASS
SAPR3 SAP
SAPSUPPORT init1234
SMD_ADMIN init1234
SMDAGENT_<SID> init1234
SMD_AGT init1234
SMD_BI_RFC init1234
SMD_RFC init1234
SOLMAN_ADMIN init1234
SOLMAN_BTC init1234
SOLMAN<SID><CLNT> init1234
TMSADM $1Pawd2&
TMSADM null
TMSADM PASSWORD
WF_BATCH null
xmi_demo sap123

 

Note that the module sap_mgmt_con_brute_login is often logged for a number of incorrect attempts hence may result in username lockout. However, the module sap_soap_rfc_brute_login is generally safe for brute-forcing. Also, note that if a set of default credentials are found, it is most likely that the standard SAP policy has not to be enforced. SAP has a standard password policy to prevent users from setting easily guessable passwords that are vulnerable to brute force (as depicted in the screenshot below). In many organizational setups, it is not found to be enforced and, in such case, a dictionary of most common passwords could also be used along with the above-listed pair of default credentials in the brute force attack. Thus, increasing the success rate of the attack.

 

 

 

SAP standard password policy

 

Default credentials

Obtaining working credentials of an account may lead to remote code execution on the SAP server. Properly executed, it can successfully provide Admin access control over the SAP server as demonstrated below:

Successfully logged in with the credentials

 

Successfully logged in, the most convenient way to obtain command execution on the server is to look for whether the user has enough privileges to execute any external OS process transaction i.e. “SM49” or “SM69”.

User privileged to execute SM49 transaction

 

If you have achieved the above screen, it has already saved a lot of your failed attempts to successful code execution.

So, now the task is to execute a system command/process that would give a server console access. Now, what would be the first and the easiest scenario that would come to a mind of a pentester? Yup, a reverse shell payload. One idea might be to try and run a PowerShell reverse shellcode as shown below.

PowerShell reverse shell command

 

SAP server console access

Also, the most important factor to be explicitly mentioned here in regard to getting a command execution is the Recon phase. Identify all the services/URLs that provide authentication check and check for the default credentials on every single service to obtain any single working credential.

It may be possible that initially, it seems that only SAP thick client is being used and that is the only service providing authentication and authorization checks against user credentials, but there always remains a high probability that an unused authentication service is running over HTTP or DIAG protocol. Missing one authentication service is losing dozens of possible account access/overtake.

Patch – It is recommended to disable all the default SAP system accounts or reset the default passwords.

2.  You Have Been Pawned!

Obtaining working credentials, one can then exploit supported SAP transactions/webservices to execute remote commands or to obtain a stable shell. Listed below are some important MSF modules for the purpose:

  • auxiliary/scanner/sap/sap_soap_bapi_user_create1
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_command_exec
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_call_system_exec
  • auxiliary/admin/sap/sap_mgmt_con_osexec
  • exploit/multi/sap/sap_mgmt_con_osexec_payload
  • exploit/multi/sap/sap_soap_rfc_sxpg_call_system_exec
  • exploit/multi/sap/sap_soap_rfc_sxpg_command_exec

3.  Insecure Authorization

A webservice may or may not require an authentication to execute successfully. Even if authentication check is implemented, it doesn’t imply that proper authorization is also in place. That said, it may be possible that a low privilege user may get to execute a webservice that ideally must have been confined to the admin status only. Below is a list of transaction codes that must be validated for proper authorization checks:

  • SE38
  • SM19
  • SUGR
  • SE13
  • RZ10
  • SE38
  • SE80
  • SA38

Below is a list of highly sensitive transactions that must be kept blocked in most components unless in the production system and having business requirements:

  • Archive administration: KA10, KA12, KA16, KA18, SARA
  • Reset transaction data: OBR1
  • Structural authorization OICP, OOSB
  • User maintenance: OMDL, OMEH, OMWF, OOUS, OPF0, OTZ1, OY27, OY28, OY29, OY30
  • Profiles: OMEI, OMWG, OOPR, OP15, OPE9, OTZ2, OY21
  • Privilege and profile maintenance: OMG7, OMWK, OPF1, OTZ3, OY20
  • Structural authorization: OOSP
  • Maintenance of user profiles: OVZ6
  • Copy by transport request: SCC1
  • Deleting a client: SCC5
  • Transport organizer (extended): SE01
  • Workbench organizer: SE09, SE10
  • Table maintenance: SE16, SM30, SM31
  • External OS commands: SM49, SM69
  • Deleting all users: SU12

 

Author


Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.