Forgotten Protocol Chronicles: Do Not Underestimate the Installed Base
Table of Contents
by:
John Kristoff
As a long-time network operator, frequent infosec community participant, and now researcher I have often found myself drawn to the challenges of the installed base. All the attention in the tech industry is given to the latest software, protocols, hardware, and innovations. Meanwhile, yesterday’s deployments fade away at a snail’s pace and this is a problem.
When reading this write-up, I think it it will be fruitful to try to come up with answers to these basic questions:
- Who maintains and pays attention to these “legacy” technologies?
- What problems loom in these aging systems we are not dealing with?
- How does the community respond to problems that arise in unmaintained systems?
ISATAP Hijacking: Self-Inflicted MITM Waiting to Happen #
When it comes to legacy IPv6 transition technologies, many people are unaware that they are active and enabled on their systems. For example, ISATAP, an early Windows-based IPv4 to IPv6 transition protocol mechanism is there to help a system setup an IPv6 over IPv4 tunnel.
Furthermore, some of you might be surprised to learn that these systems are relaying or trying to relay a significant portion of traffic to IPv6 over IPv4 tunnel endpoints that are controlled by parties unknown. In other words, there exists a sizable number of self-inflicted MitM attacks waiting to happen.
We have studied the prevalence and persistence of legacy IPv6 transition mechanisms such as 6to4 and ISATAP in a paper entitled:
Through active and passive measurement, we highlighted the traffic capture and hijack risks that persist to this day. One experiment evaluated our ability to become the IPv6 tunnel entry point for ISATAP-enabled systems. ISATAP is a domain name-based transition mechanism and active by default on Microsoft Windows systems up until version 8.1.
What we discovered is that when there isn’t an existing usable IPv6 interface, the host will issue a DNS query with the prefix label “isatap” in its default domain.
For instance, if the default domain is example.org and we register the name isatap.example.org, we will be able to return an associated IPv6 tunnel endpoint address to clients. To test this out, we registered a number of isatap names in a number of domains, including many popular ccTLDs. The end result was that we suddenly and effectively became the first-hop IPv6 tunnel router for thousands of systems all over the Internet that queried our domain names.
The non-profit organization Dataplane.org, which I am a part of, now maintains these ISATAP domain names, sinkholing DNS queries and preventing them from being abused. The plot below shows that the total number of ISATAP queries per day is on the decline, but we still see thousands of queries per day. Last year alone we saw approximately a quarter of a million unique DNS resolvers query our name server for ISATAP names. We don’t know the precise number of end systems that would ultimately try to establish an ISATAP tunnel, but we assume it is still significant.
DVMRP AskNeighbors2: DDoS Potential and Information Leak Wrapped in a Neat Package #
- Are you familiar with IP multicast technology?
My guess is that very few readers will have little more than textbook knowledge. Moreover, I bet almost none of you even know what DVMRP is. DVMRP is a long abandoned IP multicast routing protocol that ran over IGMP. DVMRP AskNeighbors2 specifically was a debugging message for early IP multicast-enabled networks defined in an experimental IETF Internet Draft in 2003. The specification was never formally adopted into an IETF RFC. Even though DVMRP has been dead for a long time, that didn’t stop major router vendors from widely implementing support for this one debugging message in a lot of gear that persisted for years.
Well, as a result we ended up writing a paper about this one too entitled:
In the paper, we detail the potential problem and its impact on the Internet. In hindsight, IGMP should never have been allowed to leave the LAN, but this one experimental, widely deployed debugging mechanism, infrequently used but for a handful of IP multicast experts was now out of the bag. The problem with this protocol is that one simple request can result in multiple response packets. And sometimes the response can be a lot of response packets. If you thought DNS reflection and amplification attacks are bad, some of the largest AskNeighbors2 responders could reach an amplification factor of one million to one!
That isn’t all. The responses contain interesting information that an attacker might want to know. Most routers would return the version of software they were running and a list of IP multicast-enabled interfaces configured for example. For some routers, both bits of information could be quite revealing, leaking potentially sensitive operational information that is usually off-limits to anyone but the network administrators.
Stubborn Persistence and Forgotten Technology #
Widely deployed mechanisms such as ISATAP and AskNeighbors2 can graduate to legacy status relatively quickly, but the rate at which they are replaced, dismantled, and removed from service is often a long, slow slope that can take many years. I bet if I asked you to name a legacy system or protocol that should cease to exist, but persists, you’ve already thought of one. I would also wager that I can probably tell you about a legacy system or protocol running on the Internet that you didn’t know existed or have forgotten about. With each new generation of innovators brings great technology, but at the same time some of our history gets pushed further away from our operational consciousness. We need to occasionally wipe away the dust.
Outside of niche research efforts like my own, we must find ways to draw attention to the practice of retiring legacy systems in a formal, documented, and measured way. Until then, we’ll keep writing research papers reminding you of what you’ve forgotten about.