Skip navigation
All Places > Metasploit > Blog > 2015 > June

As todb pointed out in the last weekly metasploit update wrapup we recently added two new exploits for Flash: CVE-2015-3090 and CVE-2015-3105, based on the samples found in the wild.


As you're probably aware, the last years, and especially the end of 2014 and 2015, Flash has become the trending target for browser exploits in the wild. Here is a summary of Flash vulnerabilities abused by different Exploit Kits. It is based on the contagiodump overview and the Malware Dont Need Coffe blog data. It also shows the vulnerabilities actually supported in Metasploit, and the targets for every exploit. It's just a summary, maybe the vulnerability set is not complete! I'm not a malware researcher after all!





Adobe Flash ActiveX

IE 32 bits on Windows XP SP3 and Windows 7 SP1




Adobe Flash ActiveX

IE 32 bits on Windows XP SP3, Windows 7 SP1 and Windows 8


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1 and Windows 8.1


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1 and Windows 8.1


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1 and Windows 8.1


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux


Adobe Flash ActiveX / IE 32 bits on Windows 7 SP1

Adobe Flash Plugin / Firefox 32 bits on Windows 7 SP1 and Windows 8.1


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux


Adobe Flash ActiveX

IE 32 bits on Windows 7 SP1

Adobe Flash Plugin

Firefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux



As you can read, we are doing our best to keep the Framework up to date with Flash vulnerabilities exploited in the wild, so hopefully people can simulate/test them from a confident source. Because of the amount of Flash exploits, we've added a kind of Flash exploitation library to make easier the task of adding them to the framework. We'd like to share 5 cents about how to use this code.


Let me start by refreshing our memory... Since 2013 Oct 2012 (thanks Haifei Lei) a common technique to exploit Flash vulnerabilities has been to abuse the AS3 Vectors, for both spraying and to achieve full memory read/write. It is facilitated by the Flash allocator and the own Vector object layout, whose length lives together with its data. The abuse of these objects has been well explained in the past. The first (and excellent) explanation which I can remind is the one provided by Haifei Li in his article Smashing the Heap with Vector: Advanced Exploitation Technique in Recent Flash Zero-day Attack. And it is precisely the technique used by the exploits in the Framework. Since I don't think I can explain it better than Haifei Li I recommend you to check the above link before going ahead, in case you're not familiar with the topic.


That said, back to the Metasploit Framework, let me start by helping you to locate the source code for the Flash exploitation library in the code base. It can be found on the data directory, at data/external/source/flash_exploiter path. Actually it supports exploitation for Adobe Flash (32 bits), ActiveX and plugin versions, for both Windows and Linux platforms. (Remark: we're not testing Flash coming with Google Chrome and IE since Windows 8, so the exploits available on MSF don't cover these targets actually). Last but not least, worths to say this code uses some ideas from @hdarwin89, whose flash exploits can be found on its own repository.


So, summarizing, the goal is which new Flash exploits just need to provide an "Exploit" class. An Exploit object must be able to corrupt a Vector.<uint>'s length with the value 0x3fffffff or longer. Once this condition has been achieved the Exploit just needs to create a new "Exploiter" instance and allow the magic to happen. Here is an "Exploit" template:


    import flash.display.Sprite
    import flash.display.LoaderInfo
    import mx.utils.Base64Decoder
    import flash.utils.ByteArray

    public class Exploit extends Sprite
        private var uv:Vector.<uint>
        private var b64:Base64Decoder = new Base64Decoder()
        private var payload:ByteArray
        private var platform:String
        private var os:String
        private var exploiter:Exploiter
        public function Exploit()
            platform = LoaderInfo(this.root.loaderInfo)
            os = LoaderInfo(this.root.loaderInfo).parameters.os
            var b64_payload:String = LoaderInfo(this.root.loaderInfo)
            var pattern:RegExp = / /g;
            b64_payload = b64_payload.replace(pattern, "+")
            payload = b64.toByteArray()

                The exploit code here. The goal is to corrupt the uv vector length with 0x3fffffff or bigger.

            exploiter = new Exploiter(this, platform, os, payload, uv, 0x13e)


