Ten artykuł został opracowany i zredagowany przez BlockWeeks
Platforma Ostium została wykorzystana przez atakującego, który ukradł około 24 miliony dolarów USDC w ośmiu transakcjach. Atakujący, posiadając jednocześnie autoryzowane klucze podpisujące oracle oraz rolę PriceUpKeep, składał poprawne podpisane raporty cenowe z datami w przyszłości, wielokrotnie otwierając i zamykając pary transakcyjne, aby stworzyć fałszywe zyski, bez żadnej rzeczywistej ekspozycji rynkowej.
Atak miał miejsce w ośmiu transakcjach, a każda z nich przekazywała środki do tego samego portfela 0x321Df1…8bfD9, przy czym największy pojedynczy transfer był wykonany w atomowej partii jako cykliczne operacje otwierania i zamykania pozycji. Ostium działa na Arbitrum i umożliwia użytkownikom handel instrumentami pochodnymi w formie kontraktów forward, które śledzą ceny aktywów bazowych, ale nie obejmują dostawy aktywów bazowych ani stałego terminu zapadalności.
Problem wynika z tego, jak system oracle Ostium autoryzuje dane cenowe. Walidator otrzymuje raport cenowy, wyprowadza tożsamość podpisującego z podpisu i sprawdza, czy podpisujący znajduje się na liście autoryzowanych. Weryfikuje jedynie tożsamość podpisującego, a nie dokładność samej ceny. Atakujący, posiadając jednocześnie autoryzowane klucze podpisujące oracle oraz zarejestrowaną rolę PriceUpKeep (odpowiedzialną za realizację oczekujących zamówień), wykorzystał tę kombinację do składania poprawnych podpisanych raportów cenowych z datami w przyszłości, a następnie wielokrotnie otwierał i zamykał pary transakcyjne, które się zabezpieczały. Pozwoliło im to generować zyski z transakcji z perspektywy systemu, bez żadnej rzeczywistej ekspozycji rynkowej.
Incydent Ostium jest jednym z wielu poważnych luk na poziomie aplikacji w tym roku, w tym przypadki Drift i rsETH od KelpDAO. Wspólnym tematem jest to, że inteligentne kontrakty i ich logika pozostają solidne, a atakujący głównie celują w infrastrukturę operacyjną i ludzkie zaufanie – w przypadku Ostium były to zmodyfikowane poświadczenia podpisującego, w przypadku Drift – socjotechniczne przejęcie administratora przed podpisaniem, a w przypadku KelpDAO – zatruta infrastruktura RPC.
Po tych głośnych lukach niektórzy wzywają do wprowadzenia zabezpieczeń na poziomie aplikacji dla środków użytkowników, takich jak ograniczenia wypłat, aby odstraszyć złośliwe działania i ograniczyć straty w przypadku wystąpienia luki. Takie sugestie należy odrzucić.
Ograniczenie wypłat wprowadza bezpośrednie ryzyko cenzury na poziomie aplikacji. Gdy protokół może jednostronnie opóźniać lub ograniczać depozyty lub wypłaty użytkowników, koncepcja samodzielnego przechowywania na tym poziomie aplikacji przestaje być absolutna, a staje się warunkowa. W takim przypadku to aplikacja, a nie użytkownik, decyduje o dostępności i sposobie wykorzystania środków. Takie podejście zaciera również granicę między atakującym a zwykłym użytkownikiem, ponieważ zabezpieczenia zaprojektowane w celu powstrzymania ataków z konieczności dotyczą wszystkich użytkowników korzystających z aplikacji.
Ryzyko „efektu śliskiego zbocza” dodatkowo pogłębia ten problem. Gdy protokół ma techniczną zdolność do ograniczania lub zamrażania depozytów/wypłat, zdolność ta staje się precedensem. Organy regulacyjne mogą to przytoczyć jako dowód, że te aplikacje mają już narzędzia do spełnienia nakazów zamrożenia, bramek KYC lub innych wymogów, a zatem powinny być do tego zobowiązane. Zabezpieczenia zbudowane w celu powstrzymania ataków mogą stać się haczykiem, który wciąga protokoły w obowiązki, których w przeciwnym razie nie mogłyby podjąć.
Ponadto niewinni uczestnicy rynku byliby również motywowani do obchodzenia tarcia wynikającego z tych środków. Na przykład ograniczeni użytkownicy szukający sposobów na wyjście z ekspozycji ekonomicznej zwykle oznaczają pojawienie się zbywalnego roszczenia, które wypełnia lukę (takiego jak tokeny potwierdzenia, IOU, opakowane alternatywy kryptowalut). To roszczenie samo w sobie staje się nową zależnością z własnym profilem ryzyka – na poziomie rynku (możliwe zerwanie powiązania, poszerzanie dyskonta w czasie paniki) i na poziomie technicznym (nowe kontrakty, nowe oracles, nowe podmioty możliwe do wykorzystania niezależnie od aplikacji). Zabezpieczenia mające na celu powstrzymanie pojedynczego punktu awarii ostatecznie pogłębiają kruchość, którą próbują zapobiec.
Tego rodzaju treści nie oznaczają, że protokoły nie powinny wzmacniać obszarów, które rzeczywiście zawiodły (takich jak zarządzanie kluczami podpisującymi, redundancja walidatorów). Ale naprawianie słabości infrastruktury operacyjnej i ludzkiego zaufania polega na wzmacnianiu tych aspektów, a nie na dodawaniu arbitralnej kontroli nad środkami użytkowników, która osłabia podstawową propozycję wartości tego, co jest chronione.
