Supercharge your infrastructure

If you think of an Internet exchange, you probably think of infrastructure that's well-protected, well-managed, and hard to compromise. The reality, however, might be different. According to research by Stanford University's Daniel Kharitonov, working with TraceVector's Oscar Ibatullin, there are enough vulnerabilities in routers and the like that the Internet exchange makes a target that's both attractive and exploitable.

The attack they demonstrate in this paper on Arxiv can be mounted against common routers and switches, and “does not require extraordinary knowledge of networks or specialized programming skills.”

As they say in the abstract, “modern network platforms are capable of targeted traffic replication and redirection for online and offline analysis and modification, which can be a threat far greater than loss of service or other risks frequently associated with such exploits.”

So how did Kharitonov and Ibatullin work their black magic?

They start by assuming that an attacker is aware of a remote code execution vulnerability on a switch or router in an Internet exchange. This isn't such a stretch of the imagination, since patches roll around on a regular basis. The second, more arcane challenge is to exploit remote access to the kit to perform analysis or modification of traffic passing through the (say) router.

As they write, “the main challenge is to deliver the “interesting” traffic to them in a manner that does not disrupt data flow and allows the eavesdropped connection to continue”.

Which is easy enough if you have command access to the network devices. Switches and routers can be configured to redirect incoming traffic briefly with the following steps:

• Capture “interesting” traffic at the ingress interface into a captive filter;
• Flick that traffic (using filter-based forwarding or policy-based routing) to the attacker's analysis engine (referred to in the paper as the “aid host”):
• Return the traffic with source and destination addresses unmodified.

Note that with the exception of the “aid host”, this is merely exploiting features of routers, with the sole exception that a remote code execution flaw has to exist. However, there's a drawback:

“For one thing, if the remote aid host resides in (or behind) a network that supports source checking via filter or a reverse path forwarding (RPF) feature, this renders direct flow from IP2 to IP1 using IP0 as source impossible. If this happens, an attacker will have to establish an aid host in the same network where the source or destination of traffic resides.”

More effective, the researchers suggest, is to use traffic replication features that already exist in devices. The people who designed port mirrors envisaged that they should be protected against malicious exploitation, so they generally constrain where mirrored traffic should be sent – but with control of enough vulnerable routers, this can be defeated.

“If an attacker controls routers R1, R2, and R3, an FBF [filter-based forwarding – The Register] entry for incoming packets from IP0 to IP1 can be matched to a next hop toward S1 with hardcoded multicast media access control (MAC) as a destination address. This will force S1 to replicate the packet on all ports (a normal behavior for unknown multicast groups). Routers R2 and R3 will both receive the packet; R2 will forward it as usual; and R3 will send it into a tunnel towards IP2 [a machine controlled by the attacker – El Reg] via FBF entry.”

This involves more kit, the researchers note, but also has a greater chance of success.

Other roadblocks in the way of the attacker exist, but aren't insurmountable: a potential attacker would need to gain access to vendors' SDKs, or would have to reverse engineer communication pipes, and would have to work out how to program the kit with “ephemeral” state changes that won't show up in its configuration logs. “This task is much less complex than it sounds, because the initial analysis is easy to do on a test system by simply tracking the logs and messages of processes handling a routine PBR or FBF configuration change.” ®

5 ways to reduce advertising network latency