6,8 miliarda dolarów ostrzeżenia: Większość ataków DeFi nie mieści się w zakresie audytu

Autor: Liam 'Akiba' Wright, cryptoslate

Skład: Chopper, Foresight News

W dziedzinie finansów zdecentralizowanych, "audytowany" często jest postrzegany jako gwarancja bezpieczeństwa całego projektu. W rzeczywistości audyt zazwyczaj obejmuje tylko określony punkt w czasie, wyznaczone kody, komponenty i wersje. Jakiekolwiek dodanie, usunięcie lub operacja poza tym zakresem może prowadzić do zupełnie innych wyników audytu.

Nowy artykuł preprintowy przedstawia konkretne liczby dotyczące tej luki. Firma bezpieczeństwa ack3 oraz badacze z Politechniki Czeskiej w Pradze przeanalizowali 135 incydentów bezpieczeństwa zgłoszonych w pierwszej połowie 2026 roku, które spowodowały straty sięgające 939,86 miliona dolarów. Odkryli, że 68 z tych incydentów miało rozpoznawalne publiczne zapisy audytów przed zdarzeniem.

W próbce 68 incydentów badacze sklasyfikowali 46 ścieżek ataku jako całkowicie poza jakimkolwiek zakresem audytu, 20 incydentów było objętych przynajmniej jednym zakresem audytu, a pozostałe 2 nie mogły być ocenione. Incydenty poza zakresem audytu stanowiły 67,6% całkowitej liczby incydentów, ale odpowiadały 94,4% całkowych strat zgłoszonych w raporcie.

Ten zdumiewający stosunek nie jest oceną skuteczności audytu ani dowodem na to, że ograniczenia zakresu audytu prowadzą do strat. Reprezentuje jedynie rozkład strat w wybranej próbie publicznych incydentów bezpieczeństwa. Dwa duże incydenty miały ogromny wpływ na dane: po wykluczeniu strat w wysokości 292 milionów dolarów z Kelp DAO i 285 milionów dolarów z Drift Protocol, w tej samej grupie audytowanych próbek, straty spowodowane atakami poza zakresem audytu spadły do 72,1%.

Nawet przy tych ograniczeniach, badanie ujawnia podstawowy problem zaufania do bezpieczeństwa: projekt może twierdzić, że przeszedł audyt, ale użytkownicy nie mogą wiedzieć, czy rzeczywisty działający system, przepływ funduszy oraz związane z tym środki kontrolne zostały poddane przeglądowi.

Prawdziwe znaczenie danych

Badanie ack3 obejmuje okres od 1 stycznia do 29 czerwca 2026 roku, w sumie 122 potwierdzone incydenty ataków oraz 13 podejrzanych incydentów. W całej próbce 35 incydentów nie miało zapisów audytowych, a 32 miały nieznaną historię audytu, obie te kategorie nie są uwzględnione w powyższej statystyce 68 incydentów.

W próbce 68 incydentów, incydenty poza zakresem audytu odpowiadały stratom w wysokości 680,97 miliona dolarów, a całkowite straty wyniosły 721,24 miliona dolarów, co prowadzi do uzyskania danych 94,4%. Po wykluczeniu Kelp DAO i Drift Protocol, straty poza zakresem audytu wyniosły 103,97 miliona dolarów, a całkowite straty 144,24 miliona dolarów, co stanowi 72,1%. Plik json z danymi może odtworzyć liczbę klasyfikacji incydentów i kwoty strat.

Etykieta "w zakresie audytu / poza zakresem audytu" jest oceną dokonaną przez badaczy na podstawie publicznych dowodów. Zespół badawczy przeglądał archiwa projektów i instytucji audytowych, aby znaleźć raporty audytowe sprzed ataku, porównując ostateczne ścieżki ataku z badanym kodem, wersjami oraz wykluczeniami audytu. Badanie to jest 6-stronicowym artykułem preprintowym, opracowanym we współpracy z wydawcą zbioru danych, a dwóch autorów należy do firmy audytowej ack3.