A couple of things to take into account. First of all, notice which the Exploit template get the platform and the operating system (as the shellcode) from FlashVars. It is because BrowserExploitServer provides this information from a prior stage, and we're using it, but you could get it by writing your own AS code on the exploit, of course.


The second important thing is the Exploiter constructor documentation, because it's the last call which the Exploit should do:


Creates an Exploiter instance and runs the exploitation magic

* exp: Exploit object instance, its toString() vtable entry will be overwritten to achieve EIP.
* pl: target platform, "linux" and "win" supported
* os: target operating system for "win" platforms, "Windows 8.1" and "Windows 7" supported
* p: ByteArray with the payload to execute
* uv: Vector.<uint> whose length is overwritten with 0x3ffffffff or longer
* uv_length: original uv's length, so the Exploiter can (hopefully) restore everything after exploitation.
public function Exploiter(exp:Exploit, pl:String, os:String, p:ByteArray, uv:Vector.<uint>, uv_length:uint):void


Most of the Flash exploits in the framework have been written or migrated to use the Exploiter code, but be careful, because we keep updating the Exploiter code, and not all of them use the last version of the code! The Flash modules actually using the flash_exploiter code are: CVE-2014-0515, CVE-2014-0556, CVE-2014-0569, CVE-2014-8440, CVE-2015-0311, CVE-2015-0313, CVE-2015-0336, CVE-2015-0359, CVE-2015-3090 and CVE-2015-3105.

And that's all for today! Stay tuned for more Flash exploits and the new Browser Autopwn being developed by sinn3r. We find the combination of these a powerful way to simulate targeted campaigns on your next pentest!

Flash as a Vulnerability Vector


hawkman.jpgWhile Adobe has made great progress in releasing both regular and emergency updates to Flash, it's becoming clear that Flash itself is becoming an albatross around the neck of every browser. This week, Adobe released APSB15-14, a fix for CVE-2015-3133. This cross-browser vulnerability was discovered and reported by FireEye, and like all the recent critical Flash vulnerabilities, it can enable an adversary to completely compromise a targeted desktop. Meanwhile, we're shipping two new Flash Metasploit modules written by our own Juan Vazquez: One for CVE-2015-3105, disclosed earlier this month, and CVE-2015-3090, disclosed in May of 2015. I expect we'll be seeing a public exploit for penetration testers for CVE-2015-3113 soon.


This all leads me to believe that the risk introduced by Flash is too big to pretend to ignore. It's enabled by default with pretty much every consumer browser, and very few normal users are aware that it's even possible to disable it. Enterprise IT organizations are also unlikely to disable Flash on a site-wide basis precisely because it's so ubiquitous, and there is a fear that doing so would "break the Internet" for their constituents. It seems to me that Flash is lagging behind every major browser when it comes to security engineering, and because of this, the good security work going into stock browsers is getting undermined by Flash's always-on, always-default de facto status. Today, Flash is a favored vector for both online criminals and Pwn2Own competitors.


Doesn't this all sound a little familiar? Two years ago, Java is was in exactly the same boat. The Internet user base was suffering through a seemingly endless series of critical Java bugs, IT shops felt like it was impossible to disable, and Oracle was not making significant headway against the onslaught of both legitimate and criminal security R&D forces targeting Java.


While Java is still a lingering problem, browsers today have Java locked under a "click-to-play" procedure by default, where user interaction is required for any Java applet to run, and many, if not most, IT organization recommend or require disabling Java on the desktop completely.


Can we do the same with Adobe Flash? According to cybercrime investigator Brian Krebs, it appears absolutely possible. After taking a vow of Flash celibacy for a month, Krebs found that Flash is not nearly as ubiquitous for multimedia content as it used to be, thanks to competing technologies like HTML5's suite of multimedia functions. Major video content sites like YouTube and Netflix generally do not require Flash at all. It is quite possible to default-disable Flash for most sites, enabling it for just one or two trusted sites where there is no alternative, and enable a similar click-to-play requirement for running that Flash content.


