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

Metasploit Pro's smart exploitation function is great if you want to get a session quickly and don't care about being "noisy" on the network, but there are certain situations where you may want to use just one exploit:

 

  • You're conducting a penetration test and want to exploit just one vulnerability so you don't draw too much attention (i.e. you want to use a sniper rifle, not a machine gun)
  • You're a vulnerability manager and want to validate just one vulnerability to know whether you need to fix it
  • You've just remediated a vulnerability and want to know if your measures stop the vulnerability from being exploited

 

Here's a quick recipe on how to do this with Metasploit Pro:

 

Discovery.png

 

  • In the Analysis tab, click on Hosts.  Then, click on the host that has the vulnerability you want to exploit.

 

hosts.png

 

  • Click on the Vulnerabilities tab and click on the Exploit in associated to the vulnerability you want to exploit

vulns.png

 

  • You'll see the module page for the exploit you have just chosen. The host IP is already pre-filled. Click Run Module

 

 

module.png

  • If the module fails to exploit this vulnerability, you will see an error message in the console text and no session for this host. On the hosts tab, the status will say "scanned" (not "shelled").

 

exploit failed.png

 

scanned.png

 

  • If the module successfully exploits a vulnerability and creates a session, you'll see:
    • A yellow line in the console Session xx created
    • The number 1 next to the sessions navigation menu item (or a higher number if you have already created other sessions before)
    • On the host tab, the label Shelled next to the host IP

 

session1.png

 

session2.png

 

shelled3.png

 

Want to give this a go? Try Metasploit for free today!

It's easy to import third-party vulnerability scanning results into Metasploit. These formats are supported:

 

  • Acunetix XML
  • Amap Log
  • Appscan XML
  • Burp Session XML
  • Core Impact Pro XML
  • Foundstone Network Inventory XML
  • IP Address List
  • Libpcap
  • Microsoft MBSA SecScan XML
  • nCircle IP360 (XMLv3 & ASPL)
  • Metasploit PWDump Export
  • Metasploit Zip Export
  • Metasploit XML
  • NetSparker XML
  • Nessus XML (v1 & v2)
  • Nexpose Simple XML
  • Nexpose XML Export
  • Nmap XML
  • Qualys Asset XML
  • Qualys Scan XML
  • Retina XML

 

Here's how you can import these format:

 

  • Click on Import on the Overview tab.

import.png

 

  • Choose the file you want to import:

 

import2.png

  • If you want, you can tag each imported file to refer back to the tag later or simply to know where the data came from. Tagging is exclusive to Metasploit Pro.

 

tag.png

 

Don't have Metasploit yet? Try Metasploit for free today!

I am proud to announce that Nexpose 5.1.0 now supports "pass the hash", a technique to remotely authenticate against a Windows machine (or any SMB/CIFS server) with the mere possession of LM/NTLM password hashes, without needing to crack or brute force them. Nexpose is able to use the hashes to perform credentialed scans to produce very detailed scan results of all sorts of local and remote vulnerabilities that may otherwise not be detectable.

 

And penetration testers, rejoice! Metasploit Express and Pro were also updated this week (version 20120124000003) to automatically communicate these hashes to Nexpose. When Metasploit successfully exploits a target host and collects its password hashes from the SAM database (ie. the host status is shown as "looted"), a Nexpose scan task initiated from the Metasploit interface can use the hashes to authenticate against the host and run a credentialed scan.

 

The combination of these two tools is extremely powerful. In a matter of minutes, a penetration tester can go from the phase of discovery, to exploitation, to generating a comprehensive Nexpose report of all vulnerabilities affecting the target, with every step being automated.

Practical Uses of Pass the Hash

For penetration testers, pass the hash can be scarily efficient.  For example, some companies follow the practice of defining a local Windows administrative account with the same very strong password on all desktops, to simplify maintenance. This is common when imaging desktops with the same disk image without bothering to randomize the local administrator password. What this means is that when only one machine  is compromised, Metasploit collects the password hashes, and penetration testers instantly gain administrative access to the entire corporate network thanks to this shared administrative account, without having to brute force or crack the password.

 

As another example, pass the hash works just as well in Windows domain environments.  When a domain administrator logs into a machine member of the domain, his password hashes are sometimes stored in the memory of the lsass.exe process. Again, if this machine is compromised, the hashes can be collected by various tools, giving the attacker instant administrative access to the entire domain.

Demonstration: Pass the hash from Metasploit Express/Pro

In Metasploit Express or Pro, after a Windows host has been scanned and exploited, and after collecting the system data using one of the exploit sessions, the host page shows the host status as looted, and the Windows password hashes are listed under the credentials tab. So far, nothing new, see:

  host.png

We can see the administrator password LM and NTLM hashes. For the reader's information, they correspond to the password test.3!@-pass but we do not need to know this. At this point, click the Nexpose button to launch a scan. This brings you to the Nexpose scan task page:

  nexpose.png

Click the new checkbox "Pass the LM/NTLM hash credentials" to enable the feature. The text field under it is automatically populated with all hashes collected by Metasploit (the end user is free to edit/add/remove any hash).

 

Finally, click "Launch Nexpose" at the bottom of the page and Nexpose will perform a credentialed scan. That's it!

Demonstration: Pass the hash from Nexpose

In Nexpose, when editing a site, click the Credentials tab, and you will see the new login type option called "Microsoft Windows/Samba LM/NTLM Hash (SMB/CIFS)":

  edit-site.png

Assuming you obtained the LM/NTLM hashes some way or another, fill out the user name and hash fields manually. Use the hashes of an administrative account for the best scan results. The hash field can either be the NTLM hash alone (eg. 3dd16f7b1c59d2b2996110c32b67f2a7), or the LM and NTLM hashes separated by a colon (eg. 79d857ddcd8e6757178853697dbbe003:3dd16f7b1c59d2b2996110c32b67f2a7). The reason the LM hash can be optional is because most SMB/CIFS services, such as Windows and Samba, disregard the LM response at the protocol level when the NTLM response is valid.

 

I recommend to test the hashes before saving them to make sure they were not mistyped: fill out the "Asset to test against" field with a host name or IP address and click "Test credentials". If the test passes, hit Save to save the credentials, hit Save again to save the site, and the next scan launched for this site will be a credentialed scan.

Demonstration: Pass the hash from Metasploit Framework

Finally, for users of Metasploit Framework, the nexpose plugin, which interfaces with a remote Nexpose console, exposes the pass the hash feature as well. Like other Metasploit plugins, a database needs to be configured first; the example below uses postgres@localhost. Here is an example session of how the plugin can be used to pass either the LM and NTLM hashes, or only the NTLM one:

db_connect postgres@localhost
load nexpose
nexpose_connect nxadmin:password@console.lan ok
nexpose_scan -c cifshash:administrator:79d857ddcd8e6757178853697dbbe003:3dd16f7b1c59d2b2996110c32b67f2a7 target.lan
(or NTLM only:)
nexpose_scan -c cifshash:administrator:3dd16f7b1c59d2b2996110c32b67f2a7 target.lan

Replace administrator:79d8...:3dd1... with the username, LM and NTLM hashes. Replace console.lan with the Nexpose console host name or address. And replace target.lan with the scan target name or address.

Bottom Line

Pass the hash is an extremely useful technique, especially because there is no way to defend against it once the hashes are stolen (it is arguably a design flaw of the SMB/CIFS protocol authentication mechanism). Its integration into Rapid7's products gives a lot of power to penetration testers.

iStock_000011431662XSmall.jpgMetasploit offers some great ways to automate its functionality through a programming interface. Metasploit users have built custom tools and processes based on this functionality, saving them time to conduct repetitive tasks, or enabling them to schedule automated tasks. Our most advanced customers have even intgrated Metasploit Pro into their enterprise security infrastructure to automatically verify the exploitability of vulnerabilities to make their vulnerability management program more efficient.

 

The Metasploit RPC API is accessed using the HTTP protocol over SSL. Metasploit Framework offers a basic set of commands, while the more advanced and higher-level API calls are reserved for Metasploit Pro. To get started with the Ruby API, you need to install the msfrpc-client GEM from www.rubygems.org. Authentication to the API happens either with a user name and password, which generates a temporary token, or an API key, in other words a permanent token.

 