Badanie nie zawiera grupy kontrolnej, która nie została zaatakowana, ani nie statystyk dotyczących czasu narażenia różnych systemów na ryzyko. Dlatego nie można udowodnić, że audytowane protokoły są ogólnie bezpieczniejsze, nie można oszacować prawdopodobieństwa wystąpienia incydentów, ani potwierdzić, że "poza zakresem audytu" jest bezpośrednią przyczyną każdej straty. Niektóre niepublikowane audyty i prywatne incydenty mogą być pominięte, a zgłoszone dane o stratach mogą nie być w pełni porównywalne.

Dlatego badanie może jedynie wyciągnąć ograniczone wnioski: zapisy audytowe i zakres audytu to dwa niezależne wskaźniki. Audytowany inteligentny kontrakt nie oznacza, że aktualizacje kontraktu, klucze uprzywilejowane, interfejsy, przekaźniki, oracle, usługi w chmurze czy procedury reagowania na incydenty mogą uzyskać równą ochronę bezpieczeństwa.

Dwa incydenty z sierpnia potwierdzają tę różnicę z różnych perspektyw. Przypadek ICON Network wyraźnie pokazuje, że dwa fragmenty audytowanego kodu zawiodły na granicach dwóch etapów weryfikacji; natomiast sierpniowy incydent bezpieczeństwa aelf to inna sytuacja, w której istniejące dowody audytu nie mogą jeszcze powiązać ścieżki ataku z zakresem audytu przed zdarzeniem.

ICON Network: Przykład awarii na granicy audytu

W ataku powtórzeniowym ICON Network z 27 sierpnia, dwa moduły w łańcuchu wypłat miały różne interpretacje tej samej wiadomości.

Zgodnie z raportem z analizy po incydencie ICON Foundation: umowa migracyjna polegała na ocenie unikalności wiadomości na podstawie wyższych bitów numeru sekwencyjnego wiadomości wypłaty; jednak podpis cyfrowy obejmował tylko 256 niższych bitów numeru sekwencyjnego. Napastnik zmodyfikował wyższe bity, które nie były objęte weryfikacją podpisu, i w ciągu około 20 minut złożył 1492 razy dwie legalnie podpisane wiadomości wypłaty, z czego 1490 razy wywołanie zakończyło się sukcesem.

Ten atak powtórzeniowy uwolnił 119,866,000 ICX oraz 531,600 bnUSD. W momencie publikacji analizy, ICON potwierdził, że straty netto wyniosły około 150,2 ETH oraz 31,204 USDC. Fundacja stwierdziła, że 531,600 bnUSD oraz 1,366,000 SODA zostały odzyskane, a depozyty użytkowników, salda kont oraz pozycje nie zostały dotknięte.

ICON stwierdził, że ta umowa migracyjna przeszła audyt zewnętrzny i wdrożono zalecenia audytowe, w tym odpowiednie zmiany w obszarze tego samego modułu; odpowiednia logika przekaźnika również przeszła osobny audyt. Lista audytów dokumentacji deweloperskiej Sodax zawiera 8 raportów obejmujących różne komponenty, w tym raport audytu przekaźnika Sodax z listopada 2025 roku.

Jednak raport z analizy wyraźnie stwierdza, że logika weryfikacji unikalności i wartość weryfikacji podpisu nie były objęte zakresem odkryć audytowych. Prosta etykieta "audytowany" nie pozwala użytkownikom wiedzieć, czy standardy oceny "unikalności wiadomości" są spójne na obu końcach łańcucha wypłat.

Oś czasu reakcji ujawnia również inny rodzaj problemu granicznego. Pierwsze automatyczne powiadomienie ICON zostało wyzwolone o godzinie 02:08 UTC, około 7 minut po rozpoczęciu ataku. Pracownicy rozpoczęli dochodzenie około 03:40, a o 03:53 wstrzymali dotkniętą umowę, a o 06:18:54 wstrzymali cały łańcuch.

Od pierwszego powiadomienia do pełnego zarządzania kryzysowego minęło około 90 minut. ICON przypisuje to dostosowaniu mechanizmu alarmowego, ponieważ zasady powiadamiania w przeszłości generowały wiele fałszywych alarmów w przypadku problemów z łącznością sieciową, dlatego nie powiadomiono personelu dyżurnego z wysokim priorytetem. Fundacja planuje wdrożyć mechanizm automatycznego wyłączania, obniżyć próg awaryjny oraz przeprowadzić specjalny przegląd dotyczący unikalności wiadomości i ochrony przed powtórzeniami.

