Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 28 2012

06:26
06:18

Man stole “numerous” customer accounts for more than a year

Windstream data loss incident circa 2012-01-27
06:07
05:39
05:03
04:57

8,000 Social Security numbers and some credit card numbers of prospective students on a public server

University System of Maryland data loss incident circa 2012-01-27

January 27 2012

20:54

"Pass the hash" with Nexpose and Metasploit

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.

14:40

Remote-controlling Metasploit through APIs

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!

January 26 2012

07:15

January 25 2012

23:15

Weekly Metasploit Update: Subverting NATs, 64-bit LoadLibrary Support, and More!

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
  • dowload_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.

16:58

Mythical Videoconferencing Hackers

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.

January 23 2012

13:00

Board Room Spying for Fun and Profit

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 join us for tomorrow's webinar "Board Room Spy Cams: How Attackers Take Over Your Video Conferencing Systems And How To Stop Them".

03:02

January 21 2012

18:59

Observations from two weeks of SSH brute force attacks

Earlier this month, I blogged about monitoring password-guessing attacks on a server, via a patched OpenSSH. This experiment has now been running for just over two weeks, and there are some interesting results. I’ve been tweeting these since the start.

As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234″, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).

Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’). For these, there were a very small number of password attempts, normally only trying the username as password. Well established good practices such as choosing a reasonably strong password and denying password-based log-in to the root account will be effective against both categories of attacks. Surprisingly, there were few attempts which were obviously default passwords from software packages (but they perhaps were hidden in the attempts where username equalled password). However, one attempt was username: “rfmngr”, password: “$rfmngr$”, which is the default password for Websense RiskFilter (see p.10 of the manual).

There were, however, some more interesting attempts. One category was passwords far too complicated to be in a standard password dictionary, or even found through offline-brute-force attacks on a hashed password database (e.g. “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, and “kx028897chebeuname+a”). The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client. Theo Markettos identified a likely source for this password database. Other odd password attempts include plain hashes (e.g. E4F89B211D997C1D5ECCE2153DC9184A which is the MD5 of “upintheair”, found by Google), salted hashes (e.g. $1$EdkQIoSn$T3gzKLxlcxF7tsTCFqC8M) and filenames (e.g. “/var/run/sshd22.pid” and “/var/run/sshd”).

One conclusion which can be drawn is that this attacker does not care enough about the quality of the password database to filter out passwords which it makes almost no sense to use. This carelessness is supported by the fact that after I initially enabled my patched SSH server, I received many log-in attempts but no passwords. It turned out that the default FreeBSD configuration is to only support keyboard-interactive authentication, rather than the more limited password authentication. The brute force attack tool only attempted password authentication, and therefore was always rejected before any password was sent, so the attack was running for days without ever having a hope of succeeding. I did enable password authentication, but some later attacks, presumably using a different tool and probably from a different attacker, attempted both keyboard-interactive and password authentication.

One attack I hadn’t seen before was to try a large number of usernames, and parts of the hostname as password. For a hostname of the style MACHINE.DOMAIN.DEPARTMENT.cam.ac.uk, the attack tried DOMAIN, DOMAIN.DEPARTMENT, MACHINE, then MACHINE.DOMAIN. This clearly isn’t a dictionary but a bit of custom code which did a reverse DNS lookup on this host then generated some possible passwords. Using the hostname as a password for a host isn’t a good idea, but I can imagine some sysadmins doing so. The fact that some attackers are taking this approach might merit some explicit statement in password selection guidance.

Another curious trend was receiving meta-data as username/passwords. This might be due to the brute force tool not properly interpreting comments in the dictionary file, or the attacker not understanding the comment notation. For example I received the following username/passwords:

  • [uratu/was HERE]
  • [I`m/A HaCkER ON]
  • [This/Is A Blow ShiT]
  • [acest/este:varza]
  • [data.conf/contzine]
  • [peste=6.000/de:usere]
  • [setate/=<SweetSoul>
  • [checking/SweetSoul]\par

It looks like the attacker thinks that square brackets are comment notation, but the brute force tool simply sends the text as SSH username/password pairs. There also seems to be a Romanian language connection. For example, “acest este varza” according to Google means “this is cabbage” (perhaps an idiom), “contzine” means “list any”, “peste de usere” means “over the user”, “setate” means “set”. The Romanian connection also came up in the previous post where Romanian for “Handbook of Mechanical Engineering” was tried as a password.

Attentive readers will note the “\par” in the above list perhaps indicating that the file was converted to RTF at some point. This appears indeed to be the case from the later attempt of username: “\*\generator”, password: “Msftedit 5.41.21.2508;}…[checking uratu]\par”. From this we can also conclude that the attacker is using Windows WordPad.

Overall it was an interesting experiment, with some conclusions confirmed but a few surprises. However, this was only a two week experiment on a single machine, so care should be taken in drawing generalisations which assume that these results are typical.

17:01

Thoughts on DeepSafe


Several people asked me recently what Ithough about DeepSafe.So, below I present my opinion...

First, for any AV system (or Host IPS,or Personal Firewall, etc) to work effectively, there are three problems that must be addressed:
  1. How to protect the AV agent (code and data) from tampering (from the rest of the OS)?
  2. How can the AV agent get reliable access to (sensitive pieces of) the system memory and registers, and/or provide reliable memory protection for the (sensitive pieces of) the OS.
  3. What are those "sensitive pieces of” memory that should be monitored or protected?
From reading various PR materials, itseems like the #1 above is the primary differentiation factor forDeepSafe (DS). So, let's consider this problem in the context of e.g.a Windows OS. In order to protect its code and data, DS uses, as itis heavily advertised, Intel VT-x virtualization technology. Now,that sounds really secure -- after all what can be more secure than ahardware virtualization, right? ;)

But VT-x (including EPT) is only aboutCPU virtualization, which in our case translates to protecting the DSmemory and registers from CPU-originating accesses. But, as everyregular to this blog knows, there is also another method of accessingmemory on any PC system, and this is through DMA transactions fromdevices. The OS (so also the kernel malware) is free to program oneof the many devices in the system to issue DMA reads or writes to anyphysical memory itwants...

Now, in order to protect some portionof the system memory (DRAM, cache) against DMA accesses, we have theIntel VT-d technology... So, one would think that DS must be alsousing VT-d in order to protect itself.

Very well, let's assume then that theDeepSafe is not a total ripoff,and that it implements also VT-d protection for its agent, although Ihaven't found this mentioned in any of the public papers or pressmaterials I found on the web...

This, however, would be a bit complexto do correctly, because the OS (so, also the kernel malware) stillhas a full control over the chipset (MCH), which is the entity...that controls the VT-d.

Now, in order toprevent the OS (or the kernel malware) from playing with the chipsetfor fun and profit, and e.g. disabling VT-d protection, DS would haveto virtualize the chipset.

If you look at some consumer VMMs, suchas VMware or Xen/Qemu, you would see that they all virtualize thechipset for their guests (of course), but that the chipset theyprovide this way is some kind of an ancient Pentium MCH. I don'tthink any of the consumers would be especially happy if they foundout that after installing DS on their brand new 2012 laptop, Windowssuddenly see a Pentium-era chipset... And this is not without areason – chipsets, specifically MCHs, are one of the most complexdevices, perhaps only beaten by GPUs in this category. There arevirtually hundreds of configuration registers exposed by the chipset,some of them control the VT-d, some other control system memory mapsand permissions, PCIe configuration, and many other things that Ieven have no idea about, and this all makes virtualizing the chipseta very challenging task.

So, it's either that McAfee and Intelfound some interesting way of how to securely virtualize the chipsetwhile preserving all of its (very rich) functionality, or thatthey... don't bother with VT-d protection and chipset virtualizationat all, assuming that even without VT-d, DeepSafe is good enough and“rises the bar” anyway (sarcasm intended).

(Can somebody from McAfee or Intelconfirm in the comments below what does DP really do?)

Anyway, let's assume they dohave VT-d protection and they do virtualize the chipsetsomehow...

Now, we're moving on to the #2 pointfrom the list of tasks above -- about the reliable
memory access or reliable protection.

So, let say that the DS agent decidedthat some part of the system memory, e.g. the IDT table, is sensitiveand should be monitored/protected. So it sets up EPT traps to triggeran VT-x/EPT intercept on any access to that memory (or IDT baseregister), in order to find kernel malware that tried to modify IDT.That sounds really nice, but what if the malware uses DMA to modifyIDT? DS would not be able to catch such access! (So far we consideredthe, hypothetical, use of VT-d only to protect the DS agent code).

One might think that DS is programmingVT-d to sandbox each and every device in the system (so includingGPU, USB controllers, NICs, SATA, etc) so they never beallowed to touch any of those sensitive parts of the system, such asIDT. Let's assume they do it this way...

And here we've arrived to the lastpoint from the list at the beginning: which of the system memoryconstitutes those "sensitive pieces" that should beprotected/monitored? IDT? Sure. What about all the code sections ofthe all the kernel modules? Yes. Are we fine now? Well, no, becausethe malware can hook some pointers other than the well known IDT.Some public NDIS data structure? Ok, we can add those to theprotected areas. But, what about some undocumented NDIS structures?And this is just NDIS subsystem, one of the many subsystems in theWindows kernel... When we think about it, it should be intuitivelyobvious that in a general purpose Operating System like Windows, itis not possible (at least for 3rd party) to make asatisfactory list of all the sensitive pieces of memory that shouldbe monitored/protected, in order to detect all the systemcompromises.

Greg Hoglund, Jamie Butler, AlexTereshkin, and myself, have been researching this area actively inthe early years of this millennium. In addition to the Alex's paperlinked above, you might also check out one of my last slides fromthisperiod.

I don't think anything has changedsince that time. It was also the reason why I gave up on writingWindows compromise detectors, or forensic tools, and moved on toresearching other ways to secure OSes, which finally gave birth toQubes OS, many years later.

So, back to DS -- in order to provide asomehow satisfactory protection level for your general purpose OS,such as Windows, it would need to:
  1. Use VT-d to protect its own memory,
  1. Virtualize the chipset, at least some (sensitive) parts of it,
  1. Program VT-d permissions for each device to exclude all the sensitive areas in the system that should be protected, and also protect one device from DMAing into/from another device memory (e.g. NIC stealing GPU framebuffer, or inserting instructions to the GPU instruction buffer, or keystrokes to USB controller buffer). Ideally, this could be done by programming VT-d to grant each device only access to its own DMA buffer, but as far as I know, this would be very hard to implement, if not impossible for a 3rd party, on a Windows OS (in contrast to Linux, which mostly support this model). Please correct me, if the recent Windows version allows for such use of VT-d.
  1. Finally, and the most hard thing to solve, how to define all the "sensitive pieces of memory" in the system that should be protected and/or monitored? Although this is a somehow more generic problem, not specific to DS, but applying to any A/V, HIPS, or forensic tool.
So, is DeepSafe another piece of crap not worth any special attention, or has McAfeeand Intel came up with some novel methods, e.g. for chipsetvirtualization, and other problems? Unless I see some technical info to backup the latter, I would have to assume,unfortunately, the former. But I would like to be mistaken – afterall DeepSafe seems to be just a new incarnation of my Bluepill ;)

January 19 2012

21:46

Simple Outlook Web Access Phishing

This 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

Tags: phishing
17:01

Metasploit Updated: Forensics, SCADA, SSH Public Keys, and More

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.

January 18 2012

15:02

Metrics for dynamic networks

There’s a huge literature on the properties of static or slowly-changing social networks, such as the pattern of friends on Facebook, but almost nothing on networks that change rapidly. But many networks of real interest are highly dynamic. Think of the patterns of human contact that can spread infectious disease; you might be breathed on by a hundred people a day in meetings, on public transport and even in the street. Yet if we were facing a flu pandemic, how could we measure whether the greatest spreading risk came from high-order static nodes, or from dynamic ones? Should we close the schools, or the Tube?

Today we unveiled a paper which proposes new metrics for centrality in dynamic networks. We wondered how we might measure networks where mobility is of the essence, such as the spread of plague in a medieval society where most people stay in their villages and infection is carried between them by a small number of merchants. We found we can model the effects of mobility on interaction by embedding a dynamic network in a larger time-ordered graph to which we can apply standard graph theory tools. This leads to dynamic definitions of centrality that extend the static definitions in a natural way and yet give us a much better handle on things than aggregate statistics can. I spoke about this work today at a local workshop on social networking, and the paper’s been accepted for Physical Review E. It’s joint work with Hyoungshick Kim.

January 17 2012

01:50
01:30

5,294 e-mail addresses, MD5 passwords, and usernames dumped on the Internet

Pakistan Horticultural Export & Development Board data loss incident circa 2012-01-16
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.