The basic set of API calls available in both Metasploit Framework and Metasploit Pro includes:

 

  • Authentication: accessing the API through authentication tokens
  • Core: managing global variables in the framework object, saving the current configuration to disk, manipuliating the module load paths, reloading all modules, managing background threads, and retrieving the server version
  • Console: writing commands as if you were sitting in front of the console and reading its output
  • Jobs: listing and killing jobs
  • Modules: listing modules, enumerating options, identifying compatible payloads, and running them
  • Plugins: loading, unloading, and listing loaded plugins
  • Sessions: listing, interacting with, and terminating open sessions to compromised systems

 

The more advanced, higher-level API calls are exclusive to Metasploit Pro:

 

  • General: accessing product version information, active projects, and configured user accounts
  • License: registering and activating Metasploit Pro
  • Updates: checking for, downloading, and applying the latest Metasploit Pro updates
  • Task: enumerating, stopping and retrieving logs for background jobs initiated by the user through the web interface
  • Feature: accessing many of the top-level features in the Metasploit Pro user interface, such as scanning, importing, bruteforcing, exploiting, web, and reporting
  • Import: importing reports from third-party tools
  • Loot: collecting evidence from compromised machines
  • Module: searching the modules database

 

The Metasploit Web UI internally uses the advanced, higher-level Metasploit Pro API, so the API has been tested rigorously by our own engineers, our customers, and more than one million people who download Metasploit each year. We host the full documentation of the Metasploit Remote API here in the community - check it out now!

NAT-PMP'ing is now easy

 

This week, we have three new modules and an accompanying Rex protocol parser for the NAT Port-Mapping Protocol (NAT-PMP), the ad-hoc router management protocol favored by Apple. Over the weekend, Rapid7 Lead Security Engineer and confessed protocol nerd Jon Hart forgot the password to a little-used Airport base station, so rather than merely resetting the device, he instead busted out a trio of Metasploit modules to make this kind of task easier in an unauthenticated way.

 

  • natpmp_map - the port-mapper for NAT-PMP. This instructs the router to forward external traffic to the named port to the supplied internal host and port.
  • natpmp_portscan - uses a neat technique to determine what external ports are mapped on a given NAT device
  • natpmp_external_address - discovers the external IP address of the NAT device.

 

Now, this won't get you magical internal network access over a NAT gateway -- these modules are designed to be run from the internal side of the network. That said, the use-case in a penetration test is pretty clear. All too often, pen testers will come across an office environment that's using consumer-grade gear for some specific business purpose (or is simply rogue). By leveraging these modules, the attacker can set up his own NAT-tunneled port maps without needing to know any kind of router authentication, which can expose devices to the greater network for further abuse. Pretty cool.

 

64-bit LoadLibrary Payload

 

Community contributors scriptjunkie and Stephen Fewer put together a 64-bit version of the LoadLibrary Payload, because (quoting the commit message) "it should exist." If you're not familiar with the LoadLibrary payload, there's a use case documented over on Room362, where Mubix describes the technique in some detail (his examples use the existing 32-bit LoadLibrary payload, but the idea is the same). Thanks guys!

 

New Modules and Scripts

 

Finally, here's the run down of this week's haul of new modules and scripts.

 

  • igss9_dataserver is a DoS attack against 7-Technologies IGSS 9 (CVE-2011-4050), submitted by jfa.
  • vmauthd_login is a VMWare authentication bruteforcer from TheLightCosine.
  • gitorious_graph is a command injection exploit against Gitorious (SA47663), submitted by joernchen
  • hp_easy_printer_care_xmlcachemgr a somewhat complicated exploit for HP's Easy Printer Care ActiveX control (CVE-2011-4786) submitted by Juan Vazquez
  • hp_nnm_ovbuildpath_textfile is a memory corruption exploit in HP OpenView Network Node Manager (CVE-2011-3167), added by Juan and sinn3r
  • download_exec is a Railgun-based post module for downloading arbitrary files using the standard URL moniker service (urlmon) from Internet Explorer, courtesy of RageLtMan.

 

In scripts, community contributor m-1-k-3 submitted auto_pass_the_hash.rc, which is a simple rc-script implementation of the tried-and-true Pass the Hash SMB authentication attack, and wmap_autotest.rc, an automated means to step through collected web pages using Efrain Torres' wmap plugin for all the heavy lifting.

 

Availability

 

For those of you who rely on the msfupdate command to track Framework development, you already have these sitting in your local checkout. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new Framework hotness today when you check for updates through the Software Updates menu under Administration.

 

For more details on what's changed and what's current, please see Jonathan Cran's most excellent release notes.

Open and frank debate is one of the great things about the security community and the recent press about our H.323 research has set off a firestorm in some circles. In one extensively written post, David Maldow of Human Productivity Lab downplays the risk to video conferencing systems and makes a few claims about the security of these systems that were hard to ignore. David's statements in "quotes" and our responses in bold:

 


 

Introduction

 

 

"I've read good things about Rapid7 and always support efforts for security, but in fairness it should be noted that projecting an atmosphere of security risk in videoconferencing is clearly in their interest."

 

 

Unfortunately, everyone has a bias - if we did not care about proactive security testing, this research would have never occurred. Rapid7 takes an empirical approach to security research, focusing on understanding the true situation regarding how systems are actually deployed in real life. For this specific research, we spent a lot of time on quantifying the data from the research and speaking with industry experts in the video conferencing space (which we do not consider ourselves to be).  Rapid7 focuses on providing products, tools, and information about security risks that allow our customers and open source users to make informed decisions. Calling attention to an issue that has historically been ignored and providing the tools to test it is what we do.

 

 

We often find situations where large numbers of systems are deployed in surprisingly insecure ways, where everyone including us would have expected that "no one would do it this way". This mismatch between expectations and reality is a major source of real world security problems. For example, I never would have expected that a very widely deployed embedded operating system like VxWorks would ship with the debugger attached and open to connections by default – and any industry expert you'd ask would similarly say "no sane person would deploy it that way".  Similarly, much of David's comments are along the lines of "no one would do it that way". The facts, unfortunately, again prove otherwise.

 

 

 

 

Videoconferencing Hackers

 

 

"The article's title claims that the boardroom will be opened up to "Hackers." However, from the rest of the article it was clear that there was no real hacking involved. Videoconferencing signals use AES encryption. This isn't a new or rare development. AES has been standard on almost all major endpoints (at all price ranges) for a long time. The use of AES means that even if videoconferencing data signals are intercepted as they traverse the internet, the encryption would have to be hacked before anyone could watch the video or listen to the audio. No one is suggesting that this type of hacking is occurring. Rather than hacking into the boardrooms, Rapid7 was simply calling them. These systems apparently answered some of their calls, as they were designed to do."

 

 

Encryption rarely has anything to do with security and hacking doesn't need to be high-tech, only effective, to be worth defending against. The issue with auto-answer is one piece of a larger problem with video conferencing deployments, but it was the issue that the NYT article focused on, due to the ease of exploitation and the visible result. In our January 24th webcast, the scope was expanded to discuss pivoting through administrative interfaces, exploiting software vulnerabilities in LifeSize equipment, and demonstrating the lack of security controls in many video conferencing systems. Given Polycom's stance of enabling auto-answer by default and the supporting data from our scans, even the auto-answer issue was worth addressing on its own.

 

 

"Rapid7 did create a program to scan the internet for videoconferencing systems. From this they were able to get a list of IP addresses, which are like phone numbers for VC systems. However, they had no idea where these systems were located and who they belonged to. It was a phone book with no names, only numbers. Not a great tool for an effective targeted hacking attack"

 

 

