Feeds

Boffins: Internet transit a vulnerability

Mirror, mirror on the port, is this something I can rort?

HP ProLiant Gen8: Integrated lifecycle automation

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.” ®

HP ProLiant Gen8: Integrated lifecycle automation

More from The Register

next story
Brit celebs' homes VANISH from Google's Street View
Tony Blair's digs now a Tone-y Blur
UK's emergency data slurp: IT giants panicked over 'legal uncertainty'
PM says rushed-through DRIP law will 'plug holes' in existing legislation
German government orders local CIA station chief to pack his bags
Sour Krauts arrest second local in domestic spy ring probe
Doctor Who season eight scripts leak online
BBC asks fans to EXTERMINATE copies before they materialise
Snowden leaks latest: NSA, FBI g-men spied on Muslim-American chiefs
US Navy veteran? Lawmaker? Academic? You're all POTENTIAL TERRORISTS
Russian MP fears US Secret Service cuffed his son for Snowden swap
Seleznev Jnr is 'prolific trafficker in stolen credit card data', it is alleged
Adobe Flash: The most INSECURE program on a UK user's PC
XML a weak spot, but nothing's as dire as Adobe player
Teensy card skimmers found in gullets of ATMs
Hi-tech fraudsters treading more softly, but gas still yielding bang for buck
Weaponised Flash flaw can pinch just about anything from anywhere
This is a 'patch now or regret it sooner-rather-than-later' mess for you and webmasters
prev story

Whitepapers

Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Eight steps to building an HP BladeSystem
Building your ideal BladeSystem infrastructure solution begins with eight simple steps, outlined in this whitepaper.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.
Build a Business Case: Developing Custom Apps
In this whitepaper learn how to maximize the value of custom applications by accelerating and simplifying their development.