Feeds

Boffins: Internet transit a vulnerability

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

The essential guide to IT transformation

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

Next gen security for virtualised datacentres

More from The Register

next story
e-Borders fiasco: Brits stung for £224m after US IT giant sues UK govt
Defeat to Raytheon branded 'catastrophic result'
Snowden on NSA's MonsterMind TERROR: It may trigger cyberwar
Plus: Syria's internet going down? That was a US cock-up
Who needs hackers? 'Password1' opens a third of all biz doors
GPU-powered pen test yields more bad news about defences and passwords
Think crypto hides you from spooks on Facebook? THINK AGAIN
Traffic fingerprints reveal all, say boffins
Rupert Murdoch says Google is worse than the NSA
Mr Burns vs. The Chocolate Factory, round three!
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Germany 'accidentally' snooped on John Kerry and Hillary Clinton
Dragnet surveillance picks up EVERYTHING, USA, m'kay?
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.