The details of the tool were not abundantly clear in the NYT article (the length wouldn't allow for it), but the scanning module we used was developed in-house and actually initiates a H.323 call to each scanned system. This module is open source and you can find it online at GitHub. The protocol handshake returns a number of useful bits of data, including the Vendor ID, Version ID, Product ID, and DisplayName.


 

The DisplayName usually describes either the location or purpose of a specific endpoint. Approximately half of the results from the scan included the DisplayName element. I have changed some of the names to prevent obvious identification, but you can see that between the product information, the DisplayName, and the attributes of the IP address (DNS and Whois), identifying the owner of a particular endpoint is trivial.


 

         IP: AAA.BBB.CCC.DDD:1720 Protocol: 5

   VendorID: 0xb500a11a VersionID: 4.5.6.2 ProductID: LifeSize Express

DisplayName: 36th Floor Board Room

        DNS: AAAAAA.dsl.chcgil.sbcglobal.net

      Whois: <CENSORED> ADVISORS-013223144143 ( IP range )


 

In this example, we identified the physical location, company name, ISP, and enough information about the product itself to know that the LifeSize exploit module included with the Metasploit products could be used to gain remote access to the system (Linux) shell.


 

If you look at just the DisplayNames, these are often more than enough to precisely identify the organization and location. These names include things like "Something Media", "BigCorp Moscow Polycom 2", and in some cases "<County> Courthouse". In the interest of not subjecting any specific entity to embarrassment or directed attacks, we have avoided publishing any detailed lists of results.

 

 

"With this list in hand, they started random dialing and peeked around some empty rooms. It should be noted that this list only included systems that were not deployed behind firewalls. "

 

 

To determine whether these systems were behind a firewall, we used the Nmap scanner to look for systems that had a large number of filtered ports. In most cases, these devices were deployed outside of the firewall, with the administrative interfaces exposed to the world. This may not be the recommended mode, but it is certainly prevalent in the wild. Even in cases where firewalls were in place, the H.323/1720 listener was still forwarded through and allowing for incoming calls. This is one of the problems with H.323 as a protocol - it is difficult to use through NAT, requires a large number of ports, and any PtP call requires the recipient to expose their system to the internet at large, using source IP ACLs or other product-specific tools to limit access.


 

By and large many organizations are ignoring the hassle and dumping the system online outside of the firewall or through a 1-to-1 NAT configuration. An industry expert pointed out one reason for so many endpoints configured to auto-answer from the internet - many MCUs are used in an outbound dial mode to start meetings and auto-answer is the most convenient way for the participates to join the call.

 

 

"Any environment with real security requirements will have their VC systems behind firewalls."

 

 

The most surprising thing about the research was how well-heeled and quite sensitive organizations were doing little to nothing to restrict access to their VC equipment. Anyone who spends the time locking down their VC systems can do an adequate job of protecting from the external attacks - it’s simply that many do not and that the overall awareness is not there today.

 

 

 

"Real hackers are scary. If someone does find a way to isolate VC traffic over the internet and hack encrypted VC signals from specific locations, I will be the first to raise the alarm. But I simply don't see a massive threat in the fact that it is possible to get lucky and randomly dial into an anonymous empty meeting room."

 

 

Real hackers are opportunists in every sense of the word. Encryption is not equivalent to authentication and often a silly software bug (such as the command execution flaw in the LifeSize web service) is all that’s needed to tear down any other defenses. The H.323 protocol provides enough information that an attacker can quickly map a network range associated with their target, identify any VC equipment, and leverage both weak default settings (auto-answer), default passwords, and software vulnerabilities to gain access to the audio/video stream, if not the internal network itself.

 

 

 

 

Flaws in Videoconferencing Systems

 

 

"In the next section I will explain why it is not easy to stealthily dial into a meeting room while in use."

 

 

Without debating each of David's points, we did prove that most VC equipment provided little or no warning when an attacker dialed into the system. In most cases, the television set is off unless a call is expected. If the television is off, there is little indication that a call is in progress. The reason for this is two-fold;

 

 

First - the base unit, not the camera, is usually what has an indicator that turns on when a call is in progress. The base units are often stashed behind a cabinet, near the floor, or generally out of sight.

 

 

Second - newer cameras (specifically, the Polycom HDX series) are extremely quiet while being panned or zoomed and the only indication they provide is the direction they are facing. We conducted a "blind" test where the conference room VC unit was accessed during a Rapid7 general staff meeting. Twenty minutes into the meeting, nobody had noticed the camera swinging from the rest position to pointing at a participant's laptop screen, zoomed in to capture his email and keystrokes.

 

 

"I think it is acceptable for low security rooms to have glass walls and video systems set to auto answer."

 

 

The expected security of a room depends on the company and the specific meeting being conducted within it. David mentioned that in some conference rooms, the walls were glass and there really was no visual protection of documents left on the table. However, it is very common that sensitive information (term sheets, passwords, personnel documents, etc.) are often being left out in the open.

 

 

A much more significant risk is the audio pickup - in many cases, the security of the VC system was literally a post-it note or other visual obstruction in front of the camera lens. This has no effect on the audio pickup. Testing similar equipment in our lab, we found that conversations could be clearly heard down the hall from where the VC unit was installed. David does make a point about a common configuration of  incoming calls starting off muted, but this is not always the case.

 

 

"If a meeting room requires security, you are as unlikely to find an unprotected videoconferencing system as you are to find an unprotected desktop computer."

 

 

Folks who spend a lot of time conducting security assessments can testify that unprotected desktops are not unheard of on external subnets. It’s a poor security policy, just like leaving a VC unit exposed to the internet, but it still happens and even large organizations that should know better make this mistake.  The issue with VC systems may be more dangerous as these systems are directly on the internet and by their nature in very sensitive locations.

 

 

"IT admins for sensitive environments are generally knowledgeable about firewalls and internet security. They are not likely to allow any IP devices to exist outside the firewall under their watch"

 

 

This is a really interesting point. IT admins often have little knowledge or experience with video conferencing unit security. An informal survey across enterprise customers using VC systems indicated that many of these were set to auto-answer, IT was not managing security patches, and often they were left exposed to the internet and sometimes with default passwords. All of these responses reinforced the results of the scan we performed.

 

 

"Rapid7 suggests a significant number of systems in otherwise secure environments are being deployed outside the firewall. This was disputed in the article by Ira M. Weinstein, senior analyst at Wainhouse Research, who stated that, "The companies that really have to worry about breaches -- the Department of Defense, banks -- put their systems behind the firewall." Mr. Weinstein's words carry some weight, considering his years covering this industry."

 

 

This was a point of debate. With all due respect to Mr. Weinstein's experience, he did not scan the internet and actually validate his assumptions. Even systems with some form of firewall in place were not provided much protection, since the devices were still configured to automatically accept incoming calls.

 

 

"Unlike a small company with one system in their one meeting room, Goldman Sachs likely is using a managed service provider to ensure that all of their systems are properly, and securely, provisioned."

 

 

We do not want to mention specific examples, but "Goldman Sachs" stood out because even though we didn't identify any of their systems in the internet survey, an organization they likely work with had access to a private link to their system. Since this organization exposed the administrative interface of their VC system and the system did not require any form of authentication to access it, the device could be used to bridge a call between an internet-facing attacker and a system on a private link such as the one labeled "Goldman Sachs". We have no proof that this system actually belonged to Goldman Sachs or that the call would have worked, but we did simulate the attack using like equipment in the lab.

 

 

Managed service providers are another area where this research took an unexpected turn. These providers typically use leased lines, VPNs, or other forms of private connectivity to bridge video services between sites. We found that many of the internet-exposed VC units also had access to the managed service provider network and internal resources. This was verified by looking at the unprotected web and telnet interfaces of units found with this configuration (again, we didn't guess passwords or attempt to bypass any existing security). Depending on how these service provider networks are configured, a single exposed customer could provide a foothold into the managed services network.

 

 

The same type of proxy attack works between IP and ISDN endpoints. An attacker accessing the administrative interface of an endpoint through the IP address can force the system to make an outbound call to an ISDN line. If the target of this proxy attack allows incoming calls from this device (often the case for systems frequently dialed in the system address book), the call will be accepted and the attacker now has snapshot access, if not much more, to the ISDN-connected target.

 

 

"The NYT seems to be simply unaware of the fact that the videoconferencing industry has had skin in the security game since its inception."

 

 

This comment refers to a statement about the lack of security built-in to video conferencing systems. I strongly disagree that security was a foremost concern for devices made between 3 and 7 years ago. The web and telnet service of the Polycom ViewStation systems from 2005 require no authentication to access. The vendors may have supported encryption since the beginning of IP video conferencing, but encryption only matters if you are protecting the data in transit, not protecting the endpoint itself from a directed attack.

 

 

Video conferencing equipment is actually pretty far behind the curve when it comes to network devices and resistance to attack. Even some consumer printers ship with a more secure administrative interface than what many vendors in the video-conferencing space provide today.

 

 

"In addition, the systems are often installed by experts with security as a priority. In a blog on this subject, IMCCA Director David Danto describes such an installation."

 

 

This varies widely by the organization, their awareness of security issues, and their choice of installer. As a generality, this doesn't appear to be true based on the results of our research. We do not disagree that a trained, security-conscious video conferencing expert can deliver a secure solution.

 

 

 

Semantics Aside - Is There A Security Risk?

 

 

"How easy is it to use a boardroom videoconferencing system to spy on a meeting? The answer is that it may be possible, but it wouldn't be very easy...Having spent countless hours testing videoconferencing systems and videonetwork infrastructure, with up to 18 videoconferencing systems set to auto answer at one time, I can assure you that it is not a silent process."

 

 

During the course of our in-house testing, using Polycom's ViewStation and HDX units, as well as an old D-Link, the results were mixed. However, we found that many of the high-end systems did not provide any easily visible notification that a call had been answered. The D-Link, however, got so annoying that we actually disassembled it and yanked the speaker out to continue the testing process.

 

 

"In addition, videoconferencing systems tend to be connected to rather large monitors. When called, the monitors will often "wake up" and display the system's logo if there is no incoming video."

 

 

Many organizations simply turn off the monitors/televisions when the device is not in use. The swing, as mentioned in a previous paragraph, is quiet with newer equipment and fairly hard to notice, especially in a busy meeting. Keep in mind that an attacker can take use a previously-acquired screenshot or a blank screen as their video source for what is displayed on the monitor.

 

 

"Videoconferencing systems weren't made with stealthy activation as a goal. They are communications devices, and they were very specifically designed to do a good job of alerting users to incoming calls."

 

 

Systems that expose the administrative interface provided two options for bypassing an incoming call alert. The first was simply to turn off the ringer to prevent any audible result from the unit itself. The second involved initiating an outbound call from the unit back to the attacker, which in some cases avoided the standard notifications. Either way, if the system is configured to make a lot of noise and the administrative interface is protected, an incoming call is going to be noticeable most of the time.

 

 

"(12 IFs truncated for brevity)... With that many "ifs" I think this may not be the top security concern for today's videoconferencing users. At this point VC spying is starting to look like Mission Impossible."

 

 

Regardless, it works, and if the VC monitor is not turned on (common, as stated above), there is usually little indicating that a call is active. We did try to replicate scenarios seen "in the wild" within our lab before making any claim and determine what the configuration must have been for the result to match. Keep in mind that most of the high-end room cameras can be controlled remotely and often you can point the camera back at the monitor to determine if it is indeed on.

 

 

"But, if you are leaving sensitive documents lying around meeting rooms, then videoconferencing is the least of your security concerns."


This generalizes physical security to a degree that is not realistic. For firms that are fairly small and manage sensitive or valuable information, it is fairly common for documents to be left in plain view within the office. Examples include law firms, small investment banking shops, and medical offices. On the other extreme, where large organizations have extremely rigid physical security, documents left sitting around a secured area may be considered safe. It would be unfair to classify either practice as insecure if it wasn't for the video conferencing unit being within zoom distance.

 

 

 

Securing Your Video Environment


 

David goes on to mention some basic security tips for video conferencing equipment. To this list, we would like to add keeping up to date on vendor patches, especially those that are security related, and requiring passcodes for access to both meeting rooms and endpoints. Polycom has a hardening guide that goes into more detail.

 

 

There is one conclusion that we still adamantly disagree with:

 

 

"Auto Answer - I have no problem with leaving auto answer enabled. However, most systems have an option to answer with audio muted. This is how I set up my systems. If I do get an unexpected call in the middle of a private conversation, the caller will not hear anything. If the NYT article made your co-workers nervous you can just turn off auto answer until everyone relaxes, but auto answer with audio muted is a perfectly acceptable secure setting."

 

 

David suggests that even with all of the known risks - that auto-answer should continue to be the standard. Fortunately, nearly every mainstream vendor with the exception of Polycom sees this differently. We still strongly recommended disabling auto-answer - the extra two seconds it takes to press the answer button on the remote provides the second-most important security measure available (the first being adequate protection of the administrative interface, which can be used to turn auto-answer back on).

 

 


Conclusion

 

 

"Even if a system is deployed outside of a firewall, it still isn't at serious risk of being hacked. It is at risk of accepting calls (which is what it was designed to do). A few common sense precautions can eliminate the risk of your system being in a call without you knowing about it."

 

 

This statement is absolutely untrue and may put users who follow this advice at risk. The H.323 video stream is only one service exposed by video conferencing systems, other services, such as telnet, web, ftp, snmp, and so on all expose the device to intrusion, using both weak credentials or exploits written specifically for that device. There is no justifiable reason to place a video conferencing system outside of firewall if at all possible and auto-answer should continue to be disabled, to prevent unexpected access to video or audio information.

 

 

"If the technology is secure enough for the Pentagon, it is secure enough for your boardroom."

 

 

The Pentagon follows vendor-specific hardening procedures to make systems far more secure, and almost undoubtedly does not deploy outside the firewall. Many videoconferencing systems vendors also sell Federal-specific versions with both hardware and software modifications that enhance security. This statement is about the same as saying "the pentagon uses computers, so if they're safe enough for them they're safe enough for you".

 

 

Software vulnerabilities are rampant (Metasploit alone exploits close to 750 of them, while Nexpose has close to 60,000 checks for known defects). Hardware appliances and network devices are even more problematic, as they tend to be difficult to update and run on proprietary software interfaces, often riddled with low-hanging security flaws. Who uses a piece of equipment is never a good test for how secure it is. Some of the most insecure equipment is still FIPS-140 certified.

 

 

 

 

Closing


 

We would like to thank David for summarizing his concerns with how the NYT article position videoconferencing security. At the end of the day, we stick by our position that videoconferencing systems are often deployed in an insecure manner and that the risk of unauthorized access is not something that many IT administrators or company executives are aware of today. We view the issue from the lens of vulnerability management, which is quite a different from that of an industry expert. Please leave a comment or open a discussion if you have any questions or would like further elaboration on a particular area.

Update: David Maldow of Human Productivity Lab wrote a response to the NYT article that presented an industry perspective on our findings. Mythical Videoconferencing Hackers and why we stand behind our claims. Additionally, the archive of Tuesday's webcast on the same topic (with live demos) is now available. Thank you to everyone who provided feedback!

 

Introduction

 

Today's issue of the New York Times contains an article describing the results of research I conducted over the last three months. In short, a large portion of video conferencing equipment is connected to the Internet without a firewall and is configured to automatically answer incoming video calls. This allows a remote intruder to monitor both audio and video information, often with little or no indication to the target. The interesting part of this research is who it affects; these units can cost anywhere from a few hundred dollars (used) to tens of thousands of dollars for high-end room systems. It is rare to find a high-end video conferencing system in an unimportant location. Examples identified by this research include corporate boardrooms, inmate-lawyer consultation areas, venture capital firms, and research facilities.

 

This research covered about 3% of the addressable Internet and focused on equipment that spoke the H.323 protocol. Of the 250,000 systems identified with this service, just under 5,000 were configured to automatically receive incoming calls. There are an estimated 150,000 systems on the Internet as a whole affected by this issue. This does not count the hundreds of thousands of video conferencing systems exposed on the internal networks of large corporations.

 

 

Scan.png

 

Quality

 

Even cheap video conferencing systems provide an incredible level of visual acuity and audio reception. In the Rapid7 lab, we were able to easily read a six-digit password from a sticky note over 20 feet away from the camera. In an otherwise quiet environment, it was possible to clearly hear conversations down the hallway from the video conferencing systems. In most cases, the remote user has the ability to drive the camera - controlling pan, tilt, and zoom - providing visibility into areas far away from where the system is actually installed. A separate test confirmed the ability to monitor a user's keyboard and accurately capture their password, simply by aiming the camera and using a high level zoom. Another test demonstrated the ability to read a user's email on their laptop screen. If the system is connected to a television set that has not been powered on, the only indicator that a call is active will be the movement of the camera itself or a small light on the base of the system. Many of the high-end models do not include a visual indicator of a call in progress on the camera at all.

 

Hand.png

 

 

Auto Answer

 

Video conferencing vendors have taken steps to provide security features, however the leading vendor, Polycom, still ships most of their equipment with auto-answer configured by default. Polycom provides a hardening guide, but default settings typically become the most common configuration, due to the lack of time, patience, or oversight required to successfully secure these devices. Other vendors, such as Sony, Tandberg (Cisco), Lifesize (Logitech), and Codian appear to require the user to specifically enabled auto-answer mode. Devices from each of these vendors were found during the course of the research, but they made up a much smaller portion of the whole compared to Polycom. Polycom documentation specifically calls out the security risks in the auto-answer option, but one would have to read the documentation, notice this, and then specifically configure the device to avoid this issue.

 

Setting.png

 

 

Firewalls

 

One of the most worrying parts of the research is related to firewalls. Many simple firewalls fail to handle the H.323 protocol in a way that works with common video equipment. There are multiple ways of solving this, including the use of H.323 gatekeepers, and firewall-friendly options within certain devices, but the easiest solution is to provide the device with a public address and call it done. The risk here is that many of these offer to little no security through their administrative interfaces, whether this is telnet, web, or a vendor-specific service.

 

Exploits

 

All Metasploit editions contain an exploit module for a vulnerability in the LifeSize conferencing systems, published last year, which can be used to directly compromise unpatched LifeSize equipment through an exposed web service. Comparing the affected version numbers with the results of the research indicate that the majority of the LifeSize equipment identified on the Internet would be vulnerable to this exploit. Just like with other "network devices", IT departments typically ignore maintenance on video conferencing units unless there is a change to functionality. The picture below shows some of the LifeSize versions found in the wild, many of which are vulnerable to the exploit module included in Metasploit.

 

LifeSize.png

 

Web Interfaces

 

The web interfaces on video conferencing devices can often be used to initiate outbound calls to other parties. In some cases, the remote party may have adequately secured their system, but added an allowance for a particular device or organization. The ability to initiate calls on these devices can bypass the security of a third-party system in this manner. One example that was identified during the research process involved a law firm that had an address book entry for the board room of a well-known investment banking organization. A used device purchased from eBay arrived with an address book containing dozens of private sites, many of which were configured to auto-answer incoming calls from the Internet at large.

 

Polycom_Web.png

 

H.323 Discovery

 

All shipping Metasploit editions contain a scanner module for quickly identifying H.323-enabled systems that accept incoming calls. This module is included in the default discovery mode of Metasploit Pro (free trial) and can be used to quickly inventory a large network to identify affected systems. This process also works for the free Metasploit Community Edition. The process for using Metasploit Pro to discover exposed H.323 devices is outlined below.

 

  1. Login to the web interface on https://metasploit:3790/
  2. Create a new Project
  3. Choose the Scan option
  4. Expand "Advanced Options" and enter "1720" into the Custom TCP Ports parameter
  5. Uncheck UDP and SNMP discovery options to increase scanning speed
  6. Launch the Scan task
  7. Once complete, browse to Analysis -> Services
  8. Enter "h323" into the Search box on the upper right

 

If you have already used the Scan component with the default settings, after applying any update in the last month, you should already have results available. Any device that accepted an incoming call should be identified by a minimum of protocol version and Vendor ID. Most devices will return the Product ID and DisplayName (Caller ID).

 

mspro.png

 

H.323 Clients

 

To validate an identified service, connect with a H.323-capable client such as NetMeeting (Windows XP), Ekiga (cross-platform, but buggy), Mirial Softphone (commercial), or ClearSea In the Cloud (only able to reach internet-exposed devices). For internal systems, I still rely on NetMeeting in a XP virtual machine as the most reliable H.323 client, however, this lacks the Pan-Tilt-Zoom (PTZ) and keypad controls of a more advanced client like Mirial or ClearSea In the Cloud.

 

ISDN

 

IP-based H.323 really just scratches the surface of video conferencing security issues. ISDN is still used to connect many of these devices and this is much more difficult to survey. A used ViewStation recently purchased from eBay contained an address book of two dozen sites - all listed via their ISDN dial-in and not an IP address. Many systems, including the Polycom demo sites, offer both IP and ISDN-based services. My gut feel is that for every exposed device found on the public internet, there are twenty more attached to an obscure ISDN number that the IT department may have forgotten about. This may be a job for WarVOX, but until more research into ISDN analog dialing is done, it is hard to tell whether this is a workable solution for detecting exposed ISDN-attached video conferencing systems (normal PSTN lines receive a busy signal or failed call from an ISDN VC endpoint).

 

Conclusion

 

Video conferencing systems are one of the most dangerous but least-known exposures to organizations conducting business of a sensitive nature. The popularity of video conferencing systems among the venture capital and finance industries leads to a small pool of incredibly high-value targets for any attacker intent on industrial espionage or obtaining an unfair business advantage. Although many vendors provide some security measures, these tend to be ignored in the real world, by both IT staff and security auditors. The additional awareness raised by the NYT article, along with the introduction of scanning tools inside of Metasploit, will hopefully drive vendors and end-users to take video conferencing security seriously.

 

If you are interested in viewing a live demo of this technique, please view the on-demand webcast "Board Room Spy Cams: How Attackers Take Over Your Video Conferencing Systems And How To Stop Them"

owa.pngThis blog post describes a simple phishing attack covered in today's webcast. The goal is to create a fake front-end to an organization's Outlook Web Access portal and convince users to login through this portal. In the course of an authorized security assessment this type of attack provides an initial foot in the door to the target organization and takes few resources to setup.

 

This technique relies on the following steps:

 

  • Clone the target's existing OWA site to match graphics and versions

 

  • Register a look-alike domain (mail.example.com -> mailexample.com)
    • Gandi.net even provides free SSL certificates as part of COM registration
    • IDN-style names can make this even harder to identify

 

 

  • Rewrite the OWA HTML to change the links/images
    • Point the form POST to the real OWA portal

 

  • Modify flogon.js to log prior to re-posting to the real OWA

 

The result is a site that looks like the original and acts like the original. A bad password takes the user to the real site with the expected error and a correct password takes them to the real site and logs them in. Microsoft could mitigate this by adding CSRF tokens to the form authentication template in OWA. This basic technique was used with both Exchange 2007 and Exchange 2010 OWA installations.

 

To convince users to access the mis-named site, I typically craft an email with a subject like "Welcome to Outlook Web Access" - pasting in a typical "enrollment" email, linking to the fake portal (with the displayed link pointing to the real portal).Telling the user that they have 24 hours to access the portal to keep their account active may help speed things along as well.

 

If you conduct this type of phishing attack for another organization, the friendly thing to do is transfer the domain to their IT staff after the conclusion of the test. At the least, it takes a potential phishing domain off a list that a real attacker could draw from.

 

Happy (legal) phishing,

 

-HD

Been a busy week here at Metasploit, so let's get to it.

 

Forensics-Centric Updates 

 

New this week is Brandon Perry's offline Windows registry enhancements. Featuring a pile of extensions to Rex (Metasploit's general purpose parsing library) and the tools/reg.rb utility, this update builds on TheLightCosine's ShadowCopy library and makes life a lot easier for the forensics investigator looking to parse through Windows registry hives. Brandon goes into the technical details over here, so I encourage you to read up on it.

 

Speaking of TheLightCosine, he's also knocked out three database schema dumpers. Given remote access to a database, penetration testers can now pull the schemas from MySQL, PostgreSQL, and Microsoft SQL databases in a uniform way. This is hugely useful for both automated evidence gathering and for getting familiar with the intimate details of a freshly-compromised database.

 

The final addition in this week's forensics-flavored update is Stephen Haywood's simple but powerful enum_artifacts module. With this post-exploit module, investigators can build up a custom set of files and registry keys to search for on a target computer. Among other uses, this can be a handy trick for nailing down if a machine has already been compromised by known malware -- users can searching for specific files matching an MD5sum, or examine the Windows registry for tell-tale registry entries indicating infection.

 

Revenge of TFTP: SCADA Attacks

 

This week we have new modules targeting General Electric's D20 PLCs, a SCADA component that's responsible for "mud-on-the-boots" physical assets. We've been working pretty closely with the guys over at Digital Bond to develop reliable exploits that demonstrate their findings over the last several weeks, and truth be told, their research is the reason why Metasploit released a more complete TFTP client library. Now that these vulnerabilities are public knowledge, people responsible for administering and validating their SCADA infrastructure can use these modules to audit:

 

  • d20pass : This module leverages a pretty major information disclosure for the device -- turns out, anyone who connects to the TFTP server on the D20 can snag the complete configuration for the device, which includes plaintext usernames and passwords. This module does just that -- downloads the configuration file, parses out the credentials, and stores them in Metasploit's database for reuse.
  • d20tftpdb : This module demonstrates an asynchronous backdoor functionality in the D20 via the TFTP interface. Again, in an unauthenticated way, anyone can connect to the TFTP server, and issue command by writing to a special location on the filesystem. Also again, this is a pretty big deal. Note that this module is currently still in the unstable Metasploit branch pending a little more QA work on getting this (pretty unique) command and channel all nice and automated. As is, though, it works just fine for demonstration purposes, and if you have some of these PLCs in your environment, you are encouraged to investigate this more (and send patches!).

 

Bruteforce and SSH

 

Last update, @escan_sachin and @aim4r noticed on Twitter that we snuck in "updates to #metasploit auxiliary scanner modules as well." Well, that's true, but the updates in question weren't quite ready to be discussed here in blog-land. Unlike the TFTP modules, these were developed pretty much entirely in the public GitHub space, so it's kind of hard to keep that sort of thing secret. That said, the work is done now, and this new mode for SSH scanning in Metasploit is ready to be discussed here. Sorry for the mysteriousness. (:

 

The ssh_identify_pubkeys module allows users to take a list of SSH public keys and scan around to find out who's authorized to use them for authentication  -- without requiring the corresponding private key. This information disclosure is a useful, but little-known, feature of the SSH protocol, and can be used to audit who has access to what without compromising the integrity of an organization's private keys. For example, this is an ideal functional implementation for an IT administrator who wants to ensure that developer keys don't accidentally (or otherwise) show up on production systems. HD Moore will be talking about this and lots of other authentication scanning and bruteforce techniques in today's webcast on the topic, so sign up here to learn more.

 

Other New Modules and Scripts

 

Metasploit community contributor m-1-k-3 committed three new example resource scripts: portscan.rc and port_cleaner.rc, which help to automate up the Metasploit-Nmap integration and tidies up the database by dropping uninteresting closed port records. He also provides his autocrawler.rb script, which targets all hosts in the current workspace that have a running HTTP service and records their linked pages for later analysis.

 

We also have new exploits for:

 

  • CVE-2011-0065, submitted by argp, which targets Mozilla Firefox on OSX
  • CVE-2005-1790, submitted by Sam Sharps, which targets Internet Explorer's MS05-054 bug
  • ZDI-12-012, submitted by sinn3r, which targets a McAfee Software-as-a-Service ActiveX control
  • An uncategorized vulnerability in BS.Player 2.57, submitted by Chris Gabriel

 

Availability

 

For those of you who rely on the msfupdate command to track Framework development, you already have these sitting in your local checkout. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new Framework hotness today when you check for updates through the Software Updates menu under Administration.

 

For more details on what's changed and what's current, please see Jonathan Cran's most excellent release notes.

As of a few days ago, the Metasploit Framework has full read-only access to offline registry hives. Within Rex you will now find a Rex::Registry namespace that will allow you to load and parse offline NT registry hives (includes Windows 2000 and up), implemented in pure Ruby. This is a great addition to the framework because it allows you to be sneakier and more stealthy while gathering information on a remote computer. You no longer need to rely on arcane Windows APIs with silly data structures and you can interact with the registry hives in an object-oriented manner. Combined with the recent ShadowCopy additions from TheLightCosine, you have a very powerful forensics suite at your fingertips.

 

Before I get ahead of myself, I should explain exactly what the registry is and why it matters.

 

When you open up regedit on a Windows computer, regedit is actually opening many different registry hives. A registry hive is a binary file that is stored either in C:\Windows\System32\config (SYSTEM, SOFTWARE, SAM, SECURITY) or in a user's profile (NTUSER.dat). These hives store system information and configurations, user information, and all sorts of just interesting information (group policy settings for instance). These files are locked while Windows is running. In the past, we have used methods like exporting specific hives in order to get around this lock, and this still works well enough. We now have the option of using the Volume Snapshot Service, or VSS, to create a copy of a hive while locked. However, there has been no good way to analyse and parse these hives on a system that wasn't running Windows after copying them.

 

The easiest way is to create copies of the hives, and pull them down to your local machine in a centralised place. I used 'reg SAVE HKLM\$HIVE $HIVE.hive', substituting $HIVE for the actual hive name, then download'ed the copied hive in meterpreter.

 

root@w00den-pickle:/home/bperry/Projects/new_hives# file ./*  
./sam.hive:            MS Windows registry file, NT/2000 or above 
./security.hive:       MS Windows registry file, NT/2000 or above 
./software.hive:       MS Windows registry file, NT/2000 or above 
./system.hive:         MS Windows registry file, NT/2000 or above 
root@w00den-pickle:/home/bperry/Projects/new_hives# 

 

 

You will find a new tool within the source tree called reg.rb (tools/reg.rb). This script consumes the Rex::Registry library and has many predefined methods to help speed up IG. Work is still being done on reg.rb, it has a lot of potential. Ideas or functionality requests are appreciated. Patches too.

 

A small primer on how the registry stores data is in order. WIthin a registry hive, you have 5 value types:

 

0x01 -- "Unicode character string"

0x02 -- "Unicode string with %VAR% expanding"

0x03 -- "Raw binary value"

0x04 -- "Dword"

0x07 -- "Multiple unicode strings separated with '\\x00'"

 

Types 1, 2, and 7 can be printed to a screen in a readable form without much issue. Types 3 and 4, however, are binary types and will be printed out in their base16 representations (\xde\xad\xbe\xef). Keep this in mind when querying values from a registry hive.

 

For instance, let's say we need to find out the Default Control Set in order to query correct values pertaining to drivers or the boot key. Your query would look similar to this:

 

root@w00den-pickle:~/tools/metasploit-framework/tools# ./reg.rb query_value '\Select\Default' /home/bperry/Projects/new_hives/system.hive
Hive name: SYSTEM
Value Name: Default
Value Data: "\x01\x00\x00\x00"
root@w00den-pickle:~/tools/metasploit-framework/tools# 

 

This tells us that the Default Control Set is ControlSet001. When we query the root key ('', "", '\', or "\\") of the SYSTEM hive, we will see the available ControlSets:

 

root@w00den-pickle:~/tools/metasploit-framework/tools# ./reg.rb query_key '' /home/bperry/Projects/new_hives/system

Hive name: SYSTEM

Child Keys for

===============

 

 

    Name                   Last Edited                Subkey Count  Value Count

    ----                   -----------                ------------  -----------

    ControlSet001          2010-08-21 08:56:36 -0500  4             0

    ControlSet002          2010-08-21 16:05:32 -0500  4             0

    LastKnownGoodRecovery  2011-12-13 21:22:55 -0600  1             0

    MountedDevices         2010-08-21 08:56:18 -0500  0             4

    Select                 2010-08-21 16:05:32 -0500  0             4

    Setup                  2010-08-21 16:05:33 -0500  4             6

    WPA                    2010-08-21 16:08:33 -0500  4             0

Values in key

==============

 

 

    Name  Value Type  Value

    ----  ----------  -----

root@w00den-pickle:~/tools/metasploit-framework/tools#

 

When querying the hives, the library queries relatively from the root key. On XP machines, the root key is always named $$$PROTO.HIV. On Vista+, the root key is always named along the lines of CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}. The guid will be variable. This is important to note because many times a key will be given to you in this form:

 

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\

 

In the above example, there are actually three parts. HKLM stands for HKEY_LOCAL_MACHINE. This tells regedit to load the local registry hives. The second part, Software, tells regedit the key is in the SOFTWARE hive. The third part, Microsoft\Windows\CurrentVersion\Uninstall, is the actual key path relative to the root key in the hive. Since reg.rb only looks at arbitrary hives, the first two parts aren't needed.

 

If you were to query the above key with reg.rb, the command would look like this:

 

reg.rb query_key '\Microsoft\Windows\CurrentVersion\Uninstall' /path/to/hive/SOFTWARE

 

This would enumerate the installed programs on the computer along with the date and time the key was created. Generally, the keys in the above key are created when the program is installed, so you can see how long a program has been installed on a computer as well.

 

The library also allows you to query for data that would otherwise be hidden. Each nodekey has the ability to have a classname. This classname isn't shown in regedit, and some very important information can be held in this container. For instance, the boot key is stored in 4 separate key classnames that would otherwise not be accessible. reg.rb allows you to query for the boot key easily:

 

root@w00den-pickle:~/tools/metasploit-framework/tools# ./reg.rb get_boot_key /home/bperry/tmo/hives/SYSTEM
Getting boot key
Root key: CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}
Default ControlSet: ControlSet001
3b53e09758c0f142a1771c47798b0b01
root@w00den-pickle:~/tools/metasploit-framework/tools# 

 

 