Of course, this is all an arms race, and I have no doubt that in two years, we'll all be wringing our hands about the next seemingly ubiquitous Internet technology. But, we have an opportunity today to learn from our own recent history, and I hope we, as a security community, take it.


New Modules


This week brings us five new modules. First, we've two Flash exploits discussed above, a local privilege escalations exploit which was also used in a Flash-based targeted campaign (so says FireEye in their blog from April). Over in auxiliary and post land, there's a new pair of Windows info leak auxiliary modules. One is for remotely dumping memory via the HTTP.SYS vulnerability MS15-034, which is kind of a big deal. The other is a new domain-level hashdump post module that's super handy for quickly snarfing all domain credentials on a compromised domain controller.


As usual, you can peek in on the changes this past week with this compare view on GitHub.


Exploit modules


Auxiliary and post modules


Weekly Metasploit Wrapup: Recog

Posted by todb Employee Jun 18, 2015

Recog Scanning with Metasploit


This week, our own Jon Hart started in on souping up a couple auxiliary modules with Recog, Rapid7's free, open source platform recognition framework. Metasploit has lots of these version scanners -- 27, to be precise -- in the auxiliary module tree, and nearly all of them would be better off with some more normalized fingerprinting. The SMB scanner already uses it, and has been for a little while now, so it's high time the other scanners got with the program.


Of course, this particular kind of omelet refactoring is going to require some broken eggs, which you can see on the currently in-progress pull request for the Recog mixin. While the pattern-matching signatures themselves are pretty rock-solid, the Recog framework itself is only about a year old with a dozen or so forks. It's safe to say that there will be lots of opportunity for tire-kicking and duct-taping during this rework effort in both Recog proper and how auxiliary modules ought to interact with it.


So, that's where you come in! We here at Rapid7 like Recog a lot. We wrote it (well, mostly Jon and HD), and we and use it in a few projects and products, but it's really easy to code oneself in a corner when we're the only ones using it. Without public pickup, even open source projects can find themselves in a place where usage can get weird and documentation ends up being a non-public oral tradition.


Since Recog so young, now is the time for you, dear open source contributor, to take a look and see where we're going with it. You're invited to read over the recent pull requests to see how you might want to start converting your favored Metasploit scanner to use Recog fingerprints, ask around on Freenode IRC or Twitter if you run into anything you don't understand, and document what tripped you up so the next volunteer doesn't get all frustrated. We're trying to keep our open source truly open and free, after all, so that's going to mean disclosing a few sausage-making details in the process.


Finally, while using any currently or future Recog-enabled modules, if you encounter services Recog is unable to identify, we'd greatly appreciate hearing about it, especially in the form of a PR to add support for the service in question. See Recog's contributing documentation.


Thanks, Jon, for leading the charge on this!


New Modules


This week brings a new exploit and a new auxiliary module, both for WordPress plugins, both from Roberto Soares Espreto, serial WordPress exploiter. We've been pretty heads-down on the Rails 4 integration work for Metasploit Pro and Metasploit Community Edition, so kind of a slow week this week in Exploit Land. We also held the UNITED Security Summit this week, so when you get a chance, check out Maria's write-up on that.


As always, you're invited to check the compare view from the last blog post to get up to speed and investigate what strikes your fancy.


Exploit module


Auxiliary module

Multi-Transport Meterpreter


Over the last couple weeks, OJ TheColonial Reeves has been fleshing out some new documentation on how Meterpreter's multiple transport system has been coming along. You can read up on it all at the GitHub wiki, but here's the tl,dr:



  1. Meterpreter sessions now have the ability to cycle between several transport protocols. This means that if a session is started on a basic TCP connection, you now have the option to "move" the session over to an HTTPS transport, assuming you have an appropriate listener set up (with, say, the multi/handler module). This is all easily done on the Meterpreter command line.
  2. If configured with multiple transports, sessions can and will fail over to alternate transports automatically. This is part of the overall goal of sessions resiliancy.
  3. You needn't name the same endpoint for your transports. This means you can hand over a session that you established on a target to a friend.


