Pentesting SAP

Introduction

In this article, you will learn how to pentest the SAP, If you have any doubts comment down below.

What should we do if we’re tasked with conducting a SAP Penetration Test?

One of the things I’ve always shied away from trying (mostly out of fear) is meddling with SAP.

Why? Well, SAP has always seemed like this enigmatic, complex beast that only experts can tame. But you know what? That’s not entirely true. Sure, SAP can be cryptic and intimidating, especially if you’re not knee-deep in it every day. But at its core, it’s just software. It follows protocols and standards like any other system.

Given its widespread use and critical importance, it’d be foolish to ignore it. So, I decided to dip my toes into SAP, learning the basics and tackling some challenges. And you know what I found? It’s not all that different from any other hacking or penetration testing endeavor!

I’m not claiming to be the ultimate SAP guru here. There are plenty of experts out there who can dive deep into how it all works. Instead, I want to share three key takeaways, coming from someone who’s still a SAP novice:

Don’t assume the SAP Router will block your access.
Even if there are restrictions on a test database, that won’t necessarily stop you from reaching production.
It’s really not as daunting as it seems!

Practical Example

Alright, so we’ve got a SAP service, let’s call it “sap_victim,” and it’s exposed.

First step? Enumeration, of course! Can’t skip that.

As always, Metasploit is our trusty companion with its arsenal of tools. Of course, there are others like Bizsploit or ERPScan that could also come in handy.

Here are some of the Metasploit Framework modules that could prove useful when dealing with SAP. And believe me, this is just scratching the surface.

Now, let’s get back to enumeration:

SAP_SERVICE_DISCOVERY vs SAP_VICTIM

msf > use auxiliary/scanner/sap/sap_service_discovery

Now that we’ve identified the exposed host as a SAP Router, it’s time to delve deeper into what might be lurking behind it. Thankfully, we can leverage the nature of the router itself along with a couple of Metasploit Framework (MSF) modules to uncover what lies beyond.

SAP_ROUTER_INFO_REQUEST

Setting “sap_victim” as our RHOSTS parameter and running the module, we uncover a route to an internal IP address.

msf auxiliary(scanner/sap/sap_service_discovery) > use auxiliary/scanner/sap/sap_router_info_request

Since we’re dealing with a SAP Router, we have the advantage of being able to conduct two types of scans on the internal network: one using its proprietary protocol and the other utilizing classic TCP. From what I understand, the SAP protocol essentially adds a few bytes to TCP.

Given that there’s likely at least one other SAP service lurking behind the SAP Router, we can direct our attention to leveraging the SAP_ROUTER_PORTSCANNER module to explore further.

msf auxiliary(scanner/sap/sap_router_info_request) > use auxiliary/scanner/sap/sap_router_portscanner

Exactly, by utilizing the SAP Router as a pivot, we’re effectively conducting a port scan on the internal network. This allows us to explore potential SAP services and other network resources that may be hidden behind the router’s perimeter.

Our target likely hosts several SAP services. We can utilize the SAP Router as a proxy for any MSF module we need. Here’s the connection string:

sapni:<saprouter>:<port>

SAP_SERVICE_DISCOVERY

Sure, let’s configure “sap_victim” as our SAP Router proxy and initiate the service discovery through it.

Alright, so we’ve discovered Dispatcher, HTTP, and SOAP services. Now, let’s consider potential vulnerabilities, like default user enumeration.

SAP_SOAP_RFC_BRUTE_LOGIN

Got it. So, this module enables us to test a list of credentials, including default ones, against a list of SAP Clients. We’re utilizing the sapni proxy for this operation.

msf auxiliary(scanner/sap/sap_service_discovery) > use auxiliary/scanner/sap/sap_soap_rfc_brute_login

Interesting development. Although the default credentials weren’t found on the 000 or 001 clients, discovering valid credentials elsewhere is significant. This allows us to make RFC requests, potentially enabling the execution of any other module that requires credentials.

SAP_SOAP_RFC_SYSTEM_INFO

msf auxiliary(scanner/sap/sap_soap_rfc_brute_login) > use auxiliary/scanner/sap/sap_soap_rfc_system_info

From this point onward, we have numerous paths we could take, considering there are already several exploits at our disposal that would likely be effective.

However, fortunately for us, that’s not the case. Instead, we have the opportunity to directly browse resources using SAP GUI by configuring the appropriate connection string over the SAP Router.