Accessing the hives programmatically

 

You may find yourself wanting to work with the hives programmatically, via a resource script with ERB, or straight from irb. The main class you will be working with is Rex::Registry::Hive. You perform queries directly off of the hive object.

 

msf > irb [*] Starting IRB shell... >> require 'rex/registry' => true >> hive = Rex::Registry::Hive.new('/home/bperry/tmo/hives/SYSTEM'); nil => nil >> hive.hive_regf.hive_name => "SYSTEM" >> hive.root_key.name => "CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}"

 

In the above example, we create a new hive object. Every hive has a root key, and begins with a regf block(which tells you what the name of the hive is, among other things). A root key is simply a nodekey with a special flag.

 

>> hive.root_key.lf_record.children.each { |k| p k.name }; nil

"ControlSet001"

"ControlSet002"

"MountedDevices"

"RNG"

"Select"

"Setup"

"WPA"

=> nil

 

Every nodekey will have either an lf_record or a valuelist (or both!). The lf_record contains the child nodekeys. The valuelist contains the child values.

 

>> valuekey = hive.value_query('\Select\Default'); nil

=> nil

>> nodekey = hive.relative_query('\ControlSet001\Control\Lsa'); nil

 

The value_query method of the hive returns a ValueKey. The relative_query method returns a NodeKey. Performing a relative_query on a value's path rather than a node's path will return the value's parent node.

 