Te mechanizmy zarządzania ryzykiem nie mogą zastąpić audytu, ale odpowiadają na inne kluczowe pytanie: czy system może szybko wykrywać i izolować ryzyko, gdy środki zapobiegawcze zawodzą?

Użytkownicy wciąż muszą odpowiedzieć na kluczowe pytania dotyczące bezpieczeństwa

aelf: Ochrona bezpieczeństwa wymaga ciągłej aktualizacji

aelf w sierpniowym incydencie bezpieczeństwa potwierdza powyższe spostrzeżenia z innej perspektywy. Publiczne materiały opisują, że wystąpiło naruszenie w czasie działania oraz możliwe przywrócenie, ale istniejące dowody nie są wystarczające, aby określić, czy ścieżka ataku mieściła się w zakresie audytu przed zdarzeniem.

Oficjalne ogłoszenie projektu wyjaśnia: istnieje nieautoryzowany inteligentny kontrakt, który może wykorzystać parametry transakcji do wstrzyknięcia zakodowanego zestawu .NET oraz instrukcji do łańcucha wykonawczego węzła.

Wstępny raport dochodzeniowy przypisuje incydent do wad w weryfikacji refleksji w czasie działania oraz dynamicznego ładowania, a także niewystarczającej izolacji między środowiskiem wykonawczym kontraktu a węzłami wrażliwymi oraz zasobami infrastruktury. aelf zidentyfikował 155 powiązanych transakcji oraz 5 niezależnych zestawów ładunków, które mają zdolność do wykonywania poleceń na hoście, prób komunikacji zewnętrznej, dostępu do kluczy węzłów, rozpoznawania infrastruktury itp.

Posiadanie zdolności nie oznacza potwierdzenia, że wszystkie ładunki zostały pomyślnie wykonane, ani że napastnik uzyskał wszystkie dane uwierzytelniające celu, czy też doszło do wycieku wrażliwych danych. aelf stwierdził, że zgodnie z potencjalnymi standardami wycieku wymienił klucze podpisowe oraz dane uwierzytelniające infrastruktury.

Na dzień 11 września, ten wniosek pozostaje na etapie oceny. Blog na stronie aelf nie opublikował żadnych aktualizacji dotyczących tego incydentu po 26 sierpnia. Ogłoszenie z 26 sierpnia obiecało późniejsze publikacje aktualizacji oraz ostatecznego przeglądu.

aelf w dokumentacji dotyczącej bezpieczeństwa technicznego stwierdza, że jego blockchain oraz kontrakt tokena ELF przeszły wiele rund audytów, w których nie wykryto problemów z bezpieczeństwem. Jednak istniejąca publiczna strona nie może powiązać ścieżki działania ataku z jakimkolwiek raportem audytowym sprzed zdarzenia. Dlatego klasyfikacja incydentu jako niedopatrzenia audytowego lub awarii poza zakresem audytu brakuje wystarczających dowodów.

Ta niepewność sama w sobie ma znaczenie referencyjne. Raport audytowy z datą stempla czasowego stopniowo odchodzi od aktualnego kodu systemu, bibliotek zależnych oraz rzeczywistego stanu operacyjnego. Użytkownicy potrzebują zapisu bezpieczeństwa z wersją, aby odzwierciedlić tę różnicę.

Ten zapis bezpieczeństwa powinien zawierać: przeglądane repozytoria i wersje kodu, adresy wdrożonych kontraktów, wykluczone komponenty, role uprzywilejowane, biblioteki zależne; a także rejestrować aktualizacje kontraktów po zakończeniu audytu, mechanizmy zarządzania kluczami, strategie izolacji w czasie działania, mechanizmy alarmowe i awaryjne oraz stan odzyskiwania aktywów z datą stempla, rozróżniając potwierdzone straty, zamrożone aktywa oraz nierozwiązane ryzyka.

Nie neguje to wartości audytu, lecz sprawia, że promocja audytu i rzeczywiste działania są zgodne oraz powiązane z aktualnie działającym systemem.

Jedna etykieta audytowa nie może odpowiedzieć na pytanie: czy przeglądane komponenty, wdrożony system i mechanizmy reagowania na awarie pozostają w tym samym zakresie bezpieczeństwa?

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.