Audytowane protokoły DeFi straciły 885 milionów dolarów w wyniku ataków, które miały miejsce całkowicie poza zakresem ich audytów

W zdecentralizowanych finansach "audytowane" często przedstawiane jest jako werdykt dotyczący całego projektu. W praktyce audyt zazwyczaj obejmuje nazwany kod, komponenty i wersje w danym momencie. Wszystko, co dodane, wykluczone lub operowane wokół tej granicy, może nosić inny poziom zapewnienia.

Nowy preprint podaje liczbę na ten brak. Badacze związani z firmą bezpieczeństwa ack3 oraz Czeskim Uniwersytetem Technicznym w Pradze zbadali 135 zgłoszonych incydentów z pierwszej połowy 2026 roku, z przypisanymi stratami w wysokości 939,86 miliona dolarów. Odkryli identyfikowalne publiczne audyty przedincydentowe dla 68 incydentów.

W ramach tego podzbioru 68 incydentów autorzy sklasyfikowali 46 ścieżek ataku jako znajdujące się poza każdym zakresem audytu, który mogli zidentyfikować, 20 jako mieszczące się w co najmniej jednym zakresie, a dwa jako nierozwiązane. Grupa incydentów poza zakresem stanowiła 67,6% incydentów, ale 94,4% ich zgłoszonych strat.

Ten uderzający procent nie jest oszacowaniem skuteczności audytu ani dowodem, że granice audytu spowodowały stratę. Opisuje rozkład strat w wybranym zestawie zgłoszonych incydentów. Dwa duże przypadki również dominują: po wykluczeniu 292 milionów dolarów w Kelp DAO i 285 milionów dolarów w Drift Protocol, udział incydentów poza zakresem spada do 72,1% strat w tym samym podzbiorze incydentów audytowanych.

Nawet z tymi ograniczeniami badanie ujawnia podstawowy problem zapewnienia. Projekt może prawdziwie twierdzić, że był audytowany, pozostawiając użytkowników niezdolnymi do stwierdzenia, czy system na żywo, ścieżka trzymająca ich fundusze i kontrole wokół niej zostały sprawdzone.

Co dane naprawdę pokazują

Zbiór danych ack3 obejmuje incydenty od 1 stycznia do 29 czerwca. Jego autorzy ocenili 122 jako potwierdzone i 13 jako prawdopodobne. W pełnym zestawie 35 nie miało zidentyfikowanego audytu, a 32 miało nieznaną historię audytów, więc żadna z tych grup nie pojawia się w obliczeniach dotyczących 68 incydentów.

Dla tej grupy 68 incydentów incydenty poza zakresem stanowiły 680,97 miliona dolarów z 721,24 miliona dolarów zgłoszonych strat, co daje 94,4%. Usunięcie Kelp DAO i Drift Protocol pozostawiło 103,97 miliona dolarów z 144,24 miliona dolarów poza zakresem, czyli 72,1%. Księga maszynowo czytelna reprodukuje liczby pojemników i sumy strat.

Etykiety wewnętrzne lub zewnętrzne pozostają osądami badaczy na podstawie publicznych dowodów. Przeszukali archiwa projektów i audytorów, zlokalizowali raporty przedincydentowe i porównali ostateczne ścieżki ataków z przeglądanym kodem, wersjami i wykluczeniami. Praca jest sześciostronicowym preprintem wyprodukowanym z wydawcą zbioru danych, a dwóch autorów jest związanych z ack3, która sprzedaje przeglądy bezpieczeństwa.

Badanie brakuje również grupy porównawczej, która nie została wykorzystana, oraz miary tego, jak długo każdy system był narażony. Nie może ustalić, czy audytowane protokoły są ogólnie bezpieczniejsze, oszacować prawdopodobieństwa incydentów ani pokazać, że wyjście poza zakres spowodowało każdą stratę. Nieujawnione audyty i prywatne incydenty mogą być brakujące, podczas gdy zgłoszone liczby strat nie są idealnie porównywalne.

Badanie wspiera zatem ograniczone wnioski: historia audytu i zakres audytu to różne zmienne. Przeglądany inteligentny kontrakt nie automatycznie zapewnia tego samego zapewnienia dla aktualizacji, klucza uprzywilejowanego, front-endu, relayera, oracle, usługi w chmurze czy procesu reakcji na incydenty.

Dwa incydenty z sierpnia ilustrują tę różnicę na różne sposoby. Sieć ICON dostarcza bezpośredni przykład przeglądanego kodu, który zawiódł na granicy między dwoma kontrolami. Incydent aelf z sierpnia stanowi kontrastowy przypadek, ponieważ dostępne dowody audytowe nie mogą jeszcze być powiązane z jego zgłoszoną ścieżką czasową.

W exploicie powtórkowym sieci ICON z 27 sierpnia dwie części ścieżki wypłaty interpretowały tę samą wiadomość inaczej.

Według raportu pokontrolnego ICON Foundation z 30 sierpnia, kontrakt migracyjny używał wysokich bitów numeru seryjnego wiadomości wypłaty, aby zdecydować, czy jest on unikalny. Podpis kryptograficzny obejmował tylko niskie 256 bitów. Zmieniając niesigned wysokie bity, atakujący ponownie przesłał dwie prawidłowo podpisane wiadomości wypłaty 1492 razy w ciągu około 20 minut. ICON poinformował, że 1490 prób zakończyło się sukcesem.

Audytowana granica, którą ICON przeoczył

