BGPmon's blog analyzes BGP routing incidents such as route leaks, hijacks, and internet outages.
HN commenters cite it as an overview of BGP hijacks, noting that hijacks capture traffic quietly and can be worse combined with SSL/CA problems.
I've asked around the company and unfortunately I can't talk about attacks (and/or suspicious "configuration errors") we've detected. There are legal issues involved, plus some of these cases are currently being investigated by law enforcement. Moreover, I don't know of any other company or person that deals with such attacks, so I have no one to quote. The only thing I can do is to offer some hand waving:
1. It's known publicly that nation states as well as criminal organizations are deflecting Internet routes. There are numerous reports of such cases; these cases aren't that hard to find since BGP information is (mostly) public.
A few published examples:
- Russian network "Rostelecom" hijacks sites of financial services: https://arstechnica.com/information-technology/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/
- Global Large scale BGP hijacks in 2013, some through "Rostelecom": https://arstechnica.com/information-technology/2013/11/repeated-attacks-hijack-huge-chunks-of-internet-traffic-researchers-warn/
- Spammers use BGP to announce fake IP addresses to spam yahoo mail users: https://ripe72.ripe.net/presentations/45-Invisible_Hijacking.pdf
- Traffic to UK organization that deals with nuclear weapons hijacked using BGP to the Ukraine: http://hub.dyn.com/dyn-research/uk-traffic-diverted-through-ukraine
- BGP hijack of bitcoin miners: https://bgpmon.net/the-canadian-bitcoin-hijack/
- "Hacking Team" (Italian company selling spyware…
Meh... "By default your neighbor just believes you, and doesn't have a really reliable way to tell if you are actually telling the truth" - while this is not 100% true with regard to most peering configurations via tier 1 carriers, there is a slight nugget of truth here. You can't just order a circuit from AT&T/Verizon/Sprint and inject whatever you want. First you have to have an AS assigned to you (if you're to have the ability to announce anyway) and then beyond that it's generally a process of negotiating sane terms of what you're presenting to them and what they're presenting to you (generally as the customer you want the entire table, but there are exceptions). At that point the config on the far end will mimic what was agreed upon (prefixes advertised and general length protections such that you don't spam out thousands of /30s from your transport or something horrid like that). While there is no way to truly validate the authenticity of the update - there is generally a decent chain of custody.
BGP is a great playground for injection research. The best part is via looking glass sites it's very trivial to target specific, and core, platforms.
That being said... Regardless of BGP itself beyond certificate validation and pinning we should also be doing path checking. I mentioned this to Moxie for a potential addition into Convergence, and from the page:
"Convergence trust notaries use network perspective to validate your communication by default, but can be…
Network geek here:
> Many are the tales of some small company misconfiguring their edge routers slightly (say a 1 char typo) and having the entire internet route through their T1, across their lan, out their backup T1.
This is what route filters are for. If you peer with someone and they advertise 0.0.0.0/0 or something equally ridiculous, and you accept this as a valid route then you deserve to fail (and then given a firm stare if you then proceed to advertise it to other peers).
A similar fail on the part of Telstra (http://bgpmon.net/blog/?p=554) was to blame for much of Australia dropping off the map earlier this year.
Also:
> Just at the IP level they have to deal with (at the edges and across substantial WANS) BGP - a notoriously ugly and fragile protocol.
I take offence at this. 80% of BGP related issues are due to misconfiguration by a given party, 19% is due to bad or missing route filters and the other 1% is due to bugs in router software. The actual implementation of BGP v4, originally designed back in the early 90's isn't completely without it's issues and behavioural quirks (I'm looking at you, route flaps) but the theory/algorithm behind is a work of art, and has coped amazingly with explosive growth, and growth that's only going to increase with IPv6.
Without it, there would be no HN
Renesys has written about this twice with more facts and less speculation: http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml, http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml
The gist of things it that the mainland Chinese network operators allowed the anycasted routes for the I-root in China to leak outside of their networks and into the global BGP routing table. If you made a DNS request to the I-root during that leak, and the best route to the I-root prefix was the leaking route from China, then your DNS traffic went through the great firewall and was altered accordingly.
Finally, I want to give the article the benefit of the doubt with regard to this:
And he said he believes there were more instances of Web traffic
being diverted to China, or "hijacked," around that time, but
wouldn't elaborate. "I believe it happened more than twice,"
Joffe said. "I can't comment on how many times because the
information is not generally public."
but many views of the BGP routing table are public (http://routeviews.org) and/or fairly well monitored for hijackings, etc. by network operators and others like Renesys and BGPMon (http://bgpmon.net/). Unless this is occurring only within China's regional networks, I expect we would've heard something about this already.
Two relics that haven't (and couldn't have) scaled past the late-90s magnitude of the Internet, and yet we're still with them:
TLS: CAs. TLS/SSL is largely "security on the internet", and any of thousands of CAs could sign a cert for any of our websites. Very few exceptions apply here - to protect against this, you effectively need to be on the client (see certificate pinning on chrome). We need something like TACK[1] here. The current state of the TLS CA system is very convenient for malicious actors of any size.
Routing: BGP is an overly trusting protocol[2]. Any of thousands of ASN can advertise a route and its peers will happily chug that traffic along to it. This would allow, for instance, a Pakistani ISP "taking over" YouTube, or more recently, Indosat trying to take over the Internet[3].
There's many things that would be "nice-to-have" fixes, but these two are pretty urgent in my opinion. They were designed for a much friendlier Internet.
[1] https://tack.io/
[2] http://security.stackexchange.com/questions/56069/what-security-mechanisms-are-used-in-bgp-and-why-do-they-fail
[3] http://www.bgpmon.net/hijack-event-today-by-indosat/
> Smallpox is inherently dangerous.
I think the equivalent (or much worse, actually) for exploits is something that is self replicating and disruptive. For example, a bug in the BGP routing protocol (or a certain percentage of the common implementations) that propagates bogus routes and disrupts some or all traffic for affected systems and spreads. Something that disrupted a large enough chunk of global traffic would not only be horrendous in its own right, but would also make dissemination of any fix quite problematic.
Then again, I assume it's probably good practice to somewhat lock down how BGP functions in your routers (if that makes sense. I'm not that familiar with it), but a certain incident from last year[1] leads me to believe that's either not possible, hard to do, or people just don't do it.
1: http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/