Yes, it's all kind of super rad, and huge thanks to OJ, Brent, HD, and Tim for making this all happen.


Of course, like all software, it's not quite "done," but that's on purpose. Since we believe in incremental, open development, right now, this very Friday afternoon, is a great time for you to jump in with this feature set and give feedback on how it's going. Love something? Say so on the Metasploit Freenode IRC channel or tweet us at @metasploit. Found a bug? File a GitHub issue, or even better, a Pull Request to either the Meterpreter repo or the Framework repo with a fix. It's all very fluid right now, but since working on Meterpreter has gotten to be quite pleasant, there's nothing stopping you from throwing in, too. It's an exciting time to be working on payload and post-exploit enhancements on long-term persistence. Just ask the shadowy puppet-masters behind Duqu 2.0.


New Modules


As indicated last week on my tweet, you really should check out m-1-k-3 and Ricky HeadlessZeke Lawshae's module for SOAP-based command execution on SOHO routers shipping with a vulnerable Realtek chipset. All told, we have eight new modules since the last blog post. For the entire diffs on Metasploit Framework, check out the compare, here.


Incidentally, if you haven't heard, msfencode and msfpayload will no longer be shipping with Metasploit. Instead, they've been replaced by msfvenom, which has the same functionality as both, and more. Consider this last call.


Exploit modules


Auxiliary and post modules

Oh hi folks,


Last year on December 9th, we made an official announcement about deprecating MsfPayload and MsfEncode. They are being replaced by msfvenom. Well, today is the day we pull the plug. We are currently in the process of removing these two utilities, and in a day or two you will never see them from upstream again.


If you are still not so familiar with msfvenom, you can always use the -h option to see the help menu. Or you can read the following wiki documentation to get started:


RIP MsfPayload & MsfEncode.


If you have any questions, please feel free to e-mail msfdev[at] Any bug reports or feature requests, please submit to Github.


Thanks yall!

Originally posted May 28, 2015


SSDP Attacks are Suddenly Huge

Like most of you, I love nothing more than kicking up my feet, donning my smoking jacket, and whiling away my work hours by reading security industry reports, such as Akamai's State of the Internet [Security]. They're dozens of pages long, and tend to reinforce my own personal biases, so it's a great way to pretend to work.


That said, the most surprising takeaway I got from the Akamai report is the huge criminal buy-in of SSDP, the Simple Service Discovery Protocol, as a spoofable, reflective protocol. At Rapid7, we've been paying attention to SSDP for a couple years now, and researchers Jon Hart and HD Moore have been warning people for a while now that that particular sky is falling.


It looks like 2015 is shaping up to be the year that the SSDP sky actually fell: according to Akami, 20% of all reflective DDoS attacks in Q1 of this year used SSDP as the attack vector, where SSDP did not show up significantly at all in Q1 of 2014. I'm no statistician, but that looks to be about a gazillion percent growth, year over year.


Given its effectiveness on bringing down targets and that there are literally millions of unsecured devices in the form of home routers that are susceptible to being unwitting participants in this attack, the Internet needs to come up with some dramatic protective measures to deal with this newly-popular threat.


Along Came A Moose

A couple weeks later, the Linux/Moose report was released by Olivier Bilodeau and Thomas Dupuy of ESET Canada Research, which details a worm that's currently romping around this huge sub-infrastructure of home routers which have predictable, default, or otherwise easily guessed external administration credentials. No exploits at all are used in Linux/Moose, but it seems pretty successful at infecting and replicating across many avenues with a goal of finding new homes in these embedded systems. It's a really fascinating read, and underlines this whole Internet of Junk that we're (we being the human species) building around us.


Incidentally, the name given by ESET, "Moose," has absolutely nothing to do with Rapid7's internal mascot. Just a coincidence.


So, what does this have to do with Metasploit?

