Russischer Provider kapert Apple-Adressraum

Für 12 Stunden konnte Rostelecom erfolgreich die IPv4-Routen von Apple übernehmen. iX erklärt, wie das geschehen konnte und was gegen solche Angriffe hilft.

In Pocket speichern vorlesen Druckansicht 105 Kommentare lesen

(Bild: Alberto Garcia Guillen/Shutterstock.com)

Lesezeit: 4 Min.
Von
  • Benjamin Pfister

Erfolgreiches Hijacking von Apples Adressraum: Der russische Provider Rostelecom annoncierte zwischen dem 26. und 27. Juni 2022 für zirka 12 Stunden IP-Präfixe über BGP, die eigentlich dem IPv4-Adressraum von Apple angehören. Im Normalfall announciert Apple seine Adressräume über das autonome System AS714. Der russische Provider Rostelecom gab ein spezifischeres Announcement vom AS12389 heraus, wodurch Datenverkehr für Apple-Dienste zu diesem Präfix über Router in Russland geführt wurde.

Am 26.07.2022 ab etwa 21:25 Uhr UTC announcte Rostelecom über das AS12389 das Präfix 17.70.96.0/19. Dieses ist jedoch Teil des AS714 und Apples Präfix 17.0.0.0/8, wobei im Normalfall 17.0.0.0/9 von Apple verteilt wird. Da eine spezifischere Route (most-specific route; Präfixlänge vor anderen Pfad Attributen) vor gröberen Routen für die Weiterleitungsentscheidung in BGP-Routern herangezogen wird, kam es also für diesen IPv4-Adressblock zu einem Routing über Systeme des russischen Providers. Dies bemerkten auch BGP-Monitoringsysteme, wie BGPStream von Cisco, die entsprechend Alarm schlugen.

Da Apple keine Validierung seiner Präfixe über Route Origin Authorization (ROA) einsetzt, gab es lediglich die Möglichkeit den fehlerhaft verteilten Präfix durch noch spezifischere Präfixe wieder zu überschreiben. Gemäß der Initiative MANRS steuerten die zuständigen BGP-Verantwortlichen bei Apple über ein spezifischeres Announcement gegen. Gegen 02:41 Uhr UTC, also über fünf Stunden später, announcten sie das Präfix 17.70.96.0/21. Erst gegen 09:39 Uhr erkannten Experten des MANRS die Zurückziehungen des fehlerhaft annoncierten Präfix.

Aktuell ist noch unklar, welche Dienste von Apple konkret betroffen waren.

Dies verdeutlicht einmal wieder die Notwendigkeit zur Absicherung des BGP-Routings vor Hijacking-Attacken. Dies kann über restriktive Routen-Filter auf Basis der RIR-Datenbanken an Peerings oder über eine Quellvalidierung im BGP auf Basis der Resource Public Key Infrastructure (RPKI) und Route Origin Authorization (ROA) geschehen. Konkret attestiert dies, dass ein oder mehrere autonome Systeme dazu legitimiert sind, ein bestimmtes IP-Präfix announcen zu dürfen.

Dies geschieht auf Basis des bekannten Public Key Infrastructure Frameworks X.509 der ITU-T. Um die bekannten Vertrauensketten von PKIs abbilden zu können, kommt die gleiche Hierarchie wie bei der IP-Adressvergabe zur Anwendung. Dies bedeutet von der IANA als Root, über die regionalen Internet-Registries (RIR), hin zu den lokalen Internet Registries (LIR).

Es bestehen zwei Optionen der RPKI-Nutzung: die Hosted RPKI oder die Delegated RPKI. Bei ersterer Variante erfolgt die Verwaltung bei der zuständigen RIR, im Fall von Europa durch RIPE NCC. Im zweiten Fall kommt eine lokale PKI beim Mitglied der RIPE NCC, zum Beispiel größeren Organisationen, welche Mitglied oder Provider sind, zum Einsatz.

Für jede LIR besteht die Möglichkeit, sich die ihr zugewiesenen Ressourcen auf Basis eines Zertifikats attestieren zu lassen. Hierzu zählen AS-Nummer und IP-Präfix. Über dieses Zertifikat lassen sich im Anschluss Route Origin Authorizations erzeugen. Mit diesen ROAs kann man die Announcements kryptografisch prüfen. Inhalt der ROAs sind das autorisierte ASN, das IP-Präfix und maximale Länge des Präfixes. Ohne Angabe der maximalen Präfixlänge kann lediglich das komplette IP-Präfix announciert werden. Dies bietet die zusätzliche Möglichkeit, ein spezifischeres IP-Präfix nicht zuzulassen, wie es in diesem Fall geschehen war.

Eine Alternative zur Absicherung stellt das SCION-Projekt dar, das sich jedoch noch in der Entwicklung befindet. Details hierzu finden sich in der aktuellen iX 8/2022 und bei heise+.

(fo)