Cosmos Hub nie został zhakowany

Incydent nie naruszył Cosmos Hub ani wszystkich blockchainów w szerszym ekosystemie Cosmos. Luka znajdowała się w cosmos/evm — współdzielonym oprogramowaniu, które pozwala niezależnym sieciom opartym na Cosmos uruchamiać aplikacje kompatybilne z Ethereum.

Zgodnie z post-mortem Cosmos Labs sześć sieci korzystających z tego oprogramowania zostało wykorzystanych między 20 a 25 sierpnia. MANTRA, TAC i KiiChain zostały wymienione w szczegółowej osi czasu; dokument nie zidentyfikował publicznie pozostałych trzech sieci.

To rozróżnienie ma znaczenie: zapobiega przekształceniu awarii współdzielonego oprogramowania w mylący nagłówek o „hacku Cosmos”. Ta sama zasada zakresu dotyczyła exploita na mostku The Sandbox — skompromitowana integracja nie oznaczała, że cały bazowy protokół został zhakowany.

Atakujący przekonali 5,72 mln USD dwiema drogami

Cosmos Labs oszacowało, że atakujący wymienili około 2,87 mln USD na zdecentralizowanych platformach, w oparciu o ceny z 19 sierpnia. Firma opisała tę kwotę jako szacunek niezweryfikowany przez niezależny audyt. Kolejne 2,85 mln USD zostało według doniesień sprzedane na giełdach scentralizowanych, co daje łączną kwotę wymienioną lub sprzedaną około 5,72 mln USD.

Cosmos Labs podało, że dotknięte sieci zgłosiły zamrożenie kont na giełdach scentralizowanych w trakcie trwających śledztw policji. Łączna kwota 5,72 mln USD się nie zmieni, ale odzyskanie zamrożonych sald na giełdach może zmniejszyć ostateczną stratę netto.

Reakcja ograniczyła również szkody. Cosmos Labs współpracowało z 13 innymi potencjalnie narażonymi sieciami w celu łatania, zatrzymania lub innej ochrony bez kolejnych zgłoszonych incydentów i koordynowało działania z 40 sieciami łącznie.

Jak niezgodność księgowa obnażyła ważne salda

Podatność wynikała z tego, że dwie części oprogramowania liczyły salda w różny sposób. StateDB w Cosmos EVM śledziło jedynie kwotę, którą konto mogło natychmiast wydać. Konto vestingowe Cosmos mogło jednak posiadać zarówno tokeny dostępne, jak i zablokowane, a system stakingu pozwalał delegować zablokowane tokeny.

Gdy oprogramowanie odejmowało pełną zdelegowaną kwotę od mniejszego salda dostępnego, niesprawdzony niedomiar arytmetyczny mógł „zawinąć” wynik do liczby bliskiej 2^256. Atakujący mógł następnie połączyć ten niedomiar z nadmiarem podczas transferu. Ta klasa błędów — nadmiar i niedomiar liczb całkowitych w arytmetyce bez znaku — to dobrze udokumentowana kategoria podatności kontraktów inteligentnych i blockchainów i jeden z powodów, dla których nowoczesne języki kontraktów domyślnie stosują arytmetykę sprawdzaną.

Sekwencja ta nie tworzyła trwałego wzrostu podaży. Mogła natomiast sprowadzić saldo konta ofiary o wysokiej wartości do zera i pozostawić atakującemu saldo, które konto wcześniej posiadało. To czyniło lukę bezpośrednim ryzykiem kradzieży środków, a nie jedynie błędnym wyświetlaniem lub księgową osobliwością.

Ostrzeżenie pojawiło się niemal cztery miesiące przed atakami

Kradzież była końcem dłuższej sekwencji. Decydujący błąd nastąpił podczas wstępnej oceny, na miesiące przed jakimkolwiek wykorzystaniem kodu.

Cosmos Labs potraktowało zagrożenie produkcyjne jak rutynową konserwację

Oryginalny proof-of-concept wykorzystywał sieć skonfigurowaną z sześcioma miejscami dziesiętnymi. Cosmos Labs testowało konfiguracje 18-miejscowe, nie odtworzyło wyniku i uznało, że znane sieci produkcyjne są bezpieczne. Ten wniosek był błędny: podstawowa niezgodność sald mogła dotyczyć każdego łańcucha Cosmos EVM, niezależnie od konfiguracji dziesiętnych.

Gdy późniejsze zgłoszenia ujawniły szerszy zasięg, Cosmos Labs wiedziało już, że środki produkcyjne są zagrożone. Firma wybrała proces cichego łatania, mający dostarczyć operatorom naprawiony kod bez publikowania szczegółów, które mogłyby pomóc atakującym.

Wydania były dostępne około 20 godzin przed pierwszym znanym atakiem, ale ich notatki nie określały powagi ani nie informowały operatorów, że opóźnienie aktualizacji może narazić środki użytkowników. Operatorzy mogli zobaczyć, że nowe wydania zawierają poprawki bezpieczeństwa, ale notatki nie wyjaśniały, że niezałatane sieciom grozi potencjalna utrata środków.