Powtórzenia uwolniły 119,866 miliona ICX i 531,600 bnUSD. W momencie raportu pokontrolnego, ICON oszacował potwierdzoną stratę netto na około 150,2 ETH oraz 31,204 USDC. Poinformował, że 531,600 bnUSD i 1,366 miliona SODA zostały odzyskane, a depozyty użytkowników, salda i pozycje nie zostały naruszone.

ICON stwierdził, że kontrakt migracyjny przeszedł zewnętrzny audyt i że wprowadzono zalecenia, w tym zmiany w tym samym obszarze. Dodał również, że odpowiednia logika przekaźnika została poddana szczegółowemu przeglądowi. Archiwum audytu SODAX zawiera osiem raportów dotyczących różnych komponentów, w tym audyt przekaźnika z listopada 2025 roku.

Jednak raport pokontrolny stwierdził, że dokładna niezgodność między sprawdzeniem unikalności a podpisaną wartością wykraczała poza te ustalenia. Odznaka na poziomie projektu nie mogła powiedzieć użytkownikowi, czy obie strony ścieżki wypłaty zgadzały się co do tego, co czyni wiadomość unikalną.

Oś czasu reakcji dodaje drugi rodzaj granicy. Pierwsze automatyczne powiadomienie ICON uruchomiło się o 02:08 UTC, około siedmiu minut po rozpoczęciu eksploatacji. Pracownicy rozpoczęli dochodzenie około 03:40, wstrzymali dotknięty kontrakt o 03:53 i zatrzymali sieć o 06:18:54.

ICON przypisał około 90-minutową lukę między pierwszym powiadomieniem a pełną reakcją na incydent dostosowaniu powiadomień. Klasa powiadomień generowała fałszywe pozytywy podczas niezwiązanych incydentów łączności i nie powiadomiła zespołu dyżurnego z wymaganą powagą. Fundacja zapowiedziała plan automatycznego wyzwalacza zamknięcia, niższe progi wyłączników awaryjnych oraz przegląd następczy skoncentrowany na unikalności wiadomości i zabezpieczeniach przed powtórzeniami.

Te kontrole nie zastępują audytu. Stanowią dowód na inne pytanie: gdy zapobieganie zawodzi, jak szybko wykrycie może stać się ograniczeniem?

aelf pokazuje, dlaczego zapewnienie musi być aktualne

aelf z sierpniowego incydentu testuje argument z innej strony. Jego publiczny zapis opisuje kompromis w czasie działania i kontrolowane odzyskiwanie, ale nie dostarcza wystarczających dowodów, aby umieścić ścieżkę wewnątrz lub na zewnątrz konkretnego audytu przedincydentowego.

Firma ogłosiła wstrzymanie sieci 18 sierpnia. W aktualizacji postępu z 26 sierpnia aelf poinformował, że nieautoryzowany inteligentny kontrakt mógł wykorzystać parametry transakcji do dostarczenia zakodowanych zestawów .NET i instrukcji do ścieżki wykonania węzła.

Provisional account powiązał incydent z lukami w kontrolach dla refleksji w czasie działania i dynamicznego ładowania, razem z słabą izolacją między wykonaniem kontraktu a wrażliwymi zasobami węzła lub infrastruktury. aelf zidentyfikował 155 powiązanych transakcji i pięć unikalnych zestawów ładunków z możliwościami, w tym wykonanie polecenia hosta, próbę komunikacji wychodzącej, dostęp do klucza węzła i rozpoznanie infrastruktury.

Zdolność nie jest tym samym co potwierdzona realizacja. aelf stwierdził, że ładunki nie udowodniły, że każda instalacja została uruchomiona, że każda docelowa tożsamość została uzyskana lub że wrażliwe dane opuściły jego systemy. Firma powiedziała, że rotuje klucze podpisowe i dane uwierzytelniające infrastruktury zgodnie z standardem potencjalnej ekspozycji.

Status publiczny pozostał tymczasowy 11 września: indeks bloga aelf nie zawierał żadnego elementu specyficznego dla incydentu opublikowanego po 26 sierpnia. Oświadczenie z 26 sierpnia zobowiązało do kolejnej aktualizacji i ostatecznego przeglądu.

Dokumentacja bezpieczeństwa aelf mówi, że jego blockchain i kontrakty tokenów ELF przeszły wiele audytów, w których nie zidentyfikowano problemów z bezpieczeństwem. Jednak dostępne strony nie łączą konkretnego raportu przedincydentowego z opisanym w sierpniu przebiegiem działania. Nazwanie incydentu pominięciem audytu lub awarią poza zakresem byłoby zatem wykraczające poza dowody.

Ta niepewność sama w sobie jest użyteczna. Historia audytu z datą może stać się odłączona od aktualnego kodu systemu, zależności i stanu operacyjnego. Użytkownicy potrzebują zapisu zapewnienia, który jest wersjonowany i wystarczająco szczegółowy, aby ujawnić tę różnicę.

Taki zapis powinien zawierać nazwę przeglądanej repozytorium i zatwierdzenie, wdrożone adresy, wykluczone komponenty, uprzywilejowane role i zależności. Powinien również rejestrować aktualizacje od czasu przeglądu, przechowywanie kluczy i rotację, izolację w czasie działania, zachowanie alertów i wyłączników oraz datowany status odzyskiwania, który oddziela potwierdzoną utratę od zamrożonej lub nierozwiązanej ekspozycji.

To nie zmniejsza wartości audytu. Czyni roszczenie proporcjonalnym do wykonanej pracy i łączy tę pracę z systemem działającym teraz.

Odznaka audytu nie może odpowiedzieć na pytanie, czy przeglądany artefakt, wdrożony system i maszyna, która reaguje na awarię, nadal dzielą tę samą granicę bezpieczeństwa.