Russian vendor hijacks Apple’s address space | hot online

Successful hijacking of Apple’s address space: On June 26-27, 2022, the Russian provider Rostelecom advertised IP prefixes via BGP for approximately 12 hours that actually belong to Apple’s IPv4 address space. Typically, Apple advertises its address spaces through the autonomous system AS714. Russian provider Rostelecom issued a more specific announcement of AS12389, causing traffic from Apple services to that prefix to go through routers in Russia.

specific incident

On 07/26/2022, at approximately 21:25 UTC, Rostelecom announced the prefix 17.70.96.0/19 via AS12389. However, this is part of AS714 and Apple’s 17.0.0.0/8 prefix, with 17.0.0.0/9 typically distributed by Apple. Since more specific route (more specific route; prefix length before other route attributes) is used before coarser routes for forwarding decision in BGP routers, this block of IPv4 addresses was routed through systems from the Russian supplier. This was also noted by BGP monitoring systems, such as Cisco BGP Flowwho sounded the alarm accordingly.

Since Apple does not validate its prefixes through 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 managers responsible for BGP at Apple countered 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 not yet clear which Apple services were specifically affected.

Protection against these types of attacks

This once again illustrates the need to protect BGP routing from hijacking attacks. This can be done through restrictive route filters based on the RIR databases on interconnects or through source validation in BGP based on Resource Public Key Infrastructure (RPKI) and Route Origin Authorization (ROA). ). Specifically, this attests that one or more autonomous systems are authorized to advertise a specific IP prefix.

This is based on the well-known ITU-T X.509 Public Key Infrastructure Framework. In order to map known PKI chains of trust, the same hierarchy is used as for IP address assignment. This means from the IANA as root, through the Regional Internet Registries (RIRs), to the Local Internet Registries (LIRs).

There are two options for using RPKI: hosted RPKI or delegated RPKI. In the first variant, the administration is carried out by the responsible RIR, in the case of Europe by the RIPE NCC. In the second case, RIPE NCC members, for example larger member organizations or vendors, use a local PKI.

For each LIR there is the option of certifying the resources assigned to it based on a certificate. This includes the AS number and IP prefix. This certificate can be used to generate route origin authorizations. These ROAs can be used to cryptographically verify the ads. The ROAs contain the authorized ASN, the IP prefix, and the maximum prefix length. If the maximum prefix length is not specified, only the full IP prefix can be advertised. 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 coverage, but it is still under development. Details can be found in the current iX 8/2022 and on heise+.

(fo)