Ujawnienie stało się publiczne następnego ranka. Pull request w forkze podrzędnym opisywał ścieżkę exploita i identyfikował dotknięte tagi wydań około 12 godzin przed pierwszym atakiem. Publiczny pull request dał atakującym wyraźniejszą ścieżkę, a Cosmos Labs już wcześniej pozostawiło operatorów bez ostrzeżenia wyjaśniającego pilność.

Dylemat, przed którym stanęło Cosmos Labs, jest znajomy w bezpieczeństwie open source: pełne ujawnienie podatności może uzbroić atakujących, zanim wszyscy operatorzy załatają kod, a milczenie może pozbawić operatorów możliwości oceny pilności. Praktyki skoordynowanego ujawniania w branży oprogramowania próbują równoważyć dokładnie ten kompromis, a ten incydent pokazuje, co się dzieje, gdy równowaga zawodzi po obu stronach.

Cosmos nie znało każdej sieci wymagającej ostrzeżenia

Nawet prywatny proces ostrzegania działa tylko wtedy, gdy opiekunowie wiedzą, z kim się skontaktować. Cosmos Labs podało, że ekosystem obejmuje ponad 115 znanych publicznych sieci, ale brakuje pełnego rejestru. W trakcie odpowiedzi firma dowiedziała się o 11 wdrożeniach Cosmos EVM, które nie były zarejestrowane w jej kanałach bezpieczeństwa.

Cosmos Labs utrzymywało współdzielony kod bez znajomości każdej sieci, która go wdrożyła. Ta luka utrudniała dostarczenie poufnego ostrzeżenia przed publikacją wystarczających informacji, by zespoły sieci same rozpoznały zagrożenie.

Oś czasu odpowiedzi pokazuje też, dlaczego komunikat musiał być jednoznaczny. Po zgłoszeniu pierwszego ataku przez MANTRA, Cosmos Labs wysłało pierwszy krytyczny bezpieczny e-mail około dwie godziny później. TAC zostało zaatakowane około 45 godzin po MANTRA mimo wcześniejszej komunikacji, a wytyczne zostały później zaostrzone do zalecenia wstrzymania wszystkich sieci Cosmos EVM.

Dla niezależnych sieci Cosmos EVM publikacja kodu nie wystarczyła. Ich zespoły musiały jeszcze dowiedzieć się, że aktualizacja jest pilna, i skoordynować wydanie zmieniające stan.

Narażone sieci muszą zaktualizować się lub wstrzymać działalność

Krytyczne zawiadomienie bezpieczeństwa wymienia jako dotknięte wersje przed 0.6.2 oraz wersje od 0.7.0 do 0.7.2 (nie włączając tej ostatniej). Operatorzy powinni przejść na Cosmos EVM 0.6.2, 0.7.2 lub nowsze wydanie.

Nie istnieje obejście oparte wyłącznie na konfiguracji. Wyłączenie prekompilatu stakingu usuwa główny wyzwalacz opisany w zawiadomieniu, ale Cosmos Labs nie traktuje tego kroku jako zamiennika aktualizacji. Sieć, która nie może natychmiast zainstalować załatanej wersji, powinna wstrzymać działalność.

BTCPay niedawno wydał podobne, specyficzne dla wersji instrukcje po potwierdzeniu kradzieży środków: zaktualizować dotknięte instalacje lub wyłączyć je offline. W obu przypadkach użyteczne wskazówki są konkretne, ponieważ ryzyko zależy od używanej wersji oprogramowania.

Następna naprawa to proces ujawniania

Cosmos Labs zapowiedziało poszerzenie triażu podatności poza proof-of-concept zgłaszającego, rozbudowę sieci kontaktów bezpieczeństwa oraz sprawdzanie, czy te kontakty pozostają aktywne. Planuje też jaśniejsze standardy dla łatek prywatnych i cichych, w tym kiedy opiekunowie powinni zalecić wstrzymanie zamiast skoordynowanej aktualizacji. Planowany jest również zewnętrzny audyt praktyk bezpieczeństwa operacyjnego.

Te zmiany adresują tę część incydentu, której kolejna łatka kodu nie rozwiąże: jak zdecentralizowana grupa niezależnych sieci otrzymuje, rozumie i reaguje na pilne ostrzeżenie. Pierwsza ocena zbyt szybko zawęziła błąd. Późniejszy proces wydawniczy ukrył pilność przed częścią osób, które miały zainstalować poprawkę. Kod był dostępny przed pierwszym atakiem. Czego brakowało kilku operatorom, to ostrzeżenia, że zwłoka może kosztować środki użytkowników.

Artykuł ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej ani bezpieczeństwa. Operatorzy sieci powinni zapoznać się z oficjalnym zawiadomieniem Cosmos EVM i zweryfikować swoją wdrożoną wersję.

Źródło: Coindoo