Today I woke up with a Telstra's ProtonMail Hijack news. In fact, one of my Linkedin connections, friend, sent me the ITNews post about the incident. When I saw it, obviously it was Hijack, not Route Leak or other type of attacks but, the post was not explaining any technical detail, what kind of attack it was, can it be prevented somehow ,etc. Thus, I wanted to mention briefly about those points, explaining technically, while trying to keep it understandable. By the way, BGP Security and many other topics about BGP was covered in my week long BGP Zero to Hero course.
If you are technical person, don't miss it!. Before I start explaining this incident, I should mention that, this incident was totally different than recent Century Link caused outage. In Century Link case, issue was their routing policy. In fact, carrying security policy over routing (I know sounds complex, thus I won't mention, lack of feedback loop with Flowspec, RFC 5575). Okay, what happened with Telstra's Hijack?
Swiss email provider ProtonMail shared a tweet that Telstra was announcing its 185.70.40.0/24. This subnet belongs to ProtonMail and Telstra announcing it as the subnet belongs to them. When you announce someone else's prefixes as if it belongs to your network, it is called 'Hijack'. Result might be packet loss, stolen money/information, delay/latency in the traffic, spam emails etc.
There are two types of Hijack overall.(There are much more than this but would be so advanced for this post). Exact prefix hijack and sub-prefix hijack.Telstra's hijack was exact prefix hijack and it is less dangerous than sub-prefix hijack. Let me explain what is exact prefix hijack and sub-prefix hijack: When you announce /24 and someone else announces your subnet with exact same prefix length then it is exact prefix hijack. But if someone advertises more specific prefix length, for example actual subnet owner announces /22 but someone else announces that subnet as /24, then this is considered sub-prefix hijack and routing prefers more specific prefix length due to longest match routing.
In Telstra's case, BGP, Inter-domain routing would decide for the networks, whether Telstra or ProtonMail is the correct owner, unless they implement filtering. So, from the AS-Path length point of view, if Telstra's announcement is shorter AS-Path length than ProtonMail, then I will send traffic to Telstra, though in this case, traffic eventually reached to ProtonMail. Traffic only got delayed because Telstra had a path and their networks have enough capacity to route mis-redirected traffic. Could this incident be prevented. Yes of course, there are couple techniques for this.
Namely, IRR and RPKI. I discussed both of these techniques in this video. Both IRR and RPKI are Origin Validation mechanism, not BGP Path validation but as long as attackers are not announcing as if they are connected to real-origin, IRR and RPKI can stop Hijacks. Thus, you don't need BGP Path Validation and Telstra's this incident, could be prevented with proper IRR Route Object or RPKI ROA creation and validation.
Response to ProtonMail's tweets, I saw two replies. I want to share something about those/ First to Andrew, hope this post helps for clarification, if not, let me know, I can record a video and share it on my Youtube channel.
As you can see, a Twitter user NewMediaGhost says, ' I thought @ProtonMail was the safest email source '. With this incident, there is no problem with the integrity, confidentiality , even availability of the traffic. So, from the security point off view, there is no problem.
Also, on Internet, anyone can announce your prefix , anytime, you can't stop it. BGP is trust based routing protocol. In this case, even though Telstra didn't hijack those prefixes intentionally, misconfiguration still can cause issues for your network!. People can announce whatever they want, but will you accept their announcement? Then, RPKI deployment should increase and we should find deployable BGP Path validation mechanism than BGPSEC protocol. So, ProtonMail continues to be safe , I am not sure if they are safest, email provider.