BGP hijacking

BGP hijacking to rozgłoszenie w internecie fałszywych tras do cudzych zakresów adresów IP, przez co ruch kierowany do ofiary trafia do infrastruktury napastnika albo przez nią przechodzi. Atak wykorzystuje protokół BGP, którym sieci operatorów, zwane systemami autonomicznymi (AS), wymieniają informacje o osiągalności adresów ^[1]. Specyfikacja BGP-4 nie przewiduje mechanizmu, który sprawdzałby, czy sieć ogłaszająca zakres adresów ma do niego prawo ^[1]. NIST wymienia przejmowanie prefiksów BGP i wycieki tras wśród anomalii, które prowadziły do odmowy usługi (DoS) ^[3].

Jak działa

Każdy system autonomiczny ogłasza sąsiadom zakresy adresów (prefiksy), które obsługuje, a ci przekazują ogłoszenia dalej. Router wybiera trasę do celu na podstawie otrzymanych ogłoszeń. Gdy dla tego samego adresu istnieje kilka tras, wygrywa ta z najdłuższym, czyli najbardziej szczegółowym, prefiksem ^[4]. Napastnik, który kontroluje router brzegowy albo cały AS, może więc ogłosić cudzy zakres albo jego węższą część i przyciągnąć ruch. Schemat poniżej pokazuje przebieg.

RYS. 1Przejęcie trasy BGP

Protokół opiera się na połączeniach TCP między sąsiadami. RFC 4271 wskazuje uwierzytelnianie TCP MD5 jako opcjonalną ochronę samej sesji ^[1], ale taka ochrona nie mówi nic o prawdziwości treści ogłoszeń.

Odmiany

Przejęcie nie zawsze jest atakiem. Część incydentów wynika z pomyłki w konfiguracji, a skutek dla ofiary bywa ten sam.

W WordPressie

Właściciel strony WordPress nie konfiguruje BGP, ale jego witryna zależy od tras do trzech miejsc: serwera hostingu, serwerów DNS domeny i serwerów, z którymi łączy się strona. Przejęcie trasy do serwerów DNS pozwala podmienić odpowiedzi DNS bez włamania do rejestratora, co przypomina przejęcie DNS. Przejęcie trasy do samego serwera kieruje odwiedzających i administratorów na infrastrukturę napastnika.

Ostatnią przeszkodą jest wtedy szyfrowanie TLS. Napastnik bez ważnego certyfikatu dla domeny wywołuje ostrzeżenie w przeglądarce. W 2018 roku fałszywe serwery przedstawiały certyfikat podpisany przez nieznany urząd, a napastnicy mimo to zdobyli dane logowania części użytkowników ^[5]. W 2022 roku napastnicy przed atakiem uzyskali certyfikat TLS dla atakowanej subdomeny w urzędzie GoGetSSL ^[6]. Dlatego ważne są HSTS (HTTP Strict Transport Security), który utrudnia zaakceptowanie błędnego certyfikatu, oraz monitorowanie wydanych certyfikatów w urzędach certyfikacji. Logowanie do panelu z uwierzytelnianiem wieloskładnikowym zmniejsza wartość przechwyconego hasła.

Zagrożenia i skutki

• Niedostępność. Ruch trafia w próżnię i usługa znika z sieci, co z punktu widzenia ofiary przypomina atak odmowy usługi (DoS).
• Podsłuch i podmiana. Ruch przechodzi przez sieć napastnika, który może go czytać, jeśli nie jest szyfrowany.
• Przejęcie DNS i kradzież danych logowania. Przez sfałszowane odpowiedzi DNS ofiara trafia na podrobioną stronę.
• Wysyłka spamu i ukrywanie ataków z cudzych adresów IP.

Jak się bronić

Podstawą jest RPKI, infrastruktura klucza publicznego dla zasobów internetowych opisana w RFC 6480 z lutego 2012 roku ^[2]. Posiadacz zakresu adresów podpisuje obiekt ROA, który wskazuje, jakie systemy autonomiczne mogą ogłaszać jego prefiksy ^[2]. Operatorzy sprawdzają ogłoszenia z ROA i odrzucają niezgodne. RFC 6480 zaznacza, że mechanizm weryfikuje pochodzenie trasy, a nie całą ścieżkę ^[2]; walidacji ścieżki służy BGPsec, który NIST omawia razem z walidacją pochodzenia ^[3].

Właściciel strony może:

1. Wybierać hosting i dostawcę DNS, którzy publikują ROA dla swoich adresów.
2. Włączyć HSTS (HTTP Strict Transport Security) i dbać o poprawny certyfikat SSL/TLS, żeby przejęty ruch kończył się błędem, a nie podrobioną stroną.
3. Włączyć DNSSEC dla domeny, który chroni integralność odpowiedzi DNS.
4. Monitorować dostępność strony z kilku sieci, bo przejęcie bywa widoczne tylko w części internetu ^[5].

Historia i przykłady

YouTube, 2008. 24 lutego 2008 roku o 18:47 UTC Pakistan Telecom (AS17557) zaczął ogłaszać prefiks 208.65.153.0/24 należący do YouTube (AS36561) ^[4]. YouTube odpowiedział ogłoszeniem dwóch jeszcze węższych prefiksów /25, które wygrały dzięki regule najdłuższego dopasowania ^[4]. Fałszywa trasa zniknęła o 21:01 UTC, po wycofaniu jej przez operatora nadrzędnego ^[4].

Spamhaus, 2013. Niebezpiecznik 30 marca 2013 roku opisał, że atak na Spamhaus był nie tylko DDoS-em, ale też próbą BGP hijackingu przez AS Cyberbunker ^[7].

Amazon Route 53 i MyEtherWallet, 2018. 24 kwietnia 2018 roku, przez niemal dwie godziny, eNet (AS10297) ogłaszał zakresy adresów serwerów DNS Amazon Route 53 ^[5]. Przejęte serwery DNS odpowiadały na zapytania o MyEtherWallet adresami napastników, a zdobyte dane logowania posłużyły do kradzieży kryptowaluty z prawdziwego serwisu ^[5].

Celer Network, 2022. AS209243 należący do brytyjskiego operatora quickhost.uk zaczął rozgłaszać swoją infrastrukturę jako właściwą ścieżkę do puli 256 adresów Amazonu ^[6]. Amazon na ponad trzy godziny utracił nad nią kontrolę, a złośliwy kontrakt przejął w tym czasie 234 866,65 dolarów z 32 kont ofiar ^[6].