Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Amazon ponownie stracił kontrolę (na 3h) nad pulą IP w ataku BGP Hijacking
W ostatnim miesiącu, Amazon na ponad trzy godziny utracił kontrolę nad pulą adresacji IP odpowiedzialnej za usługi chmurowe, co pozwoliło cyberzbójom na kradzież 235 000 dolarów użytkownikom jednego z klientów AWS. Hakerzy za pomocą ataku BGP hijacking uzyskali kontrolę nad pulą 256 adresów IP. Protokół BGP pokrótce opisując, stanowi kręgosłup (ang. backbone) – podstawę funkcjonowania sieci Internet, gdyż zapewnia trasowanie (ang. routing) pomiędzy sieciami Systemów Autonomicznych (AS) operatorów Internetu oraz podmiotów posiadających na własny użytek fragment adresacji globalnej IPv4. Routing w Internecie odbywa się poprzez komunikację między w/w. numerami AS na podstawie rozgłaszanych przez te numery tras i doboru „najlepszej” z nich dotarcia do celu.
Jak analiza techniczna wskazuje, numer AS209243, który należy do brytyjskiego operatora quickhost.uk nagle zaczął rozgłaszać swoją infrastrukturę jako właściwą ścieżkę dla innych numerów AS do dostępu do 24-bitowego bloku adresów IP należącego do AS16509 – czyli jednego z trzech numerów zarządzanych przez Amazon. Prawdopodobnie operator hostingu Quick Host również został ofiarą w tym ataku, a nie był stroną atakującą. Przechwycony blok zawierał właściwy adres IP 44.235.216.69 rozwiązywany do nazwy cbridge-prod2.celer.network. Jest to subdomena odpowiedzialna za serwowanie usługi interfejsu smart kontraktów użytkownika dla kryptowaluty Celer. Smart kontrakt jest formą oprogramowania lub protokołu automatyzacji i weryfikacji cyfrowych umów i istotnych zdarzeń wynikających z wewnętrznych zapisów w umowach, w tym przypadku – transakcja wymiany kryptowaluty na inną. 17 sierpnia, napastnicy uzyskali certyfikat TLS dla w/w. subdomeny ponieważ byli w stanie przedstawić organowi certyfikacji (CA) GoGetSSL na Łotwie, że mają kontrolę nad domeną domencbridge-prod2.celer.network. Prawdopodobnie poprzez wykonanie na tym serwerze innej podatności lub wykorzystując serwer DNS, który często służy jako weryfikacja właściciela który żąda wygenerowania nowego certyfikatu (np. poprzez dodanie konkretnego rekordu TXT potwierdza się kontrolę nad domeną i serwerami).
Rys. 1. Wycinek konfiguracji cBridge z podstawionym, fałszywym adresem smart kontraktu, źródło.
Będąc w posiadaniu certyfikatu, hakerzy hostowali ofiarom własny smart kontrakt i czekali na wizyty osób próbujących uzyskać dostęp do właściwej strony wymiany kryptowalut – cBridge. Złośliwy smart kontrakt w ciągu 3 godzin pochłonął 234 866,65 dolarów z 32 kont ofiar.
Rys. 2. Przechwycone certyfikaty, źródło.
Na podstawie weryfikacji identyfikatorów certyfikatów na stronie crt.sh, można było potwierdzić daty przejęcia oraz adresację IP związaną z siecią Celer. Ślad certyfikatu i adresacji można było zaobserwować za pośrednictwem platformy Censys (rys. 3).
Rys. 3. Powiązanie certyfikatu z adresacją Celer, źródło dostępne w Censys.io.
Adres IP powiązany z drugim certyfikatem jednak nie korelował z adresem IP przypisanym do sieci Celer, co ewidentnie może wskazywać na fakt, że podczas krótkotrwałej podmiany, takie narzędzia jak Censys lub wyszukiwarki nie były w stanie zebrać najnowszych informacji o trasie. Jedank wiemy, że adres 44.235.216.69 był związany z domeną cbridge-prod2.celer.network od początku, więc nie jest potencjalnym problemem (rys. 4).
Rys. 4. Logi historyczne powiązania adresu IP z organizacją Amazon.com Inc.
W celu rozwiązania zagadki, trzeba sięgnąć do narzędzi grafów routingu BGP np. za pośrednictwem operatora Hurricane Electric.
Rys. 5. Opis numeru AS16509, źródło.
Jak się okazało w kolumnie AS info, otrzymaliśmy informację, że numer AS Amazona rozgłasza tzw. bogony, czyli fałszywą adresację IP, która nie należy do wybranego AS (rys. 6)
Rys. 6. Informacja ze strony HE, że numer AS Amazona rozgłasza tzw. bogony
Zespołowi badaczy ze SlowMist, udało się następnie skontaktować z administratorami sieci Celer i uzyskali oni adres IP napastników z logów: 54[.]84[.]236[.]100. Adres ten jest związany z numerem AS14618, który (nie uwierzycie), ale w tym samym czasie również ogłaszał fałszywe bogony!
Rys. 7. Potwierdzenie z narzędzia HE, że atakujący również wysyłał fałszywą adresację, źródło.
Przeglądając propagację tras w/w. złośliwego numeru AS, potwierdza się, że ścieżką anonsującą adresację IP numer AS14618 (złośliwego) był numer AS16509 (Amazon). W związku z powyższym doszło do ataku BGP hijacking (rys. 8).
Rys. 8. Potwierdzenie BGP hijacking, źródło.
Posiadając numery AS oraz adresację IP obu stron komunikacji, za pośrednictwem narzędzia BGP Updates, badacze mogli zauważyć bardzo dużą wymianę tablic routingu pomiędzy 2:48, a 7:48 w dniu 18 sierpnia 2022 czasu CST (ang. Central Standard Time).
Rys. 9. Zauważone zmiany w topologii BGP, źródło.
Podczas ataku BGP hijacking, cyberzbóje starają się wycofać właściwą trasę numeru AS i podmienić go ze swoją poprzez ustawienie flagi wycofania – Withdrawn na właściwej trasie. Przeglądając zapisy narzędzia BGP Play tak się właśnie stało co obrazuje rys. 9.
Rys. 10. Potwierdzony zapis zmiany trasy AS wyłączający na 3 godz. ruch z AS16509 (Amazon), źródło.
Powyższa analiza obrazuje, że napastnicy od początku mieli wszystko przygotowane pod względem timingu, przygotowania i podmiany certyfikatu, gotowości adresacji IP oraz oczekiwania na propagację tras BGP. Przestępcy jednak musieli liczyć nieco na łut szczęścia i faktycznie ten nastał, bo dla sieci Ethereum jedna z transakcji z fałszywym smart kontraktem wyniosła aż 156 000 dolarów, więc ponad połowa kwoty skradzionej ze wszystkich 32 transakcji.
Rys. 11. Tabela strat 32 transakcji podczas trzech godzin ataku BGP hijacking, źródło.
Źródło:
- https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000
- https://medium.com/coinmonks/truth-behind-the-celer-network-cbridge-cross-chain-bridge-incident-bgp-hijacking-52556227e940
- https://www.coinbase.com/blog/celer-bridge-incident-analysis
~tt
Sporo tu treści, a mimo to 《w biegu》? Ja bym raczej krótkie artykuły wsadził do tej kategorii.
No dobra, fajny artykuł. Ale co poszło nie tak? Co powinien zrobić AS, żeby jego infrastruktura nie stała się przyczyną rozgłaszania błędnych tras?
Albo inaczej: co zrobili nie tak? – Zbyt łatwe hasło na roota w ruterze i to wszystko? Interesuje mnie jak zaczyna się taki atak, czego należy unikać?
CST to Central Standard Time , nie „China”
Literówka, poprawione, dzięki.
Ile cyberzbojów może być zaangażowanych w taki atak? Jakie zasoby są potrzebne do jego przeprowadzenia od analizy po wykonanie?
Skoro mieli kontrolę nad adresem IP, który był rozwiązaniem do fqdn (zakładam, ze o to chodziło, a nie o to ze IP rozwiązywał się do fqdn przez revDNS), to do czego im było potrzebne wykorzystywanie innej podatności i przejęcie DNS, skoro już ofiara była kierowana do kontrolowanego IP?
Cert był wygenerowany przed faktycznym atakiem, mogli zrobić ostatnie testy i zaoszczędzić czas podczas faktycznego ataku. Druga sprawa, skoro z artykułu wynika, że nie wszystkie systemy były w stanie pobrać nowe trasy, to wygenerowanie certa np z użyciem LE także mogło by być niemożliwe.
Dokładnie tak.
No ja bym również prosił o wskazanie wykorzystanej podatności (router? chmurowe UDR?), a przede wszystkim co zrobić, aby tego w przyszłości uniknąć.
O takie artykuły tu wchodzę <3