As you can see, the library is quite powerful. It gives you a lot of control over your offline hives when performing forensics or IG. There is a lot of work to be done, with write support in the future very possible. I look forward to seeing what cool modules the community can cook up that utilizes the library. Be sure to update the framework to its latest version to ensure you have the most up to date library to play with.

While unpatched systems are often the first stepping stone of a breach, it’s often weak or shared credentials that help attackers intrude deeper into the network and breach sensitive data. Common problems are:

 

  • Weak passwords that lack length or complexity
  • Passwords contained in dictionaries
  • Passwords that are easily guessed based on information about the infrastructure
  • Vendor default passwords
  • Replaying cached credentials
  • Re-use of passwords across trust zones
  • Development test credentials in a production environment
  • Active accounts of previous employees

 

Services You Can Audit With Metasploit

 

These are all issues you can scan for with Metasploit. Unlike other password auditors that only test Windows login credentials, Metasploit Pro can brute force passwords to audit passwords across a wide range of operating systems and services, including:

 

  • Services.pngSMB/Windows/CIFS server
  • PostgreSQL database
  • IBM DB2 database
  • MySQL database
  • Microsoft SQL Server database Oracle
  • Oracle RDBMS Server
  • HTTP server (basic authentication)
  • HTTPS server (basic authentication)
  • Secure Shell server
  • Telnet server
  • File Transfer Protocol server
  • Post Office Protocol v3 server
  • BSD Remote Execution server
  • BSD Remote Login server
  • BSD Remote Shell server
  • VNC/RFB server
  • Simple Network Management Protocol

 

