Hunting for low-hanging fruits in SAP Applications

5 min readAug 17, 2020

Howdy!

This write-up is about basic security vulnerabilities that commonly exist in SAP Applications and how they can be exploited.

Caveat: We are not going to look at software flaws that exist in the underlying code of SAP Applications but we will rather look at weaknesses that exist as a result of not implementing best practice configuration and how to exploit them. Reason being, SAP Applications are pretty robust and a lot goes into securing the platform itself. They even have a Vulnerability Disclosure Program (VDP) at https://hackerone.com/sap?type=team. So, if you are after 0-days, Good luck with that!

How do you go about interacting with SAP Applications?

The two common ways I have seen is using SAPGUI and through the usual web browsers for web hosted SAP applications. SAPGUI is a fat client installed on users computers and interacts with an SAP server hosted on a corporate network. Web-based SAP Application are also pretty common in today’s enterprises as they open up such applications to be accessed by their clients and vendors.

So, how do you go about hunting for these low-hanging fruits?

Let me point out that there is no one-size-fits-all way of identifying and exploiting these vulnerabilities. I will illustrate common techniques that worked for me and that I frequently use during pentests. The most common techniques are the use default credentials, information disclosure, and exploiting unpatched SAP systems.

1. Default Creds!

Default credentials are the usual culprits that is often overlooked or even forgotten by SAP system developers and administrators when configuring and deploying SAP Applications. A simple google search for “SAP default credentials” will give you what you are looking for.

I however prefer using the following Metasploit modules which will do a decent work in bruteforcing for default credentials. You can choose from these modules depending on the service used by the SAP Application:

auxiliary/scanner/sap/sap_web_gui_brute_loginauxiliary/scanner/sap/sap_soap_rfc_brute_loginauxiliary/scanner/sap/sap_mgmt_con_brute_login

The /sap/bc/soap/rfc SOAP service is a commonly used service in web-based SAP Applications.

Using the obtained credentials, you can read data from the SAP system tables. Here you can use the auxiliary/scanner/sap/sap_soap_rfc_read_table module that which makes use of the RFC_READ_TABLE Function to read data from tables using the /sap/bc/soap/rfc SOAP service. The values for TABLE and FIELDS are the default ones in SAP. Go look them up.

If you are lucky enough, you can do a directory a traversal, access the back-end of the SAP Application and use the obtained credentials to login to the back-end. A common directory to access the backend is https://sap.evilcorp.com/sap/bc/webdynpro/sap/configure_application. Most of the time, this will give you read-only access to the back-end.

2. Information Disclosure

The credentials obtained can also be used to disclose information about the server hosting the SAP application including file system structure, DB version, OS kernel version, SAP version, and SAP patch level as shown below:

Another way of disclosing more information about the system hosting the SAP Application is by using the auxiliary/scanner/sap/sap_icf_public_info Metasploit module. This will return system information such as DB System used by the application, OS, Internal hostname and IP address of the server.

You can as well get this info by browsing to https://sap.evilcorp.com/sap/public/info in case it is a web hosted application.

3. Unpatched Systems

Depending on how much leg work you’d put in your enumeration and fingerprinting, you can identify unpatched SAP systems based on their version and patch levels. You can thereafter look for CVE’s with working POCs which might give you a shell. You gotta be careful with POCs that you get from the internet though, they might break things. Most of these POCs are written in python, so, it should not be a hustle to read what the code does before running it against a production system.

One of the decent scripts that gets the job done when it comes to exploiting the infamous SAP Gateway 10KBlaze vulnerability can be found here:

chipik/SAP_GW_RCE_exploit

This PoC exploits an ACL misconfiguration in the SAP Gateway (port 33xx) that leads to a Remote Command Execution…

github.com

This is a one liner script………………..

python SAPanonGWv1.py -t 172.16.30.28 -p 3300 -c whoami

Here is a typical architecture that shows how a web-based SAP Application is deployed and how a penetration tester can exploit for the low hanging fruits.