In effect, Snow had weaponized this protection to create a denial of service for Orange subscribers.
Madory wrote:
As demonstrated in our earlier analysis, the internet’s RPKI ROV deployment has reached the point where the propagation of a route is cut in half or more when evaluated as RPKI-invalid. Normally this is desired behavior, but when an RPKI config is intentionally loaded with misconfigured data, it can render address space unreachable, effectively becoming a tool for denial of service.
Graph showing 40-50% drop in traffic from 14:20 to 18:00 UTC
Credit:
Kentik
Graph showing 40-50% drop in traffic from 14:20 to 18:00 UTC
Credit:
Kentik
Using Kentik’s aggregate NetFlow, we observed the outage (illustrated above) as a large drop of the volume of inbound traffic to Orange España (AS12479) between 14:20 UTC (3:20pm local) and 18:00 UTC (7pm local). However, there were more developments prior to this window of time as well as some lingering effects, which we will dig into in the post below.
After regaining control of its RIPE account, Orange restored service by publishing the proper ROAs. Madory said, however, that many of the bogus origins remain published. “It’s not causing any problems because they published legit ones with the correct origin, but they should just revoke these: https://rpki-validator.ripe.net/ui/149.74.0.0%2F16?validate-bgp=true.”
Snow’s unfocused and, at times, ineffective tinkering with the Orange routes makes the ultimate objective of the hijacking unclear. The party initially published ROAs that had little or no effect at all. Even when Snow published more destructive ROAs starting at 14:00 UTC, the effect was more limited than it could have been, since it deleted roughly 20 percent of the Orange’s 9,200 routes.
Going “nuclear”
Madory wrote:
I suspect, at first, the person was just seeing what they could do in the account. Maybe they assumed that it might be monitored and they would get kicked out after doing some innocuous things. But over time they got more daring until they decided to cause a major outage to get the provider’s attention about their poor security practices. I don’t think the objective was solely to cause an outage, but I’m really just speculating.
It seems, at first, this person was just seeing what they could do without causing harm. Then [they] tried changing the origins of a few routes [to see if it] could potentially cause a little disruption. Then at 14:20, they went nuclear with the two /12’s ROAs.
Besides underscoring the continued fragility of BGP, the incident exposes a concerning lack of security hygiene at Orange. For one, an infostealer installed on an employee’s computer that went undetected for four months. For another: the use of a weak password and the failure to secure the account with multi-factor authentication to protect an account on a Regional Internet Registry such as RIPE. All are amateur omissions that should never have been possible at an organization with Orange’s reach. Also troubling: Madory said that until Wednesday, the Orange RIPE account was never configured to track the creation of new ROAs, a lapse that made route announcements harder to track.
