SAP PENTEST: Metasploit Writeup
What to do if we happen to be committed with SAP Penetration Test?
One of the many things I had never tried before (because of fear) was trying to mess with SAP.
Why? Because SAP is a mystery, SAP requires vertical expertise, SAP is haaaard.
False. False. False. Or better, SAP is cryptic, hard, strange and incomprehensible unless it’s your job and almost the only thing you focus on and, because of this tough nature, many believe some big expert is needed to understand something about it at all. While all of this might be true about installation, configuration and maintenance, it’s also true that it’s just a SOFTWARE which uses PROTOCOLS and STANDARDS.
Given its critical relevance and its extreme diffusion, it would be stupid to ignore it, so I started studying SAP, very minimal, basic notions and concepts, then I found some challenges and I got there and…surprise! There is nothing different than any other hack or PT!
I won’t be the next big expert out there and explain how all of this works, there are already many sources for that.
Instead I’d like to highlight three small concepts, reminding all of you that the one writing is someone who barely knows of SAP existence:
1. SAP Router won’t stop you from gaining access
2. Restrictions on a test DB won’t stop you from getting to production
3. It’s not that hard!
Practical Example
So we have a SAP service, we can find it exposed as what we are going to call “sap_victim”.
First things first, what to do? Enumeration! You don’t say!
As usual Metasploit comes in handy with its set of tools (others could be Bizsploit or ERPScan):
…and these are all the Metasploit Framework’s modules that could be useful against a SAP, just a few…
Back to the point, enumeration:
SAP_SERVICE_DISCOVERY vs SAP_VICTIM
msf > use auxiliary/scanner/sap/sap_service_discovery
Now we know that the exposed host is a SAP Router. What might be there behind it? We can discover it by taking advantage of the router’s nature itself and a couple of MSF modules.
SAP_ROUTER_INFO_REQUEST
By setting “sap_victim” as our RHOSTS parameter and running the module, we discover a route to an internal IP address.
msf auxiliary(scanner/sap/sap_service_discovery) > use auxiliary/scanner/sap/sap_router_info_request
But how can we get there? SAP Router lets us run two types of scan on the internal network: one using its own protocol, the other using classic TCP (my understanding of the SAP protocol is that it simply adds a few bytes to TCP)
Having a SAP Router, surely there will be at least another SAP service behind, so with this concept in mind we can focus on using the module SAP_ROUTER_PORTSCANNER
msf auxiliary(scanner/sap/sap_router_info_request) > use auxiliary/scanner/sap/sap_router_portscanner
Yeah that’s right, this way we are doing a port scan using the SAP Router as a pivot:
Our target really has some SAP services running, what might they be? There’s this really nice feature that lets you use the SAP Router as a PROXY for every MSF module we could think of.
Connection string is:
sapni:<saprouter>:<port>SAP_SERVICE_DISCOVERY
Let’s set “sap_victim” as our sapni proxy and run the service discovery through SAP Router:
Okay…so Dispatcher, HTTP and SOAP…what might go wrong?
Default users enumeration for example:
SAP_SOAP_RFC_BRUTE_LOGIN
This module allows for testing a credential list (default ones for starter) on a list of SAP Clients. Also here we are using the sapni proxy.
msf auxiliary(scanner/sap/sap_service_discovery) > use auxiliary/scanner/sap/sap_soap_rfc_brute_login
…and something was found, sadly not on the 000 or 001 clients, but this is enough to make RFC requests, thus potentially running any other module which 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 here on, we could take one of many paths, because there are already many exploits we could use, which would probably work. Luckily for us, this is not the case, so we have the opportunity to browse resources directly using SAP GUI, by setting the right connection string over SAP Router:
root@kali:/opt/SAPClients/SAPGUI7.30rev9/bin# ./sapgui /H/sap_victim/S/3299/H/<victim host>We can logon to the above Client using the discovered credentials. Once inside we want to know what we can do and in this instance the SAPCPIC user has permissions to unlock the SAP* user and to edit DDC (administrative!) credentials, so we can escalate privileges to the top on this logon Client.
What else can we achieve? We know there are some “intra-client” RFC connections, but will there be any saved credential?
Here they are! This is a saved credential that lets anyone in. In this example from Client 00X to 00Y.
To demonstrate this we are using the RFC_READ_TABLE function to read the data of a Client-specific CLIENT DEPENDENT table 00Y:
And there you would have the content (sorry you can’t read it :P )
We have shown that we can move between clients using connections with stored credentials. What else can be done? Elevate further? Access clients 000/001? Run commands or get a shell? All of this actually.
By running transaction SM69 we can create commands to be run by the OS and get a feedback of the execution:
Nice! But this is really really uncomfortable, so we’d prefer an interactive shell…pity that we are behind a SAP Router, so let’s try to see if by chance it allows us something different:
Well then, by reading the file saprouter.tab we notice that developers left some ports open, routed but unused. Not yet at least, so let’s use them!
Now we know that if we establish a connection over the sapni proxy, SAP Router will forward our requests to the above mentioned ports to our victim, so to have a bind shell we run the usual netcat command directly from SAPGUI:
Meanwhile getting ready with exploit/multi/handler on MSF:
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:3299We run it and…whoops! Interactive shell! Now let’s just upgrade it a little with Python and…done!
What can be done with a shell? Practically everything, but without going to do the usual escalation path to root (which is not necessary) let’s see if some careless developer has left something useful, like a script that does things in the DB:
What do we have in the script:
- the path to the binary to access the database
- credentials and logon type
- DB specific parameters, censored
And here is how to access Client Dependent data on Client 000, directly from the DB:
Had we been less lucky, here we would still have the .dat containing the unencrypted data (it is 40GB but a well tailored grep would allow us to extract all the information we want)
CONCLUSIONS
This was a case where some precautions were taken, but I still managed to gain access thanks to distractions that could be considered as minor.
In other occasions I have been able to ascertain that more elaborate transactions such as SE16N or UASE16N would still allow lateral access to Client Dependent data. While where it is not allowed, SAP debugging (/ h) helps us, because it lets us directly modify requests and even to make editable fields that would normally be read only (debug -> modify SHOW in EDIT).
Alternatively you could play with the DBA COCKPIT or directly with user profiles.
In this article I have not dealt with the possibility of decrypting SAP passwords, but the topic is quite widespread and known. CODVN I was used here, which uses the multiple encryption of the BCODE, PASSCODE and SSHA fields, so I didn’t eve try, but remember that the most likely situation is to find pieces of credentials between BCODE and PASSCODE.
For someone who doesn’t know SAP I feel quite satisfied.
Insights:
Practical SAP Pentesting — Alexander PolyakovSAP’s Network Protocols Revisited — Martin GalloSAP Penetration Testing Using MetasploitSAP Penetration Testing with Bizsploit — Mariano Di Croce
Hardcore SAP Penetration Testing
Originally published at https://www.linkedin.com.
