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:
After the clients are enumerated, below module extracts SAP users for each client:
With a list of existing SAP users, one can proceed with brute forcing. MSF provides below listed modules for the pupose:
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.
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.
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, 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”.
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.
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:
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:
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