Jak ocenić, czy tak zwany „HACK”, który przydarzył się projektowi kryptograficznemu lub Blockchain, jest legalny, czy też jest to tylko mechanizm umożliwiający ukrycie dywanika?

Opublikowane ponownie przez Plato

Obserwuje: 0

Oczywiście, po tym, co stało się z MtGox lub QuadrigaCX lub podobnymi przypadkami, w których założyciele twierdzili, że stracili klucze prywatne zawierające większość zasobów cyfrowych ich giełd, a następnie zniknęli lub zostali znalezieni martwi, ludzie w sferze kryptograficznej są coraz bardziej podejrzliwi, gdy słyszą o włamać się do projektu i pierwszą myślą, jaka przychodzi mi do głowy, jest to, że założyciele w zasadzie opróżnili fundusz i uciekli z nim, tak powszechnie nazywa się RUG.

Prawdopodobnie tak było w przypadku wielu projektów, ale niekoniecznie we wszystkich, dlatego dzisiaj przyjrzymy się sprawie, którą uważamy za prawdziwe włamanie ze względu na charakter sytuacji.

Uważamy, że jest to interesujący przypadek do przeanalizowania, ponieważ pomoże lepiej zrozumieć znaczenie bezpieczeństwa i audytów w projektach smart-kontraktów lub ogólnie związanych z łańcuchem bloków.

Obiektywnie przeanalizujemy dramat, jaki spotkał projekt RING Financial, token uruchomiony na BSC (Binance Blockchain).

Zanim przejdziemy do hackowania, najpierw podsumujemy projekt i jego sytuację przed nim:

RING Financial przed włamaniem

RING Financial był projektem DeFi, którego celem było uczynienie DeFi bardziej dostępnym dla społeczności DeFi i kryptowalut. Ambitny projekt, który miał na celu stworzenie protokołu przynoszącego węzły, który byłby zarządzany przez posiadaczy węzłów i przydzielał płynność do ponad 300 protokołów jednocześnie. Celem było uzyskanie dostępu do wszystkich protokołów przez jeden RING Node i przez RING Dapp.

Protokoły te zostały zweryfikowane przez zespół, a następnie społeczność głosowała nad nimi, gdzie je przydzielić. Ta sama koncepcja głosowania, co w DAO, co czyni RING całkiem atrakcyjnym.

RING Financial uprościł również sporo procesu badawczego i procesu wdrażania dla jednego Node Holdera. Jeden Dapp, aby uzyskać dostęp do wszystkich innych Dappów, więc potrzebujesz tylko jednego interfejsu zamiast 300 różnych z własnymi dostępami i własnymi węzłami.

Wreszcie, celem RING Financial było obniżenie opłat za wdrażanie na różnych protokołach, wraz z wolumenem wiążą się niższe opłaty transakcyjne dla poszczególnych posiadaczy, co było jednym z głównych punktów sprzedaży projektu. Projekt z talentem i ambicjami, aby ułatwić życie społeczności i jeszcze bardziej stać się głównym nurtem dla tych, którzy nie są świadomi Defi.

Jednak talent i ambicja nie zawsze wystarczą i potrzebujesz wiedzy i doświadczenia, które na nowych i niedojrzałych rynkach są rzadkim odkryciem i dlatego RING Financial nie mógł całkowicie spełnić swojej obietnicy.

Co tak naprawdę stało się z RING Financial? I dlaczego został zhakowany? Dzięki łańcuchowi bloków mamy wszystkie dowody kryminalistyczne potrzebne do zagłębienia się w to i sprawdzenia, gdzie były luki i dlaczego RING Financial nie było oszustwem.

RING Financial HACK miał miejsce 5 grudnia 2021 r. między 2:01 a 2:06 UTC.

Tak, wszystko wydarzyło się dosłownie w zaledwie 5 minut! Nawiasem mówiąc, dzięki skanerowi blockchain dla tych szczegółów, udostępniamy ci tuż pod linkami transakcji związanych z HACKiem, a także adres umowy dla tych, którzy będą chcieli szukać bardziej szczegółowo.

Oto podsumowanie wyjaśniające lukę, którą wykorzystał atakujący:

Musisz zrozumieć, że smart-kontrakt RING Financial składał się z kilku części, jednej dla tokena i wszystkich danych z nim związanych, a drugiej dla wszystkiego, co dotyczy księgowania węzłów i nagród. Część tokena miała zabezpieczenie, aby tylko administrator umowy mógł modyfikować ważne dane tej umowy, aby pokazać ci kod, oto nagłówek funkcji umowy, która jest chroniona przez atrybut „onlyOwner” który stanowi, że funkcję może realizować tylko administrator:

Funkcja, która nie ma tylkoWłaściciel atrybut (lub równoważny atrybut chroniący dostęp do funkcji) może być wykonany dosłownie przez każdego.

Teraz zgadnij co? Funkcje w części Nodes and Rewards nie miały tego atrybutu, jak widać, patrząc na nazwy funkcji poniżej (tzw. tylkoWłaściciel brak atrybutu):

I jak możesz sobie wyobrazić, haker wykorzystał i oszukał tę lukę, aby uzyskać wykładniczą liczbę nagród w RING, a następnie wrzucił je do puli płynności i prawie brutalnie ją opróżnił w ciągu kilku minut. W ten sposób dokonywał swoich oszustw.

Teraz pewnie zadajesz sobie dwa pytania:

Jak twórcy mogli zostawić taką lukę?

Po rozmowie z programistami Solidity (język używany do kodowania smart-kontraktów na Ethereum), jest to błąd związany z dziedziczeniem ról między dwoma smart-kontraktami, dziedziczenie jest pojęciem języka programowania i aby nie przyprawiać Cię o ból głowy, my pozostanę w prostych słowach: Zasadniczo jest bardzo prawdopodobne, że osoba, która zakodowała kontrakt, myślała, że funkcje części Node odziedziczyły role bezpieczeństwa funkcji części Token, ale niestety tak nie jest w przypadku Solidity i konieczne jest ponowne zdefiniowanie ról każdej funkcji każdej umowy, niezależnie od ich związku. Więc nasz wniosek w tej kwestii jest taki, że deweloper nie był ekspertem i prawdopodobnie opublikował umowę BEZ poświęcenia czasu na jej ponowne przeczytanie, prawdopodobnie w pośpiechu.

Skąd wiesz, że to nie sam deweloper celowo zostawił tę usterkę i nie było to oszustwo?

Bardzo dobry sprzeciw i łatwo założyć oszustwo, gdy nie jesteś pewien, jak to zrobić inteligentne kontrakty działa, ale w rzeczywistości bardzo łatwo jest założyć niewinność dewelopera, ponieważ opublikował i zweryfikował publicznie cały kod smart-kontraktu na BSCSCAN.COM (najpopularniejszy skaner Binance Blockchain), 19 listopada 2021 r., że to znaczy ponad dwa tygodnie przed RING Financial HACK. I jak wyjaśniono wcześniej, usterka została zapisana w kontrakcie CZARNYM NA BIAŁYM i każdy doświadczony programista zauważyłby to i zareagował, ale niestety pierwszy nie miał litości. Jest zatem oczywiste, że deweloper nie był świadomy tej wady, ponieważ nie podjąłby ryzyka, aby w dowolnym momencie pozwolić komukolwiek zabić projekt RING Financial.

Wracając do kontynuacji RING Financial HACK, deweloper zdał sobie sprawę ze swojego błędu i po prostu zamroził kontrakt, aby wstrzymać jakąkolwiek dystrybucję nagród, tak aby atakujący nie opróżnił całkowicie puli. Następnie ponownie wdrożył kontrakt Node, tym razem z atrybutem bezpieczeństwa „onlyOwner”. Ta nowa umowa Node była w stanie poprawnie obsłużyć nową dystrybucję nagród, z wyjątkiem tego, że było już za późno, ponieważ w wyniku HACK-a całe zaufanie do projektu i zespołu zostało utracone, a presja sprzedaży zabiła i zakończyła token i projekt.

Podsumowując, wybraliśmy tę historię, ponieważ pokazuje dwie ważne rzeczy na temat inteligentnych kontraktów i projektów kryptograficznych, nigdy nie koduj umowy w pośpiechu i zawsze kontaktuj się z firmami audytorskimi, ponieważ po włamaniu jest już za późno na uratowanie łodzi i Projekt RING Financial jest dobrym przykładem, co więcej, zgodnie z ich komunikatem, skontaktował się z firmami audytorskimi w sprawie drugiego kontraktu Node i nie opublikował go publicznie na BSCSCAN, dopóki nie był pewien jego bezpieczeństwa. Ale, jak powiedziano wcześniej, dla RING Financial było już za późno, a szkody były nieodwracalne.