If you've been reading this blog for more than a few weeks, you'll know that I, too, tend to pay special attention to modules that come in which abuse SOHO routers, and when I see new pull requests come in from long-time contributor Michael m-1-k-3 Messner, I know I'm about to get a face full of hot home router mess. This week is one of those weeks, and we now have a new module, the Netgear Unauthenticated SOAP Password Extractor, which does pretty much exactly what it says on the tin, based on the work by Peter darkarnium Adkins and Robert MŸller. Thanks, Michael, for the work on that!


Peter's initial reports didn't seem to get a whole lot of pickup when he reported them back in February, and the BID and OSVDB references are pretty sparse. But, never fear, you can read all the gory details over on his GitHub repo, and see that this is Kind Of A Big Deal(tm). The short story is, if a device has remote management enabled, there are trivial authentication bypasses thanks to some insecure SOAP services, and this is present on several versions of Netgear routers. Of course, these routers also live in your local coffee shop, so attackers can also perform this attack in the default configuration of LAN-side only. Oops.


Hopefully, this module publication will raise the visibility of this and other kinds of SOHO router bugs that appear to becoming epidemic in my favorite place, the Internet.


New Modules

This week, we have the aforementioned Netgear module, along with a new Flash exploit and a rather terrifying Lenovo privilege escalation. You can always check the full compare against last week for more on what's been going on in Metasploit.

Exploit modules

Auxiliary and post modules

Originally posted May 22, 2015

Greetings, fellow citizens of the Internet. It's time for your favorite blog post and mine, the Metasploit Weekly Wrapup.

So Many Repos

If you've been following along with Metasploit Framework development, you may have noticed that we have more than a couple repositories for committing code. I wanted to take a moment today to outline which of the 84 public repos under the Rapid7 GitHub account you, the intrepid open source, are most likely to care about:

Meterpreter: This is the flagship command shell interpreter, and is usually the payload you want for any given exploit delivered by Metasploit. There's a ton of activity in there on making life even better for you offensive security types.

Meterpreter-deps: Chunks of code that Meterpreter depends on to be built. This doesn't ship with Meterpreter directly, but is used to build it.

Metasploit-payloads: This is where the build artifacts for the Windows and POSIX meterpreters live now, and where the rest of the Meterpreter payloads are headed. It intends to replace the old meterpreter_bins repository, and if we ever get into the business of compiled payloads that aren't Meterpreter, they'll likely show up here. All one happy persistent shell family.

Metasploit-credential: Metasploit-credential is responsible for most of the back-end logic around how authentication works. It's been shipping for nearly a year, and many -- but not all -- of the most popular bruteforce modules rely on it to track usernames, passwords, realms, tokens, and how they all interrelate.

Metasploit_data_models: This gem handles all the database and ActiveRecord components of Metasploit, and provides the means to treat Metasploit as a Rails Engine -- see the link for more on what Rails Engines provide for other Rails-based applications. If you're a Rails-ish developer and want to integrate Metasploit-flavored things in your web application, you'll want to start here to get a sense of how it all works.

Metasploit-model: This is the pixie dust that lets metasploit_data_models and metasploit-framework actually function together in the ways you'd expect.

Metasploit-concern: This allows for using ActiveSupport::Concerns in Metasploit-based applications. They're all the rage in Rails land, and tend to make the syntax of some functions a lot easier to read and understand. You're invited to read this writeup from DHH on why Concerns are good for your Rails applications, and then deconvince yourself about their usefulness with Corey Haines' blog post on why he doesn't use ActiveSupport::Concern.

Recog: Recog is a stand-alone project that abstracts out all the logic needed to make fingerprinting calls on services and hosts. It's used by both Metasploit and Nexpose, and if you're in the remote identification business and like working in Ruby, you'll definitely want to check it out.

While far from inclusive of the several dozen repos, this should be enough to get you started if you happen to be looking for projects related to Metasploit that you want to make your mark on.

