China’s International Hacking Exploit

A quick not-so-technical bit about April 8, 2010. One of China’s smaller Internet providers tricked online traffic into flowing through China’s ISP system. Quite a few Federal/high-security computer networks also happened to be rerouted. If you didn’t know, traffic can be recorded and analyzed by ISPs. People are divided on whether it was an accident.

Now the technical bits:

During the hijacking of international Web traffic in 2010, China spoofed 37,000 fake IP addresses and routed a huge amount of traffic via a central Chinese backbone ISP. Notably, this was done via simple methods that almost any 3-rd tier ISP could perform. The issue is the BGP table, otherwise known as the Border Gateway Protocol. The BGP determines the routing paths for larger ISPs, which are mirrored with a number of like-sized ISPs, as well as ISP providers up and down the chain.

Methods to prevent BGP hijacking are complex. A simple, Symantec-style prevention would block all traffic from the hijacking ISP after the fact. This is essentially blackballing the offending ISP provider, whom would be unable to receive traffic from the blocker. While not practical for larger ISPs, this would be an effective deterrent to smaller ISPs.

Unfortunately, the hijacking ISP from China was a smaller ISP which spoofed its ISP addresses via the larger ISP, thus almost acting like a virus – injecting a payload and then gleaning from the effect, while riding on the massive strength of China’s backbone ISP. Even if the smaller ISP was banned from traffic, this would not prevent hijackings in the future.

Another, more complicated method would be to maintain a warning system within the IPv6 load sent from secure, trusted servers. This would act as a countermeasure or antibody, as the same mechanism that performs ISP hijacking would be used to prevent it. While the mathematics is beyond me, a modified algorithm could detect sudden switches in traffic either to a specific known ISP block (the block of blackballed ISPs mentioned in solution 1, for example), or via a sudden change in server distances where standard server routes should theoretically maintain a general range. While there are ways to defeat both of these measures (for example, penetrating and utilizing trusted servers to corrupt safety messages, or altering routes so that the required distance appears to match the known range), all three of these solutions could be implemented with various amounts of haste.

For further reference, see the article at Arbor Networks:

For a quick summary of the situation, see Computerworld’s article. Also details the political fallout from the debacle:

This entry was posted in Information Technology, The Cloud and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s