Credential Generation.pngMetasploit Permutates Password Candidates On Wordlists

 

Metasploit Pro uses an advanced password cracking mechanism that takes into account wordlists (including built-in dictionaries and custom wordlists) as well as information gathered from the infrastructure, such as machine names. To brute force the passwords, Metasploit Pro creates numerous permutations of passwords, for example exchanging letters for numbers (password becomes “passw0rd”). Metasploit Pro also tries known vendor default passwords.

 

Recycle Collected Evidence And Keep Iterating


After gaining access to a system through brute forcing or exploitation, Metasploit collects passwords and password hashes from compromised systems. Using its integrated John the Ripper algorithms, Metasploit Pro automatically brute forces encrypted passwords for replay attacks. When you launch a second and third brute forcing pass on your network, Metasploit Pro will use collected passwords and replay password hashes (pass-the-hash attack) to get access to more systems. You can also specify known credentials, such as development accounts and accounts of employees or consultants that are no longer with the company, to verify that these cannot be used to gain access to any systems on the network.

 

 

Iterating the process gives you access to additional machines, harvesting more and more credentials and hashes. You should definitely try this process across trust zones, e.g. DMZ and internal network, to uncover credentials in an untrusted zone that also give you access to a trusted zone.

 

 

Credential Mutation.png

