For 12 hours, Rostelecom was able to successfully take over Apple’s IPv4 routes. iX explains how this could happen and what helps against such attacks.
Successful hijacking of Apple’s address space: Between June 26 and 27, 2022, the Russian provider Rostelecom advertised IP prefixes via BGP for around 12 hours that actually belong to Apple’s IPv4 address space. Normally, Apple announces its address spaces via the autonomous system AS714. Russian provider Rostelecom issued a more specific announcement of AS12389, causing traffic for Apple services to that prefix to go through routers in Russia.
specific incident
On 07/26/2022 from about 21:25 UTC Rostelecom announced the prefix 17.70.96.0/19 via AS12389. However, this is part of the AS714 and Apple’s 17.0.0.0/8 prefix, with 17.0.0.0/9 normally being distributed by Apple. Since a more specific route (most-specific route; prefix length before other path attributes) is used before coarser routes for the forwarding decision in BGP routers, this IPv4 address block was routed via systems of the Russian provider. This was also noticed by BGP monitoring systems, such as Cisco’s BGPStream, which raised the alarm accordingly.
Since Apple does not validate its prefixes via Route Origin Authorization (ROA), the only option was to overwrite the incorrectly distributed prefix with even more specific prefixes. According to the MANRS initiative, the responsible BGP managers at Apple counteracted this with a more specific announcement. At around 02:41 UTC, more than five hours later, they announced the prefix 17.70.96.0/21. It was not until around 0939 that MANRS experts recognized that the incorrectly advertised prefix had been withdrawn.
It is currently still unclear which Apple services were specifically affected.
Protection against such attacks
This once again illustrates the need to protect BGP routing from hijacking attacks. This can be done via restrictive route filters based on the RIR databases at peerings or via source validation in BGP based on the Resource Public Key Infrastructure (RPKI) and Route Origin Authorization (ROA). Specifically, this attests that one or more autonomous systems are authorized to announce a specific IP prefix.
This is based on the well-known Public Key Infrastructure Framework X.509 of the ITU-T. In order to be able to map the known trust chains of PKIs, the same hierarchy is used as for IP address assignment. This means from the IANA as root, via the regional Internet Registries (RIR), to the local Internet Registries (LIR).
There are two options of RPKI usage: the Hosted RPKI or the Delegated RPKI. In the first variant, administration is carried out by the responsible RIR, in the case of Europe by RIPE NCC. In the second case, a local PKI is used by members of the RIPE NCC, for example larger organizations that are members or providers.
For each LIR there is the option of having the resources assigned to it certified on the basis of a certificate. This includes AS number and IP prefix. This certificate can then be used to generate route origin authorizations. These ROAs can be used to cryptographically check the announcements. The ROAs contain the authorized ASN, the IP prefix and the maximum length of the prefix. If the maximum prefix length is not specified, only the complete IP prefix can be announced. This provides the additional option of disallowing a more specific IP prefix, as was done in this case.
The SCION project represents an alternative to hedging, but it is still under development. Details can be found in the current iX 8/2022 and at voonze+.
(fo)
