
So much for the original intent of the ARPANET
Seems it might not be so robust in a time of war.
People's connections in the US to Google – including its cloud, YouTube, and other websites – were suddenly rerouted through Russia and into China in a textbook Border Gateway Protocol (BGP) hijack. That means folks in Texas, California, Ohio, and so on, firing up their browsers and software to connect to Google and its …
well it was only a test, and apparently a SUCCESS! [just not for Google and people in the U.S. trying to access their services]
If I'd have know, I would have polluted the snooping by making bizarre requests on google for things that would be extremely embarrassing to anyone looking at the data... [wait, was THAT a NAKED PICTURE of Henry Kissinger?]
/me laughs because in the 1970's, there was a parody Cosmo edition done by Harvard Lampoon, and the centerfold was, in fact, Henry Kissinger.
The original thinking for ARPANET did not include BGP. I believe that the alternative routing strategies were provided by static routing with routes preferences and hopcounts providing alternate pathing.
For some history, look up RIP, which was deployed sometime around 1969.
But RIP would never cope in today's massively complicated Internet. Since class-based routing broke down to allow re-use of the previously reserved network ranges that have been freed up to keep IP4 going, the routing tables that the core routers have to know are HUGE.
But considering how BGP hijacking has been known about for a long time, I'm surprised that it has taken this long for a key based trust system to be introduced.
@Ole Juul
The access control for these routers is as follows:
Do you work for (relevant ISP)?
Do you have the credentials?
That's it. Of course things are logged, but by the hooky ISP(s) in question.
The logs will be where they always are, somewhere google/law enforcement can't look, within a Chinese/Russian/African ISP.
> So...is there a solution? Some sort of key exchange to confirm the identity of core routers?
The main article links to this:
“Perhaps the most promising improvement to BGP comes from the Internet Engineering Task Force (IETF) in the form of BGPsec. Like DNSsec, BGPsec is an extension to BGP that introduces several new protections. Among them is Resource Public Key Infrastructure (RPKI), which will provide a way to associate Autonomous Systems with cryptographic certificates to maintain integrity.”
How does this work if the invalid routes are advertised by a valid ISP with valid keys? It appears to me that China Telecom is valid (?) just being naughty for whatever reason but *is* a valid carrier. Of course RPKI would prevent external actors fiddling with configurations without keys but is there any evidence that what is happening is external to these organisations?
So...is there a solution?
Yes. Filter YOU PEER'S BLOODY ROUTE ANNOUNCEMENTS!!!
Widely deployed in Europe. In fact, some Internet exchanges do not allow you to connect if you do not. I used to help maintain the software that generated the actual ACLs in a SP in one of my past lives.
USA - nobody does that despite repeated recurring and near identical incidents going as far back as the late 1990es. In fact, the first incident I remember was in 1997 (or was that 1996) when some mom-and-pop ISP playing with gated codebase in a shed in Florida brought most of the USA internet down for a couple of hours.
The incidents goes to show that a USA telco like ATT, VZ, etc (the ones which Google "peers" with) will accept anything China telecom feeds them and say "thank you, with pleasure".
Damn, that sounds so simple. I wonder why US telcos don't give a damn like that ?
Because it's not that simple.
As I mentioned just the other day, AS routing is a big, complicated problem, which many experts have been examining for many years. (Bellovin's original paper on the subject was published in 1989.) "Drop all BGP announcements from your peers" isn't a good strategy when you may need to adopt changes published by other ASes.
There are a bunch of mechanisms (prefix lists, communities, etc) for filtering BGP, and they're widely used. They can't solve the general problem. In fact, the 2008 Pilosolv & Kapela attack (which introduced BGP interception to the public) uses filtering as a critical component - they construct prefixes so that the victim AS will forward traffic to their AS, while some other ASes retain the original, valid route, so they can forward it on.
Now, it's true that Kapela claimed at the time that "aggressive filtering" by ISPs could prevent BGP hijacking. But he was talking specifically about certain classes of attacks; the filtering would be expensive and require frequent maintenance; and all ASes on the path (for a given packet) would have to implement it for it to be secure.
If there were an easy, inexpensive fix for BGP hijacking, it would already have been implemented.
The incidents goes to show that a USA telco like ATT, VZ, etc (the ones which Google "peers" with) will accept anything China telecom feeds them and say "thank you, with pleasure".
I believe the phrase you are looking for is "Thank you sir, may I have another?"
https://youtu.be/bIZoVO8ZyyQ
"Unlikely but you can contact them about this. I've done it before"
You are assuming that I want to actually be able to understand the Russian adverts that Google shows to me, when I'm not using ad blockers, and VPNing through my Dutch server. If I'm forced to send more information about me to Google than I normally do, then I'm more than happy for them to get incorrect information.
And the great digital transformation drive has turned this into critical infrastructure.
Because it was easier to do that than to build on the secure trusted protocols built into OSI. Remember those arguments, why use closed OSI protocols dictated by telcos, when we can all use the open, public IP stack that's freely available to the whole world?
This is why. Too late.
Maybe time for anybody who messes with BGP, to be isolated from the rest of the network and force all their traffic through a dedicated gateway. Yes hard luck on for arguments sake China/USA/Russia/UK/Iran/India citizens, as it would enable even easier snooping, but the rest of the world would be more secure.
It's much worse than that. Gsuite is used by UK Central Governent departments as well. I have never understood why. It's bad enough that Google knows all about your private email, it now also has full access to some HMG mail, documents, Hangouts discussions etc. FFS why give that kind of advantage to a US commercial company?
Back in the day when I ran Gov IT systems we insisted the data was all on local boxes we could actually touch. GSI (version 1) changed some of that by moving mail through a commercial (but UK based) system. Later versions further watered down the local storage and processing paradigm. We now seem to be so enamoured of all the "cloud" bollocks that we are prepared to give away most of the crown jewels.
Face palm for obvious reasons.
And to add to my last comment. If the docs end up in Russia or China, that council is technically in breach of GDPR. Fun.
Not to mention that to manage GSuite at the commandline you need to use a tool called GAM. It is one big security hole.
GAM creates a custom key for the admin that set it up on their device. If someone then was able to steal the folder they have "installed" GAM in, they can then run all the admin commands as that admin account with no further authenticated required, even if those commands are now being run from a totally different IP range that they were being run from 5 minutes ago.
they can then run all the admin commands as that admin account with no further authenticated required, even if those commands are now being run from a totally different IP range that they were being run from 5 minutes ago.
Wait, google can do that?
Then why the hell do I get 'security warnings' when I sign in from the same machine with the same IP and the same hardware etc etc as I did 2 minutes ago???????
"Then why the hell do I get 'security warnings' when I sign in from the same machine with the same IP and the same hardware etc etc as I did 2 minutes ago???????"
Perhaps for the same reason I do? Coz I'm using insecure protocols, with non trusted programs. Like fetchmail using SSL and POP3 to fetch my email. Waaay less secure than HTTPS, and much less trusted than Google Chrome. Though apparently it's only insecure once every few months, rather than the once a minute it actually polls at.
Today, if you try to buy transit, you will be asked to ensure you have route objects and / or AS-SET's registered with the likes of RIPE/ARIN or RADB or manually submit prefixes. This is generally quite good. The issue comes where someone more than one AS hop away starts slipping in routes which contain AS4134 (China Telecom) in the path, which the filtering may not catch.
The issue with RPKI signing all routes is that apart from the circularity of depending on a network to authorise your acceptance of network routes, is that it transforms the internet into a strictly hierarchical structure. Someone could decide to lean on RIPE or whomever and get you knocked off the net: temporarily of course until you got a new block, but it's something to bear in mind.
""We will conduct an internal investigation of this issue and make appropriate improvements to our systems to help prevent or minimize future recurrence."
I'd actually like to see it happen more often please. So often Google ceases to exist would be nice.
Google, want to improve your systems in a way that is helpful to people? Turn your servers off, and some public meetings with your higher ups would be cool - I know a great venue in that dark alley over there.
Failing that, at least stop being evil. Stop the spying, stop the privacy invasions. No, scratch that. Just stop.
The fine article does not - as far as I could see - mention a couple of rather important facts.
1. Were users actually prevented from connecting to Google, etc.? Or did they manage to connect and use the sites normally - just by a circuitous route?
2. The article speaks of "theft" and suggests that packets were "stolen". Again, that implies that the packets were never delivered to the intended destinations. True or false?
1. Yes. Users were prevented from contacting Google's servers. (at least, I was)
2. if you read the rest of the article, it says that the Chinese server black-holed the packets at least for some of the time, and so, Yes, the other packets were arguably stolen, but who knows if anything was able to inspect them.
...it was MainOne in Africa - https://www.bbc.co.uk/news/technology-46194279
The following is a joke... of course... to the tune of, "Blame Canada"
----
Time's have changed
The Internet's getting worse
They won't obey the IETF
...and go to V6 instead
Should we blame the government?
Or blame society?
Or blame the traffic of Internet TV?
No, blame Africa, blame Africa
Their update was a surprise.
They re-routed all our files.
Blame Africa, blame Africa
We need to form a full assault
It's Africa's fault
----
Don't blame my poor old router
It saw the wrongest route
And now it's off to China and Japan.
And Russia's on the path
My files have gone "Прощай"
And buggered off to the East instead of West
Well, blame Afria, blame Africa
Something technical went wrong
When Africa came along
Blame Africa, blame Africa
They're not even between me and L.A.
My data could have been a movie, or a best selling book.
Now it's down a black hole, come and look.
Should we blame the fibre?
Should we blame the light?
Or the technicans who buggered it up last night?
Heck no
---
Blame Africa, blame Africa
'Cause of MainOne's hullabaloo
They lost all your traffic too
Blame Africa, shame on Africa
All the smut got lost, the traffic all got crossed
All this routing mess must be undone
We must blame them and cause a fuss
Before someone thinks of blaming us
Hi
To put some perspective on this, BGP configurations are complex and a small error can have a wide effect. Like throwing a pebble into a pond.
If you put hard filtering on BGP broadcasts from adjacent ISP, then you will loose the flexibility of BGP/dynamic routing to define the best routes through the Internet and larger outages could occur.
I know ow easy it is to make an error, as I accidentally put a /16 mask on what should have been a /28 network and took out all that ISP's monitoring systems. That was noticed straight away and the outage was only a few minutes for the operations centre.
I would consider human error first, before looking at melovance........
A network engineer
Russia has figured out the pattern in large Prime Numbers:
https://motherboard.vice.com/en_us/article/pa8dw8/prime-number-pattern-mimics-crystal-patterns
...and they have all your passwords is belong to us now.
Both UK and US have been re-routing Internet traffic for decades in order to spy on their citizens, so it's a bit hypocritical to get all upset when someone else follows suit. (There is no technical reason for your Internet data to get routed to Menwith Hill).
In any case, if this was really deliberate (and it may well not have been), then it was simply a denial of service attack rather than a spying mission because it stopped any TCP connection being made, and no data is sent unless and until the TCP handshake has completed. Had there been servers in Russia, China or Nigeria accepting the connection requests and pretending to be Google, then it would have been far more sinister.
World War Three will not be televised. Or browsed, apparently.
As I read the article, for some reason that Monty Python/Terry Gilliam "bit" with the German fish being eaten by the Japanese fish, which in turn was eaten by the British fish was running in Mr Brain.
I may have the order of fish wrong, because the nationalities don't matter in the analogy.
All our cat pix are belong to bad actors at the state level t'would seem. Then again, given the three-letter agency oversight it turns out *isn't* just a paranoid fantasy, that's been the case since, well, forever.
"
So basically people are complaining that traffic destined for Google may be stored, analysed and used for nefarious purposes by someone other than Google?
"
Ignorant people may be complaining about that, but that was not what happened. The only significant traffic that was mis-routed would have been SYN (connect) attempts, which went unanswered. Whatever request or data the person trying to contact Google may have intended to send would thus have not been sent. To anywhere. So the only data that would have been obtained was the fact that a connection request was made to Google from a particular IP address at a particular time for an unknown purpose - hardly something that is likely to be of any concern.
Possibly there was a bit of UDP data that got through (UDP does not require a connection be established before sending the payload - often used for live streaming video or audio for example), but in almost all cases there would be some sort of 2-way handshake before streaming the data over a UDP connection, so really no risk that Internet calls were being intercepted.
A little known fact, but the creator of colosal cave - adventure, also worked on the distributed distance vector routing system used in RGP and later BGP.
You are in a twisty little maze of routings, all different.
https://en.wikipedia.org/wiki/William_Crowther_(programmer)
http://rickadams.org/adventure/
Max K.
People's connections in the US to Google – including its cloud, YouTube, and other websites – were suddenly rerouted through Russia and into China in a textbook Border Gateway Protocol (BGP) hijack.
I was wondering why Google's system performance seemed much better on Monday...