Report On Your Findings

 

Once you have completed your password audit, you can generate an Authentication Tokens Audit Report that includes passwords, SSH keys, and SMB hashes, summarizing:

 

  • Guessed password frequency
  • A list of all guessed passwords
  • Authentication token frequencies
  • A list of all authentication tokens

 

You can configure the reports to either show or mask found passwords, depending on the report’s audience. Password audit results are also reflected in other reports, such as PCI and FISMA compliance reports.

 

Where You Can Learn More

 

HD Moore, the Metasploit Chief Architect, is showing some of the tips and tricks of how to audit passwords with Metasploit in next week's webinar. Register now and save the date on your calendar!

aws_logo_v3.gifMetasploit Pro is available as an Amazon Machine Image (AMI) so it can easily be run in the Amazon cloud to conduct external penetration tests. This is especially useful since several team members can use the same instance of Metasploit Pro in the cloud at the same time through Metasploit Pro's web-based user interface, even if team members are working on different projects at the same time.

 

Before you start a penetration test, there are a few things to notice so you don't violate the Amazon policies. Amazon requires customers to obtain authorization for penetration testing (or vulnerability assessments) both from or to their AWS resources. Amazon offers a form (linked from this page - requires login) to streamline this process.

 

AWS Security will then add your source and destination addresses to a white list for the duration of your penetration test. As always, you need to have the legal permission from the owners of the assets your are conducting your security tests on. AWS Security will revoke your white list privileges if they receive any complaints or reports about DoS attacks. Amazon currently doesn't permit testing m1.small or t1.micro instance types to prevent performance impacts on the resources shared with others.

 

If you'd like to find out more, read Amazon's full policies about penetration testing and vulnerability management .

 

Have you conducted penetration tests on or from the Amazon cloud? Please comment on this blog to share your experience!

 

To try out Metasploit Pro, get the free trial!

Time for another Metasploit Update - this week we've got some new goodies for Meterpreter's Railgun, SSH, AIX, and a few new exploit modules. Enjoy!

 

Railgun Updates

 

Metasploit open source contributors Chao-Mu and kernelsmith have been busy over the last month or so, cranking out a pile of commits to Railgun in order to facilitate Windows API error message handling. For you non-post module developers, Railgun is a super-handy Meterpreter extension that "turns Ruby into a weapon," and you can get the technical details on the RailgunUsage wiki page over on the Metasploit development site. I wanted to highlight this effort this week because this is a great example of the collaborative feature building that goes on around here. Thanks guys!

 

New Modules (and scripts!)

 

In between handling customer feature requests and bug reports for Metasploit Pro, thelightcosine knocked out a couple new AIX-centric modules: a password hash dumper for AIX passwords (post/aix/hashdump) and a John the Ripper module to crack the same. AIX is a touch more exotic when it comes to operating systems, but there are plenty of enterprises that have one or two running. What's more, those machines have a tendency to run some pretty critical infrastructure.

 

Thomas Ring took up the challenge posed a couple weeks ago to submit some example resource scripts to demonstrate some low-level automation by working up three new Oracle-based scripts to automatically interrogate found Oracle servers for more information. This is a great example of driving Metasploit modules via data from the database, and has spurred some conversation on where RC scripts might go in the future.

 

In addition to these, we have six other modules added to Metasploit Framework:

 

  • drupal_views_user_enumeration , which exploits an information disclosure on Drupal usernames
  • sybase_easerver_traversal, which exploits CVE-2011-2474, a directory traversal vulnerability in Sybase EAServer
  • op5_license, which exploits CVE-2012-0261, a remote command execution vulnerability on OP5 Monitor
  • op5_welcome, which exploits CVE-2012-0262, another RCE vulnerability on, you guessed it, OP5 Monitor
  • xampp_webdav_upload_php, a WebDAV-vectored general purpose PHP file include exploit
  • adobe_reader_u3d, which exploits CVE-2011-2462, a file format bug in Adobe Reader (a tricky bug nailed down by exploit heavyweights sinn3r, jduck, and Juan Vazquez in another display of collaborative development teamwork)

 

Availability

 

For those of you who rely on the msfupdate command to track Framework development, you already have these sitting in your local checkout. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new Framework hotness today when you check for updates through the Software Updates menu under Administration.

 

For more details on what's changed and what's current, please see Jonathan Cran's most excellent release notes.

Integrating Nexpose with Metasploit.pngMetasploit has three ways to integrate with Nexpose vulnerability scanner. I've heard some confusion about what the different options are, so I'd like to summarize them here briefly:

 

  1. Importing Nexpose reports: This is a simple, manual file import. Apart from Nexpose, Metasploit can import about 13 different third-party reports from vulnerability management solutions and web application scanners. This feature works in all Metasploit editions.
  2. Initiate a Nexpose scan from Metasploit: If you have Nexpose installed on the same machine, you can initiate a vulnerability scan from Metasploit. Once completed, the results are automatically imported into Metasploit. This feature also works in all Metasploit editions.
  3. Integrate with your Nexpose infrastructure: If you have a Nexpose vulnerability managment infrastructure in place, especially if they comprise several scan engines located on various sites around the globe, your best option is to integrate Nexpose directly with Metasploit. Metasploit can connect with any number of Nexpose scan engines to query and import vulnerability reports from the scanners. The advantage of this option is that you don't have to conduct a new scan and you don't have to manually export/import any files. This feature is exclusive to Metasploit Pro.

 