root@kali:/opt/SAPClients/SAPGUI7.30rev9/bin# ./sapgui /H/sap_victim/S/3299/H/<victim host>

Great, so once we’re logged into the mentioned client using the credentials we’ve discovered, we have some significant capabilities.

For instance, we can escalate privileges by using the SAPCPIC user to unlock the SAP* user and edit DDC credentials, which are administrative credentials.

Now, let’s consider what else we can achieve. We’re aware of “intra-client” RFC connections, but is it possible that there are any saved credentials within these connections?

Excellent! Here we have a saved credential that grants access to anyone. Specifically, it facilitates access from Client 00X to 00Y in this instance.

To illustrate this, we’ll utilize the RFC_READ_TABLE function to read the data from a client-specific, client-dependent table in 00Y.

No worries! I’ll take your word for it. If you have any other tasks or need further assistance, feel free to let me know.

Wow, it sounds like we have quite a range of possibilities at our disposal!

To elevate further, accessing clients 000/001 could be an option. Additionally, we could explore running commands or obtaining a shell.

By executing transaction SM69, we can create commands to be executed by the operating system and receive feedback on their execution. This opens up even more avenues for exploration and potential exploitation.

It’s understandable that an interactive shell would be much more convenient in this scenario. Let’s explore if, by any chance, the SAP Router allows for a different approach that could facilitate obtaining an interactive shell.

It’s a stroke of luck that the developers left some ports open, even if they’re currently unused. We can leverage this opportunity.

Since we’ve observed that establishing a connection over the sapni proxy allows the SAP Router to forward our requests to the mentioned ports on our victim, we can proceed with setting up a bind shell. We’ll execute the usual netcat command directly from SAPGUI to achieve this.

Great thinking! Having exploit/multi/handler ready on Metasploit Framework ensures that we’re prepared to catch the incoming connection and handle the exploit effectively. It’s a crucial step in ensuring a smooth and successful operation.

msf auxiliary(scanner/sap/sap_soap_rfc_system_info) > use exploit/multi/handler

msf exploit(multi/handler) > set payload linux/x64/shell/bind_tcp

msf exploit(multi/handler) > set rhost <target>
rhost => <target>

msf exploit(multi/handler) > set lport 50100
lport => 50100

msf exploit(multi/handler) > set proxies sapni:sap_victim:3299
proxies => sapni:sap_victim:3299

Fantastic! With the interactive shell successfully obtained, upgrading it with Python will definitely enhance its capabilities and make it even more powerful. It sounds like we’re making excellent progress towards our goals.

Absolutely, a shell grants us nearly limitless possibilities. Let’s skip the usual escalation path to root since it’s unnecessary in this context.

Instead, let’s investigate if any careless developer has left behind something useful, such as a script that interacts with the database. This could provide us with valuable insights or even allow us to execute certain actions within the database environment.

It sounds like we’ve hit the jackpot with this script! Here’s what we’ve found:

The script contains the path to the binary used to access the database, providing us with a direct route to interact with it.
We’ve also discovered credentials and the logon type required for accessing the database, which is crucial for authentication.
Additionally, there are DB-specific parameters, although they’re censored in this context to maintain security.

Now, let’s see how we can access Client Dependent data on Client 000 directly from the database:

Even if luck hadn’t been on our side, it seems we still have a valuable resource at our disposal: the .dat file containing unencrypted data. Although it’s a hefty 40GB, with some careful crafting, we could utilize grep to extract all the information we need from it.

This demonstrates the importance of thorough investigation and resourcefulness in navigating through security challenges.

Conclusion

It sounds like you’ve navigated through quite the challenging scenario with impressive skill and resourcefulness. Despite the precautions taken, you managed to gain access through seemingly minor distractions, showcasing your ability to exploit vulnerabilities effectively.

Your experience highlights various methods for lateral access, including utilizing transactions like SE16N or UASE16N, leveraging SAP debugging for direct modification of requests, and exploring options within the DBA COCKPIT or user profiles.

While you didn’t delve into decrypting SAP passwords in this article, it’s a well-known topic with widespread techniques like CODVN I, which utilizes multiple encryption layers.

Overall, your ability to navigate and succeed in accessing SAP systems without extensive prior knowledge demonstrates your competence and adaptability in the field. Well done!

Also Read: Pentesting Java Debug Wire Protocol