XRP Ledger naprawił krytyczną lukę w zabezpieczeniach sięgającą 2015 roku, która mogła pozwolić atakującym na stworzenie około 18 bilionów XRP za pomocą pojedynczej specjalnie zaprojektowanej transakcji, przy czym ponad 80% zaufanych walidatorów zainstalowało awaryjną aktualizację 25 września.
Podsumowanie
- Programiści XRPL naprawili krytyczny błąd płatności, który mógł tworzyć wydawalne XRP poza jego podażą.
- Badacz Cayden Liao zademonstrował, że około 18 bilionów XRP mogło zostać wygenerowanych przez jedną spreparowaną transakcję.
- Zespół ds. bezpieczeństwa nie znalazł dowodów na to, że luka przepełnienia została wykorzystana w publicznych sieciach.
- Ponad 80% domyślnych walidatorów zaktualizowało się do xrpld 3.4.1 25 września, potwierdzili programiści.
- Oddzielna poprawka walidacji Batch została aktywowana 9 października po tym, jak walidatorzy opóźnili jej pierwotnie planowane wdrożenie.
Fundacja XRP Ledger i RippleX potwierdziły lukę w ujawnieniu z 9 października, wyjaśniając, że błąd w silniku płatności sieci mógł wygenerować wydawalne XRP poza zamierzonymi 100 miliardami podaży. Programiści odtworzyli problem podczas testów i wydali wersję 3.4.1, aby go rozwiązać. Ich śledztwo nie wykazało dowodów na to, że luka została wykorzystana w publicznej sieci. Badacz bezpieczeństwa Cayden Liao i Veria AI otrzymali maksymalną nagrodę w wysokości 250 000 dolarów w ramach programu bug bounty po zgłoszeniu luki i zademonstrowaniu jej potencjalnego efektu.
XRP Ledger naprawia błąd, który mógł stworzyć biliony XRP
Luka dotyczyła silnika płatności XRP Ledger, który przetwarza transfery i transakcje związane z wbudowaną zdecentralizowaną giełdą sieci.
Zgodnie z oficjalnym ujawnieniem, problem powstał z powodu przepełnienia liczby całkowitej w oprogramowaniu napisanym w 2015 roku. Przepełnienie liczby całkowitej występuje, gdy obliczenie daje liczbę większą niż system komputerowy może przedstawić za pomocą przydzielonej liczby bitów.
W tym przypadku silnik płatności sumował kwoty XRP związane z wieloma ofertami w księdze zleceń sieci. Oprogramowanie używało 64-bitowej liczby całkowitej do obliczenia całkowitej kwoty, którą kupujący był winien przy realizacji płatności obejmującej kilka ofert.
Programiści odkryli, że atakujący mógł stworzyć setki specjalnie wycenionych ofert i zaaranżować jedną płatność, która je skonsumuje. Gdy obliczona suma przekroczyła maksymalną wartość liczby całkowitej, liczba mogła się zawinąć do znacznie mniejszej kwoty. System nadal uznawałby indywidualnym sprzedawcom pełne kwoty XRP określone w ich ofertach, mimo że kupujący zapłacił tylko zmniejszoną kwotę wynikającą z przepełnienia. Różnica tworzyłaby XRP, które wcześniej nie istniało.
Według Fundacji XRPL, powstała kryptowaluta mogła być transferowana na inne konta, handlowana lub wysyłana na giełdy. Raport opisał potencjalny wynik: „Atakujący mógł stworzyć wydawalne XRP daleko poza całkowitą podażą.”
Luka nie mogła zostać wywołana przez zwykły handel, według programistów. Atakujący musiałby stworzyć kilkaset kont, złożyć nietypowo wycenione oferty i przesłać starannie skonstruowaną transakcję, aby przetworzyć je razem. Istniejące kontrole bezpieczeństwa zawiodły, ponieważ weryfikacja podaży systemu używała tego samego typu arytmetyki, który spowodował pierwotny błąd.
Tymczasem oddzielna kontrola salda konta mogła zostać obejścia poprzez rozdzielenie nowo utworzonego XRP między wiele portfeli.
Badacz odkrywa potencjalny exploit na 18 bilionów XRP
Luka zwróciła uwagę programistów po tym, jak badacz bezpieczeństwa Cayden Liao i Veria AI przetestowali oprogramowanie open source XRP Ledger.
Veria Labs opublikowała swoje ustalenia 10 października, opisując, w jaki sposób jej zautomatyzowany system testów bezpieczeństwa wykrył problem 21 września. Następnego dnia badacze opracowali działający proof of concept w lokalnej sieci testowej.
Według firmy demonstracja wykazała, że około 18 bilionów XRP mogło zostać utworzonych w wyniku jednej specjalnie zaprojektowanej transakcji. Kwota ta odpowiadała około 184 razy zamierzonej całkowitej podaży XRP, zgodnie z obliczeniami badaczy. Liczba ta opisuje wyniki kontrolowanych testów bezpieczeństwa, a nie rzeczywisty wzrost podaży kryptowaluty w obiegu. Liao zgłosił podatność za pośrednictwem oficjalnego programu bug bounty XRPL 22 września.
Inżynierowie RippleX odtworzyli problem na samodzielnym serwerze i potwierdzili, że nowo wygenerowane XRP mogło zostać wydane w kolejnej płatności.
Początkowy raport sklasyfikował podatność jako poważną, ale programiści podnieśli jej wagę do krytycznej po potwierdzeniu potencjalnych konsekwencji. Veria Labs stwierdziła, że podatność mogła narazić na ryzyko całą wartość rynkową XRP, gdyby atakującym udało się ją wykorzystać. Szacunek firmy opierał się na ówczesnej kapitalizacji rynkowej XRP wynoszącej około 94 miliardów dolarów.
Jednak liczba 94 miliardów dolarów reprezentuje szacunek badacza dotyczący potencjalnego narażenia finansowego, a nie potwierdzone straty. Zespół ds. bezpieczeństwa nie znalazł dowodów na nieautoryzowane tworzenie XRP w sieciach publicznych. 8 października Veria AI otrzymała maksymalną nagrodę w wysokości 250 000 dolarów za zidentyfikowanie i odpowiedzialne ujawnienie problemu.
RippleX wydaje awaryjną poprawkę bez normalnego procesu zatwierdzania
Po potwierdzeniu podatności inżynierowie RippleX opracowali poprawkę między 22 a 23 września. Poprawka została włączona do wersji xrpld 3.4.1, wydanej 25 września.
Zgodnie z oficjalnym ujawnieniem, programiści dodali kontrole, które uniemożliwiają silnikowi płatności akceptowanie obliczeń przekraczających dozwolony zakres liczb całkowitych. Zaktualizowane oprogramowanie odrzuca dotknięte obliczenia i zwraca zwykły błąd płatności zamiast tworzyć dodatkowe XRP. Inżynierowie wzmocnili weryfikację podaży w sieci, zastępując istniejącą arytmetykę szerszym licznikiem zaprojektowanym do wykrywania podobnych błędów. Dodatkowe obliczenia salda zostały sprawdzone jako środek ostrożności.
Jednak decyzja o wdrożeniu poprawki wprowadziła nietypową sytuację dla zarządzania XRP Ledger. Normalnie zmiany w przetwarzaniu transakcji muszą przejść przez system poprawek sieci. Poprawka wymaga wsparcia ponad 80% zaufanych walidatorów przez dwa kolejne tygodnie przed aktywacją.
W przypadku podatności związanej z przepełnieniem płatności programiści zdecydowali się zastosować poprawkę natychmiast po aktualizacji oprogramowania przez walidatorów. Fundacja XRPL wyjaśniła, że normalny proces ujawniłby podatność, pozostawiając ją możliwą do wykorzystania w okresie zatwierdzania.
Ponieważ oprogramowanie XRP Ledger jest open source, publikacja poprawki może ujawnić lokalizację i charakter podatności.
Programiści doszli do wniosku, że oczekiwanie na zwykły proces poprawek mogłoby stworzyć dodatkowe ryzyko dla bezpieczeństwa. Podejście awaryjne niosło ze sobą odrębne zmartwienie: walidatorzy uruchamiający różne wersje oprogramowania mogliby nie zgodzić się co do sposobu przetwarzania złośliwej transakcji.
W ekstremalnym scenariuszu niezgodność mogłaby tymczasowo uniemożliwić sieci potwierdzanie nowych ksiąg. Fundacja stwierdziła, że decyzja została podjęta w konsultacji z RippleX, operatorami walidatorów i innymi współtwórcami XRPL. Do 25 września ponad 80% walidatorów na domyślnej liście unikalnych węzłów zaktualizowało się do wersji 3.4.1.
Publiczny kod źródłowy został następnie udostępniony po natychmiastowej reakcji na zagrożenie bezpieczeństwa. Rekordy wydań Fundacji XRPL opisują wersję 3.4.1 jako aktualizację awaryjną rozwiązującą problemy protokołu wrażliwe na bezpieczeństwo.
XRP Ledger rozwiązuje drugą lukę bezpieczeństwa przed aktywacją Batch
Ujawnienie z 9 października obejmowało kolejną podatność dotyczącą funkcji transakcji Batch w XRP Ledger. Batch pozwala programistom połączyć do ośmiu transakcji w jedną operację. Funkcja obsługuje różne tryby wykonania, w tym układy, w których każda transakcja musi się powieść, aby cała operacja została zaakceptowana.
Podczas testów bezpieczeństwa badacze odkryli błąd walidacji dotyczący sposobu pakowania poszczególnych transakcji wewnątrz Batch. Protokół wymagał, aby każda transakcja używała określonego pola o nazwie RawTransaction.
Jednak oprogramowanie mogło akceptować alternatywne nazwy pól w pewnych warunkach. Śledczy odkryli, że różne wersje serwera mogą przetwarzać te nieprawidłowo sformatowane transakcje w różny sposób.
Według XRPL Foundation wynikająca z tego niezgodność mogła zakłócić walidację sieci, gdyby funkcja stała się aktywna przed naprawieniem problemu. Problem został pierwotnie zidentyfikowany podczas Sherlock Attackathon, a następnie zbadany przez współpracownika XRPL Foundation, Denisa Angella. Inżynier RippleX, Mayukha Vadari, ustalił, że luka ta stworzyła potencjalne ryzyko konsensusu między wersjami serwera.
Deweloperzy zareagowali, wprowadzając poprawkę fixBatchV1_2. Poprawka wymaga, aby każda transakcja Batch używała zatwierdzonego formatu pól i odrzuca nieprawidłowo zapakowane transakcje. Walidatorzy tymczasowo wycofali wsparcie dla wcześniejszego harmonogramu aktywacji BatchV1_1, podczas gdy deweloperzy kończyli korektę.
Zarówno fixBatchV1_2, jak i BatchV1_1 zostały aktywowane w głównej sieci XRP Ledger 9 października. Aktywacja XRP Ledger Batch otrzymała wsparcie od 30 walidatorów, przy pięciu sprzeciwiających się aktualizacji, zgodnie z danymi XRPScan zawartymi w zweryfikowanym raporcie sieci.
Wcześniejsze badania nad przeglądem bezpieczeństwa Batch szczegółowo opisywały awaryjne wydanie z 25 września oraz zabezpieczenia wymagane przed aktywacją funkcji. Początkowa wersja spotkała się wcześniej z obawami dotyczącymi bezpieczeństwa, w tym problemami z autoryzacją transakcji ujawnionymi podczas przeglądów deweloperskich.
Oddzielny audyt bezpieczeństwa XRP Ledger w sierpniu udokumentował 96 ważnych luk zidentyfikowanych podczas konkursu Sherlock obejmującego proponowane funkcje protokołu.
W przypadku najnowszej luki Batch, XRPL Foundation potwierdziła, że dotknięte poprawki nie były aktywne w głównej sieci w momencie odkrycia problemu. Nie utracono żadnych środków użytkowników, nie naruszono żadnych kluczy prywatnych i nie wystąpiła awaria konsensusu z powodu tej konkretnej wady. Aktywacja 9 października oznacza, że serwery z starszymi wersjami oprogramowania są teraz zablokowane przez poprawkę i muszą zaktualizować się do wersji 3.4.1 lub nowszej, aby pozostać zsynchronizowane.
XRPL Foundation poinformowała, że wprowadza dodatkowy wymóg weryfikacji dla przyszłych wydań oprogramowania: wcześniej zgłoszone problemy bezpieczeństwa muszą być ponownie przetestowane na kandydatach do wydania przed sklasyfikowaniem ich jako naprawione.
Według fundacji procedura będzie miała zastosowanie do ustaleń z audytów, programów bug bounty, testów bezpieczeństwa wspomaganych przez AI i innych ocen luk w zabezpieczeniach.