Now, with all these gems, we're still working out a decent, contributor-friendly way to manage the various feature requests and bug reports involving these repositories. On the one hand, most people today only notice bugs or come up with enhancement ideas when using Metasploit Framework or Metasploit Pro proper, and simply report against those projects. This is how we handle things today, and it seems okay. After all, if you're running into an issue with metasploit-credential, you're almost certainly using normal, everyday Metasploit.

On the other hand, these are for real, stand-alone repositories that do not technically require Metasploit Framework to function, and could come up for use in someone else's Rails-based application. As such, they may be deserving of their own issue trackers, which they have today, even though they are rarely used. Actually embracing this, though, means slightly more accounting overhead when we want to find out how much "work" has gone into "Metasploit," and how much there is left to do. It also tends to require more sophisitication on the part of the user to figure out where a bug "really" is, and many, many Metasploit users are not professional Ruby developers.

So, if you happen to know of a good, open-source, multi-repository methodology to track changes and measure things like developer velocity and technical debt that doesn't require a master's degree in Jive Mechanics, please tweet it at @metasploit. Getting a handle on the true labor investment the open source community is contributing to Metasploit is a subject near and dear to my heart, mainly because I know we wouldn't be anywhere without you all. The Metasploit community is kind of a huge open source success story, after all. We have over 3,800 forks today, which puts us in the top one hundred GitHub projects running, and I'm always interested in how to keep telling that story so that not only we get better at producing quality software, but so that other open source projects can replicate our success.

The Metasploit T-Shirt Contest

In non-code news, the Metasploit T-Shirt Design Contest has one more week to go. You can sign up over at 99Designs, and as of this moment, we have 106 designs submitted. There are already some pretty rockin' designs in there, so competition is stiff. If you're of a graphic design bent, and want to completely blow the cover of thousands of onsite penetration testers, then maybe take this upcoming holiday weekend to scribble something amazing.

Recent Changes

You're welcome to inspect the entire diff from the last Wrapup blog post by popping over to this compare view. The high points for the last couple weeks have all been around the incremental fixes to Meterpreter -- the work from OJ and Brent accounts for about 28% of the total commits since May 6. If you haven't messed around with Meterpreter lately, now is a fine time to jump in -- see the repos mentioned above to get started. The projects compile cleanly, the codebase is mostly sane, and we're rocketing forward with making Meterpreter even more stable, useful, and pleasant to both work on and with.

In module land, we have ten new modules, three of which target F5 Networks gear. Thanks to Denis Kolegov for seeing those auxiliary modules through!

Exploit modules

Auxiliary and post modules

Originally posted May 7, 2015

Hi folks. It's been a little while. I know, I know. Things have been a little wonky around here lately, as you no doubt have noticed. So, while this is nominally the Weekly Metasploit Wrapup, it's been a little more than a month since the Community Cutover on April 1st. That said, our blog platform now seems stable enough to resume writing these missives, so let's cover the highlights of what's been going on in the People's Republic of Metasploit since the last post.

If you just want to see the diffs, just check out the GitHub compare. Only about a thousand changes to go through for the last several weeks, so have a blast with that.

WordPress Exploitation Extravaganza

Metasploit now boasts over a dozen new WordPress-related exploits an auxiliary modules, most of which were contributed by Roberto espreto Soares, with hat tips to community committer Christian FireFart Mehlmauer for landing assistance. This avalanche of exploits illustrates rather obviously the problems historically associated with wordpress plugins, arguably to the point that this particular dead horse has truly been beaten into a soupy, dessicated mass.


So, we've had to rate limit the sheer volume of WordPress exploits that were hitting the Metasploit pull request queue, lest we accidentally become WordPressSploit. In fact, after I so cruelly dismissed a handful of new WordPress modules in this comment, that's precisely what Roberto did, and now he's chugging away on WPSploit, which can be used as a local add-on for all your WordPress plugin exploitation needs. All you need to do to track it is keep up a local clone of that repository, and symlink the auxiliary and exploit module directory structures in your local $HOME/.msf4 directory, and you can pick them up immediately. After all, who am I to be the sole arbiter of what's worthy of a Metasploit module?