If you're using Metasploit Pro, you also have the option to tag your imports, for example by source or time. This enables you to later filter or report by import.

 

Both Metasploit and Nexpose are available as free community editions as well as commercial enterprise editions. To get your free community version, download Metasploit Community Edition or Nexpose Community Edition now!

iStock_000004398297XSmall.jpgWhen conducting a penetration testing assignment, one objective may be to get into the network without tripping any of the alarms, such as IDS/IPS or anti-virus. Enterprises typically add this to the requirements to test if their defenses are good enough to detect an advanced attacker. Here's how you can make sure you can sneak in and out without "getting caught".

 

Scan speed

 

First of all, bear in mind that you'll want to slow down your initial network scan so you don't raise suspicion by creating heavy network traffic. In the Advanced Settings of hte Discovery Scan, set your network scanning speed to Sneaky or Paranoid. This feature is included in Metasploit Community Edition, Metasploit Express, and Metasploit Pro.

 

paranoid.png

 

Evading IDS/IPS

 

Metasploit has many different settings to evade an IDS/IPS (intrusion detection system/intrusion prevention system).

 

Metasploit Framework enables you to set many of these manually, for example changing the transport type, encoding, fragmenting traffic. Finding the right setting to evade the IPS system can be a little tricky.

 

If you want to make your life easier, you can use Metasploit Pro's pre-defined levels of evasion: You can choose Transport Evasions, and Application Evasions, all of which have the options of None, Low, Medium, and High. In the back-end, the tuning is different for each type of exploit. For example, if you’re choosing low transport evasion, it will run the exploit a little slower and chunk it up into more segments. With higher options, we change exploit-specific settings, like the compression type, the name of the webserver, or use different Unicode encodings.

 

You can set these IDS/IPS evasion settings in the Advanced Options of the Exploitation screen:

 

  • Concurrent exploits: Reduces the number of exploits that are launched at your targets at the same time. Reduce this to ensure the attack doesn't raise any red flags.
  • Transport evasion: Sends smaller TCP packets and increases time delay between packets to avoid detection.
  • Application Evasion: Adjusts application-specific evasion options for exploits involving DCERPC, SMB and HTTP. The higher the setting, the more evasion techniques are applied.

 

IDS evasion.png

 

Social engineering

 

When choosing the payload for social engineering campaigns, you should choose Encrypted HTTPS to ensure that your payload phones back using an encrypted session. These are harder to detect by your IDS/IPS. Social engineering campaigns are only available in Metasploit Pro.

 

payload.png

 

Avoiding anti-virus

 

Even if you get past the IDS/IPS systems on the network, the anti-virus engine on the machine you're trying to exploit may stop your attack if you're not careful. A lot of AV vendors are flagging Metasploit exploits and payloads as malware because they can be used in an attack. That is also a reason why you shouldn't have a malware scanner installed on the machine you run Metasploit on - otherwise it may block your installation or exploits. If you must install an AV solution installed, ensure that you have excluded the Metasploit directory from the scans.

 

Metasploit includes various ways to avoid anti-virus detection, which again differ between editions. Metasploit Framework and Metasploit Community share the same basic AV evasion. Metasploit Express adds a self-signed binary and templates to evade detection by anti-virus solutions. Metasploit Pro includes a Rapid7-signed binary to inject code that bypasses a white list and a persistent agent that is compiled differently every time, making it very hard to detect. To get an impression how successful Metasploit is in evading anti-virus, check out the results from our test lab in the blog post "Become invisible to anti-virus protection".

 

How are your defenses holding up to advanced evasion techniques? Download Metasploit and register for a free Metasploit Pro trial today.

Turns out, the week between Christmas and New Years was pretty slow, at least as far as Metasploit Framework development was concerned. This release has a few small spot fixes on Framework, and a handful of new modules.

 

ShadowCopy

The most significant addition to the framework was TheLightCosine's work on the appropriately scary-sounding ShadowCopy library. Based on the research published by Tim Tomes and Mark Baggett, the modules implementing this library enable an attacker to leverage a Windows target's Volume Shadow Copy service to make "backups" of otherwise locked file resources. This is handy for snagging, among other things, the Security Accounts Manager (SAM file), running databases, et cetera, without having to worry about locked files. Pretty neato.

 

Other Modules

Brandon Perry did some work on gathering information about a target organization -- not just a target computer or network -- via his newly committed Corpwatch modules. These use the Corpwatch_API to dump information gathered from SEC filings on publicly-traded companies. This kind of reconnaissance can be useful for an initial penetration engagement, since it can give clues to relationships between organizations and where entry points into the target network might lurk. We also have a new exploit from Metasploit community contributor Fady Mohamed Osman for CoCSoft's StreamDown streaming media server (BID-51190), so thanks to him for that.

 

Year in Review

This update represents the first update of 2012, though technically, most of the work was finished in 2011, so it's kind of the last update from last year. Community contributor Chris John Riley put together a quick list of all the new modules for Metasploit introduced in 2011. You can read that list on his blog, so I won't really rehash it here. However, I'd like to take a minute to throw some bullet points out there about the growth and change that's been going on in Metasploit over 2011 aside from the module shuffle.

 

 

So, kind of a lot. We also had six major released for the Framework in there, too, incrementing along from 3.5.1 to the current 4.1.0. According to my counts, we added 143 exploit modules, 96 auxiliary modules, 123 post modules, and 23 payloads to Metasploit Framework along the way. That's a grand total of 362 new modules (385 counting payloads, which really, you should), averaging out to just about one new security-relevant feature a day.

 

Availability

For those of you who rely on the msfupdate command to track Framework development, you already have these sitting in your local checkout. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new Framework hotness today when you check for updates through the Software Updates menu under Administration.

 

For more details on what's changed and what's current, please see Jonathan Cran's most excellent release notes.

If you're working in IT security in U.S. federal government, chances are that you have to comply with the Federal Information Security Management Act of 2002 (FISMA). With Metasploit Pro, you can generate FISMA compliance reports that map penetration testing findings to controls, as recommended by Special Publication 800-53a (Appendix G) published by the National Institute of Standards and Technology (NIST) and by Consensus Audit Guidelines issued by a number of constituents including NIST and federal agencies such as the DoD and DHS.

 

Reports can be generated in PDF, RTF, XML and HTML formats. I've attached sample copies of all file formats to this blog post.

 

Here's a snipped from a recent webinar showing how easy it is to generate a FISMA report:

 

 

Note: This video is an excerpt from the webinar about Metasploit 4.1 entitled “What's new with Metasploit? HD Moore's personal tour of the next product version”. To view a recording of this webinar, please visit this page

webscan.pngMost tools for web application security testing have the approach of going deep into an application to uncover issues inside a single web application. There's nothing wrong with this approach if you want to do a deep dive into one specific web application, especially if it is a major application exposed on the Web. The other approach is to see what web servers are running on a network and seeing if they can be exploited with quick and scalable testing. This is the approach Metasploit Pro takes.

 

When conducting a penetration test, especially an internal one, a web app scan with Metasploit Pro will reveal a lot of web servers you didn't know you had. In a quick scan on a sample network with 78 hosts, I found 18 hosts that were running a total of 34 HTTP/HTTPS services. That's almost half the hosts exposing a web interface. Some of these were servers, laptops, and VOIP devices, often exposing an administration interface or sometimes a rogue webserver - providing a potential way to exploit the host. Most of these would be overlooked in a dedicated web app audit that focuses only deep on one web application.

 

Here is how you run a Web app audit on your network:

  1. Run a Network Discovery on the IP range of your network
  2. Select all the hosts in the list and click on WebScan
  3. After the WebScan is completed, select all websites in the Web Apps tab and click on Audit Web Apps
  4. If you want to try exploitation, select all websites in the Web Apps tab and click on Exploit Web Apps.

 

The Web Apps feature is exclusive to Metasploit Pro. If you'd like to test drive it on your network, download your free Metasploit Pro trial today.

Filter Blog

By date: By tag: