Skip navigation
All Places > Metasploit > Blog > Authors jhart


3 Posts authored by: jhart Employee

This post is the eighth 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.


A week or two back, Mercurial inventor Matt Mackall found what ended up being filed as CVE-2014-9390.  While the folks behind CVE are still publishing the final details, Git clients (before versions, 1.9.5, 2.0.5, 2.1.4 and 2.2.1) and Mercurial clients (before version 3.2.3) contained three vulnerabilities that allowed malicious Git or Mercurial repositories to execute arbitrary code on vulnerable clients under certain circumstances.


To understand these vulnerabilities and their impact, you must first understand a few basic things about Git and Mercurial clients.  Under the hood, a Git or Mercurial repository on disk is really just a directory.  In this directory is another specially named directory (.git for Git, .hg for Mercurial) that contains all of the configuration files and metadata that makes up the repository.  Everything else outside of this special directory is just a pile of files and directories, often called the working directory, written to disk based on the previous mentioned metadata.  So, in a way, if you had a Git repository called Test, Test/.hg is the repository and everything else under the Test directory is simply a working copy of of the files contained in the repository at a particular point in time.  An nearly identical concept also exists in Mercurial.


Here is a quick example of a simple Git repository that contains has no files committed to it.  As you can see, even this empty repository has a fair amount of metadata and a number of configuration files:


$  git init foo
$   tree -a foo
└── .git
    ├── branches
    ├── config
    ├── description
    ├── HEAD
    ├── hooks
    │   ├── applypatch-msg.sample
    │   ├── commit-msg.sample
    │   ├── post-update.sample
    │   ├── pre-applypatch.sample
    │   ├── pre-commit.sample
    │   ├── prepare-commit-msg.sample
    │   ├── pre-rebase.sample
    │   └── update.sample
    ├── info
    │   └── exclude
    ├── objects
    │   ├── info
    │   └── pack
    └── refs
        ├── heads
        └── tags


If you then add a single file to it called test.txt, you can see how the directory starts to change as the raw objects are added to the .git/objects directory:


$ cd foo
$ date > test.txt && git add test.txt  && git commit -m "Add test.txt" -a
[master (root-commit) fb19d8e] Add test.txt
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$  git log
commit fb19d8e1e5db83b4b11bbd7ed91e1120980a38e0
Author: Jon Hart Date:   Wed Dec 31 09:08:41 2014 -0800

    Add test.txt

$ tree -a .
├── .git
│  ├── branches
│  ├── config
│  ├── description
│  ├── HEAD
│  ├── hooks
│  │  ├── applypatch-msg.sample
│  │  ├── commit-msg.sample
│  │  ├── post-update.sample
│  │  ├── pre-applypatch.sample
│  │  ├── pre-commit.sample
│  │  ├── prepare-commit-msg.sample
│  │  ├── pre-rebase.sample
│  │  └── update.sample
│  ├── index
│  ├── info
│  │  └── exclude
│  ├── logs
│  │  ├── HEAD
│  │  └── refs
│  │      └── heads
│  │          └── master
│  ├── objects
│  │  ├── 1c
│  │  │  └── 8fe13acf2178ea5130480625eef83a59497cb0
│  │  ├── 4b
│  │  │  └── 825dc642cb6eb9a060e54bf8d69288fbee4904
│  │  ├── e5
│  │  │  └── 58a44cf7fca31e7ae5f15e370e9a35bd1620f7
│  │  ├── fb
│  │  │  └── 19d8e1e5db83b4b11bbd7ed91e1120980a38e0
│  │  ├── info
│  │  └── pack
│  └── refs
│      ├── heads
│      │  └── master
│      └── tags
└── test.txt


Similarly, for Mercurial:

$  hg init blah
$  tree -a blah
└── .hg
    ├── 00changelog.i
    ├── requires
    └── store

2 directories, 2 files
$  cd blah
$  date > test.txt && hg add test.txt && hg commit -m "Add test.txt"
$  hg log
changeset:   0:ea7dac4a11f0
tag:         tip
user:        Jon Hart date:        Wed Dec 31 09:25:07 2014 -0800
summary:     Add test.txt

$  tree -a .
├── .hg
│   ├── 00changelog.i
│   ├── cache
│   │   └── branch2-served
│   ├── dirstate
│   ├── last-message.txt
│   ├── requires
│   ├── store
│   │   ├── 00changelog.i
│   │   ├── 00manifest.i
│   │   ├── data
│   │   │   └── test.txt.i
│   │   ├── fncache
│   │   ├── phaseroots
│   │   ├── undo
│   │   └── undo.phaseroots
│   ├── undo.bookmarks
│   ├── undo.branch
│   ├── undo.desc
│   └── undo.dirstate
└── test.txt


These directories (.git, .hg) are created by a client when the repository is initially created or cloned.  The contents of these directories can be modified by users to, for example, configure repository options (.git/config for Git, .hg/hgrc for Mercurial), and are routinely modified by Git and Mercurial clients as part of normal operations on the repository. Simplified, the .hg and .git directories contain everything necessary for the repository to operate, and everything outside of these directories is considered is considered part of the working directory, namely the contents of the repository itself (test.txt in my simplified examples).


Want to learn more? Git Basics and Understanding Mercurial are great resources.


During routine repository operations such as cloning, updating, committing, etc, the repository working directory is updated to reflect the current state of the repository.  Using the examples from above, upon cloning either of these repositories, the local clone of the repository would be updated to reflect the current state of test.txt.


This is where the trouble begins.  Both Git and Mercurial clients have had code for a long time that ensures that no commits are made to anything in the .git or .hg directories.  Because these directories control client side behavior of a Git or Mercurial repository, if they were not protected, a Git or Mercurial server could potentially manipulate the contents of certain sensitive files in the repository that could cause unexpected behavior when a client performs certain operations on the repository.


Unfortunately these sensitive directories were not properly protected in all cases.  Specifically:


  1. On operating systems which have case-insensitive file systems, like Windows and OS X, Git clients (before versions, 1.9.5, 2.0.5, 2.1.4 and 2.2.1) can be convinced to retrieve and overwrite sensitive configuration files in the .git directory which can allow arbitrary code execution if a vulnerable client can be convinced to perform certain actions (for example, a checkout) against a malicious Git repository.  While a commit to a file under .git (all lower case) would be blocked, a commit to .giT (partially lower case) would not be blocked and would result in .git being modified because .git is equivalent to .giT on a case-insensitive file system.
  2. These same Git clients as well as Mercurial versions before 3.2.3 have a nearly identical vulnerability that affects HFS+ file systems (OS X and Windows) where certain Unicode codepoints are ignored in file names.
  3. Mercurial before 3.2.3 on Windows has a nearly identical vulnerability on Windows only where MS-DOS file "short names" or 8.3 formats are possible.


Basic exploitation of the first vulnerability is fairly simple to do with basic Git commands as I described in #4435, and the commits that fix the second and third vulnerabilities show simple examples of how to exploit it.


But basic exploitation is boring so in #4440 I've spiced things up a bit.  As currently written, this module exploits the first of these three vulnerabilities by launching an HTTP server designed to simulate a Git repository accessed over HTTP, which is one of the most common ways to interact with Git.  Upon cloning this repository, vulnerable clients will be convinced to overwrite Git hooks, which are shell scripts that get executed when certain operations happen (committing, updating, checkout, etc).  By default, this module overwrites the .git/hooks/post-checkout script which is executed upon completion of a checkout, which conveniently happens at clone time so the simple act of cloning a repository can allow arbitrary code execution on the Git client.  It goes a little bit further and provides some simplistic HTML in the hopes of luring in potentially vulnerable clients:



And, if you clone it, it only looks mildly suspicious:


$ git clone
Cloning into 'ldf'...
$ cd ldf
$ git log
commit 858597e39d8a5d8e3511d404bcb210948dc835ae
Author: Deborah Phillips Date:   Thu Apr 29 17:44:02 2004 -0500

    Initial commit to open git repository for!

The module has the beginnings of support for the second and third vulnerabilities, so this particular #haxmas gift may need some work by you, the Metasploit community.





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:




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 wants to allow hosts on the public Internet to connect to a game server it is hosting on, 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 ->


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 (thanks, RFC 5737!)  and another internal, listening on 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




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:





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,, to our IP, :




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




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:




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




Finally, showing that now resolves the address we specified,




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:




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




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





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, usually indicating that the other interface hasn't received an IP address yet
  • 24,927 devices responded with an RFC1918 address (, and 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:


  • 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  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:




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 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:


NAT-PMP External AddressCount


NAT-PMP External AddressCount


NAT-PMP External AddressCount


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
Russian Federation133126
United States64182


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.




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.




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



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




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


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


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


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


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


Vulnerabilities Summary


More detail is available below, however the summary is:


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


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

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



Disclosure Timeline


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


Technical Analysis


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


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


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


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


This can be seen by running the ntp_peer_list_dos Metasploit module:


Or utilizing the ntpdc command:

ntpdc -nc listpeers <host>

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


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


This can be tested by running the ntp_peer_list_sum_dos Metasploit module:


Or utilizing the ntpdc command:

ntpdc -nc peers <host>

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


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


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


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


This can be tested by running the ntp_reslist_dos Metasploit module:


Or utilizing the ntpdc command:

ntpdc -nc reslist <host>

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

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


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


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


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


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


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


This can be tested by running the ntp_req_nonce_dos Metasploit module:


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


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


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


This can be tested by running the ntp_unsettrap_dos Metasploit module:


Conclusions and Recommendations

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


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

Filter Blog

By date: By tag: