You can read Part 1 here.
It may be possible that multiple SAP servers could run across different systems. Identify all the servers before proceeding with the assessment. This is so, as all the SAP servers (could run the different or same set of modules) interact with each other, and compromising one could lead to compromise others. The assessment approach mentioned below holds individually for each SAP server hosted within the organization. This implies, that each server must be tested following the same approach even if there may be a possibility that the servers are implemented to behave as active-passive.
Understanding that SAP solution comprises of multiple modules, hence generally, a number of services are found enabled over an SAP server IP. A typical Nmap scan of the SAP component would look like this:
A huge list of open services and the fact that typically, there is multiple SAP server components set up in an organization with similar lengthy lists of open services may open up multiple possible attack surfaces, services, and vulnerabilities.
Initially, we will proceed with attack vectors that may help in obtaining system access without depending on credentials.
1.1 Attacking SAP Router
Once the list of IPs running SAP components is obtained, enumerate the list of services running over them through Nmap.
SAP router or SAP gateway is a term used for a device that acts as a router/gateway for all the SAP services. It is used to allow and restrict network communications between SAP systems and/or between SAP and external systems. Every request to any SAP component goes past through it before it reaches the intended SAP component. The default port for the SAP router is 3299. Identify this IP running the SAP router as it’s important to route your payloads to other SAP components. Following modules of Metasploit may help in enumerating SAP router:
- auxiliary/scanner/sap/sap_router_info_request
- auxiliary/scanner/sap/sap_router_portscanner
The first module listed above could be used to enumerate the router/gateway itself. While the second module could be used to port scan devices behind the SAP router. If a service is enumerated using sap_router_portscanner which is not listed in the direct Nmap result, one can further enumerate the service by setting the router as a proxy. Assuming that SMB is enumerated:
msf > use auxiliary/scanner/smb/smb_login
msf > set Proxies ni:192.168.3.221:3299
msf > run
1.1 Enumerating Existing SAP Vulnerabilities
Once the SAP router is identified, proceed with enumerating the current SAP version running. One simple way to do is through the MSF module:
- auxiliary/scanner/sap/sap_mgmt_con_version
The above module will reveal the SAP server version, host OS details, its architecture, server SID, etc.
SID – The SAP System Identifier is a unique 3 characters identifier corresponding to each SAP component. Typically, the acronyms are common and reveal the component running on the IP which can be further looked at for any existing vulnerabilities.
Once we know the SAP version, look for the existing vulnerabilities related to SAPGUI and the Web interface, which includes account takeover, insecure authorization check, privilege escalation, etc. in older versions that must not be overlooked.
1.2 Enumerating SAP services
Next, we enumerate all the SAP services running on the components. The point to remember is that all the services open on an IP running an SAP component may not necessarily be handled by the component itself. It is highly possible that there may be another service that is required as a dependency for the SAP component. Or that a separate server is intentionally made to run on the IP by the admin. This is also a poor security practice as compromising that server may lead to compromise of the SAP component and its sensitive information.
Also, remember the SAP Penetration Testing goal is not just getting system access but to obtain system access first and then exfiltrate the data in a readable format. Hence, ensure that apart from the services handled by the SAP component, all other running services are probed for vulnerabilities.
Metasploit framework has a module for SAP services enumeration on a component:
- auxiliary/scanner/sap/sap_service_discovery
Running the above on each SAP component will reveal all the information regarding the services on those components. The service corresponding to each port obtained are actually the technical modules of SAP. Incorporate the above information with the port scan results of Nmap to obtain a clear picture and purpose of each component. This is a critical step in identifying the most critical of all SAP components and exfiltrating the data with minimum noise. Refer to the links mentioned below to understand services running over each port:
- https://help.sap.com/viewer/ports
- https://help.sap.com/doc/saphelp_nw73/7.3.16/de-DE/4e/c26cdc58e968b9e10000000a42189e/content.htm?no_cache=true
- com/attachment.php?attachmentid=9&d=1284317492
1.3 Enumerating SAP ICM
SAP ICM – Internet Communication Manager is an interface between SAP internal network and the external network i.e. as a server, the ICM can process requests from the Internet that arrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls the relevant local handler for the URL in question. One can use the below module to obtain information about the ICM server running on each component.
- auxiliary/scanner/sap/sap_icf_public_info
The default page for ICM contains sensitive host system information. By inspecting ICM, you may encounter a list of web services running on the system. Strongly keep this component in mind as it is the part mostly left unchecked and that may lead to critical issues. It is discussed in detail in the SAP RFC’s section.
Patch – It is recommended to disable the web admin console login as SAPGUI application is already being used for the purpose.
1.4 Hail Mary – An Intro To Onapsis’s Bizploit
Bizplot is an SAP unoffensive pen-testing tool that automates the tasks and checks for a list of vulnerabilities that may be present on an SAP component. The interface is quite similar to the Metasploit framework. To begin with, it follows the commands in the sequence as demonstrated in the below evidence:
As you enter “back” it will port scan the IP address. Once the port scan completes, proceed with the commands shown below:
Bizploit categorizes its plugins into:
- Vulnassess – Plugins for vulnerability testing
- Discovery – Plugins for information gathering
Once Bizploit is set to run all vulnassess and discovery plugins enter the “start” command. With this, all the plugins are then executed sequentially in verbose mode enlisting all the RFC’s/plugins executed and whether the vulnerability exists or not (RFCs have been discussed thoroughly in the Bizploit’s Insider’s Secret section). Once it’s done, the following result typically appears:
A prominent vulnerability in SAP components is unrestricted access to the “registerExtServer” web service i.e. Evil Twin attack. This allows an attacker to create a fake and identical server on the attacking system and make the server itself route the original traffic to the attacker’s system. Onapsis had a blog regarding the vulnerability and how to exploit but unfortunately, they have deleted the blog as of now. However, you may still access it on:
The TPNAME mentioned in the blog is a unique name for the server. If you have followed the blog, you already have it. A similar result could be obtained by running the Metasploit module
- auxiliary/scanner/sap/sap_icf_public_info
Follow the above reference to create the Evil-Twin for the SAP component.
Patch – In order to fix the Evil Twin attack, it is recommended to either disable the registerExtServer web method or secure the same with an authentication check.
Bizploit Tip: Remember when I compared Bizploit interface to MSF? Just hit the Tab twice if you stuck anywhere on bizploit console and let the wizard help you.
1.5 Bizploit’s Insider’s Secret – SAP RFC’s
So how does Bizploit actually work and what features of an SAP component does it leverage to identify vulnerabilities and why is it that can’t be solely relied upon? The answer to this lies in SAP Remote Function Calls (RFCs) aka SAP web services or SAP web methods.
SAP uses web services for both intra-communication among SAP components and inter-communication with external devices. To make SAP perform any action, there must exist a corresponding RFC for it. These RFCs are called through SOAP API requests and expect user authorization to perform the action. Here lies the catch: there are hundreds of web services supported by each SAP component and thus, quite difficult to manage authorization and authentication checks on each of them. Below mentioned MSF module checks for some of the prominently used web services against authentication check alongside other properties enumerated without authentication.
- auxiliary/scanner/sap/sap_mgmt_con_instanceproperties
Now, we have some sensitive information at our disposal but how should we leverage it. It depends upon how well the ICM component of an SAP environment is enumerated. This component is the key to compromising the complete SAP setup.
Once the unprotected methods are revealed, it’s time for complete ICM web service enumeration. The below MSF module will look for default SAP URLs active over an SAP component:
- auxiliary/scanner/sap/sap_icm_urlscan
Run the module on every port that has any of the “HTTP” / ”msg server” / ”gSOAP” / ”J2EE dispatcher interface” in its service enumeration. Now hit any of the obtained URLs in the browser. If the browser throws an error, just add a “?wsdl” at the end of the URL and try again, it will work. Intercept its XML response in Burp. Burp extension “Wsdler” converts XML content into SOAP requests.
This will provide a list of all web services supported on that port. Hence, don’t forget to enumerate each port. Depending upon the service running, it is possible that web services for remote command executions are left without an authentication check.
If the web service request’s response contains “HTTP Error: ‘Unauthorized’” then it seeks authentication. If you have access to credentials, just append an “Authorization” header with a value of “Bearer base64(username:password)” as:
Authorization: Bearer VE1TQURNOlBBU1NXT1JE
Say the credentials are TMSADM:PASSWORD
To verify whether authentication/authorization is required for a web service without actually executing it, all the SAP components support an AccessCheck web service. It may be used to verify the vulnerability without causing potential harm to the SAP server.
P.S: Seclist collection also contains 2 files containing default SAP URLs that are worth looking for. Located at:
- seclist/SecLists-master/Discovery/Web-Content/sap.txt
- seclist/SecLists-master/Discovery/Web-Content/URLs/urls-sap.txt
“ReadFile” & “ReadLogFile” can be used to obtain system files. Generally left unchecked, if the SAP component is running as root, it may fetch the attacker /etc/passwd and /etc/shadow files. SecStore.properties & SecStore.key are 2 critical SAP system files to worth looking for. They are located at:
- C:\usr\sap\<SID>\SYS\global\security\data\SecStore.properties
- C:\usr\sap\<SID>\SYS\global\security\data\SecStore.key
They can also be accessed using ReadLogFiles or similar available web services if the authentication check is not properly implemented.
Once you obtain access to the web services it is possible to chain multiple web services and leverage their features to compromise the system even without having any need for a valid credential set.
Patch – It is recommended to disable all the unwanted web methods supported by the SAP server. The web services that are required by the system must be put for an authentication check before execution.
The SAPControl Webservice interface of sapstartsrv differentiates between protected and unprotected Webservice methods. Protected methods are executed only after successful user authentication. This is not required for unprotected methods. The default setting is set so that all methods that change the status of the instance or the system when called are protected.
The parameter service/protectedwebmethods determines what methods are protected. It can have two different _default_ values: DEFAULT or SDEFAULT. SDEFAULT is the new default implying to protect almost everything, just allowing consoles to show the initial view. It is active if service/protectedwebmethods = SDEFAULT is set in the startup profile of the corresponding instance.
1.6 A Pentester’s Crush on Sensitive Information
Some Important MSF No Auth Information Gathering Modules:
- auxiliary/scanner/sap/sap_mgmt_con_getaccesspoints
- auxiliary/scanner/sap/sap_mgmt_con_getenv
- auxiliary/scanner/sap/sap_mgmt_con_startprofile
- auxiliary/scanner/sap/sap_mgmt_con_listconfigfiles
- auxiliary/scanner/sap/sap_soap_rfc_system_info
- auxiliary/scanner/sap/sap_soap_th_saprel_disclosure
- auxiliary/scanner/sap/sap_hostctrl_getcomputersystem
NOTE: Apart from above mentioned methods, authorization checks corresponding to each user functionality must also be tested for any kind of privilege escalation vulnerability that may lead to RCE and ultimately system compromise.
You can read Part 3 here.
