Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.
At Team Cymru, we have got into the habit of using BLUF, bottom line up front. Allow me to do so here as well. There exists a little known IP multicast tracing and troubleshooting capability referred to as DVMRP Ask Neighbors2 (the request) and DVMRP Neighbors2 (the response) that can leak router configuration detail and be abused in amplification and reflection attacks. Now, for a fuller accounting of the story.
As I am wont to do, when I take myself out to lunch I will often bring
with me some reading material, usually some recent research paper.
Approximately four years ago this month, on one such dining and study
occasion I happened to bring with me a paper entitled Extracting
Intra-Domain Topology from
mrinfo. IP
multicast is a subject that has long held my attention since many of my
formative years operating networks involved inter-domain IP multicast
deployment. mrinfo, from the
mrouted package. is a command line
tool I was familiar with so this paper along with the overall theme of
network discovery and measurement immediately appealed to me. After
having read the paper and then after a long hiatus from IP multicast
troubleshooting tools like mrinfo, I rediscovered how useful this was
for mapping Internet topology not necessarily specific to IP multicast
by obtaining otherwise unobtainable information from some Internet
routers. Fast forward three years. In October 2013, my mind was often
preoccupied with amplification and reflection
attacks, but I
had an opportunity to experiment with the mrinfo tool again when I
almost immediately realized the Internet community had another
potentially worrisome DDoS threat vector on our hands. From then on up
to the present day we have set out to better understand and study all
the ramifications of what many would deem to be a case of “protocol
abuse” in two forms, an amplifcation and reflection threat and a network
topology disclosure threat. We felt both of these threats needed to be
brought to the attention of certain vendors and the Internet community
so mitigation could begin before miscreants discovered and took
advantage of the threats. This blog post provide some background
technical material about the threats and the small part we have been
playing in mitigation response.
The Internet Group Multicast Protocol (IGMP), IP protocol 2, is essentially a signaling mechanism used between hosts and local IPv4 routers. In essence, end hosts use IGMP to join and leave IP multicast groups and routers use IGMP to maintain group membership on the local network. In practice, there is no operational requirement that these group membership maintenance messages ever leave the local network. Now, I’m not one to advocate for wholesale prohibition of otherwise harmless IP datagrams across internetworks, but here is where the trouble initially begins, but first we must say something about an IP multicast routing protocol that utilizes IGMP.
A now little used and largely obsolete IP multicast routing protocol, the Distance Vector Multicast Routing Protocol (DVMRP), the first widely deployed approach to help move IP multicast data packets around an internetwork, specifies the use of IP protocol 2, making DVMRP a subset type of IGMP messages. The initial specification of DVMRP, version 1, was published as experimental IETF RFC 1075 in 1988. Some years later, work began on updating DVMRP, including bundling in support for additional features that perform “tracing and troubleshooting” capabilities. This latter effort never left Internet Draft status and was ultimately abandoned in final publication draft-ietf-idmr-dvmrp-v3-11. It is the implementation of the DVMRP Ask Neighbors2 and DVMRP Neighbors2 request and response messages in the draft specification of DVMRP that worried us. The former message is specified to be a unicast request, directed to a DVMRP router. If supported, the target router sends a DVMRP Neighbors2 response that includes, primarily, a list of logical interfaces and each interface’s properties such as a local IP address and neighbor IP addresses. See Appendix B - Tracing and Troubleshooting support in the draft for further details. Not only was this feature and capability widely implemented in two of the most prominent router vendors' products, but soliciting an Ask Neighbors2 response does not require DVMRP to be running, only some other basic IP multicast component. As you might guess, not only do some routers that respond to these messages disclose information about a router an operator might otherwise wish to keep private, but because a single, small request can potentially solicit a sizable response, this tracing and troubleshooting capability makes for a novel new amplification and reflection attack vector.
We might express some outrage that this little known capability, never
formally ratified in an IETF RFC has not only been widely implemented,
but has lay lurking as a potential problem for years. We may also be
inclined to fret about this threat existing on some of the largest, most
well connected and vital pieces of equipment on the Internet. These
reactions may be justified, and we do not want to belittle the issue,
but we think the potential for widespread abuse may not be as bad as we
have seen with other recently disclosed threats through the NTP or the
DNS. Two reasons lead us to this belief. First, we believe the
changes, fixes or other approaches to limiting abuse are more easily
and likely deployed when compared to other protocol abuse threats. By
in large, IGMP does not need to transit routers so as a last resort,
network-wide filtering of IGMP is not only feasible, but with the
exception of being able to use a tool like mrinfo, come
with few adverse side effects. Second, it turns out that some networks
and some widely deployed network gear already do not forward IGMP
messages so widespread scanning and ultimately attacks, will presumably
never be able to travel along certain paths of the Internet.
According to our initial research, we believe at least tens of thousands of Internet routers as of this writing will respond to Ask Neighbors2 request messages. While many routers provide minimal responses, many will amplify the request with large or multiple responses, in some cases we have seen an amplification factor of over 100 to 1. While we have discovered numerous responders and have cataloged a number of interesting properties about many routers and responses we have seen, we have partnered with the good folks at The ICSI Networking and Security Group to perform more rigorous and detailed analysis of our findings. We hope to have a proper research paper related to this work appear soon. In the meantime, I’ll close with a few final technical details, how to go about mitigating the issue and a warm thank you to a couple of vendor security teams.
The two vendors that are most associated with support for IP multicast
routing are Cisco Systems, Inc. and Juniper
Networks. Both of these vendors have long
supported the DVMRP tracing and troubleshooting features in many of
their products. While this capability is not enabled by default, it
does not require DVMRP specifically to be activated. For instance, on
many Cisco products, simply enabling PIM (a more modern and common suite
of IP multicast routing protocols) on any interface will suffice.
Likewise on Juniper, PIM on an interface or enabling the igmp
protocols group globally will do. We are unfamiliar with other
implementations, but based on our experience with the Internet-enabled
IP multicast infrastructure, we suspect others will be relatively
uncommon.
Where Cisco and Juniper routers support and respond to DVMRP Ask Neighbors2 requests, there are some distinct behaviors they each exhibit. Cisco equipment will limit each IP datagram response to 576 bytes, but send as many messages as necessary to provide a complete list of interface detail. Cisco also encodes the major and minor IOS version numbers in the associated named fields in the DVMRP Neighbors2 response header. Juniper will fragment it’s responses. It is worth pointing out, that as a result of correspondence with both Cisco and Juniper, both vendors are in the process of deprecating and removing support for the DVMRP troubleshooting and tracing feature in future versions of their software.
Mitigation of this issue is relatively straightforward. Short of completely disabling any and all IP multicast capabilities, both Cisco and Juniper have provided simple configuration guidelines that should be easily applicable in practically all environments. For Cisco equipment, as documented in The Multicast Security Tool Kit, the following statements can be applied in global configuration mode (be sure to use an access-list number that works for you).
ip multicast mrinfo-filter 52
access-list 52 deny any
For Juniper networks, the following firewall filter to the loopback interface can be applied:
filter igmp {
term igmp_accept {
from {
destination-address {
224.0.0.0/4;
}
protocol igmp;
}
then accept;
}
term igmp_drop {
from {
protocol igmp;
}
then {
discard;
}
}
}
The configuration guidelines outlined above are those that are
recommended by Cisco and Juniper respectively. Both behave and operate
slightly differently and this difference should be noted by network
operators. A Juniper device will still respond to Ask Neighbors2
requests directed to a IP multicast group address, but will not forward
unicast-directed Ask Neighbors2 probes. The Cisco mrinfo-filter
directive prevents only the local router from responding to Ask
Neighbors2 requests, but may forward unicast-directed probes to other
networks and hosts. To limit unicast forwarding on a Cisco device, an
access-list on an interface could be used to mimc the behavior of the
Juniper filter:
interface FastEthernet 0/0
ip address 192.0.2.1 255.255.255.0
ip access-group 101 in
!
access-list 101 permit igmp any 224.0.0.0 15.255.255.255
access-list 101 deny igmp any any
Today, in the security track at NANOG 62 we present a brief talk entitled DVMRP Ask Neighbors2: an IGMP-based DDoS leak/threat, in coordination with bulletins released by both Cisco and Juniper. Let me end by expressing our gratitude and appreciation for a pleasant experience working with both Cisco PSIRT and Juniper SIRT. The representatives we worked with throughout the last year, as we made progress and plans to publicly discuss this threat, handled our concerns with the utmost professionalism and seriousness. We thank them for their cooperation and are happy to report both exhibited an ability to address the issue completely, discretely and in coordinated fashion.