This development over the last couple weeks illustrates the ease of forking and maintaining a customized build out of Metasploit Framework. After all, we have a permissive, open license, and given the collaborative power of GitHub, pretty much anyone with an interest can start building out their own sub-communities of exploit development. Yeah, that open source model is pretty powerful stuff, and WPSploit is already up to 18 additional modules.

Naturally, given the third of our three-clause license, Rapid7 neither endorses or promotes the use of this (or any other) side-repository of Metasploit modules, but I'm happy to let you know that it exists and that I'm happy about it.


Another Round of Flash Exploits

On the other side of the browser connection, we also have four new client-side Flash exploits contributed by our own Juan Vazquez, half of which were based on the research work of hdarwin89. This has been an area of interest for a while for Juan, especially given that there are more than a couple black market exploit kits that include a number of Flash exploits. Now that he's wrapped up the server side Java Remote Management Interface research, presented at last month's InfoSec SouthWest, Juan has dived head first into Flash exploitation research and development in order to better simulate the world of Internet crime.


Want to Help?

If you're the sort of person who reads this blog regularly, want to help out, and lives in Austin, Texas, USA (or can get here quickly), we have an internship open for working on the Metasploit family of products. Don't worry, all of Rapid7's internships are paid, and in fact, the last intern we picked up for Framework, William Vu, turned out to be an amazing new permanent hire, and is a huge reason why Metasploit Framework is now the in the top ten of all GitHub-hosted Ruby projects. So, this is definitely not a boring, go-get-me-coffee-and-then-do-all-this-horrible-gruntwork kind of internship; a successful applicant has every opportunity to make a name for themselves here on the forefront of open source, openly developed security software. For more details on the requirements, see the official job description here. And hey, I'd be happy to review your resume if you'd like. Hit me up on Twitter.


New Modules

Right, so like I said at the top, it's been about a month since the last Weekly Wrapup, so there are more than the usual on the "new" module list -- thirty-nine, to be precise, including the above-mentioned WordPress and Flash modules. Other highlights include a denial of service module for the much-ballyhooed HTTP.sys overflow (use with care, for you will bluescreen if successful!), a local exploit for the Apple OSX "rootpipe" bug (a patch for which was not backported to older versions of OSX), and a couple SOHO router/DOCSIS modem exploits.

You can check the release notes for the last three Metasploit Pro and Community updates over here.


Exploit modules

Auxiliary and post modules

Metasploit 2014 winning design


Originally posted May 15, 2015

Hacker-designers! We need you! Show us your graphic skills, design an epic Metasploit t-shirt, and win Eternal Fame and Glory!

Ahem, er, rather, we're looking for someone to design this year's Metasploit t-shirt.


And if you are this year's winning Metasploit t-shirt designer, you will get $230USD and the notoriety and/or *immense* personal satisfaction in knowing that you're the 2015 Metasploit t-shirt designer, whose design will be printed on thousands of t-shirts that we'll distribute at this year's BlackHat conference in Las Vegas.

We've had stellar contributions in years past -- last year's design was quite nifty (see image at right) -- and as is only right for anything Metasploit-related, the winner is determined by community votes. So calling in old favors and leaning on your friends is highly encouraged!


This contest doesn't run for long, so act fast -- 2015 Metasploit T-Shirt Design Contest - 489841/brief

Originally posted April 19, 2015


Due to changes in regulatory requirements that are applicable to Metasploit (Pro and Community) and similar products, as of Sunday, April 19, 2015, individuals outside of the US and Canada who would like to use Metasploit Pro or the Metasploit Community Edition will need to request a license and provide additional information regarding themselves or their organization designation. In accordance with the new requirements, the request will be reviewed by Rapid7 and, unless the user is a non-US or non-Canadian government agency (or is otherwise ineligible to receive the products without approval from the US Department of Commerce), the request will be fulfilled. This affects license requests made through as well as any third party sites that currently offer Metasploit Pro or Community products for download.


This does not in any way affect or apply to Metasploit Framework. As an open source project, Metasploit Framework will remain available for download and access outside of the US and Canada without additional process.


Why is this happening?

Rapid7's Metasploit products use encryption and, like other products that use such technologies, are subject to US export requirements.  In addition, Metasploit and other intrusion software products are encountering increasing US and international regulatory review and restrictions.  In compliance with these regulations, we need to change the process by which free and trial versions of Metasploit Pro and Community editions are obtained.


What does this mean?

Due to increasing US and international regulatory restrictions, certain prospective users are ineligible to receive Metasploit Pro and Community editions without approval from the US Department of Commerce.  Users will need to provide reliable and accurate information to Rapid7 in order to request a license. As a general matter, non-governmental users will be eligible to receive a license key.

Please note that while most users will continue to be able to receive a license key for the free Metasploit Community and Pro editions, there will be a longer licensing process than there was historically due to the requirement that we review the information to make an assessment of whether the non-US/non-Canadian user is eligible to receive the products. We will work to process license key requests that have provided complete and accurate information expeditiously, but please anticipate that it may take up to 48 hours to complete. If you are in the United States or Canada, there will be no change for you.


I already have a Metasploit Community license or a Metasploit Pro evaluation. Will my license be revoked?

No, as a general matter this issue should not affect existing licenses retroactively. Once your license expires however, you will need to go through this new process. (Metasploit Pro trials will last for 14 days until they expire, and Metasploit Community licenses last a year.)  We will follow the appropriate US and foreign government regulations and seek authorization to continue serving our customers who already have licenses, but cannot guarantee the success of these applications to continue usage in the future.  We will stay in touch with any impacted customers and keep them apprised of their license status as they renew.


If you are outside the US and Canada, and are currently evaluating a Metasploit Pro license, we encourage you to reach out to your Account Executive for more information on this issue.


Please let us know if you have any questions, and we appreciate your understanding as we comply with US export laws.  Thank you.

It is always a running battle to keep an application's backend up to date with various technologies. Today, we are excited to announce that Metasploit Framework now ships with Rails 4.0. Upgrades like this are sometimes hard to get excited about because if everything goes well, users should see no difference. There are many reasons to upgrade to Rails 4, though.

Why Upgrade

Here are the important reasons to upgrade from our perspective:

o Security is a big part of why we have to keep our code up to date. We want to make sure that any third party technology we use is up to date in order to receive security updates and patches. This is especially important for us, given what our product does.

o Rails 4 comes with many new features that make our lives easier from a development perspective. We want to make sure that we can utilize the latest and greatest things in order to become more efficient in our everyday programming efforts.

o We want to make sure we can provide the best integration experience possible. Staying with industry standards helps us provide the best experience possible to our community and our customers.

What Should I Expect

Your everyday experience with Metasploit Framework will be no different. This upgrade does not introduce any changes to the way Metasploit Framework works. Thus, you should not see any usability changes. Additionally, we are always committed to delivering high quality code all the time. We have performed extensive testing to make sure we are not introducing any issues to Metasploit Framework. At this point we are very confident that our users' experience will not degrade at all.

However, as any developer knows, when you are dealing with a complex application such as Metasploit Framework, there is a likelihood of things slipping through the cracks. Thus, we kindly ask our users that if you see unusual behaviour as you continue to use Metasploit Framework, especially shortly after Rails 4.0 rollout, please keep in mind that the behaviour might be surfacing due to Rails 4 upgrade and please approach troubleshooting the issue with that in mind. Additionally, we kindly ask you to open an issue on Metasploit Framework Project - Github to let us know about your experience and steps you have taken to verify the issue.

I want to thank you for the folks here in Austin, TX for their hard work that they did past couple of months in order to make this upgrade possible.

As always, I want to thank our community for supporting us to improve Metasploit Framework years to come.

*** Rails 4 is only included in Metasploit Framework Master Branch on Github. If you are using Metasploit Community edition you will receive Metasploit Framework Rails 4 upgrade within two weeks. We will call the changes out in our release notes.


Eray Yilmaz - @erayymz

Sr. Product Manager, Metasploit

Filter Blog

By date: By tag: