3299 - Pentesting SAPRouter
Last updated
Was this helpful?
Last updated
Was this helpful?
Copy of:
Saprouter is basically a reverse proxy for SAP systems, typically sitting between the Internet and internal SAP systems. Its main purpose is to allow controlled access from hosts on the Internet to the internal SAP systems, since it allows for a finer grained control of SAP protocols than a typical firewall.
This means that saprouter usualy ends up being exposed to the Internet, by allowing the inbound TCP port 3299 to the saprouter host on the organization's firewalls. And from the saprouter, at least it should be possible to reach an internal SAP server. This makes it a very interesting target, since it can provide a way into the “high value” network.
The following figure shows a basic network setup, which we will use for the examples:
So, from the output we see that someone on the Internet (1.2.3.12) is connected to an internal host (192.168.1.18) on port 3200. Port 3200 is a common SAP port for the DIAG protocol (that's where the SAP GUI application connects to SAP servers). We also obtain information about the internal IP addressing scheme, they're quite surely using at least the 192.168.1.0/24 network, or some subnet in that network.
Enumerating internal hosts and services
The module connects to the saprouter and requests connections to other hosts (defined in the TARGETS option) in specific TCP ports. It then analyses the replies, and understands whether the requested connection is possible or not. This module provides a few options that can used:
At the very least you'll have to set the saprouter's IP address, in the example case, 1.2.3.101. Then, set TARGETS to the internal network addresses you'd like to scan, and finally set PORTS with the TCP ports to scan.
The module provides also an INSTANCES option that allows simplifying the definition of the PORTS option. SAP installations support multiple instances, providing similar services, so each instance has assigned TCP ports. For example, SAP instance 00 will have the SAP dispatcher service (where SAP GUI connects to) on port 3200 and instance 01 on port 3201. The PORTS option supports a “wildcard” which is “NN” that will be replaced with the instance number, hence scanning ports for all the defined instances. So, if we want to scan instances from 00 to 50, we can define the INSTANCES and PORTS variables this way:
With this setting the module will scan ports in range 3200 to 3250.
In the source of the module you have information regarding the common default ports on SAP systems, which we will now be using for scanning:
We can try to understand why some connections are not allowed through the saprouter by using the VERBOSE option. When VERBOSE is set to true we are able to see the response from the saprouter, and map the defined ACL.
We will now scan the 192.168.1.18 and the 192.168.1.1 hosts, but only on port 3200, to see if we can connect to both SAP dispatchers:
As you can see, we now also know that we cannot connect to other host on port 3200, since it is blocked by the ACL defined on the saprouter.
Mapping the ACLs
An interesting thing about the saprouter, is that it supports two types of connections:
Native – These connections are simply TCP connections;
SAP protocol – These are TCP connections with a twist, the protocol states that all messages are started with 4 bytes stating the length of the following content.
The SAP protocol is specific to saprouter, and is what the SAP GUI uses to connect to the SAP DIAG port through the saprouter. The native protocol is used for allowing other types of connections to pass through saprouter.
This module allows for specifying which type of connection to test during the scan in the MODE option. The default is the SAP protocol, which is the most probable to be used in production. However, it is not uncommon to find other services allowed through the saprouter, where the ACL will allow native (TCP) connections through.
We can set the MODE to TCP in order to assess whether this type of connections are allowed. We will now scan the internal hosts, both on port 3200 (SAP DIAG) and 80 (HTTP), with VERBOSE set to true, on both instances 00 and 01 and see what happens:
From the output and the previous information we now know that the ACL is something like this:
Allow TCP connections from any host to 192.168.1.1 to port 80
Allow TCP connections from any host to 192.168.1.18 to port 80
Allow TCP connections from any host to 192.168.1.1 to port 3201
Allow TCP connections from any host to 192.168.1.18 to port 3201
Allow SAP connections from any host to 192.168.1.18 to port 3200
Blind enumeration of internal hosts
If you recall, we started by obtaining information from the saprouter which allowed us to know the IP address on an internal host, and we went on from there. But what if the saprouter doesn't provide us with that information?
One option is to just start scanning private address spaces, and see what happens. The other is to blindly enumerate hosts by hostname.
Saprouters are able to resolve hostnames we request it to connect to. Saprouter is also kind enough to let us know what are the errors when it fails to connect (you can actually see the raw responses by uncommenting line 242 on the module source).
With this feature we are able to enumerate internal hosts by hostname, and try to go directly for the gold!
For this, we need to set the RESOLVE option to “remote”. In this case, the module will request connection to the TARGETS defined, without resolving them locally, and we can try to guess the internal hosts, and eventually connect to them without ever knowing their IP addresses.
Important things to remember when blindly enumerating hosts:
Set VERBOSE to true;
We'll get more information from saprouter if MODE is set to SAP_PROTO;
It is enough to set only one port to scan, since we're only interested at this point in the information sent by the saprouter (try 3200);
Results will vary depending on the configured ACL. Unfortunately blocked connections won't give us much info.
In this example we'll try the hostnames sap, sapsrv and sapsrv2.
From the output we see that the host “sap” does not exist, but that host sapsrv does, although it is unreachable, and sapsrv2 exists and we can connect to port 3200.
This technique can also be used to try to find other hosts on the network, not SAP related, just try using common hostnames, like smtp, exchange, pdc, bdc, fileshare, intranet, or what other nice hostnames you might have on your bag of tricks
The last mile
Now that we have obtained all this information, we know the internal hosts available, what services are allowed, and what protocols we can use to pierce the saprouter, we can actually connect to internal servers, and proceed with our pentest.
If all went well, you'll have a nice output of the module in the loot containing interesting internal information from the target SAP host (such as internal usernames you can then try to brute force ).
Pivoting can (and should!) be used to run other modules against internal hosts, not only SAP systems!
Conclusion
We've seen how it is possible to exploit weak saprouter configurations that can allow access to internal hosts all the way from the Internet, all this using only metasploit's support for pentesting SAP systems.
I hope this article can help shed light on both the risks associated with saprouter deployments, as well as SAP security in general.
References
port:3299 !HTTP Network packet too big
First we'll start by performing a SAP service scan of the exposed IP address, using the module, in this case, 1.2.3.101.
The scan shows us that the host is running a SAP router on the expected port TCP 3299. We can now dig deeper, and attempt to obtain some information from the saprouter. If it has been misconfigured, and often they are, it may be possible to obtain internal information, such as connections established through the saprouter to internal hosts. For this purpose we use the module:
With this information, we are now able to start scanning the internal network. Since saprouter works like a proxy, we will attempt to connect to it and request connections to internal hosts and ports, and see the replies from saprouter. This may gives more insight into the internal hosts, services and ACLs, depending on the configuration of the saprouter. We'll be using the module for this purpose.
Metasploit provides us with an awesome way to saprouter as a proxy, using the Proxies option, thanks to Dave Hartley ().
So at this point, we want to start gathering information on the internal sap server we have discovered in host 192.168.1.18. As an example, we'll be using the module which exploits CVE-2013-3319 and give us details on the OS the server is running on by querying the SAP Host Control service on port 1128 via an unauthenticated SOAP request. We'll be pivoting through the saprouter, using the proxy support in metasploit:
[ - Mariano Nun ez Di Croce - SAProuter .pdf]( - Mariano Nunez Di Croce - SAProuter .pdf)
